So what happens after your minimum viable product (MVP) is completed?
Game on.
This is where the real fun begins, because now you have a sellable product. So the first thing you want to do is… sell it.
Selling Your MVP
Some companies look at a minimum viable product and say, “We can’t sell that. It’s nowhere near what we expected yet.”
But you know what? They’d be wrong. And all you’d have to do to prove it to them is point at that middle word in MVP: viable.
That’s right, your MVP is a minimum viable product. That means it provides a value that someone – anyone – is willing to use and pay for.
In the Harvard Business Review, Building a Minimum Viable Product? You’re Probably Doing it Wrong, two types of MVPs are discussed: validating and invalidating. A validating MVP sells the idea by producing a watered down or flawed version of a final product. If it succeeds, it validates the idea. But if it fails, you’re not sure whether it was because the idea was wrong or the product simply wasn’t good enough. Many companies assume the latter, and end up chasing the wrong solution to make it “better.”
An invalidating MVP takes a smaller bit of functionality and produces a better product. If it succeeds, you have a winner, although it doesn’t necessarily prove your full-featured vision will be successful, too. If it fails, you’ve invalidated the idea, learning as early as possible that you’re solving the wrong problem.
Ascendle, like the Harvard Business Review, recommends starting with an invalidating MVP. If it’s successful, continue on. If inconclusive, you can either shift gears to other projects, or produce a validating MVP to fully test your vision.
The reason I bring all this up is because many companies simply give their minimum viable products away. Yes, this gets your product into customer hands, giving you a source of feedback. But it doesn’t validate (or invalidate) anything when all you’re doing is giving it away.
That’s why it’s so important to plan on selling your MVP from the outset. Whether it’s a validating or invalidating form is less important.
Finding Your MVP Market
So where do you find a market for your minimum viable product?
You’re not looking for a massive global audience at this point. In fact, your target audience might be extremely small – possibly no more than a handful of potential customers.
If you’re already operating in that industry, you might be able to cherry-pick a few trusted partners that could benefit from your MVP. The advantage of that is to rely on already established relationships for better, more constructive feedback.
If you’re reaching out to a new market, on the other hand, your best option is to find a few industry influencers who could benefit the most from your MVP solution.
The key thing to remember is that you’re selling your MVP – not a vision of your long-term project. Your MVP should be presented as a viable, useful, and worthy product in its own right. Visions of the future may intrigue your prospects, but it’s more important that they’re satisfied with the actual product you’re selling them today.
If you’ve planned your MVP right – i.e. if it solves one or more key customer problems – then there should be a clearly defined audience for that product. One of the biggest mistakes software developers make is not putting their MVP on the market at this stage. Until you put your product into customer hands, you’re operating on guesswork rather than true market feedback.
Gather Business Intelligence
Once your minimum viable product is on the market, you can start collecting data. Real data.
This is important, because the decisions customers make with their expense accounts and checkbooks are NOT the same decisions they’ll promise over a cup of coffee at your local Starbucks. Likewise, you should never fully trust purchasing intel acquired from interviews or questionnaires.
When you sell your MVP, you’ll see exactly how the market responds to those features you thought were important. You can discover why customers purchased your product – or why they didn’t.
You can also see how customers use your MVP. Their experiences with your software will provide the best indicators of what features and improvements should be built next. Find out what they’re struggling with… and what they think would make your commercial software product more useful.
Reprioritize Your Product Backlog
Up until now, what you built into your minimum viable product was based on what you thought was important. But after the MVP, you have much better advice to follow: the advice of real customers using (or possibly not using) your software.
If you follow that advice, you could find your product veering along unexpected paths. Some companies will resist that, clinging to what they thought was important instead. But in doing so, they’re losing sight of why they created an MVP in the first place.
Reprioritizing your product backlog is how you respond to the data you’ve gathered. The product backlog lists all the features you’ve imagined or planned for your product, broken down into smaller chunks called user stories. In Scrum, these user stories are reprioritized before each production sprint. That means that every two to four weeks (depending on how long your sprints are), you can adjust your efforts to better accommodate the business intelligence you’ve gathered.
In this way, your very next production sprint can develop the most important feature(s) currently on your list… no matter how many times your priorities have changed since you developed your minimum viable product.
Stick with Your Production Sprints
Scrum’s production sprint process is perfect for growing your software out from its MVP version. All you need to do is stick with the process.
Once you’re accumulating data from real market situations and real paying customers, your development becomes more strategic and less guesswork. Every sprint, you’ll be assessing your feedback and prioritizing which features matter most. You can address the wants of existing customers, develop new functionality to reach new audiences, or combinations of both.
As long as you adhere to the production sprint process, you’ll continue to improve your software product in ways that provide the most value. And when huge priority shifts occur – whether dictated by market forces or from your own management – you’ll never be more than two to four weeks away from your next sprint.
The production sprint process can take you all the way to your final vision. Simply continue reprioritizing your backlog and conducting your sprints as you grow your software. You’ll know you’re done when your sprints no longer produce enough marginal value to justify your software development team’s efforts. At that point, you can transition your team to other projects and place your now fully developed commercial software product into maintenance and update mode.
If you need help developing a minimum viable product, selling it, and growing it through production sprints, Ascendle specializes in these kinds of commercial software development. Contact us today to learn more.
