- •Introduction
- •And Cue the Lean Startup
- •Chapter 2
- •Vision, Values, and Culture
- •Vision and Values
- •Version 1
- •Version 2
- •Version 3
- •Over the Horizon: a Framework
- •Personas: Create a Fake Customer
- •If You Get Nothing Else from This Chapter
- •Chapter 4 Wading in the Value Stream
- •Value Assumed Before Deep Customer Interaction
- •Value Validated After Deep Customer Interaction
- •Value-Stream Discovery
- •Chapter 5 Diving In
- •Chapter 6
- •Viability Experiments
- •Crowd-Funding Test
- •Viability
- •Chapter 8 The Valley of Death
- •Minimum Viable Product
- •Your First mvp
- •Buggy Product
- •Unfinished Product
- •Stolen Product
- •Beginning of the End or End of the Beginning?
- •An mvp Takes Guts
- •Thinking Through Viability
- •Mvp Testing
- •Innovate the Funnel
- •Selling to Businesses
- •Marketing
- •Passionate
- •Satisfied
- •Hopeful
- •Convinced
- •Trusting
- •Intrigued
- •Brant cooper
- •Patrick vlaskovits
Buggy Product
Although perhaps reasonable at first glance, these fears are largely unfounded. The suggestion to release a product earlier rather than later doesn’t mean you should release an unusable product.
Unfinished Product
Investor Paul Graham says: “[launch] when there is at least some set of users who would be excited to hear about it, because they can now do something they couldn’t do before.”2 You don’t truly know when your users will be excited until you try to excite them. Launch doesn’t mean release it to the world and make hay about it. It means get it in front of early users to understand whether you have uncovered the quantum of utility or whether you are at least on the right path.
Entrepreneurs often swing from one extreme to another. If they focus on minimal they forget viable and if they focus on viable, they don’t know when to stop building.3
If you have a controlled, early release that turns out to not be viable, it’s easier to retool compared to building until you think it’s done, whatever that means.
This is the point of iteration. You make a reasonable stab, otherwise known as a hypothesis, also known as an educated guess. It’s not exactly right. Some customers seem to be kicking the tires but in a rather lackluster fashion. Make changes and try again. If, on the other hand, you keep building features, delaying your release—and then the product isn’t exactly right—not only did you lose time finding that out, but it’s harder to know what you got right and what you didn’t!
You want to understand what product functionality produces your must-have use case, as this provides the foundation of your product moving forward. The must-have use case is the one you must not destroy as you continue to build out the product and bring on additional market segments.
Once you are able to provide the utility that excites the user, you will find that the early adopters are willing to put up with glitches. This is the classic definition of the early adopter. As thought leaders in their space, or as social leaders that others look to for new products, they tend to forgive product issues as long as the core benefit addresses their pain or passion.
The great irony to the idea that customers will never return to a faulty product is that the entrepreneurs who espouse this philosophy stake their entire business on their personal belief that their fully fleshed out product isn’t somehow faulty. But there’s always one more bug to fix, one more design element to clean up, one more feature to add. You know this because you don’t fire your engineers and designers after release. You need them to fix bugs, clean up faults, add features.
But I thought you said the product is done!
Entrepreneurs often say you can’t launch early, because the product isn’t done, but once it has been declared done, they then think the only thing left to do is to tell the world as quickly as possible. Done only really means the date they chose months ago has arrived. Because the day arrives, it must mean it’s time to launch to full fanfare, pray to the media gods that TechCrunch highlights the product on its front page; that the Wall Street Journal declares you a visionary. We must release because it was in the plan!
After all, these founders believe, the only thing missing is product buzz.
What about beta programs, you ask? Most beta programs are part of a prescheduled launch process, primarily used to fix major bugs.
Beta used to represent a feature-complete product. The term has evolved over time to the point that in some organizations, the beta release is in essence the final release, because the developers recognize that it will continue to evolve over time. This really is the essence of most software these days, so beta ceases to have real meaning. Google’s Gmail was in beta for five years, way beyond product-market fit.
If you are not going to release early, how do you know when the product is done? What if you’re wrong? Building a big product does not make success more likely. Remember the feature threshold; the winner isn’t the one with the most features.
