"Can I make it smaller": practical MVP approach to building features

MVP is not only for startups?—?applying an “MVP Razor” to every feature you build can save you time and resources. We’ll explore this using examples from Groupon and Clothing rental products.

Problem statement

As a Product Manager, you surely know about the idea of MVP. Long story short, the thinking process is quite intuitive:

• We don’t know what customers want for real and how they’ll react to our offering
• We don’t have enough resources (time, people, funds) to build the ideal version of the product
• That’s why we build a limited (minimal) but still functional (viable) product version
• We invest more resources if it receives neutral to positive customer feedback (usage, purchases, clicks, ratings). If not, we… stop and find some other idea to pursue

The theory is simple. But why are there still so many delayed projects that invest so much time and effort into things users do not engage with? The source of the problem is the definition of “minimal.” Less experienced product leaders usually already have their mental picture of the product/feature in mind and pursue it. More experienced ones apply an MVP Razor to every step they do.

Introducing The MVP?Razor

The idea of an MVP Razor (inspired by Occam’s razor) is to approach every feature you build with the question, “Can I make it smaller while still preserving its essence?” The more senior the PM and the more complex their products are, the more often the answer to this question is positive.

Let’s consider the famous case of Groupon company. They made their fortune by connecting businesses with customers through deep discounts. For example, a spa salon in my area offers me a whopping 50% discount for the first visit. Wow, what a deal; I will try it for sure. It is also a “hit” for small businesses: one more lead, potentially converted to a regular customer after a tryout.

Pause reading for a second. Imagine you are the founder of this startup. How would you get to market with minimal investments (you have none)?

The founder, Andrew Mason, started with a simple WordPress blog where he posted “offers” every day. When someone was interested, he manually generated a PDF coupon and emailed it to them. There was no fancy technology, no payments, just a simple blog, and a few handmade scripts. They invested in complexity only after the team realized they had found traction. That’s the radical MVP razor in action?—?they cut almost everything!

Could this have gone wrong? Of course! For example, they might not have applied the MVP razor and invested in a complex marketplace system and double layered discounts, intelligent ML ranking and AI-generated descriptions, and other bells and whistles, and after two years of development, they could have realized that:

• No one cares about coupons because customers still understand it is just another way of advertisement
• Or another startup, Couponix, has already entered the space 1.5 years ago and won the market
• Or the product became so complex that customers do not understand how to use it

Luckily for Groupon, they had a clever (and lacking funds) founder who started small.

Although it was a company MVP, if you zoom in, you’ll see it consists of a list of features (website, coupon, redemption method, etc.) and decisions made for each of them. For example, for a website, the founder could have chosen to go big (build Android and iOS apps right away) or small (WordPress blog). This leads us to the next topic.

MVP Razor for a?feature

It is easy to start small when you have no resources. But if you are already in a medium to big company, you have a team and funding, and it is much more appealing to fall into the trap of building an overblown MVP. Let’s consider an example.

Imagine you are a PM in a clothes rental startup. You allow customers to exchange their looks every month for a decent fee. You quickly design a prototype and are ready to start development. Pause for a second and look at the picture. Is this the most minimal MVP we can start with?

Let’s examine the first two steps of the Customer Journey Map a bit closer. It consists of multiple experiences (registration, search, wishlist), each with multiple features (registration with email, Gmail, and X). We can and should apply our MVP Razor for each of these.

For example, do we really need registration with three methods for MVP? Even if your internal perfectionist says “Yes!” your internal product manager should say, “Well, not really. One can be enough to validate my hypothesis of whether people even care about Clothing Rental”.

If you think, “Big deal! It will take my developers 5 minutes,” well, especially in complex projects with a wide net of microservices, adding one more database (to store emails and passwords), notification system (to send confirmation emails), and two external integrations (to Google and X APIs) is not 5 minutes. It can take months for midsize companies and a year or two for giants like Amazon.

So, we cut the complexity and left only email registration. Moving on!

Let’s cut another?feature

The MVP razor is unstoppable now! What do we cut next? Let’s see… do we really need a wishlist? Don’t get me wrong, this is an amazing feature, but it comes with a price: time and effort.

If you think it is easy, then again, think of the database to store all the mappings between users and saved items, and a flow that asks them to log in to able to wishlist, then about additional UI to highlight what was saved and a separate screen with all liked items. It can take weeks for a small startup and a few years for a big company.

If you’d like to solve a few more MVP-related exercises, check out?this free material?that finishes this clothes rental example.

MVP razor inside a single?feature

You saw how we can make the whole company MVP more “minimal” by removing unnecessary features. Interestingly enough, we can apply the same concept to a feature itself!

For example, email registration can even be done with a different level of precision. We can choose to do the following:

• A classical “Enter email once, then choose password” and send an “Account is created” email
• Or do more robust: same plus ask to re-enter email again to reduce typos
• Or even more robust: same, plus send a verification link
• Or extremely robust: also ask for a telephone number and send an SMS

If you think MVP Razor reached its limit, it did not.

For example, for MVP, you can choose not to resend verification emails (if one email is lost, you stop there). Or you can do all such emails only in English to save time. Or you can avoid tracking of clicks on email because you realize that calling the tracking API (all tracking is sending an event about specific user action to the API) work will take an additional three weeks, and you want to avoid it.

Those are all the ways to make a feature small enough to check your central product hypothesis without spending ages to launch.

A product leader should remember?that…

Regardless of the “zoom level” (company, project, product, specific flow, feature), there is always an opportunity to remove something you do not need for the MVP?—?use MVP Razor for that. What exactly to cut is up to you?—?history will show whether you were right.

There is no formula for defining the minimal version of the product. I suggest seeking opportunities to define MVPs for your own product/features. After ~10 cases, you should start to feel what is minimal enough and where to apply the MVP Razor.