Ditch the Minimal Viable Product (Do This Instead)
Everyday I hear startup companies launch their “Minimal Viable Product” (MVP for short).
While there’s been many debates on how an MVP should function, here’s why it’s largely flawed…
The Minimal Viable Product often focuses on the wrong thing… the product!
Here’s a quick reminder: No one (aside from the team), cares about the product
So what do they care about? The problem or pain it solves for them.
What to Do Before the Minimum Viable Product
Before writing a single line of code, or digging too much into wireframes, mockups, youtube videos, or anything else, you need to setup a Minimal Viable Pain.
In other words: What is the problem you think your solution is going to solve?
In JTD’s terms: What is your target customer going to “hire” your product to do.
Can you validate this is actually a pain?
From this, you develop your minimum viable pain. Then you can do customer research to validate whether that’s an actual pain.
The benefit of starting with a minimum viable pain is that it doesn’t require any technical chops, AND forces you to focus on what matters: The pain you’re solving. All that’s needed is persistence, curiosity, the ability to ask questions (mainly “Tell me more”), and the ability to google search + send emails or calls.
Let’s run through an example, and compare the two (Product vs Pain):
A startup team has an idea to help restaurant owners bring in more local traffic, but curating a list of restaurant goers into the area, and sending them push notifications when a special is going on near them.
Here’s how the two would typically approach this:
Typical Product based “MVP”:
What they want to test: Will owners and users use the app? Do they find it valuable?
They build a wire frame, sit down with restaurant owners, and ask them questions around functionality, usage, what they feel is “missing”. They learn a lot, and ship the product in “beta”. Restaurant owners say “it’s great”, but none of them want to pay for it. Users say the app looks great, but if there are not restaurants on board, it’s meaningless. The company tries to offer it restaurants for free (to then get consumers), and they get a few dozen “beta customers” (ie not paying in any way). The app drives 1–2 patrons (maybe), the startup never gets traction, and they go under. They chalk it up to the “startup grind”, get celebratory “failure beers”, and look for the next one.
The Minimum Viable Pain Approach:
What they want to learn: How are owners currently solving the pain of getting more customers in the door?
Instead of building anything, they email 1,000 restaurant owners, asking them what’s been the biggest barrier to getting more customers in the door. They tell the owner they have nothing to sell (which is true…no product!), and they want to learn. They might even make a report and the pain points across different owners and share it with anyone who participates (to encourage responses). From the 1,000 emails, 100 respond. The team then asks to jump on a phone call or in person meeting to learn more. They then ask the owner questions like: What tools do they use? Where do they feel helpless? What tool do they “wish” existed? What’s been the best promo they ever ran? They learn that they best promos occur when they do JV deals with nearby businesses (for example: They give a $10 off coupon to their famous BBQ ribs to every customer who buys a big screen TV at the nearby business). So you begin to look at a solution that connects business to help them with cross promos.
In the MVPain approach, they want to learn about the pain, and the market, before touching anything that deals with the product.
This approach causes the founding team to relentlessly focus on the pain they want to solve in the world. They helps them build a better product sooner. It helps them understand how to sell and market. It helps them understand how to support and serve these customers.
In short: Ditch the “product” MVP until you’ve been able to validate your minimum viable pain. THEN build your product to test, and get feedback, once you know that your startup is moving in the right direction. This dramatically reduces the risk (especially important for first time founders and founding teams) for the new venture, because once you know the pain exists… you know someone will solve it. Now it’s time to bet on you and your team to solve it.
Written by David Cristello, Founder & CEO of Jetpack Workflow. I don’t have a special email list, course, book, anything to sell. If you enjoy the post, leave a comment, share it. If you completely disagree, leave a comment, then share it with other people who disagree ;)