MVPs Suck! Why this latest buzzword is such a pain in our *££€$$!
It’s the latest and greatest business bingo term, the Minimum Viable Product, or MVP! It even has its own children now, like Minimum Loveable Products (M♥️Ps), Minimum Marketable Products (MMPs), and Minimum Marketable Features (MMFs). It’s made it up to the executive level, and almost every organization I work with these days has at least heard of the MVP.
But almost no one actually does it right. Most just map the name onto old Project Management concepts of “this is what I want in my first release”. Like Agile itself, MVP is a mindset shift. It’s not like anything most of us have ever done before.
- Do your “MVPs” take less than a month to build? If not, you’re doing them wrong.
- Do your customers pay you to build your “MVPs”? If not, you’re doing them wrong.
- Do your “MVPs” make your users light up with joy? If not, you’re doing them wrong.
I'll show you a build and release prioritization technique, based off of Lean Startup workshops I’ve been running since 2010, that can be done in hours - not days - and which will produce a true Agile Design that your teams can implement, in true iterative fashion.
Outline/Structure of the Workshop/Game
This presentation is a new evolution of a previous talk I’ve delivered. The MVP portions of my previous talk on how “Emergent Design is not Agile” were the parts that people kept asking about, and so I wanted to spend more time on them.
Introduction (10 minutes)
I like to set the stage for MVPs by talking about the reason why they exist. It begins with a story about a large project for the Air Force. After about 6 months it was deployed, only to find out that half the user base couldn’t use it. Nobody in 6 months remembered to tell us that they didn’t have access to secure network the system was built on.
This sets the ground for emphasizing how important it is to get something in front of users and do usability testing. I tie this into brain biology and how we funtion as a difference engine - we notice what’s different than the usual, and ignore repetitive details. This means that most-important, fundamental details of our customers jobs, then things they do multiple times every day, they don’t remember to talk about, because “of course the system should do that.” It’s nobody’s “fault”. It’s not bad design or bad requirements gathering. It’s just human nature.
I then offer that to counter this biological instinct, you have to put things in front of users as frequently as possible. The more times you can get user eyes on a product during development, the better the product will be.
Workshop Activity in 4 Rounds
Here’s where participants start the hands-on acitivites.
Round 1: User Story Mapping (10 minutes)
I start with a quick 1-pass-version of Jeff Patton’s “Map Your Morning” Exercise, having tables use sticky notes to make a list of all the activities they do to get ready in the morning.
Round 2: MVP - Version 1 (5-10 minutes)
I then ask participants to label each sticky note based on frequency:
- Used by Most / Most of the Time
- Used by Most / Some of the Time
- Used by Some / Most of the Time
- Used by Some / Some of the Time
The goal here is the realization that we don’t need to serve all of our customers at the very beginning. We also don’t need to serve all of our customer’s needs. It’s ok.
Round 3: MVP - Version 2 (5-10 minutes)
But then I say that this is not an MVP. “Imagine that your alarm didn’t go off, you need to get to work, but you only have 15 minutes to get out of the house. What do you cut and what do you keep?” Participants are forced prioritize based on value towards an end goal, getting to work.
Round 4: MVP - Version 3 - The Real MVP (5-10 minutes)
I wrap up by throwing them 1 more curve ball. I say, “But this also is not an MVP... Imagine that your alarm didn’t go off, you wake up, and you only have 5 minutes to get to work? What do you do?” (This final step they just call out.) Usually answers are down to “Throw on some clothes, grab a piece of gum [audiences always prioritize fresh breath], and jump in the car. Get someone else to take care of the kids [or pets].” Or, “I just dial in from home and skip the commute.”
I love this last version because it allows me to talk about “Frakensteining”, a form of prototyping where you use someone else’s software, and only build what’s unique in your solution, or “Wizard of Oz” and “Concierge” prototypes where you manually do most (or all) of the work, with the goal of verifying that the outcome is valuable enough that people will pay for it.
The end result is an understanding that a Real MVP is something that can be done in 1 or 2 sprints that can be put in front of a customer for their feedback. Then you do the next MVP, then the next MVP, etc., always verifying value of each MVP.
- Learn the true definition of Minimum Viable Product
- Understand the importance of User Story Mapping
- Apply 3 methods of User Story Prioritization
- Create a product Roadmap
- Understand the landscape and importance of prototyping tools
Product Managers, Product Owners, ScrumMasters, and Agile Coaches
Prerequisites for Attendees
Knowledge of basic product design and Feature definition. Experience with User Story Mapping is a plus.