← Back

Asking what features to cut is not the right question

Anyone who’s worked in software development in the last five years has probably heard the term MVP. A lot. And if you are responsible for the user experience, chances are you’re often frustrated by these three letters. Probably because you usually encounter them closer to the end of the project, in sentences like this one: “It’s a great idea but we just can’t build it right now. Let’s launch the MVP and add this later.”  Sometimes you hear that even if there are no plans for future iterations.

The most common definition of Minimal Viable Product is a product with just enough features to satisfy early customers and provide feedback for future development. Unfortunately, sometimes this statement is misunderstood and teams think that building “just enough” means focusing purely on functionality. However, a product is more than the sum of its features. You can’t just ship something functional and wait for the next iteration to make it usable. User trust is fragile and once it’s broken it’s hard to rebuild.

The model below, originally proposed by Jussi Pasanen (which later became the artifact of any blog post on the topic), explains how not to disappoint your users while getting the product to them as quickly as possible. It suggests that instead of building layer by layer, you should be creating the minimum piece across each layer. Any MVP must have a set of features that gives users: enough value, a reliability level that earns their trust, and a usability level that allows them not to think about your design and to sprinkle a bit of joy on top.

In this article, I want to share my thoughts on how to find those minimal pieces that you need to build.

Minimum Viable Product: Build a slice across, instead of one layer at a time. Based on the diagram by Jussi Pasanen.

There is another idea that this diagram captures very well. Product layers are stacked and if you extend the scope of one layer you will increase the scope of all the layers above it. For instance, the more we add new functionality, the more work we invite to keep the product reliable and easy to use. If we want to reduce the scope, the most sensible place to start is at the foundation of this pyramid — functionality.

So what features do we want to include? How do we decide? I know your UX spidey senses are tingling now. Mine did too, until I realized that the “functional layer” is a false bottom of this pyramid. The diagram above covers only characteristics of a product itself, but products don’t exist in a vacuum. We build them to help people who will hopefully pay us back for the provided value. The real foundation layers for your product are your audience and their needs.

Let’s say we want a product that solves problem X for our users. Which segments of our users should we build the MVP for to validate our approach? This question should be driving the negotiation on the scope of the project. Nothing can cut the development time more significantly than selecting “your audience” (whoever will get the most value from the product in its initial phase ) and saying no (or “not now”) to everyone else. The broader your audience, the more needs and problems it has, the more features you must build, and the more complex and hard-to-use your product will be.

There is a saying that points out that your MVP doesn’t have to be as cool as a final product, but the experience of using it should still be enjoyable: “The MVP of a car is a tricycle, not four wheels.”

But if you glance under the hood of this MVP you’ll see that the biggest difference it has from the finished product is the breadth of users it serves. A car is for everyone: old and young, those who travel alone or in a group, those who commute to work or carpool to the next town. A tricycle, however, exclusively serves the transportation needs of toddlers.

Segmenting your users, and choosing which needs of each segment you want to fulfill, allows your team to double-down on creating a great experience for those users and winning their love.

Let’s get back to the pyramid and take a look at the line that cuts across all layers and separates the “minimum” from the rest of the product. It’s clearly important as it outlines the scope of your work. How do you know where to draw it? I think this line indicates users’ expectations. Whatever audience you choose, they will have beliefs about what your product should be and do, and you can’t afford to fall short of their expectations.

The scope of your MVP is basically a function of your audience and their expectations.

It’s crucial to recognize the difference between what users want and what they expect. “Expectation” is how people believe something should work, while “want” is their desire for improvements on the current state of things. Coming up short on wants can be bad, but not meeting expectations can be a disaster. For instance, if it usually takes you half-an-hour to get to work, you would expect it to take you about the same amount of time tomorrow. Would you like your trip to be shorter? Of course, but you know that you don’t always get what you want. However, if your streetcar shows up 15 minutes late tomorrow, and your ride turns into 45 minutes, you might go ballistic.

Any product, not just MVP versions, will never satisfy all of your users’ wishes. There’s always room for improvement! However, when your product doesn’t meet user expectations, it’s a quick road to failure. When trying to identify user expectations, there are a few things you should keep in mind.

As long as you are not developing something absolutely new (think flying cars) you have to consider the experience that your competitors (even indirect ones) provide. If they sync user data immediately, then a 4-hour delay in your app might just not cut it. It might push you to draw the line on the diagram a bit more to the right and increase the scope of your project.

Ten years ago you could get away with building a product that works only on desktop, but today it’s a given that it has to be accessible on mobile. A product that fails to support users when they are on-the-go probably doesn’t check the mark for “reliability” by today’s standards.

I love the example Jared Spool gives in his blog post about user expectations. His team did a usability study on Google Spreadsheets and observed the bookkeeper getting really frustrated when she couldn’t find a way to indicate a double underline. Could she use a regular underline? Technically yes, but the practice of double underlines for grand totals predates computers and spreadsheets, and your attempt to limit the scope of your MVP is just not a good enough reason to ignore that.