Forget About MVP. It’s All About the MTU

(A version of this post was originally published on Medium, April 2016)

Let’s all agree on one thing: Creating elegant, desirable and profitable user experiences is hard. Damn hard. In fact, in most cases, it’s so damn hard it’s impossible. We can list hundreds of reasons why it’s so hard, not the least of which is, it’s a constantly moving target. Can we really say there’s even such a thing as an elegant, desirable and profitable user experience?

I’m the last person to apologize for anything less than a world-class experience. But the reality is overwhelming: very few companies are capable of delivering world-class anything. As a UX strategist, I have to find a way to help my clients up their game, even if it means falling far short of what could be achieved.

A buddy was chatting with me the other day about a nasty little problem he’d been asked to resolve: designing a “simple” pop-up window to notify users when a call was coming in. Simple, but nasty. Not a major UX design. Not some disruptive technology that was going to change the world. All in all, a pretty small exercise, typical of the sorts of things we are asked to look at every day.

Let’s forget about the fact that their system already had a pop-up solution that didn’t work. Meaning, it didn’t support their users’ needs and was universally ignored or disabled. In response to its lack of utility, his team had invested person-years in early development of a completely different approach to solving their users’ problem; a solution that had nothing to do with a pop-up. But now, after they’d invested all that time, the company had decided not to pursue the alternative approach for reasons unknown (but likely financial). His team was asked to revisit the pop-up.

Nasty.

He was at a loss as to how to proceed. On further probing, he told me his team had a ton of research about why the existing pop-up wasn’t effective, and what specifically they needed to do to improve its utility. With all of that knowledge, the real question I had for him was: “What’s the problem?”

MVP. Now, before you swipe this aside and go on to the next startling article, let’s be clear: MVP is a fantastic idea. When executed as it had been originally intended, it can deliver wonderful results. The problem isn’t really with MVP per se, but with how organizations have twisted it into something very different from its original meaning.

As with many technologies, there is nothing good or evil about MVP. Instead, it’s how the technology is used that ultimately leads to a positive or negative outcome. For organizations that have not fully embraced UX as a strategic weapon in their arsenal, UX is just another user story potentially traded off against 20 other stories in the pursuit of MVP. How many product backlogs have user stories in them along the lines of “User wants an improved experience.”

Really?

And let’s just ignore the notion of emotion, delight and all of that other stuff UX is supposed to own, deliver and care about. For the sake of this story, none of that is a part of my buddy’s company’s definition of MVP. In fact, he and I mused, he already had an MVP: the original pop-up. By all accounts it was a working product that did what it was supposed to do: notify the user of an incoming call. But clearly, the MVP wasn’t close to an acceptable product.

So what was my buddy to do? He had all of the necessary research. His team had done all of the strategic thinking. It became clear during our conversation that the one thing he needed in the new pop-up was to cross the Minimum Threshold of Utility — MTU. In my buddy’s case, the MTU was obvious: the pop-up had to provide specific information contextualized to the users’ job role and to the caller. Those attributes were not present in the prior pop-up and without them, users wanted nothing to do with it.

Tweet this: A proposed solution is only an MVP when it crosses the Minimum Threshold of Utility (MTU)

For my friend, the MTU was obvious: it was based on the research he’d done the prior year, the complaints the company had been fielding, and the universal hatred of the original solution.

The problem with his company’s approach to MVP was their prioritization of the technology solution to the exclusion of the MTU. Just because they had user stories that included the word “user” in their template didn’t mean they actually delivered functionality that crossed the MTU.

Let me unpack that a little.

Product backlogs, by definition, are supposed to be user-focused. They are called user-stories after all. Stories need to be written from the users’ point of view to accomplish a task, often without reference to how the story is accomplished. (I’m reminded of my mother’s explanation to me when I was very young about how the car worked: “I push this pedal with my foot,” she’d say, “and lots of squirrels run around in cages in the engine.” Naturally she didn’t believe that, but as far as she was concerned, that’s as much as she needed to know to make the car go.)

User stories describe tasks real users want to accomplish, not minute descriptions of screen elements, gestures or the like. Users don’t care how they are going to get to their destination; they simply want to get there.

The MVP is all about crafting the smallest possible product definition the company can release to the market. It’s a foot in the door, not the final aspiration for the offering. Similarly, the MTU is all about the least amount of usability — utility — below which users won’t accept the offering. Can I even use the thing to do my job? Utility might be expressed in specific stories, but more frequently, it is expressed through the acceptance criteria. Maybe they’re physical performance criteria: screen must refresh within 11 milliseconds (a usability requirement based on how our vision systems operate). Or maybe they’re more detailed descriptors: Data filter X is preset to “A on, B on, C off.” In any event, the ACs are specific, measurable and demonstrable usability attributes of the story that represent the MTU.

Irrespective of how the MTU is expressed in the product backlog, it has to be present. Without it, the MVP is all about the technology and not a minimum expression of the users’ needs. I’ll restate the tweetable quote from above: If a proposed solution fails to cross the Minimum Threshold of Utility (MTU) it can’t be an MVP.

For my buddy, his quandary seemed to be resolved. By the end of our conversation, he had a game plan:

• Confirm with his technology team that they could build the MTU (a contextualized version of the pop-up)
• Confirm his users agreed with his concept of the MTU before his team built it

So, the next time you face the struggle of identifying the MVP, step back. What is the MTU? With it, you may not achieve delight, but you’ll at least cross the true minimum threshold demanded by your users.