How to put the minimum in MVP

A minimalist metaphor for product management

The takeaways

Consider the following when determining what is truly minimum for your MVP:

  1. When building v1 consider making a few decisions up front to provide constraints that can eliminate many decisions later.
  2. When building a feature for your MVP, don’t only consider the cost to build it but the cost to test, maintain, support, and market it.
  3. It’s better to add a feature post MVP than to remove an MVP feature after launch.
  4. Product development is ultimately more chaotic post launch, so build in buffers.
  5. It’s worth deeply considering whether you really need as many features as you think you do.

The story

When Rachel (my wife) and I decided to move to Uganda to join SafeBoda, we wanted to make the most of it by taking 2 months to travel between jobs.

Our plan was to gradually make our way to Uganda. First through Europe, then north Africa, then west Africa (where I had previously lived for 2 years) and finally to Uganda.

Knowing we would be traveling by plane, train, bus, and walking, we decided to bring only that which we could hold in carry-on sized backpacks. The price of shipping anything to Uganda was so prohibitive, that we decided to make do with what we had and only purchase things we really needed when we got there. Since arriving, we’ve only purchased a handful of items, such as pots and pans, but no new clothes.

Previously, we had always been intrigued by the idea of minimalism, but had struggled to actually implement it — endlessly deliberating whether a piece of wardrobe should stay or go. Making the item-by-item decision to get rid of things was like pulling teeth. This trip provided a wonderful opportunity to simply “rip the bandaid” and start from nothing. In retrospect, it was a very helpful approach, and I would recommend it to anyone seeking become a minimalist. The benefits of finally embracing minimalism have been tremendous because I spend much less time managing and worrying about stuff and invest the regained time, energy, and focus in people and efforts I find meaningful.


But that’s not what this post is about. I’d like to share some things I learned from this experience that I believe are important to keep in mind when building v1s of great products. Though these ideas are not universally true, I believe they’re helpful to consider when determining what is truly minimum in your MVP:

(1) It must fit in the bag: using the power of focused constraints

When my wife and I were deciding what to bring on our journey, we knew everything needed to fit into two carry-on sized backpacks. This initial constraint was extremely helpful when choosing what to pack for our trip. We didn’t need to spend time considering things we would have loved to have but knew wouldn’t fit, such as my guitar or a second laptop. A similar approach is helpful when building your MVP.

Agreeing on product constraints in-line with your vision up front allows your team to make a million small decisions by making a few big, early ones.

These constraints can be in the form of customer problems to focus on, time goals, platforms, etc. While you may later realize that the assumptions that led to these constraints were wrong, making them in the first place gives your team focus that leads to these faster learnings.

(2) Don’t bring it if you don’t want to lug it: assessing the true costs of features

Lugging our bags while crossing the border from Liberia to Sierra Leone.

Although everything needed to fit, we still had numerous discretionary decisions to make on what we should try to squeeze in and what we would leave without, such as the next book on my reading list or my fancy electric toothbrush. Ultimately, we used this heuristic in making these decisions:

“Is this something worth lugging thousands of miles around Europe and Africa for the next two months?”

If the answer was not unequivocally “Yes”, then it was easy for us to say “No”. I love this as a metaphor for which features to attempt to “squeeze” into your v1 product. In my experience, I’ve often seen myself and other product managers severely underestimate the amount of time, effort, and resources required to build a feature, let alone test it, technically maintain it, operationally support it, market it, etc. I think asking yourself, “Do I want to lug this feature around for thousands of metaphorical miles?” is a good practice when deciding whether to include something in your product.

(3) You can buy it on the road: it’s better to add later than add now and remove later

This is me wearing the cursed jacket on Valentine’s day. There are no pictures of it from our trip because I never wore it.

When it was painful to leave something behind, Rachel and I would console ourselves by saying, “we can always buy it on the road.” I knew of ownership bias and the endowment effect (essentially, that you over value things you own) from behavioral economics classes, but experiencing it in a powerful way was a good lesson. Rachel, typical of her thoughtful self, packed me a jacket, despite my insistence that I would be fine. We both rued the decision. I never wore it, and it was always the last thing that we just couldn’t fit in the bag. Many a times did we run to catch a plane or train with me holding that dumb coat in my arms. But we just couldn’t make ourselves get rid of it (What if we needed it?). This lesson is nothing new to product managers. I think we’ve all experienced how painful it is to deprecate features. That’s why, when building v1, I believe it’s important to keep this lesson firmly in mind:

It’s much better to add something you need later than to add something you don’t need upfront and remove it later.

(4) It just won’t fit: your world pre-launch is definitely different post launch and the importance of buffers

Back to that dumb jacket. It did fit the first time. But never again. Why? Because the first time we packed, we had weeks to find the optimal arrangement of items. While repacking our bags while leaving our Airbnb at 5 AM to catch a flight, we did not. We should have foreseen this and built in a buffer by not packing to the brim. The same can be said when building your MVP. You might know you’ll have the theoretical capacity to maintain, scale, and support everything you’ve built before you go live, but if you get traction, your world will become much more complicated with more time pressure. I think it’s always wise to “build in a buffer” with what you decide to include in your MVP.

We still don’t have a trash can: you really don’t “need” as much stuff as you think you do

Since arriving, Rachel and I have purchased a few things to add to our two-backpacks-worth of stuff. But we still have not purchased a trash can. We have developed a lean, inventive system to deal with trash, and we’re doing well. If you would have asked me if I could have ever lived without a trash can before, I would have said, “No way!”.

It’s a good reminder to me that you don’t always need the things you think you do, especially when building MVPs.

Life experiences can be a good source of analogues and mental models for product development. What experiences in your life have caused you to reflect on product principles? I would love to hear them! As always, I would also love to hear any critiques or disagreements!

Note: Some of the ideas above, may suggest that I oppose product experimentation. I don’t. I’m a very big advocate of it. But v1 is a prerequisite to running any sort of reliable experiments. So as said above, consider these ideas as guidelines when considering what is truly minimum in your MVP.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.