Except:
If it were as easy as that, not almost all of them would fail, would they?
Here is a little story:
A start-up team wants to found an enterprise. Based on an APP, it is supposed to realize a profitable business. There is an industrious team and an intensely discussed idea, and the persons involved have more than enough enthusiasm. They are all prepared to really get under way and accept material hardships. Even nights spent working and, if necessary, postponing or even sacrificing goals of life are accepted.
Accidentally, I get involved. They asked for my help because they feel the project has come to a dead end, yet none of the parties concerned is willing to admit it. After only a few sessions, I discover that the project is off course. The team is already in the middle of implementation, which is especially painful.
During my long life, I already witnessed quite a few founders who ran aground – in the truest sense of the word. Consequently, I now have a lot of responsibility. Yet at that moment, I cannot life up to said responsibility, because the founders are trapped in their own ideas and no longer willing or able to listen. It might well be understandable that they no longer wish to hear bad news.
In this case, I give a warning and leave. And a few months later, I hear that they have “run aground”. This is why I will now give founders a few pieces of general advice.
First advice:
You cannot do it without a blueprint
What are you supposed to do in a project if you discover that there is no “shared direction” in a team? Or even worse: if every one of them has his/her own idea of what they want to achieve?
I would recommend in such a situation that you immediately stop implementing anything and go back to the beginning. In other words: return to the phase of requirement engineering. It will certainly be painful, but it is the only way to save the project. As a consolation, you can remember that you can later benefit from all the experience.
But this time, it must be a modern, agile, empathic and educational requirement engineering! When defining the requirements for new and innovative solutions, you will have to “experimentally learn a technical situation”. If you want to succeed in innovation, you have to ask the right questions. And before you can ask them, you have to find them. Which is not at all easy.
Only after having finished this, you can start with defining your requirement. And only after that, you can think about solutions. You will find solutions by dividing the goal into the “right” user stories. You want to start with one of those and then analyse the underlying use case. They can be analysed and described. But, please, use the “wisdom of the masses”, rather than the “simple-mindedness of the individual person”. Especially when we are talking the future and innovation!
“Learning the market” is only possible if you use “technological empathy”. Yet we have to know the market. After all, it is where we want to sell and use the product. Especially the market of the future must be discovered through trial-and-error and experiments. Against the dogmatic brain concepts of an individual person. This is how you want to keep learning at all times. Using an honest and optimal discourse: open and agile.
If you forget this important initial work, you will program (or build) things nobody wants to buy. Whatever the team thinks will then revolve around a product that is questionable, at least on the market and that – with its technological and other problems – will detract from the main goal and eat up all the combined energy of the team.
The failure of the product is often delayed through missing functionality. Allegedly, all you have to do is even more programming, then the success will come. This is a misconception. When those seemingly so important functions are finally available, nothing changes for the better. The failure will then be attributed to poor sales and marketing. All you need is a few millions for sales and marketing …which you will never get, because there is no potential sponsor you can convince with the already existing results.
Scenarios like these will always happen when the “start-up” has no valid and flexible blueprint to start with. You have no shared interest you actually live up to and consequently you cannot convince anybody. So what you need is a blueprint. In former times, the blueprint was called “specification sheet”. As opposed to the specification sheet, however, the blueprint only specifies the essentials. And it remains active.
The word “requirement engineering” will easily give you the wrong ideas. Just like the term “specification sheet” is not modern, especially if it is understood as following the idea of the “V- model”. Modern “specification sheets” will have to be agile and improve iteratively and incrementally!
If you have a small but nice blueprint, you can test it on the market. It is easy to come up with a good blueprint. It will develop a life of its own and therefore become more and more resistent. Mind you, I would not wish you to misunderstand my argument in favour of the blueprint. I definitely would not wish to speak up in favour of the antiquated waterfall model.
On the contrary: the implementation, too, must begin at an early stage. But only with a simple and important, perhaps extremely small, user story following the blueprint. With a little luck, you can perhaps quickly gain the first “quick win”, which will carry you towards a successful future.
Consequently, founding an enterprise is a linked tightrope walk in many dimensions.
Here are some more recommendations for start-ups:
Find the right target groups
User software (like many other products), if seen exemplarily, will always have at least two target groups – the “technological department” and the users. Incidentally, that is also the difference between user software and purely technological software development, such as the construction of a compiler.
The technological department wants to achieve a simplification and improvement of the necessary processes with the product. The user is supposed to accept this solution. The product must give him a noticeable help. He can do a better job in an agreeable way.
Business Case
It is of central importance. We need a story. If you found the right target groups and have a nice blueprint, then you can develop the business case. You want to wrap it in a good, even a fascinating story. You want to fascinate potential partners, possible sales and marketing routes, multipliers and others. And then you can approach all the many chances the market offers.
Technology
Only after you have a really good blueprint (perhaps supported by the Oldie Rapper vulgo called „dummies”), only after you made the surface and the functions “understandable”, only after you determined the target groups and the business case, only after your prototypes have shown individual functions does it make sense to build the “King Version”. This “King Version” will then have to be developed quickly and goal-orientedy. Directly to the point, without much ado.
And then the agile tire can start rotating. The main purpose of such a “King Version” is to learn through and with it – on all levels. And the idea to advertise the product. Perfection is not important. Developers and engineers have to be careful, because they often think in terms of technology far too soon. That is something you can do later, after knowing what the evolution will actually accept.
Design
You cannot be too early with picking a logo. It will become the symbol of the team and send a message. As a shared team symbol. Consequently, the entire team should be consulted when the logo is determined.
When trying to find a design or a pattern or prototype, you should orientate yourself towards modern applications. Images and pictures will play an important role with the surfaces of the future. Beauty can do no harm, but is only of secondary importance. The product message is the most important thing. This will also be helpful for the founders when they have to coordinate their constructs.
Financing
More often than not, founders think about the financing far too soon. If I want financing, I first have to have something to offer. Meaning more than a business plan – which mostly is no more than a poor profession of faith. I need all the things that have been written down: the blueprint, the business case, the pattern, a beautiful design – all those things have to transport an idea and fascinate the people. Consequently, external money cannot be expected before you build the “King Version”. And that, too, is rather hard – as a general rule, only special friends will help in this kind of situation.
And above all: you have to be a strong team. VCs, SCs, federal financing, but also partner enterprises or private investors are less interested in your actual product. For them, the business case, the story, and above all, the team, are important. Incidentally, a team is only a strong team if the members themselves are truly and still realistically convinced that their product is top quality.
General Notes
There is no “stroke of genius” when it comes to ideas. Such a concept is and has always been a fairy tale. A stroke of genius is a dream which will only too quickly become a nightmare. Visions will often become hallucinations.
The success of start-ups and innovative founders has many parents. Developing a successful product means hard work. The path includes many setbacks and errors. You cannot force success. You just have to try and create the ideal environment for it to come one day.
Actually, it might even make sense – especially if you cannot operate with cost-covering turnover from the outset – to pave the way through the purgatory of a “Business Plan Contest”. As a general rule, you can benefit hugely from the experience. Finding out that a project is not realistic, too, is of huge value. It saves a lot of money and time. Taking part in such a contest can also help to create the “right” networks and find the “right” mentors.
But above all!
A start-up is not an elegant way towards self-actualization. Instead, it is a very risky and massive challenge. What you need is an enthusiastic team where every member is prepared to accept the task and open for change. If this is not the case, you should keep your distance. Because if founding your enterprise were as easy as some seem to think, we would not see so many founders, even in the IKT sector and the world of elegant APPs, ending as a failure.
RMD
(Translated by EG)
P.S.
In this article, I related my personal ideas based on my individual experiences. They do not claim to be the one and only truth. I believe that every founding process is different from the next and they all have their individual stories.
As I see it, there is no general cooking recipe for “successful” founding. However, if you follow my description, you might actually succeed. Whereas you can assume you will fail if you try a different approach!
P.S.1
About the picture: It is from 1808 and titled “Admiralty carriage mount for a British 18-pounder carronade”.
Source: Scanned from Chappelle, Howard I., The History of the American Sailing Navy: The Ships and Their Development, New York: W. W. Norton and Company, Inc., 1949, ISBN 1-56852-222-3, Plate VII, facing p. 152.
Unattributed, apparently from U.S. National Archives
Loading ...