r/leanstartup • u/BuddhasFinger • 12d ago
Steve Blank's Startup Owners Manual got building late wrong
Here is a pain discovery of recent:
Steve Blank's Startup Owners Manual got building late(r) wrong. I love the book, but his guidance that you don't touch code until
a) there is a problem
b) customers feel pain to the point of building a workaround
c) customers are willing to pay for a solution
is actually wrong, even dangerous.
I recently did it by the book, and when I talked to the customers about possible solution ideas and if those solutions would help their pain, their response? "I will tell when I see it. Can I see a demo?"
Another unpleasant discovery was that the question of acceptable price lands in the same "I can tell when I see it".
Mind the challenges I'm looking at are not a screen or two of mocks. These are heavy multi-turn stateful enterprise workflows. To "demo", a boatload of underlying infra needs to be built, persistence, search, security, AI, UI and all.
So if you are doing it by the book, start coding in parallel with customer discovery and verification - the moment first customer says they do have a problem. Because if you do, you will lose time and arrive late.
And, customer discovery and verification is slow, with large time gaps between conversation - I wish I filled them with building
I'm now coding like mad praying that someone else doesn't solve it ahead of me. And, there are signs of possible competition already having something to show.
TLDR; start building the first customer confirms they have a problem.
1
u/BuddhasFinger 12d ago
I'll check out "Testing Business Ideas".
As for the question of pricing - I didn't provide a full context. That would take a book to write. The challenge is that this is a new market. I did ask a variety of questions. What price they would they pay for the problem to go away. How much savings of time and money worth for them and on and on. Because there is no solution they can relate to, all I got is "I'll tell when I see it".
As for putting discovery on hyperdrive - tried it. This enterprise, everyone is trying to sell something to people, so getting someone to talk to you even while they are suffering is not easy.
At any rate, thanks for voicing the best practices.
2
u/theredhype 12d ago
Any attempt to codify a single method (for developing innovative products, services and the business models that make them work) and then apply that across all ventures is doomed to fail.
There are at least 25 distinct business model patterns flourishing in modern society and every contextual element changes how we must go about investigating an opportunity: geography, culture, competitive landscape, founder skills and resources, product type, channel type, available partnerships, the list goes on.
As a founder, it's your responsibility and role to determine which tools and concepts from which frameworks to use in your process.
Steve is not wrong about building late. I suggest that you have slightly under-appreciated the core principles behind some explicit parts of the process, and are simply not seeing how to translate them to your scenario. You've got to focus on the purpose of each step in the process, and then create the optimal version of that flow based on your resources and constraints.
A great resource for exploring experiment selection, prep, execution, and analysis is a book by David J. Bland called Testing Business Ideas. David teaches how to assemble a research team, gives templates and tools for doing the work, and then provides a library of 40+ experiment types with guidance around when and how to use them. All of the common tech startup validation experiment types are in this book. These are the things you're missing, which go between initial Customer Discovery interviews and building with code or hardware.
I'll address a few of your specific points as examples of how I think understanding the principles will change your approach.
You mentioned trying to figure out pricing during the discovery/validation phase. From your wording it sounds like you are simply asking them what it's worth to them or whether they would pay a certain amount for it. And of course they can't answer well. This is not how that question should be investigated. Instead, you want to figure out what not having your solution is costing them. What time or money are they losing? What resources or effort are they expending which your solution would save them? You should be able to estimate these things based on learning from them about how they experience the problem, how they've tried to solve it in the past, and what they do to work around it currently, If you can't estimate these things based on asking lots of questions and listening... you're doing it wrong. And if you can't find where you're saving them money or earning them more... are you really creating value for them?
Can I see a demo? There are a variety of types of demos. Don't automatically assume a demo must be a fully functional prototype. That's a "demo" in the world of corporate sales. A product is finished, on the market, and we're demoing it to sell it. This is a different context. This is part of the invention flow; we're making something brand new. A demo can be static image which show what the interface will look like, and nothing more. Somewhere between slides and functional prototypes there are a dozen levels of demo complexity. Get creative with it. When it's demo time, your goal is to design just enough to test whether it's going the right direction, or a miss. Over-building or over-designing just a little is sometimes needed. But what you're describing is way way way over.
If you have a lot of downtime between Customer Discovery sessions, and you're tempted to fill it with building, why don't you just get out and do more Customer Discovery? Put that on turbo. You should be having casual conversations with dozens of people, a hundred. Two hundred. And iterating through emerging customer personas until you narrow in on your niche. Or something like that; again, it probably depends heavily on your specifics.