Lesson: Customer Discovery Primer with Steve Blank

Step #3 Erroneous Process: Don’t confuse a faith-based vision with customer facts

What did we use to believe on how you physically build a startup? What was the process we used? We used to build startups by managing processes. We said, "Well hey, we understand how to build products." We built them exactly like we built them in large companies. We hire product managers, and we do something called waterfall engineering, which I'll explain in a second which basically are step by step by step. In fact, what we used to do is we used to draw this diagram on napkins. We used to say, "Well you come up on a concept then you raise some seed funding and then you go into product development, and then you have alpha test, beta test, and first customership. What could be wrong with that? In fact for 30-40 years this was the canonical model for how to build startups and we'd say marketing, well, we understand. While engineering is developing the product, marketing is creating all the marketing communications material, hiring a PR agency, and creating early buzz and then from marketing the world's most fun job was have the party. You get to create demand by having a launch event and you think about branding and your job really was to create end-user demand and drive it into the potential sales channel. For sales, what that meant is unless the VP of Sales was the founder you tended to hire them around the time engineering were saying, "We're in alpha and beta test." And they we're going out and starting to hire their first sale staff and they were looking at your 5-year revenue plan and since it obviously came from a burning bush and it was the word of God they were just going to execute that plan. Why? Because it's said so and you said so and if you had investors they said so. There might not be any facts behind it but there it was. It was the spreadsheet. And so they were building the sales organization so again and at first customership, if marketing was going to drive demand they were just going to have a sales curve that took off because the revenue plan said so. The next piece was the Biz Dev. In business development used to mean the group that put together all the deals to create the whole product. The whole product meant startups just because of their size are incapable of creating all the features and services, etc., that a mainstream customer might need. So why don't we hire business development people to do partnerships. So at first customership we could look like a large company for mainstream customers. The only fallacy in this is that you assume that your first customers are going to be in the mainstream. It turns up for most startups your first customers are actually crazy people like you and so therefore creating this entire cloud of deals are actually useful a year after first customership but in fact just get in your way on day one. The other piece is engineering, and engineering--how simple could that be? It was understood. We did exactly what we did in the large corporations. You wrote a market requirements document then engineering shut their doors, rolled up their sleeves, and went into waterfall engineering, which we'll describe a little later. You hired a QA department then at the end finally when it was all done you hired a tech pubs department and all the products were ready to go in version 1.0. All the features at one time at first customership. And this for 30 or 40 years was the way we thought about startups. There can be no other way. This is how we manage the process. We now know this was just simply wrong and I'll explain to you what we're going to do instead.

If you remember I said engineering was doing waterfall development. Waterfall development is just a step by step process that says marketing writesrequirements of what the product should do. Engineering takes that and translates that into features. Engineering then designs the product. Either codes it or builds the hardware. They test it and they 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. 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. 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.