How to Work With MVPs (Minimum Viable Products)

Let’s talk about MVPs (Minimum Viable Products) and how you, as a product manager or User Experience professional, can work with tight deadlines and budgets whilst still delivering a great product.

What Is an MVP?

You’ve probably come across the acronym MVP before—almost certainly if you work in the tech industry—and despite being a controversial three-letter word, an MVP is probably one of the most important steps on your way to building a great product. The main goal of shipping a Minimum Viable Product should always be “putting it in front of customers to start validating your assumptions”.

As a team, you need to gather your strengths and focus on creating a shared understanding of the business vision and goals. You need to identify the problem you’re trying to solve and work out how you’ll organize to, as quickly as possible, start learning about what customers really want and how they’ll help you drive those goals.

The Doughnut Analogy

When I began talking about MVPs in classes, I would use the analogy of a simple plain doughnut (that would be my MVP) and a doughnut full of chocolate, sprinkles and all the goodness possible (a later iteration of the product).

mvp doughnuts — MVP and later iteration? Doughnut icons from Diana Toma

Nowadays, the more I work with teams and the concept of MVP, especially now that I have a Product role, I find myself questioning this analogy. Building MVPs to validate assumptions may in fact mean that you were wrong to start with, and the next iteration isn’t even a doughnut; perhaps it’s a plain waffle?! Granted, it would still be plain, and you’d again need to go through the process of validating it, but it would no longer be a doughnut.

So... What Isn’t an MVP?

For this I’m going to borrow an illustration from Henrik Kniberg, explaining what an MVP shouldn’t be.

mvp by Henrik Kniberg — by Henrik Kniberg

Henrik describes two different approaches that share the same vision: a car. Now if the problem you’re trying to solve is transportation, would you, as a customer, go anywhere with a tire? Definitely not with a tire, but certainly with a skateboard.

Henrik defends the agile, incremental way of delivering products but states that every iteration should be a usable/testable product. Obviously, a skateboard is far from being a car, but at least you have your customers trying your product much earlier in the process and feeding back so you can start learning and thinking about the next iteration.

You shouldn’t be spending a lot of time looking at design or making it technically great—you don’t want to make it perfect to begin with, but instead you should build just enough to validate your business hypotheses.

To sum up, an MVP isn’t...

A product that can’t be used and tested by customers or early adopters from day one.
A product that doesn’t allow you and your team to learn and validate assumptions.
A product that isn’t solving (or trying to solve) customer problems.

Focusing on Problem Solving

Ultimately, when building products, your main goal should always be solving customers’ problems. If you’re not solving their problems, and you’re not bringing something new that fits in with their daily routine, they most likely won’t be using your product. With the surge of design techniques, UX teams are gaining tools to get to know customers and get to the bottom of what they want earlier in the process.

There are a number of techniques you and your team can use to get to know your customers and understand how you can solve problems:

Focus groups. If you’re building a new product, invite a group of people that are using your competitors’ products and ask them about pain points, plus things that they really like, and try to get a good understanding of what they’d change and why. If you’re improving an existing product or adding a new feature, why not invite your own customers and ask them the same questions? Focus groups are a great start for developing a good understanding of what your customers may want from your product, but bear in mind focus groups can be a bit biased; there’s always someone with really strong opinions that may influence others, so you should try to read between the lines.

Ideation workshop. Gather your team (stakeholders included) and expose some of the pain points found. You should also try and print as much as you’ve learnt so far about the defined vision and business goals and pin these up on the walls so everyone can clearly see them. In these sessions, ask everyone to sketch as many solutions as they can think of for the problems you’re trying to solve. You’re looking for quantity, not quality.

Prototyping and user testing. Ideally, you should be prototyping at least once a week. Nowadays, UX teams are more agile and UX designers tend to spend more time sketching and user testing paper prototypes or low-fidelity wireframes than spending longer periods of time behind a computer making decisions on their own. Get your UX team to use prototypes as early as possible in the process to get some juicy feedback from users. Guerrilla testing is a great and effective way of testing early designs, and it takes almost no effort.

Strategizing on Building an MVP to Start With

So you did a lot of testing while trying to design the best solution. You ran weekly guerrilla sessions, you took your designs to the lab, and you’re confident you’re on the right track.

