Product ~ The MVP isn’t for everyone
My name is Dutch. I’m a Strategic Product Manager, a lifelong geek and military veteran who lived 50 years before being diagnosed with ADHD. My topics may vary from article to article, but feel free to subscribe and hang on for the ride!
(PRODUCT ARTICLE #1)
The MVP may not be for everyone, but the MVP+ is.
One of the biggest challenges I’ve had is shared among most Product Managers, and that’s convincing stakeholders about what we were defining as the Minimum Viable Product (MVP).
Side Note — There’s a trend of not calling something the MVP, but rather the “Minimal Lovable Product” or MLP. I’ll touch on this more in a bit, because it will further emphasize my point that these are not the same thing, and whether you call something the MLP or not, you will always have an MVP.
….and the MVP is not for everyone.
According to Wikipedia, the MVP is : “is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.”
According to Technopedia, the MVP is : “a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.”
Product Adoption Curve
Both of these definitions call out “early” customers and adopters. These make up the first two stages of what marketers and product professionals call the Product Adoption Curve.
Phase 1
The first stage of developing the product will interact with “Innovators”. This is commonly estimated as 2.5% of those who would potentially pay to have your product. This number isn’t set in stone, but merely to portray the concept that there’s not going to be a lot of people using the product at first.
Also to note, some products may not have any customers who pay, whether the product is free, or for internal users.
“Innovators” are those who help with new ideas. The stakeholders and product team can sometimes be in this group. There may only be a handful of other people who are shown the initial product or given access to it. Regardless, this group will provide valuable feedback on how well the product is being received, and what else it needs to be viable for users, (paying customer or not).
Phase 2
The MVP is really for the Early Adopters.
The MVP isn’t going to be perfect.
Early Adopters know and accept the imperfection. Anyone customer-facing and in contact with these early adopters should confirm it.
The MVP is intended to provide insight to customers, who are willing to provide feedback on what will truly solve their problem.
Software is never complete, unless a decision has been made to retire it. This is why the MVP is a “v1.0” version, allowing lots of room for incremental versions to increase in value as the Product evolves. Sometimes, the Beta version is only a “v0.5" if it’s really just a prototype that the team desires feedback from external folks.
The MVP is focused on being a tool to gather feedback. Maybe that’s about how well the product solves the targeted problem. Maybe it’s discovering what other features are desired. It’s important to know how intuitive the product is, and how much value the prospect or customer finds in it.
For most companies, the MVP will confirm how much customers would be willing to pay for it, once it’s slightly more mature.
Phases 3 & 4
The Product Roadmap will not just define MVP, but the MVP+.
The Early and Late Majority take up an estimated 68% of your customers. They get the MVP+, whether it’s a
Corrective enhancements and added features are targeted at this majority, and actively being built by Engineering while talking to the Innovators and Early Adopters.
The Roadmap for any startup Product should include the MVP 1.0 and the MVP+ versions that will be available to the majority, whether that’s a v1.5, v2.0, or later. Every team needs to figure out at which point the MVP+ is ready for the masses. How and when that happens is a topic for another day.
Phase 5
The “Laggards” aren’t really a focus group for the MVP or the MVP+.
These are the folks that won’t buy-in until the majority has accepted it and is talking about it. They won’t even know what the MVP was, because the Product has grown into something of value.
The Laggards are the ones that accept the MLP, because other people already love it. Until that point, they don’t even give it a second thought.
HOWEVER, although this isn’t a group to focus on in the early stages, they shouldn’t be ignored or forgotten in the long-term. This minority segment still needs to be considered, as they may have special requirements or use cases.
Their needs are just further down the Roadmap than the MVP.
SUMMARY
When negotiating priorities with stakeholders, make sure everyone can agree on what makes up the MVP for those early adopters, and then what immediately follows in the MVP+ for the majority of users. The stakeholders will always have the MVP+ heavy on their mind, and because of their passionate desire to have people benefit from the new Product, they feel it should all be included together.
The MVP is the appetizer, while the MVP+ is the main course.
A fast food restaraunt can give you a “combo meal”, but it never turns out like the pictures. Fine dining (and software development) takes time, care and attention to details.
I suggest you make the MVP as v1.0, and the MVP+ as one or more versions before reaching v2.0. This is critical when dealing with non-technical stakeholders. The amount of development that goes into the v1.0 can take months, perhaps even more than a year. They will suspect that going from v1.0 to 2.0 will take just as long as from 0 to 1. Making smaller incremental releases will reinforce that although it will take time to make the MVP+, it will not take as much time as the MVP.
Relative ADHD Superpower
Stereotypically, people with ADHD prioritize work and tasks with “Now” and “Not Now”. We are hyper-focused on what needs to be done now, while everything else goes in our brain’s backlog. Some people are more efficient at this mental juggling than others, but the fact that we have technology that can keep a prioritized list for us alleviates the need to keep it in active memory.
The definition of what needs to be done now can be changed, but it really needs to be justified with reasons of why something else becomes an equal or higher priority to what’s already in progress.
Your Technology Product Philosopher
~ Dutch
NEXT ARTICLE —
Building a Product Team (Link will be available when published.)
Building the team before defining the product is putting the cart before the horse.