Most agile product teams have heard the concepts around using a Minimum Viable Product (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 in software development 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

This is the mental horror of imagining people scoffing over what you should have known to include or identifying your brand with an early prototype. In reality, given the overall low success rate of startups due to product-market fit, this is a far less urgent concern. With a well-targeted product in hand, you’re in a much better place to achieve success with further revisions. Remember that the first iPhone shipped without copy/paste or the capability to run third-party apps.

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

For this minimal, targeted MVP, you’ll be targeting early adopters – people who are willing to take a risk on an unproven product, who are excited about the opportunity to have early influence, who are curious about what’s new and eager to be the first to try it out. For this audience, seeing the potential is much more possible than for a user who wants everything nailed down before they’re willing to give a product a try. 

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.

Overidentification with your job title

Engineers want to write code – that’s what feels productive. Designers want to design. Architects want to architect. Product folks want to… make product calls! It’s hard to step out of your role and take the time to instead reconceptualize the product (or collaborate with someone else to do so). Furthermore, management expectations often reinforce these impulses, rather than challenging the team to keep their eye on the learning goal at hand and work across role boundaries. 

  • 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

Take some time to really ponder the core product assumption, and take a look at some examples online. Bat it around with your team. Do they agree that it accurately represents what the existence of this product implies? Give them a chance to suggest iterations of the wording. 

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

It’s hard for us to know what assumptions we are making that simply describe the world as we believe it to be – the “background” against which our other ideas live. What are the assumptions you don’t know you’re making? Have you background-assumed that a given problem exists and that people would buy a product to solve it, and identified a more advanced aspect of the product as the assumption? Take your assumption and try walking it backward to see what deeper assumptions are silently baked into it.

Not sure how to validate the assumptions

Depending on the assumption and the circumstances, it may be harder or easier to get to qualitative or quantitative data. There are lots of options at hand: split testing, surveys, prototyping, measuring “buy now” clicks (operational or otherwise!), even crowdfunding. The Lean UX framework gives a lot of ideas. 

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 

We all hate hearing that something is less well-received than we think it should be – or having our ideas redirected. And when gathering product feedback from users, you will be subjected to a range of connotations – rudeness, indifference, excitement (if you’re lucky!). It’s tough! Have a conversation with your team in advance and agree not to jump hard at a single piece of feedback, nor to be led by the nose by whatever a potential customer says they might want. Get a little emotional distance from the feedback, step back and look for patterns, and try to cultivate a relaxed sense of nonattachment. Depersonalize and have a sense of humor.

Feeling too attached to the current incarnation of the idea

It’s easy to feel that this idea is the “big one” and that negative feedback or feedback that suggests a change in direction will destroy it. However, the risk of this only increases from delaying feedback, when increasing amounts of time and money have been spent on the current product direction. Some pivots are subtle but important; others may challenge the fundamental basis of the direction. Be prepared to bring your creativity and entrepreneurial spirit to the challenge – you are more than this single concept.

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.