The MVP - ProductFTW #61
Hint: It's NOT the Most Valuable Player
One of the great blog posts on product management is Henrik Kniberg’s 2016 post on “Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable”. You should go read Henrik’s blog post (and then come back and read this one, too).
His post includes an important drawing trying to describe how to think about MVPs:
I’ve spoken about this so much with my team, we all know it as the “skateboard graphic.”
The way I usually summarize the graphic is that you need to think about what problem the user is trying to solve (see ProductFTW #12: Determining the Problem to Solve) and find a usable partial solution, rather than just building parts of what you think is the ultimate solution.
In this example, if the problem is "I need to get somewhere fast, and carry things with me," then a wheel doesn’t do anything. However, a skateboard, while not a car, does get you where you are going faster than walking and with a greater ability to carry something.
Over-used Terms
The phrase “minimum viable product” (MVP) is overused because it’s often hard to get folks to agree on both what “minimum” means in any context and what makes something “viable.” Many people use MVP as the shorthand for the first thing they are willing to ship and make available to the public. Some folks use it to refer to intentional beta products or test products. Folks love to quote LinkedIn co-founder Reid Hoffman’s saying, “If you are not embarrassed by the first version of your product, you've launched too late” as a way to justify shipping partial products. [Ed. note: We couldn't find the original publication of this quote, but here's an essay Hoffman wrote saying he coined it in 2007.]
We spend a lot of time with our clients discussing how to align on internal tests, external tests, and public launches as a way to talk about what each phase is. Since the term “MVP” can mean different things inside a team, everything must be crystal clear.
It’s All About Shipping
In startups and in new projects in big companies, many projects are trials. It’s unclear if the product being built will be a winning solution, so there is a natural tension to limit the amount of investment made to get the product to market to test it. I am also a huge believer in the value of constrained capital, which drives creative solutions (necessity being the mother of invention, and all).
If you don’t have an external deadline or a clear definition of your milestone versions, you could be stuck in build mode forever. For decades, I have been arguing with clients and business leads about whether a product is “ready” or not.
If we go back to basics, these products are designed to solve a problem. So, we need to figure out what the simplest version is that solves the problem.
I’m not sure that a skateboard really solves the problem of “I need to go somewhere fast with stuff,” and it’s a bit silly of an example, so I’m going to use Wallaby as my example.
Wallaby 1.0
The core problem the Wallaby app was trying to solve was “I can’t remember which credit card to use at which store to maximize my points.”
The solution was to tell people which card, amongst those in their wallet, to use at a store as they were standing at said store (it was an iPhone app to start). To do this, we needed to know:
- Which cards were in their wallet
- How each of those cards worked
- Where they were shopping
- What type of merchant it was
We also felt that for version 1.0, people needed to be able to log in and save their data.
That’s the MVP (or initial launch). We had a few key components:
- Sign-up/Login (Authentication)
- Wallet Building (Picking Cards)
- Card Database
- Geo-location Services
- Recommendation Pages
We made a lot of shortcuts in each area:
- Authentication - you couldn’t change your password or email address
- Picking cards - this just worked poorly!
- Card database - we started with 600 cards, but in reality, we needed 2,000 (we didn’t know)
- Geo-location - this worked OK, but we were guessing at a lot of categorization
- Recommendation pages - we didn’t explain the recommendation, we just gave it
The app was embarrassing in some ways. Who ships an app without the ability to change your password? Me! We were totally overwhelmed upon launch with “I can’t find my card” and “You don’t have my card.” Some of this was due to the bad search in wallet building and some due to the small card database.
(Not only was the app an MVP, but so was the admin tool. It took 20 minutes to add a new card to the database, which was such a problem that the whole team pivoted for a week to improving the admin workflow of adding new cards.)
Wallaby 1.0 was a great initial launch, though. We had thousands of users out of the gate and a ton of feedback and data to learn from.
Tiny Solutions
Wallaby 1.0 was successful because, for most users, it solved the core problem. It was missing enhancements (or even basics, like "change password"), but it did recommend the best card to use at the store at which you were shopping. We were able to add those other features rapidly and build much more complexity, responding to our users' needs over time. (Did you know that many people want to value their points differently than we did? We didn’t. We built it later, though.)
So when you’re thinking about how to align your team against the MVP (or whatever you call it), be ruthless about focusing on solving the user’s problem in the smallest way possible and ignoring some of the things you normally feel you must have. You can always add them later.
About ProductFTW
ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.
Part of the Product Requirements Field Guide — ProductFTW's collected essays on the six phases of writing requirements, from problem definition to launch.