Building a MVP: A Founder’s Guide to Success
Whether launching your first product or a brand new feature, finding product-market fit can be a daunting process for software leaders. Often, it means going through many iterations, false starts and near-misses. And sometimes, what seemed like a great idea can turn out to be a total flop when it gets into the hands of your customers.
The business impact of all of this can be profound, so to accelerate the process while minimizing the pain, a Minimum Viable Product (MVP) is the go-to product development strategy for software founders.
Here’s what I’ve learned from launching my own MVPs, and how I believe others can make a success of the process.
What an MVP Is (and Isn’t)
An MVP allows you to prove a concept before committing too much time or budget to full-blown product development. Most agree that an MVP is a product with a minimal number of features needed to engage customers and validate a basic concept for further development. Importantly, it’s not final — the idea is that it’s something you augment and refine over time.
Uber, Facebook, Slack and Dropbox are some of the most high-profile examples of businesses that used MVPs to prove to their backers — and to themselves — that they could validate convictions from previous experience and get the feedback needed to scale their products to where they are today.
I’ve spent a great deal of my time on the process: first while building a back-end-as-a-service business that was later sold to Amazon Web Services, and now, building m3ter, a metering and pricing engine for SaaS companies. For both businesses, identifying an idea, proving it, and bringing it to market was crucial — and developing the most recent business in stealth reminded me of the value of testing and developing a product with a closed set of customers before launching it to the wider world.
Conduct Research
When you think you have a great idea, it can be tempting to rush off and build it — that’s the fun part, after all.
But skipping over the discovery phase can be a costly mistake. You may have a strong hypothesis grounded in your previous experiences, but you need to make sure that the problem you plan to solve is as commonplace as you think it is. To put it simply — have you identified a real issue, and are enough people willing to pay to make it go away?
Do your research. We spoke to VCs, SaaS businesses and pricing specialists to find out whether our idea had legs, holding over sixty conversations before we were confident in our convictions.
Let Your Customers Help You Understand What to Build and How to Do It
A common mistake is to stop your research at that point, without understanding the needs of real users. Bringing your customers into the design process early and making product development a consistent, collaborative process will keep you closer to what’s really important to them.
At m3ter, our first customers were specifically recruited as design partners while we were in stealth. By taking this approach, we found them to be more understanding and forgiving, as well as more engaged in the design process. We talked about what we were hoping to build and what problems we intended to solve, selling them on the idea rather than the product. And we made it clear to them that they weren’t yet fully-fledged customers.
It was really important while engaging with these partners, that we created a continuous feedback process so our team could go back and iterate as our product was being used and tested. We’d ask them what was missing and where pain points still existed for them, rather than focusing on bugs or other minor wrinkles in the product.
Another step that worked well, and others may find helpful, has been joining relevant community groups where SaaS leaders are able to speak openly with us about the problems they face.
With a strong feedback loop in place, we set up semi-autonomous product squads in our team that each “owned” a customer problem or outcome that would determine the direction of our future roadmap.
Take a Holistic View
A potential “gotcha” is to focus too narrowly on features and lose sight of the overall experience. You want to ensure your MVP doesn’t just work but is also valuable. So as well as functionality, you need to consider how usable your product is, and how well adapted it is to solving use cases in practice.
Echoing the points above, this requires an intimate understanding of your users so you need to have champions of their perspectives in the team. We tend to lean into our Product people to provide this and have also experimented successfully with hybrid product or tech writer roles that are dedicated to the overall product discovery and onboarding experience. But it can come from anywhere.
Take Everyone Along with You
Fast iteration is crucial in this phase, so you should have regular showcases and status updates within the team so that there’s a shared sense of what has been delivered, awareness of research findings and customer feedback, and alignment on where the focus needs to be applied next.
I’d also suggest making these informal because, in my experience, that ensures better engagement. It’s an inherently messy process, so keeping things casual reflects that and allows for levity and celebration. One inspiring story I’ve heard involves a startup holding ‘open house’ demo sessions on Friday afternoons to which friends and family are welcome – which was apparently grounding, fun, motivating, and something I’d love to experiment with.
Getting off the Ground
An MVP is the most effective way to deliver a product that is desired, needed and valued by its customers. Product visions and aspirations are all very well, but it is powerful to be able to launch from stealth with happy customers already using your product to solve real pain points.
An MVP is also a great way to form and galvanize your team — an attainable short-term goal that is a powerful catalyst for engagement and problem-solving. Plus putting an early score on the board is a great morale booster.
Yes, it can be messy. But if you approach the process with an open mind and a willingness to experiment, that can be part of the fun.