Your app’s customers aren’t won over by features. They’re won over by the product experience.
It’s in this context that you need to shape your product releases—not with a feature checklist, but by marrying business goals with user needs, and working to define an experience that engages your target audience and drives them to action. At the same time, you need to be prepared to learn from real world usage and continue to adapt your product as needed to capture, sustain, and grow your customer base.
If you’re trying to add features to your product in an effort to make sure it is “complete,” or to cover multiple edge cases, you are delaying the point when you can begin learning what will drive customer engagement, what will drive users to action, and what will lead to business results.
Your first product release is a critical opportunity to learn how you can create an experience that engages real users, not just your perceived users based on vague demographics or even rich personas. This is why it’s essential to get your product in the hands of your prospective market as quickly as possible with a Minimum Viable Product (MVP).
Getting to Market Quickly
Many products that make it to market started out as something different.
Foursquare is a great example. They spent almost two years focused on mayoral gamification. They found that the gamification model led to rapid adoption, but it did not make a sufficiently compelling experience that could sustain their core product, allow them to monetize, or offer long-term value. So they pivoted to focus on local search.
The Foursquare example illustrates why it’s important to get to market quickly to test your assumptions. The two years they spent focused on an unsustainable experience would have killed most similar products, burning through millions in investment dollars without getting any closer to profitability.
An interesting example that illustrates a better MVP strategy is Hyperlapse, just released from Instagram/Facebook.
When you open the app, you’re invited to start recording your video. When you finish, you can set a speed from 2x to 12x the original video recording. When you set that speed, the sped up video is saved to your camera roll and you can then share to Instagram or Facebook.
That’s the app.
There’s no account setup. No in-app file management. You can’t see any of the previous videos you’ve saved in the app.
You can only make a video once, and you can’t change the video speed settings once you’ve saved them. You just set the speed and share your video.
“We Can’t Launch Without Those Features”
Most companies would say, “We can’t launch without these features.”
Let’s briefly summarize what’s actually required to ship something like the Hyperlapse product with two extra features: file management and video editing.
To accomplish this, you’d need to consider how the user would access these features (navigation and on screen controls), design those screens and assets required to bring these features to life, develop these features, including file system access and complex video APIs to support editing. Then you need to test and release the product.
It’s sure to be four times the interface work, and six times the development work of the current app.
And that doesn’t consider development issues and edge cases which may arise due to the complicated work ahead. In each case, properly addressing these new features requires time. That means the product gets to market two, three, four, or more months later. And if no one digs it, then what? If you can’t monetize it, then what?
You risk missing valuable insights if your MVP is slow to market, overburdened with inessential features, or worse, based on wrong assumptions.
Designing An Answers Machine
With a new product, you are standing at the intersection of your collection of assumptions about your customers and the actual behavior of the users of your product. All the while you’re pushing for new marketing opportunities, dealing with shifting target needs and a big pile of additional unknowns.
These assumptions and unknowns you bring to your MVP create additional variables. Additional variables make it more difficult to test your assumptions. If you can’t effectively test your assumptions, you can’t collect useful data to help you refine your product.
Your MVP is a machine for turning questions into answers.
The purpose of your MVP is to reduce the number of assumptions you carry forward into product development and reduce the size of that pile of unknowns. In other words, your MVP is a machine for turning questions into answers.
The Core Experience of Your Product
It’s clear the more you design and build without releasing, the longer it takes you to get to market. Worse still, the more you design and build without market input the less likely you’ll have the focus and attention of the user you’re trying to serve.
This happens because your focus has inevitably been on combining the features of an app based on a growing set of unproven assumptions. It’s like piecing together a massive jigsaw puzzle without any photo reference.
Instead, you need to focus on the core experience that will serve your target. Strip your product down to its core, define the one job to be done with your app that will be indispensable to your target. Put this in the hands of your target and see how they respond.
If you don’t focus on the core experience, and instead create a wide but shallow product, you’ll find your users lost, confused, or bored, and, more than likely ready to walk away. Most importantly, you won’t find those passionate folks who can’t live without that one great thing you do, and therefore you won’t find traction.
Too Many Buts
The typical product design process has some built-in forces that tend to create MVPs that actually don’t deliver the critical benefits of speed, focus, efficiency, and insight.
You’ll always find reasons to do more before you get to market, none of which deliver the insight you need to make a great product. So let’s look at these objections and how they lead to failure.
There are three primary places where we see pushback to creating a valuable MVP. If you hear these coming from a product manager, there are diplomatic ways to talk about the negative effects of a bloated, unfocused MVP.
If you are a product manager, we’d urge you to consider that your users’ experience with your MVP is the most important factor you can optimize for. Missing that target means that something much bigger than the development budget of your MVP is at risk.
But 1: “I need to get more value from the MVP”
As a business owner or the person signing the checks, it’s tempting to try to create an MVP with more features than necessary. Pushing the feature count higher seems to deliver more value from the budget if you believe that more features means more value. But more features really just means more work, while often leading to diminished value for the product experience.
It makes about as much sense as defining the value of a car by its number of wheels. Six wheels must be better than four because you get more wheels.
This is not a reasonable argument. Nor is increasing the number of features in your MVP, because features do not equal experience. In fact, the more features you have, often the more convoluted and confusing the experience can be. These extra features bring side effects that make the product difficult to use while increasing development, maintenance, and support costs.
Taken another way, the number of features in an MVP is not even loosely correlated with the MVP’s ability to:
- Test your assumptions
- Deliver data about user and market preferences
- Deliver the core experience of your product to your users
To risk repeating myself here, adding features to an MVP delays the point at which you can begin doing those things.
If there’s something you’re trying to optimize for, it’s how quickly you can find passionate users of your product, not increasing the product’s feature count.
But 2: “We need to cover all the use cases, or we risk alienating customers”
Let’s get this out of the way right now: you simply cannot cover all the use cases.
Feature-rich products that have been in development for dozens of years, with thousands of developers, still don’t cover all the use cases. It’s a fool’s errand, made worse because this path at best distracts you from the experience for your core users and, at worse, forces you to ignore your core users.
Consider Microsoft Office. Office is the second pillar of Microsoft revenue after Windows, but it is being upset by Google Docs and a plethora of other writing tools. Office is not as as fast, cross-platform friendly, or simple to use as these challengers. The challengers are focusing on core writing tasks instead of features that appeal only to power users.
Let’s suppose the majority of Word users use just 5% of the product’s functionality. That means any company that does just that 5% better is going to have a compelling advantage over Microsoft Word.
Building an MVP that covers edge cases and power user features tends to follow the 4x design to 6x development effort multiplier noted above. Adding these kind of features also confuses the user interface by adding all sorts of extraneous information a user needs to sift through.
So, not only is it substantially more development work, but it adds substantial cognitive overhead each time a user must figure out how to do just what they need to do.
The bottom line is this: for the bulk of users, using Microsoft Word for everyday writing tasks involves too much noise, too many choices, too much distraction, and too much difficulty. At best, users are ignoring the majority of the interface they never use. At worst, they can’t figure out what they need to do as they click through menu after menu.
While Word is a mature product and not an MVP, it’s an excellent example of what happens when the goal is maximizing the product’s feature list.
So repeat after me: you can’t cover all the use cases. Now get back to focusing on the experience.
But 3: “We need to finish the app before we launch”
The notion of completion is a common impediment to creating a successful MVP.
This pushback often comes from sales or marketing stakeholders, who fear that a true MVP (one optimized to get to market quickly and gather useful data) isn’t complete.
This fear is fostered by a misperception about what creates a compelling product experience, and what reduces the friction around product adoption.
More features, or a more complete feature list almost never leads to a compelling, delightful experience. Really nailing the core experience of the product does. This means all of your resources should be focused on planning, designing, developing, and shipping a remarkably well-crafted core experience. That alone is a substantial undertaking.
All your additional efforts to complete the product just lead to delays and compounding assumptions, creating a disconnect between your product and the target. In truth, your product will never be finished. As you learn from each user, as business rules change and markets shift, your product needs to adapt on an ongoing basis to address these factors. The sooner you begin learning and adapting, the more likely you’ll be successful.
Your MVP Probably Needs to Cut Even More Features
I don’t say this lightly: your MVP probably needs to have fewer features than you’re planning for.
Cutting features will almost always improve your product along two important dimensions:
- Time to market
- Budget
Remember that every feature is exponentially more work because it requires input from multiple stakeholders, including:
- Content
- Design
- Engineering
- Testing
- Maintenance
- Legal
Consider this every time you want to add something to your product.
Keep Your Focus on the Experience
Time to market and budget are not even the best reasons to pare down your MVP, they’re just added benefits of doing so.
Every effort, from every stakeholder, should be filtered through the lens of the core experience of the product. From the product’s inception, to launch, and with each iteration that follows, focus your available resources on knocking the core experience out of the park.
You should constantly be asking how your users will react to, benefit from, and utilize your product, whether you’re looking to make feature additions, or interface changes.
If anything detracts from the product’s core experience, stop making changes and release your product. You’ll get more insight by doing less and seeing how people engage with the product as it is, what behaviour they exhibit, and reviewing this against your assumptions. This insight will always pay the greatest dividends as you strive for product market fit.
Image of amusment park ride courtesy Shutterstock.
