The Wrong and Right Way to Build an MVP

A few years ago, a new subscription-based music service came on the scene with a lofty goal: change the way the world streams music. The industry had been broken for decades, and the rise of free streaming and download services like Napster, Pandora, and Spotify were only making the situation worse. Artists weren’t getting paid fairly for their work, and fans wanted access to their favorite music without having to burn a hole in their wallets or listen to ads every three minutes.

In October 2014, the platform launched in the US, UK, and Canada amid huge anticipation. Backed by some of the biggest artists in the game (including Jay Z, Beyonce, Rihanna, Madonna, Kanye West) and packed with ad-free, high-quality, exclusive content fans were craving, Tidal was poised to start a revolution.

But the revolution never came.

Years later, Tidal is struggling to stay alive, let alone change the industry as it promised. Even the most diehard music lovers, reviewers, and even the artists themselves are calling it quits. With subscriptions still sitting at a fraction of Apple Music’s and Spotify’s member base, and a new CEO taking office every few months, Tidal needs to make some major changes…or face the music.

What happened? Why hasn’t Tidal taken off? What’s holding it back?

While there are tons of reasons it may be doomed to fail, the core of the problem lies in its flawed MVP.

The Problem with MVPs

The idea of a minimum viable product (MVP) was first coined by Frank Robinson, then popularized 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 a phase of the product discovery process: “the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

This concept caught on with designers and developers, especially as the tech industry boomed and the barriers to product development lowered. It gave product designers a framework for getting new products to market quickly. Developers and marketers also loved being able to ship a stripped-down product, test it with real customers, and measure its success in the marketplace without building a fully-baked solution.

Perhaps the problem is that MVP was defined incorrectly in the first place. 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.

As the industry embraced the concept of an MVP, they started to reap the benefits of saving time and money, and getting feedback quickly. But over time, a new problem has emerged: We’ve misunderstood the definition and intent of an MVP.

Now, many designers, developers, and product managers use the MVP as an excuse to be lazy. They cut corners, remove features, and sacrifice the user experience in the name of “staying lean” and “shipping.”

Perhaps the problem is that MVP was defined incorrectly in the first place. 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.

The Real MVP

A Minimum Valuable Product has a few key characteristics:

Your product must solve at least one real problem, for one real audience, in one unique way. Otherwise, there’s no reason for the user to react, feel invested, do business with you, or give you their feedback.

After all, 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 the four characteristics above is missing, the test results will be skewed, leading to biased decisions and potential product failure.

Your product must solve at least one real problem, for one real audience, in one unique way.

It’s also crucial to constrain the MVP timeline. As people who like to “tinker” by nature, 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.

Decisions, Decisions: Prioritizing What’s In and What’s Out

The common misconception is that an MVP is all about stripping down a product to ship it as quickly and cheaply as possible. What about this feature or that one? Gone. UX design? No time for that, barely functional will do. The code? Just do it fast, and you can 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.

To start determining your minimum valuable product, consider these questions and exercises.

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.

Target Market

Defining your target market is the first place to start during product discovery. There are tons of people you could help, but this market contains the people you want most and are most equipped to help. To start honing in on your target market, 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?

Job to be Done

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, etc.) that motivates them to buy your product.

Pinpointing your product’s JTBD involves:

1. Identifying your focus market (see “Target Market” above)
2.  Identifying the jobs customers are trying to get done
3. Creating job statements
4. Prioritizing the JTBD opportunities

Framework courtesy of innovatorstoolkit.com

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:

1. Definition: In one succinct sentence, what is the product or service?
2. Users: Who is it for?
3. 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 to this question! Ask, “Why?” five more times to drill down to a deeper purpose that both your team and your customers will connect with.)
4. Differentiation: How will it solve that problem or pain point better than the current solutions?
5. Value: How will it make our business and users’ lives better? What benefits and results will it deliver?
6. Goals: What’s the end goal? How will our success be measured?

Summarize all of these elements into one clear, succinct statement that your team can use as a North Star throughout the development and product management process. Two of our favorite formats are below. (Check out this article for more information on how to create and validate your design philosophy.)

Source: Richard Banfield

Source: Product Thinking by Nikkel Blaase

User Stories

With your design philosophy in hand, your team will probably have dozens – maybe even hundreds – of ideas for potential features that could be included in your MVP. To prioritize 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 #1 until you have an exhaustive list of features that 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. Prioritize 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, now you have a huge backlog of future features to revisit as you move into product management!)
5.  If you’re having a hard time prioritizing, try assigning each story a numerical ranking from 1-5 so you can look at the numbers objectively.

Can We Launch?

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 prioritize those feature requests, but when all else fails, ask one critical question:

“Can we launch without this feature?”

Keep in mind 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.

When all else fails, ask one critical question: “Can we launch without this feature?”

When the Going Gets Tough, the Tough Get Creative

Like any project, MVPs rarely go as planned. The work takes longer than expected…the budget gets cut or spent it 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 of the ways we’ve seen companies tackle these common challenges and go on to achieve great things.

Problem: Timeline

Solution: Reduce automation.

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

Sometimes, it’s ok 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.

Sometimes, it’s ok to include features in your MVP that don’t scale.

For example, many products pull in a bunch of data, analyze it, and deliver reports to their users that make the information easier to view and understand. 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 concepts 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!)

Problem: Lack of support or resources

Solution: 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 & 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 same design philosophy and user research, and their findings should be shared with other teams to maximize usefulness.)

If you’re trying to work around departmental resource constraints, consider spinning off a separate Research & Development Team.

Problem: Budget

Solution: Consider an alternative MVP.

Budget is often the biggest concern for a new product. In addition to the suggestions above, 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.

Consider whether there’s a completely different way to prove your concept without even building a product at all.

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?”

Since launching in 2012, they built a full-fledged software product and were acquired by Full Contact. However, 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.

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 they 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.