Summary: The MVP (Minimum Viable Product) is a double-edged sword that focuses your engineering and product management priorities, but also may steamroll user priorities. An MVP that misses ‘desirable’ will risk the unintended consequence of poor user adoption. Instead, MVP’s should focus on what constitutes priority, need, and desire from an understanding of user context, behavior, and scenario. The focus should shift to the MDP (Minimum Desirable Product).
Where MVP went wrong
The MVP concept comes from the Lean Startup (book by Eric Ries). Ries emphasized meeting user needs and failing fast. For Ries, this meant quick prototypes and rapid user testing. Unfortunately, like many Silicon Valley UX teams (and authors), his definition excludes the important user needs discovery process that is part of the ISO and industry-standard Human-Centered Design method.
It is important to trace the source of our MVP craze to understand the squiggly use of the MVP approach by teams globally. Simply put, teams are leaving out the essentials. If “build, so you can test and fail fast,” is the understanding, no wonder UX comes last or later in the typical MVP decision process! Technically Lean Startup says Build-Measure-Learn. Instead, a good Lean UX approach would start with Learn first (capture user goals, needs, pains etc), then define MVP, then prototype and test and adjust the final MVP candidate based on that failure-protection approach. So the adjusted-for-UX approach would be Learn-Build-Learn-Measure.
Viable to whom?
Software engineering teams have interpreted MVPs as the minimal fail point (or effort) to undertake. Many MVP’s imply user priorities are present. At Experience Dynamics, we find user priorities not present in most cases. Instead they are imagined, namely, with an internal set of priorities. Through implied urgency and priority, vetting what’s viable from a user’s point of view is often absent.
A Lean UX approach can help define what users think they need vs actually need in a feature (leaning on the actually need portion). Teams can determine this by observing and interviewing users and hearing about the problems they want to solve, and observing them either coping (without your product/service) or fumbling their way through your current offering (as in a redesign). This can involve informal user testing combined with interviewing. Literally having the user show you their regularly used features while describing their goals and needs helps you understand their context of use. This blended interview (show me + tell me more) can yield powerful insights into their “desirability criteria”. Note: See the webinar and bootcamp offer at the end if you need more on this.
Minimum Desirable Product (MDP)
Definition: Minimum Desirable Product is a Lean UX approach to guiding product and engineering priorities by bringing in what is of the highest value and priority for users. This is based on problems users are trying to solve, real pain points, and of course, perceived user needs and desires.
As noted above, the problem with MVP’s is that they are based on internal priority. Excluding users from MVP decisions leaves products and services in danger of poor user adoption, MVP or not. Often MVP’s focus is on usability fixes. Instead of strategic pivots, they end up being tactical for users, though oftentimes very strategic for the business. Striking a balance should be any organization’s goal.
MVP lives inside a User Story (feature or usage scenario, usually internally defined) and an Epic (general use case, collection of stories) framework. Instead, a good Lean UX process requires a Saga (strategic view and the wider context of the problem space) to contain the Epics which contain the Stories. The outer-layer Saga is the missing link that brings wider context clues to user priorities. From there the right Epics and the right Stories can be prioritized to scope the MDP.
An example of accessibility
In uncovering what’s desirable without business constraints, MDP’s can determine feasibility from a user perspective. For example, we asked ourselves a few times on e-commerce ‘Find a Store’ features: “Can a blind user even interact with this map because it is a visual paradigm?” In Google Maps’ case the answer was “No” up to only a few years ago. It now supports screen readers, and therefore users with visual impairments. It took them 15 years to make their Maps tool accessible. They even recently added ‘wheelchair accessible transit markings’ for certain cities.
Why the big delay? The development was clearly not viable. What this meant was that within the sites using the API, (several of our client e-commerce projects), nobody stopped to think that an inaccessible map (visual object, the map itself) would require a deliberate layout (versus a visually pleasing one, or a random one chosen by developers or your agency). Laying out the map + search for a store page so that the map was not the first object the screen reader encountered would allow users with screen readers to actually access results or to know, “Yes, there is a store 2 miles from me”.
Again, first, determine user feasibility, then vet it for technical feasibility.
From MVP to MDP!
Instead of what’s minimally viable, we should be talking about what’s minimally desirable for users. That’s right, go ahead and change your language now! (Hint: It’s a great Sprint meeting opener). At least viability needs to include what is feasible and what is desirable (or urgently needed by users). Deciding what is MDP should come from insight into user needs, context of use, pain points, and of course highest value features and functionality.
MVP priority should be defined by UX Research, in particular Field Studies, Diary Studies or user interviews (online and remote research works too, especially during pandemics).
Determine what is desirable
To illustrate, consider the photo above, where a car buyer is purchasing a car. An Minimum Desirable Product decision approach might tell us the car buyer persona only cares about seating comfort and the noise-canceling environment because she spends a lot of time in her car making calls (many salespeople and commuters do this in America). This shapes what is desirable for her. In a typical MVP approach, the manufacturer might focus on an MVP decision on the sound system and sunroof because those are obvious emotional aspects of owning a car. But the user does not care about sound unless Bluetooth is seamless, or connecting a phone is super simple. The sunroof is nice, but that’s a secondary purchase criterion.
This is based on a case study for which Experience Dynamics was involved in a redesign of a major car buyer portal (used on Cars.com; AutoTrader.com; eBay Motors). In that case study, two-thirds of personas cared about the emotional value such as the number of cup-holders for their children and didn’t notice technical specifications. The engineers thought to exhibit tech specs was an obvious need. At least it was obvious to everyone in the company. Who buys a car without getting under the hood? Most people, it turns out, do. Consumers do not look under the hood. They are not expert in the technical side of how cars work.
Key considerations for MVP decisions
Defining the right user priorities is critical for your UX strategy and for bringing an MDP approach to your MVP feature definition. However, there’s another layer that is paramount and ought to be realized early on: how the MVP features act and are displayed for the user. This is where good Interaction Design is important for presenting features in a way that engages with users in their context. An example from a recent user interview: the user has an Apple Watch and a Fitbit. She uses her AppleWatch for heartrate monitoring, and on her other arm, her FitBit counts steps and sleep. However, the Apple Watch does both of those things. As it turns out, she prefers the layout of the FitBit for those other data monitors; it is more motivating than the Apple Watch.
When should MVP direction be set?
There is also an issue of timing. When should MVP direction be set? Many dev teams specify an MVP at the start and then look to UX to support that all-important goal. This is backward. Again, UX early-on can guide an MVP toward what a more balanced definition of viability– namely one that involves user priorities and user adoption essentials. MVP direction should hold off until user priorities are clearly identified. Any product manager looking to leverage smarter Lean UX processes should take notice.
MVP decisions should be informed by UX process. Good UX process includes field research or discovering Sagas (capturing the wider Customer Journey direction). So MVP’s need to be baked after User research, not before!
Viability should then be determined after desirability is explored and articulated (with proof from users) into a Minimum Desirable Product. Feasibility can be evaluated both from the engineering perspective after the user’s feasibility is evaluated. Doing this can save enormous amounts of wasted MVP effort.
Want to learn more?
For more UX process tune-up mentoring, get on the early access list for Frank’s VIP Inner Circle: www.uxinnercircle.com
