The problem with the term MVP today is that it’s used as a cop out. The temptation is to throw out the minimal product that you can ship.
Wikipedia’s definition is reminiscent of this approach, “just enough core features to effectively deploy the product, and no more.”
This can lead to a pile of excuses when the crappy MVP fails. As a result, many technologists now feel burned by the term.
But, this is completely against the spirit of the term. The term was born out of the agile & lean startup movements to emphasize shipping fast to learn.
A much better definition of Minimum Viable Product (MVP) is the version of the product that helps you test your most critical assumption.
It is NOT:
bad design
bad code
something that could harm the company’s reputation
Those are minimal products (MP).
So, the crux of the term is “viable.” A modern MVP, done right, is all about fast experimentation.
To actually learn, the MVP needs to be viable enough that others won’t question the learnings of the MVP. If they say the design was sub par, then it wasn’t minimally viable.
It also must be a “product.” A signup form or waitlist are proofs of concept. These are great to test demand, but they are hardly MVPs.
Let’s go through some examples of famous MVPs, to understand:
1. Amazon:
Bezos identified the risky assumption he wanted to validate was whether he could compete on online sales.
So, instead of buy a bunch of books and get a warehouse, he sold books he didn’t have. When customers bought them, he bought and shipped them.
Imagine how much more time and money it would have cost to buy the books, set up a warehouse & shipping network. It would have taken Bezos hundreds of millions of dollars and years.
Instead, he was able to test the critical assumption for competitive success in a few weeks.
2. Reddit:
The key assumption of the product was the ability to vote on content.
They shipped it in a few weeks!
No subreddits
No posts of your own
No comments
Just simple content submission & voting.
And the engagement was there! So they got data to continue.
3. Airbnb:
The key assumption was whether people would stay on air beds in other people’s places.
So Nate, working part-time, quickly shipped a simple site:
No payments
No map view
Just a few properties
But the demand was there - & the team got validation to continue.
Notice how each of these 3 famous MVPs were not cop outs. They were not badly designed waitlists. They were production ready products - done quickly to test critical assumptions.
This core spirit of MVPs should be a part of every startup & PM’s toolkit. If needed, avoid use of the term, as some people are anemic to it. But, you should undeniably seek to ship fast to test key assumptions.
Learning via real product is the BEST way to learn.
How Google Docs Took on Microsoft Office
Google Docs has over 2B monthly active users. It all started with the acquisition of a small team of 4 in 2006.
In the mid-2000s, AJAX technology was just released. It allowed quick, incremental updates to websites.
A few veterans from Intuit decided to create a company, named Upstartle, leveraging AJAX. They tried a few things. The one that got the most traction was writely.
writely had a killer feature: real-time collaborative editing. This developed a small but loyal following for the browser-based word processor. In one of the most underrated acquisitions ever, Google acquired writely.
writely would combine with two other acquisitions to become the pillars of Google’s productivity suite:
XL2Web → Sheets
Zenter → Slides
They were cheap: each acquisition was ~$10M. The three became GSuite, a browser-based alternative to Microsoft’s Office juggernaut.
Before 2007, Word, Excel, & PowerPoint had almost 100% market share. Finally, there was a competitor.
Users loved:
Being able to access their docs anywhere
Collaborating in real-time
Instead of pursue parity with Office, Google doubled down on these 2 differentiators.
In 2010, the company launched a big update that ratcheted up the collaboration. It added:
A sidebar to see who else was editing the doc
The ability to chat with those editing at the same time
Character by character edit updates
These were huge leaps.
In 2014, the team doubled-down on making docs available anywhere with standalone iPhone & Android apps. In 2016, the team added mobile comments to these apps. The apps became killer features.
And it all stemmed from the 2 differentiators the team envisioned 10+ years before.
Office365 has put up a good fight, but the loss of dominance is unmistakable. Recent estimates put GSuite head to head, in terms of monthly active users. Google created such a strong disruptor in the productivity market by pursuing Clay Christensen’s playbook.
Sure, Gsuite has less product performance. To this day, you can do far more in Excel than Sheets.
But, Google created a cheaper product - one especially attractive to different markets, like education & the developing world. It’s slowly then moved upmarket.
What can we learn from the success of Google Docs?
Acquiring small companies can be effective to expand into new product areas
Sticking to core differentiators creates an effective wedge
A reliable way to disrupt an incumbent is a cheaper product with less, but specific, performance
Plus: 21 Essential Reads for Every PM
If I could only choose 21 books every PM should read, these would be it:
Escaping the Build Trap by Melissa Perri
The Hard Things About Hard Things by Ben Horowitz
Inspired by Marty Cagan
Good to Great by Jim Collins
Continuous Discovery Habits by Teresa Torres
The Making of a Manager by Julie Zhou
Zero to One by Peter Thiel
The Innovator’s Dilemma by Clayton Christensen
The Design of Everyday Things by Donald Norman
Hooked by Nir Eyal
The Lean Startup by Eric Ries
Grit by Angela Duckworth
Shoedog by Phil Knight
The 7 Habits of Highly Effective People by Stephen Covey
Getting Things Done by David Allen
Empowered by Marty Cagan
Creativity, inc by Ed Catmull
Steve Jobs by Walter Isaacson
Crossing the Chasm by Geoffrey Moore
The Lean Product Playbook by Dan Olsen
Cracking the PM Interview by Jackie Bavaro
How would you then define what gitlab is doing. Namely a "minimal viable change". it just brings the same notion to features? So to go out with the smallest feature possible. Still good quality and good design, dadadada.. but only as much to test your assumption for its demand (aka desireabiltiy)? And if you see it actually is desirable you double down? I mean now that i wrote it it just sounds so obvious but tell that to people doing product who, in my experience, so often go down the waterfall route and only ship when its perfect, or in essence only shipping iteratio number x (where x > 1)... and by it totally leaving out their chances to not over engineer and not implement "waste" (aka stuff noone actually likes or wants).
Very cool breakdown. Refreshing.