Still, even if you’ve only tested with users of your product, they’re a small percentage of your audience, and they were subject to a testing environment (hardly neutral). Testing with customers earlier in the process is invaluable, but you’ll want to get your product out there for a bigger audience to test.

Strategizing on building and launching a Minimum Viable Product is the next best thing to validate your assumptions and continue building on what you’ve learned so far.

A good way to start thinking about your MVP is to look at the roadmap you’ve built in previous sessions and focus on things that solve customer problems.

Once you’ve done this, ask the question: what can I build with the minimum effort that helps me validate this product?

This is where I still struggle: my UX heart (body and soul) always tells me to try and get as much out as possible. I want to build a seamless experience from day one, for every user.

As a product owner, with a tight deadline and a budget on my hands, I want to build just enough to make sure we are building the right thing, and I truly believe this is a good product call.

The Importance of Tagging

Nothing. Can go out. Without tagging.

Well we’ve said it before, right? The goal of building an MVP is to learn and iterate. There’s no way to learn (I mean to really learn) with your customers unless you have a system in place that allows you to track what customers are doing with your product. You need that precious data to make informed decisions. You can do qualitative research and ask your customers how they feel about your product, but we know this may not be enough.

You’ll need to make sure you build tags into your MVP that will help you understand how your product is performing against your KPIs (Key Performance Indicators) and measure your assumptions.

Analytical (or tracking) tags are often supplied by third-party providers such as Google Analytics to help us integrate our product (website, mobile app) with their tracking tools. Tracking tags are no more than a piece of code that you’ll have to embed in your product’s source code to send whatever customer actions you want to track and make it easier for you to visualize data.

Let’s say you want to track the number of times a certain button is clicked; the provider will ask you to add an event tag to the button’s source code to make sure a tag is fired to their tool every time a customer clicks that button. Their tool will then register this action along with other actions you define to give you a detailed view of what customers are doing with your product.

There is a range of tools you can use to track your customers online. Start by choosing the right one for you and your business needs, and liaise with their customer service team to get some help building tags into your product:

Adobe Omniture (Adobe Marketing)
Mouseflow (Recordings, Heatmaps, Funnels)
Google Analytics
Optimizely (you can use this for experimentation with A/B or Multivariant testing, which I’ll cover later in this article)

Learning With Data and Insights

Once tracking is in place and your MVP is out, you can start looking at what your customers are doing with your product.

If you’re new to analytics, there are a few things you can do to get your head around data and what you should be looking at. Google has a few introductory videos to get you started, and you can also read the book Lean Analytics. These will help you understand actionable metrics and what to do with the data you’re getting.

If by any chance you’re lucky enough to have a team dedicated to insights in your company, they’ll be able to help you understand the data even better! They’ll most likely be able to build reports with the key metrics you want to follow to make your life easier.

Whatever the means are for getting this data to you, the whole team should have access to it. You should all be discussing the outcomes and what’s next for your product. How’s customer satisfaction? Is it driving the goals you’ve set?

If the answer is yes, then great news! Your previous assumptions were right, and you did a great job. If, on the other hand, your MVP isn’t driving the metrics you expected, understand why and agree on what you should be doing next (also, say grace that you decided to launch an MVP before allocating tons of resources and money to a product that wouldn’t have been as successful as you initially thought it would).

Multivariant Testing

If your customer base is good enough, you should encourage A/B or Multivariant testing. This will allow you, throughout the life cycle of your product, to test different variations and make sure you keep driving those metrics.

You can make changes to your interface and see what works best for your customers. Try small changes like changing the copy on a title, or a button color, and have two versions of your product running side by side to analyse results. You could also completely change an interface; Optimizely is just one example of a tool that can help you run these experiments. Set the parameters you want to test and the percentage of customers you want to show the new version of your page or product, and track results.

Go Forth and Iterate!

It’s time you started iterating and building on top of what you already have. Ideally, your roadmap is prioritized by now, and in a way that you can continuously release product increments. Now is the right time to start mobilizing your team to think about the next drop.

Remember, each iteration of your product should be usable (the “viable” in MVP). It should seek to validate or challenge your assumptions, and in a way which gives you measurable data. Good luck using MVPs in your product development workflow!