How to Get Your Product Right the First Time

Here are three key things that are wrong with most MVPs and how you can make better products from the get-go.

A shopping cart, a white sign on an easel with “MVP” written on the canvas in black block letters and a plain cardboard box.
Image: Shutterstock / Built In
Brand Studio Logo

Search “minimum viable product” on the internet, and you’ll get over a billion search results. What can we say that hasn’t already been said?

And yet, despite all the wise words out there, most startups and new product development teams get their first product attempt wrong.

This happens because it’s extremely hard to strike the right balance in defining the MVP features appropriately — not so many that they make development and iteration slow and the product too complex for the stage you’re in, and not so few that you can’t provide a viable solution to test your hypotheses because your MVP lacks sufficient functionality.

To strike that balance between features and viability, focus on the core functionality that addresses the primary user needs with a positive user experience, without overcomplicating or oversimplifying the product. Easy, right?

So how do we do that?

3 Ways to Create a Winning Minimum Viable Product

  • Focus on one type of customer rather than trying to appeal to everyone.
  • Test that your product’s core value proposition resonates with users.
  • Put your product through usability testing before launching it.

More on Product Design6 Ways to Bring Continuous Design into Product Innovation

 

Focus on Your Customers — But Only Some of Them

Even if your startup’s strategic goal is to conquer the world (which it absolutely should be) and address a multitude of problems for various user groups, when it comes to your MVP, narrow your focus to a specific type of customer.

Introducing new products to the market and convincing people to adopt them is challenging enough. This challenge multiplies when you attempt to cater to the needs of multiple user segments simultaneously.

Instead, concentrate your efforts on one specific customer type, develop superior solutions for them and minimize the number of variables when gathering insights. You can always expand your audience or pivot to a different customer type after gaining valuable insights and traction.

Your MVP shouldn’t attempt to cater to everyone’s needs right from the start. In fact, attempting to do so significantly reduces your chances of success.

You’re more likely to try to add too many features or overengineer, prolonging your development time and increasing the complexity, dependencies and overhead. It also limits your opportunities for iterations while increasing sunk costs when adjustments become necessary.

 

Deliver the Core Value

An MVP isn’t merely “building something.” It must be viable. You should be able to validate whether the core value proposition your product offers resonates with users.

In addition, given that the MVP serves as your primary learning tool, you should be able to validate the core hypothesis of your product plan. If your strategy depends on users taking a certain action, then ensure this action is included in your MVP and that you’ve built a way to validate when users perform the action.

We often see situations where an MVP is deployed but doesn’t get traction, yet the team remains puzzled about the reasons. It could be because the core value proposition doesn’t resonate with users, or because a critical enablement feature wasn’t built, and it created too much friction to adopt.

To prevent this problem, it’s wise to go back to your original list of product hypotheses (the list of statements that begin with, “We believe ... ”) and compare it with your MVP feature list, ensuring your key hypothesis can be validated with the features you’re building into your MVP.

Sail to Scale book cover
Image provided by How 2 Conquer.

Another technique is to rank the features you want to include. Every single feature needs to earn its way in either by being part of the core use case or by helping validate a key hypothesis for your business. If neither of these are true, then the feature is a “nice to have,” and you should therefore (painfully) postpone it.

There are numerous other areas in which you can be resourceful and prioritize development speed over development cycles.

For non-differentiated parts of your solution, get off-the-shelf modules. There are probably designers that have great ideas for a new way to implement a timer, but unless your startup is building an intelligent, quantum-computed, next-generation timer, it’s not worth the time and effort.

While this might not be intuitive, you should also do things that don’t scale — such as relying on manual work and operations to fulfill some activities that could be automated but shouldn’t be until you clear your Launch Wave and are ready to scale.

And your engineering team should resist the temptation to overengineer your infrastructure to handle massive usage. It’s highly likely you won’t require such scale immediately. By the time you do, you’ll have accumulated a wealth of insights about your products and user behavior, necessitating a re-architecting of your infrastructure anyway.

More on Product DevelopmentAgile Gave Us Tech Bloat. Now What Should We Do?

 

Take Your Time Designing for UX

Yes, we just told you to focus, but there are areas you can splurge on because they’re worth it: design/user experience and metrics.

Great design and user experience of the core value proposition are worth it. If your MVP is low-quality, breaks or is hard to understand, your users may have a bad reaction and not engage. Remember that first impressions are lasting ones, and they’re usually made rapidly when first experiencing a product.

If user experience was bad, then you wouldn’t know if your users lost interest because of the experience or because of the core value proposition. You may attempt to re-engage them later by fixing things, but you can only have one first impression.

Make sure your MVP has gone through the right level of testing and usability analysis before you launch it.  If you don’t have a plan to gather feedback and learnings, your MVP will be useless.

Feedback can be both quantitative (making sure you’ve invested in observability and the ability to look at your metrics) or qualitative (with surveys or interviews lined up to gather customers’ feedback). This is one of the most precious values of your MVP.

 

Past the First MVP

We emphasize identifying as quickly as possible when your MVP isn’t working, and you consequently need to iterate on it. What we aren’t emphasizing on during your Launch Wave is creating a scalable, full-featured product.

Remember, your MVP is a vehicle to test hypotheses quickly and with minimal effort, to quickly converge on a viable, marketable product. Continue iterating with urgency until you’re sure your MVP has connected with a possible product-market fit.

If you confirm that you can sell it, then you’re heading to the Scale Wave. Otherwise, you’re back to iterating on your MVP, or perhaps having to face the Pivot Wave.

Excerpted from Sail to Scale: Steer Your Startup Clear of Mistakes from Launch to Exit by Mona Sabet, Heather Jerrehian and Maria Fernandez Guajardo. Copyright 2024 Mona Sabet, Heather Jerrehian and Maria Fernandez Guajardo. Reprinted with permission.

Explore Job Matches.