In a way, Amazon’s journey is similar to how an MVP’s should be.
The multi-billion-dollar behemoth was started in a garage, with just the bare essentials in place, similar to how basic an MVP needs to be to start off.
Did you know that Jeff Bezos zeroed in on the name ‘Amazon’, the biggest river in the world, because he had a vision of creating the biggest company in the world?
But how did he start building his dream company? By just selling books.
There’s a lot to learn from the Amazon story. In this article, we’ll cover just five of the many things we can learn from Amazon about building an MVP.
- On-point product strategy
All of us are familiar with the arrow from the ‘a’ to the ‘z’ in the brand’s logo. It represents that the company sells everything from A to Z.
But when Bezos started out, he wanted to start with just one thing. If it worked, he could just scale it, he must have thought.
He had made a list of 20 items that he could sell, of which ‘books’ was an option. Why books?
Bezos says, “I picked books because there were more items in the book category than in any other category. And so you could build universal selection. There were 3 million in 1994 when I was pulling this idea together — 3 million different books active in print at any given time. The largest physical bookstores only had about 150,000 different titles. And so I could see how you could make a bookstore online with a universal selection. Every book ever printed, even the out-of-print ones was the original vision for the company. So that’s why books.”
We know that product strategy plays a big role in the success of an MVP. Bezos’s product strategy was crystal clear and on point.
When Amazon started off, a bell would ring the moment a sale was made. The bell, however, had to be taken down after a few weeks of Amazon’s launch, as it kept ringing constantly.
In its first month, Amazon sold books in all 50 states of the US and 45 different countries!
- Built only what they needed
Once the product strategy was clear, the Amazon team quickly came up with a basic prototype.
This MVP had just the bare necessities in place and is far from the Amazon, we know today. As we keep reiterating, they didn’t build what they didn’t need.
The MVP was lean and did only the ONE thing it needed to do. They just took one idea and stuck to that.
It might seem counterintuitive to many people.
Many product owners think users would ‘expect’ these features because a similar product has them. Or they probably believe that if their product has all the features of the successful one, people will start using it.
Built only what they needed
Jeff Bezos knew better. He knew the right way to go about it. And the results are there for us to see.
Not just Amazon, if you look at any successful company, you will notice that they did not build what they didn’t need at any given point in time.
Dropbox started with just an instructional video, Facebook started out as Facemash, with only the feature to compare two faces and rate the better one.
- Built what they needed really, really well
Once the basic idea was in place, along with the strategy, Amazon built the MVP extremely well.
No matter how incredibly good an idea is, if the users find your product tough to navigate and difficult to use, your product will fall flat.
Built what they needed really, really well
Your MVP needs to be high on performance. In the case of Amazon, they needed their MVP to respond to user requests in a fraction of a second. Any longer, and it would have resulted in negative reviews, a ton of complaints, and a dissatisfied user base.
Another reason why it’s important to not build what you don’t need is that you can focus on only the features you need and build them really, really well.
Amazon did just that.
- Built usage, not features
If you visit the Amazon website or app now, you will see that there are a ton of features that you barely use. You probably use the search bar, the ‘Deal of the Day’ button, and a couple of other features at most.
Frankly, it’s quite feature-heavy. Amazon’s MVP did not look like that.
Built usage, not features
We have a principle at Akrity: Build usage, not features.
That’s exactly the principle Amazon also used in its MVP.
Their product only had features related to searching for, ordering, and tracking books. No less and more importantly: no more.
Building extra features might seem like a great idea (and many people are guilty of doing it), but in reality, it is extremely detrimental to your product.
Firstly, you are taking your docs away from the core feature and spreading yourself too thin by trying to add unnecessary features.
Secondly, you are introducing bloat on your product, which will affect its performance.
Thirdly, you are wasting time, resources, and budget on something that is absolutely not needed.
And lastly, you are taking a longer time to develop your MVP, which is a downright sin. It is imperative to move fast in the MVP stage and anything that jeopardises speed must be foregone.
Amazon did not aim to add any more features than absolutely needed and their MVP was lean, efficient, and effective.
- Quick Feedback-iterations-development cycle
One of the great benefits of developing an MVP is that it allows you to test your product in a real-life scenario without having to go all in.
You can receive user feedback and reviews and tweak your product accordingly — trying new features, adding features they want, altering features that can be improved, and culling features that are not required.
Quick Feedback iterations development cycle
Amazon did an excellent job of this during its MVP phase.
They gathered feedback from as many users as possible and kept iterating their MVP. They kept fine-tuning it and calibrating it to their user expectations, making their product better and better, in the process driving costs down and margins up.
Speed is the name of the game when it comes to the MVP stage. Amazon’s speed of iterations and rapid development helped them hone in on the keys to their product’s success.
Studying successful companies gives us an insight into actions we can take today to succeed in our business. More often than not, product managers try to rely on their own logic instead of what actually works.
In a way, it’s like reinventing the wheel. It’s not needed and the chances of their success are slim.
It’s best to learn from the example in front of us and use the experience of others to our advantage and that’s what this article aims to do.
Which other company do you think nailed the MVP phase? Mention in the comments below.