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.
schedule Submitted 1 year ago
People who liked this proposal, also liked:
Craeg K Strong - Kanban Antipatterns: What You Don’t Know Can Hurt YouCraeg K StrongCTOSavant Financial Technologies, Inc. d/b/a Ariel Partners
schedule 1 year agoSold Out!
In this interactive workshop we will examine multiple examples of Antipatterns observed in real-world Kanban boards. In each case we will identify the issues and discuss ways to improve the situation. We will review a number of better alternatives and see how the improvements map to the core principles of Kanban such as visualization, managing flow, and making policies explicit. Brand new to Kanban? Learning by example is a great way to get started! A long-time Kanban veteran? Come to see how many antipatterns you recognize and help firm up our Kanban Antipattern taxonomy and nomenclature!
Kanban is an extremely versatile and effective Agile method that has seen significant growth in popularity over recent years. Kanban’s flexibility has led to widespread adoption to manage business processes in disparate contexts such as HR, loan processing, drug discovery, and insurance underwriting, in addition to Information Technology. Like snowflakes, no two Kanban boards are alike. The downside to this flexibility is there is no well-known and easily accessible library of patterns for designing effective Kanban boards. Like Apollo engineers, teams are expected to design their board starting from first principles. Unfortunately, sometimes teams get stuck with board designs that may not provide the visibility and insight into their workflow they hope to see. Worse, some designs actually may serve only to obscure the situation. Working within the limitations of an electronic board can exacerbate the problem even further. Is all hope lost? Certainly not!
Let’s learn more about effective Kanban system design by examining what to avoid and why. Learning by example is effective and fun!
Pete Oliver-Krueger - Vulcan is Dead and You're Next: How Ignoring Emotions Can Torpedo a Promising EnterprisePete Oliver-KruegerHolistic Agile Management ConsultantLithespeed
schedule 1 year agoSold Out!
Are customers beating down your door before the product is even ready? Do you have an inexhaustible number of new ideas on the horizon? And are your teams cranking them out month after month? If you answered no to some or all of those questions, then... your employees are probably afraid of emotions, and it's standing in your way.
Yes, I did just say that emotions are the thing in your way.
And you're not alone. The Age of Reason brought us Scientific Discovery, which is vital to continued survival, for people and companies. It inspired the Industrial Revolution. We reached for the stars, and touched other planets. So we raised up idols like Mr. Spock from Star Trek, and phrases like, "It's not Rocket Science". The Toyota Lean Movement inspired additional data-driven revolutions like Agile and DevOps. We automated our factories, and our stock market transactions. We created machines that can learn, and cars that can drive themselves.
And... we tricked ourselves into thinking that WE also became logical in the process.
But we're still human beings. In 2002 the Nobel Prize was awarded to two economists for research that proved that the decision making part of our brain is not connected to the logical part of our brain. Decision making is still done with our emotional brain. The emotions of your customers prevent them from buying. The emotions of your managers prevent them from making the right decisions. The emotions of your employees prevent them from delivering great ideas. And you can't just remove emotions from the equation. You must understand them, embrace them, and journey through them, to get to the other side. And on that other side you will coincidentally find our old friend, Reason.
If you don't start embracing emotions, talking about them, and designing for them, then you will be left behind. It's what makes Apple and Amazon successful. (It's why Donald Trump got elected.) And it's why your products are failing.
Pete Oliver-Krueger - Choose Your Own Agile Adventure: A Holistic Vision of Business AgilityPete Oliver-KruegerHolistic Agile Management ConsultantLithespeed
schedule 1 year agoSold Out!
Having led or assisted on multiple whole-organization Agile Transformations, I know it can be a difficult road to navigate. There are many flavors of Agile, each with their own dictionaries of common Agile terms, often in conflict with each other. Agile coaches can give you widely different advice. And on top of this there are different levels of experience throughout the organization, so some employees are overwhelmed while others are bored.
Are you struggling with your Agile Transformation? Have you ever rolled out a new technology or a new practice that worked great for one team but fell flat with another? Do you have some teams that just aren’t getting any better? You’re not alone.
The reason is psychology. Some organizations and some teams aren’t ready. Others, like Icarus, fly too high, too fast, and crash and burn. In my practice I started noticing an overlap, between the Agile landscape and a 40-year study on human social evolution I had been exploring. Now, several transformations later, I can show you how to spot the patterns, and engineer your own Agile Transformation.
In this workshop we’ll walk through and self-assess your organization across 4 levels: Team Value Delivery, End-to-End Team Alignment, Data-Driven Market Analysis, and Culture/Mission. We’ll use a simplified form of an assessment tool called the Agile Transformation Roadmap that you can take with you as a way to plan your own Agile Transformation adventure.