Get Lean with Your MVP by Hacking Human Psychology | SitePen

Most agile product teams have heard the concepts around using an MVP to learn about what customers want, Lean Startup style, but the process of defining an MVP to fulfill those goals often proves to be easier said than done. Let it be reiterated that an MVP is not needed when the market and/or user needs are well known, leading to much confusion and dilution of terminology commonality in which the enterprise world has used the term to simply refer to the first release of any product and the inevitable scoping such a release receives. One popular agilist widely said, “Oh, if it’s already viable, why even build further?” This is a simple misuse of the term!

The Lean in Lean Startup refers to getting rid of what is waste relative to the immediate goals of a new product. It’s not that the other work you might do is inherently valueless — only that it doesn’t provide the value you need for this moment in time. Until the product idea has been validated, any work other than what’s needed to validate that idea is going to add time between you and that validation, and could even prove to be a throwaway.

This means that for a brand new product, the goal is not to earn as much money as possible nor to provide a solid framework from which the product can linearly evolve. It’s to confirm the basic assumption that underlies the existence of that product.

Lean Startup author Eric Ries likes to say that when he worked for IMVU, the only work that was ultimately of value was the final 3% in which they created the landing page. Because no one would download the product to begin with, the rest of the MVP offered the company no value at all since it provided them with no further learning opportunities. He’d reduced the MVP down to a slim 6 months, relative to the longer MVP timelines of previous companies — but the real potential MVP was more like a handful of days.

Similarly, when Airbnb was started, the founders had one single apartment — their own — and a simple website to facilitate its rental. This established that there was a real demand for the product, giving them the confidence to develop further functionality from that point.

Yet despite a handful of dramatic stories like these, the actual work of paring down an MVP into the right and smallest MVP, and then testing that to get the much-vaunted payoff of “validated learning,” is surprisingly hard work. What gets in the way?

Fear of embarrassment about what’s missing / Fear of tarnishing your image or brand

Feeling that without a full slate of features, any evaluation of the product won’t be trustworthy

To help yourself conceptualize cutting down the product, try this exercise Ries suggests. Once you’ve put together the list of features for your MVP, estimate them, then ask, “what could we put out in half that time?” Keep asking and halving and see what ideas it opens up.

Over-identification with your job title

  • Make sure your startup is incentivizing the right behavior. If you measure for something, that’s what you’ll get.
  • Get the team together for big picture conversations.
  • Make sure that they know what succeeding looks like, as a whole, rather than at a personal level. It doesn’t matter if each person succeeds individually if the team fails as a whole.
  • Try taking off your role hat for periods of time. Let what you notice impact the daily work you do. As Steve Blank says, “Titles in a startup are not the same as what your job is.”

Not sure what the real “business assumption” of the product is

Can everyone on the team tell you what assumption (along with any more discrete value or growth hypotheses) they are trying to prove or disprove? If they can’t, they don’t have the information in hand to help with scoping and solutioning. If “agile” isn’t helping you to build the right product, it’s not serving its goal. Your engineers aren’t just on the team to execute what the product group tells them to build, but collaborating on solutions.

Identifying the assumptions down the road, not the essential assumptions

Not sure how to validate the assumptions

Don’t get caught up in “vanity metrics” that don’t truly relate to the business assumption or its primary hypotheses. Prefer “real” behavior over “projected” behavior whenever possible, but don’t box yourself in.

Sensitivity to feedback

Feeling too attached to the current incarnation of the idea

It’s human nature to want to hang on to that perfect, original vision for as long as possible — and failure stings. But the only people who never fail are the ones who never try, and ultimately that’s the biggest failure of all. So recruit your team to help you find out how to fail fast with your MVP, knowing that it paves the way to bigger and more authentic wins.

Originally published at on March 22, 2021.

Modernizing Apps, Tools & Teams | | Twitter: @sitepen

Modernizing Apps, Tools & Teams | | Twitter: @sitepen