The Wrong and Right Way to Build an MVP

A successful MVP isn't about shipping the cheapest, fastest version of your product. It's about building the minimum valuable product -- the fewest features necessary to solve the primary problem for your primary market. Get that wrong, and you get Tidal.

What Is the Real Problem with MVPs?

The idea of a minimum viable product (MVP) was first coined by Frank Robinson, then popularised by Steve Blank's Customer Development methodology in the 1990s and Eric Ries' Lean Startup movement in the early 2000s. Ries defined an MVP as "the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

Solid definition. Terrible execution -- industry-wide.

As the tech industry boomed and the barriers to product development lowered, designers and developers embraced the MVP as a framework for getting new products to market quickly. Ship a stripped-down product, test it with real customers, measure its success without building a fully-baked solution. What's not to love?

The problem is that over time, MVP became an excuse to be lazy. Cut corners. Remove features. Sacrifice the user experience in the name of "staying lean" and "shipping."

Tidal is a perfect example of what happens when you get this wrong.

How Did Tidal Get Its MVP Wrong?

In October 2014, Tidal launched in the US, UK, and Canada with enormous anticipation. Backed by Jay Z, Beyonce, Rihanna, Madonna, and Kanye West, packed with ad-free, high-quality, exclusive content, and promising to fix a broken music industry -- Tidal was poised to start a revolution.

The revolution never came.

Years later, Tidal is struggling to stay alive, let alone change the industry as promised. Even the most diehard music lovers, reviewers, and the artists themselves are calling it quits. Subscriptions sit at a fraction of Apple Music's and Spotify's member base, and a new CEO takes office every few months.

While there are plenty of reasons it may be doomed to fail, the core of the problem lies in its flawed MVP. Tidal tried to make a big splash right out of the gate instead of doing one small thing really well.

What Is a Minimum Valuable Product?

Instead of a "Minimum Viable Product," we believe in the "Minimum Valuable Product:" one that has the fewest features necessary to solve the primary problem for your primary market.

A Minimum Valuable Product has a few key characteristics:

• It solves at least one real problem
• For one real audience
• In one unique way

Without all three, there's no reason for the user to react, feel invested, do business with you, or give you their feedback.

An MVP is just an experiment. As a product designer or developer, you're essentially doing usability testing to see if your hypothesis is accurate. If even one of those characteristics is missing, the test results will be skewed, leading to biased decisions and potential product failure.

It's also crucial to constrain the MVP timeline. Designers and developers could iterate forever -- but customer feedback is like currency. Every day you're not on the market is money lost on product discovery and development instead of gathering input.

How Do You Decide What to Include in Your MVP?

The common misconception is that an MVP is all about stripping down a product to ship it as quickly and cheaply as possible. UX design? No time for that, barely functional will do. The code? Just do it fast, clean it up later.

Rather than helping products succeed, this is exactly how they fail. The most effective MVPs still maintain a high standard of quality when it comes to code, design, UX, and content. They simply limit the scope.

Here's how to figure out what stays and what goes.

Who Is Your Target Market?

Defining your target market is the first place to start during product discovery. There are tons of people you could help, but your target market contains the people you want most and are most equipped to serve. Ask yourself and your team:

• Who could we help?
• What do those people have in common? (demographics, motivations, values, etc.)
• What are some of the problems or pain points they experience?
• Which segments aren't being targeted or aren't having their problems solved by our competitors or the current solution they're using?
• Which segments could we impact most, given our current skill set?
• Which segments would be the easiest to help?
• Is this a big enough market to make a difference?
• Are they easily accessible?
• Can they afford a solution to their problems?
• Do we know enough about them to meet their needs?

What Job Is Your Product Being Hired to Do?

Whether you're iterating on an existing product or creating a completely new solution, it must do the one job your users are "hiring" it to do. The "job to be done" (JTBD) could be a task the user wants to complete or the higher purpose -- emotional, social, personal -- that motivates them to buy your product.

Pinpointing your product's JTBD involves:

• Identifying your focus market (see "Target Market" above)
• Identifying the jobs customers are trying to get done
• Creating job statements
• Prioritising the JTBD opportunities

What Is Your Design Philosophy?

To have a successful MVP, you must hone in on at least one primary job your target market can hire your product to do. Having a defined vision, strategy, and goals also helps focus your team's efforts and design a more meaningful experience. Consider these questions:

