When your Minimum Viable Product (MVP) is successfully released, you can still screw things up. Here’s how to avoid squandering your MVP and messing up your full product.
The best possible start
Let’s paint a picture where your startup has done everything right, from concept through first release.
You identified a customer problem—a need—and envisioned a novel product solution. You pared your idea down to the essentials that serve an initial target user group, and judiciously scoped a Minimum Viable Product (MVP).
Quickly and nimbly, your team designed and built a spartan but pleasing-and-effective version of the product. You identified how to measure the success of the MVP (i.e., how to determine whether your solution sufficiently meets the user need). Your team releases the MVP to your initial users without incident.
All of the above is difficult enough to do well, but let’s take it one further: your proof-of-concept MVP passes the big test with users!
So, from concept to validation, you have relatively quickly confirmed that your core idea for addressing a customer need is a good one, and that the product is worth building on.
Everything is great. But it’s still pretty easy to screw up from here.
What’s NOT a screw-up
Let’s take a step back and imagine another outcome.
What if the released MVP showed that your product doesn’t effectively solve you users’ problem? That’s not a screw-up. That’s the reason why you went the MVP route to begin with; if the idea was going to fail, you want to fail quickly and cheaply.
But again, that’s not your story. Your core product is effective, and clearly worth moving forward with.
What’s left to screw up?
Ways to screw up your MVP, post-release
1. You don’t fully leverage your MVP as the experiment it is
Even if your main focus was to confirm market viability, there is still a bunch more you can learn from your MVP and its users. Test deeper.
Your measurements met your success thresholds, sure, but what else can they tell you? What else could you measure? How exactly do your users use the product, and how does that map to your expectations? What do your users have the most trouble with? How do they feel about the current product and its potential? What features and enhancements do they say they want the most? What do potential paying customers care about vs. what free-version users do? Etc.
Wring all the knowledge you can out of your MVP while it’s still active.
2. You rest on your laurels, or simply wait too long
The next big step after validating your core idea is to move toward developing your full product.
Don’t wait
If you built your MVP in a not-really-production-ready fashion—which it often makes sense to do, to facilitate cheap rapid development—then it will likely be obvious to you that you need to move quickly to replace it with the real product.
If, however, your MVP was developed in a production-ready fashion and is a suitable foundation to build upon immediately, then, ironically, you’re a little more likely to get complacent and put it off.
Either way, waiting too long to follow up on your MVP is a mistake. It was an experiment of its time, and its lessons get staler and less reliable the farther it gets in the rearview. Planning an MVP effort from the start should include time and resources to immediately follow up on the result.
Don’t stay minimal
Also, don’t lose your way after your MVP test. The lesson of the MVP process thus far wasn’t that the narrowest of core functionality is all you need, indefinitely. Just because you were able to eliminate a bunch of potential features and enhancements from your successful MVP doesn’t mean those features aren’t good, or even business-critical. They just weren’t essential to proving out market viability in your MVP experiment.
Your early adopters were likely only a subset of your target user base; your product may require additional features and smoother edges to satisfy the next set of users. (The early adopters won’t have infinite patience, either).
Your product won’t remain viable for long with just the minimum set of features. (Just checking, if I’d written “Your P won’t stay V if is remains M for too long”, would you have understood what I meant?)
3. You move forward with your head down
You had a ton of ideas that didn’t make it into the MVP. You made a prioritized list of all the features and enhancements that you still want and need to do.
This is your vision for the full product. Your MVP tested the waters. Now that you can dive in, how do you proceed?
Don’t stubbornly stick to your roadmap
Even before your MVP was released, you probably had a well-thought-out roadmap of future features and enhancements to pursue.
But no matter how good your roadmap is, it’s going to be at least a little wrong.
Don’t work on the full product with your head down. Listen to and observe your users, and observe the realities of the market as it’s playing out with your MVP.
Listening and observing will:
- tell you what features you should prioritize,
- show you what needs to be redesigned for usability,
- guide you toward promising revenue streams and away from bad ones,
- inform you as to how your users view your product vs. similar existing products,
- inspire important features that aren’t already on your list,
- and eventually make you realize that some of the features on your list don’t need to be.
Keep iterating
Even though your MVP experiment is behind you, you should continue to apply a similar philosophy to the rest of the product lifecycle.
Keep applying a build–measure–learn approach. Adding a new feature? Get it to market quickly, get feedback, then develop it further or fix it if it’s not effective.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
BetaTesting Blog 