Minimum viable (sometimes valuable) product is one of the least understood and most commonly misused concepts in product prototyping.
The story usually goes something like this: you're building something new or modifying something you already use based on a signal from your customer (or based on an idea someone had that seemed too good to pass up).
A big group of no less than 15 people get together and plan out a roadmap that has a ton of work in its first quarter, some big ideas in the next quarter, and market-beating-AI-driven-best-in-class perfection in the third quarter.
Someone creates a beautiful, 30 page PowerPoint presentation that summarizes the business case and the roadmap along with a ton of facts, numbers, and charts.
Then, the rational one of the group says: we need to go faster to hit a market window, can't we just deliver this one feature the next quarter? We need a MVP.
Typically, it's at this point that an engineer speaks up and says something to the effect that we need to have the fundamental data and services architecture (along with some key integrations) up and running to even deliver that feature.
After all, this is an innovative solution that disrupts your current pattern of delivering. Of course you'll need to transform your underlying tech stack.
Oh, and our current infrastructure is already bogged down in tech debt so we should use this as an opportunity to build anew.
After a week of discussion broken up by other urgent meetings that the team must attend to in order to run the business, you agree to a MVP -- which will take 45 days to build. Not bad, right? It's less than that one-waterfall-project-that-one-time that took over a year to complete. Seems minimal enough.
Here's the problem: if you were really serious about learning if the MVP will work for as little cost as possible -- which is the whole point of the concept -- you would've approached the problem differently.
Enter the mVP.
Microscopic Valuable Product (mVP): solve the surface of the problem WITHOUT needing any underlying engineering, as Jake Knapp of Google Ventures puts it in "Sprint".
The surface of the problem is where your solution meets the customer. Where they interact with your solution for the first time. At the surface, learning about 1) the value and 2) the usability of your solution is ALL THAT MATTERS at this stage.
You are not trying to learn about the feasibility of building the full solution or even parts of it OR the business support model you will need to deliver it. That comes later.
By creating a Hollywood-style stage set from Keynote, Powerpoint, a $50 Wix site, manual intervention, and a little bit of smoke and mirrors, you can test your entire concept with real customers in less than two weeks. And you only need to test it with about 6 customers (yes, 6) to be sure your idea works.
Really. It's really that simple.
Where most go wrong falls into four broad themes:
Committing to the roadmap too early. Your MVP has morphed into your first release of a solution to an unvalidated customer problem.
Never isolating the surface of the problem. Using an MVP to solve a problem too far downstream or too far upstream from the actual problem to be solved.
Including too many voices to define MVP. Perspectives matter, but when you're testing a revenue-generating idea for the first time, less is more. You don't need everyone in the room who has an opinion, just the experts. No more than 6-8 people.
PowerPoint Theater. Veiling the critical flaw of an untested, material issue with your approach to a customer problem under an avalanche of gorgeous slides and a roadmap.
Next time you run across someone using the concept "MVP" ask a powerful question: can you show me the surface of the problem this is solving and, if so, how might we test this in a week?
To go faster, go smaller. Microscopically smaller.
Comments