Why Start-Ups Fail
Why Start-Ups Fail
Waterfall isn't the best way to develop software, so why do so many startups use it as a business plan?
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
You’ve probably heard that a start-up’s chance of success is very low. There are many factors of why that happens. I want to illustrate this through the waterfall process that plagues many companies,.
The process we’re talking about looks like this:
- Vision – A startup founder usually comes up with an idea. In an established company it would be a VP product or similar. The idea is fuzzy, and is definitely not validated. Sometimes it’s a technical solution looking for a problem. But it’s there as the anchor for the entire process.
- Business case – Once we decide on the idea, we need to monetize it somehow, or explain why people (not just customers) would pay for the product. When we’re done with this phase we have some ideas (usually one), which will be the anchor for the next phase.
- Features roadmap – We know how we want to make money so we start making a list of everything we need in order for the idea to put money (any money – actual customer money, VC investment) in our pockets. Our feature list (or roadmap) is optimized to that business case – which let me remind you, didn’t go through too much validation so far.
- Design – Now that we know what to build, we need to architect a solution. Because the feature list is set in stone, the solution design is optimized to support those features. We’re now on the road for implementation.
- Build – The people who work with agile methodologies usually start their participation here. They iterate and get feedback, and maybe stir away, but since both roadmap and architecture are already set, they “play with their agile”within these limits. There’s a very small chance someone is brave enough to say “this doesn’t work, we need to go to square one”. The non-agile people just work according to plan. Of course they miss out on schedule and budget and remove features, but they are also go according to the preset track.
- Release – Finally we release the software, and find out if we were right or wrong.
What’s the Common Thread Here?
From a single vision, we’re locking the business case, roadmap, and execution.
Here’s the catch: Assuming everything is up to us (which it never is), we need to be right every time for the product to succeed. We need to be right on the vision, the solution, the design and the execution and not make any mistakes.
What’s the chance that we’re going to be right on every decision? Very slim. And every time were committing, we throw away options that otherwise might have been viable. Once we’re committed it’s all in, and usually on the wrong path.
Going down a single path, committing money and resources is why start-ups fail. Either that or they need to be very lucky.
Of course, this is true not just for start-ups. Unless you’ve changed the way you work, most companies work in this risky process as well.
Lean Startup has got the right idea: We need to validate our ideas through small and short experiments. We need to do those all the times and in every stage. That means we do not commit until we know why (Real Options). When we’re really sure about the business side, the architecture and technology, and not a minute sooner.
And for agile practitioners? If all your agile methods are restricted to the development team, it may already be too late. You are probably building the wrong thing spectacularly well.
Published at DZone with permission of Gil Zilberfeld , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.