• Definition: In one succinct sentence, what is the product or service?
• Users: Who is it for?
• Purpose: Why do we want to create it? What user problem or pain point will it solve? What difference will it make in the world? (Don't just stop at the first answer -- ask "Why?" five more times to drill down to a deeper purpose that both your team and your customers will connect with.)
• Differentiation: How will it solve that problem or pain point better than the current solutions?
• Value: How will it make our business and users' lives better? What benefits and results will it deliver?
• Goals: What's the end goal? How will our success be measured?

Summarise all of these elements into one clear, succinct statement your team can use as a North Star throughout the development and product management process.

How Do You Prioritise Features with User Stories?

With your design philosophy in hand, your team will probably have dozens -- maybe even hundreds -- of ideas for potential features. To prioritise those features and decide what stays and what goes, try this User Stories exercise:

1. On a Post-it Note, write down one task you want users to be able to complete with your product. Put it on a wall or whiteboard.
2. Repeat step one until you have an exhaustive list of features you want your users to be able to do at some point in the future.
3. Group the Post-its by theme or category.
4. Prioritise them from most important to least important to the user. The most important features become your "A stories." This group also represents the least amount of stories needed to deliver a distinct, well-designed experience that adds value and accomplishes the main job to be done. (As a side benefit, you now have a huge backlog of future features to revisit as you move into product management.)
5. If you're having a hard time prioritising, try assigning each story a numerical ranking from 1-5 so you can look at the numbers objectively.

Can You Launch Without This Feature?

Throughout the product discovery, design, and development process, new features and ideas are bound to come up. You can use your design philosophy and user stories to prioritise those feature requests, but when all else fails, ask one critical question:

"Can we launch without this feature?"

This question should be answered from the user's perspective, not a developer's or designer's point of view. What is minimally valuable for the user? If we launch without this feature, will we still be able to solve their primary problem?

If the answer is yes, be ruthless and move the feature to the backlog. If the answer is no, it's time to evaluate what it will take to add it. Will it cause you to go over budget? Does it fit within the current timeline? This is where hard decisions -- and successful projects -- are made or broken.

What Do You Do When Your MVP Hits Real-World Obstacles?

MVPs rarely go as planned. The work takes longer than expected. The budget gets cut or spent in other areas. The executives don't approve the full project.

There are always going to be new reasons to postpone launch or pivot, so the key is to get creative and find ways to make it happen. Here are a few ways we've seen companies tackle common challenges and go on to achieve great things.

What If You're Running Out of Time?

Reduce automation.

Many apps and products rely on automation to streamline an existing process and save their users time. However, that automation takes time and resources to build.

Sometimes, it's okay to include features in your MVP that don't scale. It may seem counterintuitive, but continuing to complete a process manually behind the scenes -- while making it seem automated to your users -- still adds value without incurring additional development time and expenses.

For example, many products pull in a bunch of data, analyse it, and deliver reports to their users. Ideally, this process would be automated. But does it have to be at first? Nope.

Instead, your product could have the user import or add their data, then show them a screen that says, "Your report will arrive in your inbox in the next 12 hours." It seems like magic is happening behind the scenes, when in reality your team could be manually completing the process on the back end. It appears automatic to the user, but it's not.

If the concept works, you can truly automate the process in V2 or V3, but in the meantime you're still providing value to your users and gaining meaningful feedback from your customers. (That feedback might even change the way you automate the process in V2 or V3.)

What If You Don't Have Enough Resources or Support?

Spin off an R&D team.

Some of the most successful products and brands in history -- like the Mac and some of Nike's shoes -- started as a skunkworks project. If you're trying to work around departmental resource constraints, consider spinning off a separate Research and Development team who can dedicate separate buckets of time and budget to innovation instead of product management.

Just be sure that this team doesn't become siloed from the rest of the company. Their work needs to be guided by the same design philosophy and user research, and their findings should be shared with other teams to maximise usefulness.

What If the Budget Just Isn't There?

Consider an alternative MVP.

Budget is often the biggest concern for a new product. Consider whether there's a completely different way to prove your concept without even building a product at all. That way, you can show its potential value, gain buy-in, and earn budget for a more full-featured MVP.

That's what Mattermark did. Initially, they wanted to solve a specific problem: "How can we help venture capitalists and investors get better deal intelligence to inform their investment decisions?"

Mattermark didn't even start as a product. First, it was a blog about the startup investment scene. Then it gained enough popularity to evolve into a spreadsheet that tracked company Growth Scores, location, total funding, and more -- before the team finally had enough momentum and budget to build the app. Since launching in 2012, they built a full-fledged software product and were acquired by Full Contact.

How might you channel your inner Mattermark, test your hypothesis, and solve your target market's main pain point without building a product at all?

Is Your Product Viable or Valuable?

As brands like Tidal have experienced firsthand, creating a successful MVP is less about building a product that makes a big splash right out of the gate, and more about doing one small thing really well. If Tidal can refocus on solving one key problem and reinforce the bottom rungs of the Experience Success Ladder -- functionality, usability, and comfort -- perhaps the tides will turn.

Until then, consider what your team can learn from cautionary tales like Tidal, as well as role models like Mattermark. The more we all shift from a mindset of viability to value, the more successful our businesses -- and our users -- will be.

FAQ

What is the difference between a minimum viable product and a minimum valuable product? A minimum viable product is often misused as an excuse to ship something stripped-down and low-quality. A minimum valuable product is different: it has the fewest features necessary to genuinely solve the primary problem for your primary market, without sacrificing quality in code, design, or UX.

How do you know which features to include in an MVP? Ask one question from the user's perspective: "Can we launch without this feature?" If the answer is yes, move it to the backlog. If no, evaluate the cost and timeline implications. Your design philosophy and user stories should guide every prioritisation decision before you even get to that question.

Why do most MVPs fail? Most MVPs fail because teams treat "minimum" as a licence to cut corners on quality rather than a directive to limit scope. When the user experience, UX design, and code quality are sacrificed, the product can't gather reliable feedback -- because users don't engage with something that doesn't solve their problem well.

Can you test an MVP concept without building a product? Yes. Mattermark started as a blog, then a spreadsheet, before eventually becoming a full software product. If budget or resources are a constraint, consider whether a different format -- content, a manual process, a landing page -- can prove your concept and earn buy-in before you build anything.

How do you define the "job to be done" for your MVP? Start by identifying your target market, then identify the jobs those customers are actually trying to get done. Create job statements and prioritise the opportunities. Your product needs to do at least one of those jobs better than the current alternatives -- that's what earns a user's attention and trust.