Business Model Canvas
I’m not going to dive too deep into the Business Model Canvas, Srategyzer, the creators have this very well explained here. Their 2 minute video will get you up to speed. As you validate assumptions you will update the Business Model Canvas with new information and new questions and assumptions. I will refer to the Business Model Canvas a few more times in this post.
To start, please read my experiences at a Lean Startup Machine bootcamp I attended a couple of years ago: Failure Feels Good. Otherwise, here are the highlights:
“We should have been focused on the customer by listening to their problems, then finding ways to solve them, not starting with the solution. We had a hammer and we were asking if anyone had a nail they needed hammered.”
“Once we tossed out the list of questions and the time limit per interview, and just talked, we learned so much more. Not only did we learn more about the customer, we learned about problems we didn’t know existed…Go have a coffee or beer with your potential customer and just sit and talk to them, you might be surprised in what you learn.”
“Writers often say you have to kill your darlings, meaning you have to be willing to kill an idea no matter how emotionally invested you are.”
Simple Lesson: Ask Open Ended Questions
During the customer development process, be wary of asking closed ended questions, which will develop confirmation bias. The best thing you can do is try to invalidate your assumptions. Failing to invalidate means you’re on to something interesting.
As engineers who had never done this before, talking to people didn’t seem like real work. Real work was coding. But in reality, 20 hours of great interviews probably would’ve saved us an accrued 18 months of building useless stuff. – Peter Reinhardt, Co-founder, CEO @ Segment
Simple Lesson: Ask Why 5 Times
When doing customer development interviews be ready to ask the “5 Whys“. Asking “Why” 5 times will often get you to the root of the problem and you can build the right solution to the right problem. My team won a hackathon mainly because we kept asking why the problem was a problem. It went like this:
- Us: “We want to build a market place for Kenyan farmers to sell their crops at a fair price”
- NGO Mentor: “That’s great, but Kenyan farmers barely have enough crops to feed their families let alone sell to market”
- Us: “Why don’t they have enough crops to feed their families?”
- NGO Mentor: “Their crop yields are too low”
- Us: “Why are the crop yields are too low?”
- NGO Mentor: “We don’t know, we’re trying to find that out. We did a study to find out”
- Us: “Can we have the data from the study?”
- NGO Mentor: “No, it’s on damaged paper in boxes somewhere. Also the data was collected in different units of measurement”
- Us: “So Kenyan farmers have a crop yield problem and your NGO has a data collection problem?”
- NGO Mentor: “Yes”
Validating The Value Hypothesis
The biggest place I’ve seen early-stage startups fall down is not solving a problem worth solving, meaning someone won’t give you money to solve that problem. Maybe there is a problem, but it’s not a pain, its a nice to have. A business without revenue is just a hobby. The best way to generate revenue is to solve a customers’ pain that has urgency.
I’ve covered this idea in some depth in this post: Is Your Problem Worth Solving? But this concept comes from Eric Ries’ startup bible The Lean Startup. At this stage, the key step is to validate the Value Hypothesis, which “tests whether a product or service really delivers value to customers once they’re using it.”
The basic minimum requirement for an early-stage startup to validate the Value Hypothesis is to:
- Solve a problem.
- Solve a problem worth solving, meaning someone will give you money for your solution. If you can’t validate with a customer that you creating significant value, you shouldn’t start building anything.
- Have the right solution to the problem. Heads up, you will most likely build the wrong thing the first time around.
- Build a Minimal Viable Product to test hypothesis of points 2 and 3. Get that MVP into potential customers’ hands to test.
“Nothing else you do will matter if you are not making something people want. You can be the best spokesperson, the best fundraiser, the best programmer, but if you aren’t building a product that satisfies a real need, you’ll never succeed.” – Jessica Livingston, co-founder of Y Combinator
“Because getting a product in the hands of users is a top priority, even great engineers will intentionally take shortcuts and accumulate technical debt in order to launch sooner.” – Coding VC
“Most startup failures were caused by building the wrong product, or lacking strong sales skills, or not having a viable business model. The presence or absence of amazing engineers was rarely a factor.” – Coding VC
Your goal, meaning validating the Value Hypothesis is to have customers tell you to shut up, build the product, and take their money.
MVP is NOT a Cheaper Product
Instead of reading The Lean Startup book right now, as a stop gap, check out this blog post: Your ultimate guide to Minimum Viable Product. It summaries most of the same concepts, specifically: The Business Model Canvas, Customer Development, and building an MVP.
Smoke tests are great tools to test interest in a problem or solution, but should not be confused as a replacement for an MVP. An MVP is a minimal solution that delivers the value of the full product, not a gauge of interest. Examples of smoke tests are:
- Landing pages
- Explainer videos
- Communities such as blogs or social media groups.
Another misconception is an MVP is just a cheaper version or piece of the full version of the product. Again, the goal of the MVP is to deliver the value of the product is the simplest way possible, even if it’s manual. Steve Blank explains this further:
The team confused the goal of the MVP, (seeing if they could find a delighted farmer who would pay for the data) with the process of getting to the goal. They had the right goal but the wrong MVP to test it. Here’s why.
The teams’ hypothesis was that they could deliver actionable data that farmers would pay for. Period. Since the startup defined itself as a data services company, at the end of the day, the farmer couldn’t care less whether the data came from satellites, airplanes, drones, or magic as long as they had timely information. – Steve Blank
- Prototyping: InVision
- Learn to code: Codecademy
- Book: The Lean Startup, by Eric Ries
- Jessica Livingston’s Pretty Complete List on How Not to Fail
- Why Startup Technical Diligence is a Waste of Time
- Your ultimate guide to Minimum Viable Product
- An MVP is not a Cheaper Product its About Smart Learning