Waterfall development: What is it?

Waterfall development is just a step-by-step process that says marketing rights are requirements of what the product should do. Engineering takes that and translates that into features. Engineering then designs the product. Either code it or build the hardware.

They test it and maintain it and this is kind of a waterfall life cycle step by step. But if you really look at this, there’s an implicit fallacy that no one ever noticed for 40 years. To write the requirements and do the design, assumes on day one you know the problem or need the customer has.

Assuming you understand the customers’ needs

Let me say it again, waterfall development assumes you understand the customer problem and need on day one. Now in a large company with existing customers, existing products, existing sales channels, you know what, this might actually be true but in most startups, all you have is the founder’s vision and what you tend to do in a startup is confuse a faith-based vision with customers facts about problems and needs and what happens?

It bears tremendous risks

The consequence of assuming you know the customer problem means you assume you know every possible feature to ship on day one. So therefore you shut the door and you start implementing and instead of just implementing a piece at a time, you actually implement every possible feature you could think about for version 1.0. The irony is that we now know somewhere between 85 and 90% of most software product features are unwanted and unneeded by customers. That’s an enormous amount of waste of time and money that ends up on the floor.

We now know that waterfall and product management execution on two knowns is just kind of the wrong way to approach it in a startup.

It makes all the sense in the world in a large company.