Military history

Dave Baskind
Picket
Published in
3 min readNov 10, 2020

Like many revolutionary ideas, the MVP started off as a Utopian ideal of not biting off more than one can chew. It has since become a rallying catch-cry of the new product development process.

When Frank Robinson originally coined the acronym it represented “the right-sized product for your company and your customer.” The problem is in arriving at an agreed definition of “right-sized”.

Robinson originally intended it as an ethos but nowadays we tend to use it as a stand-in definition for the first real version of a product that will evolve as we start to see real people interact with it. It has become the definition of a product that a client will take to an agency to have built and it will be subject to the normal and important discussions about what will and won’t be included — and for what price.

What is commonly missed in the original phrase is the technical definition that follows: “The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers.

When we approach the MVP in this context it can become easier to prioritise what’s needed in those crucial early stages of a product’s life.

Fighting for your first five users

The one weird trick we use to help the MVP lose weight is to frame it as the minimum set of features needed to satisfy only the first five users of a new product.

We ask our clients to think about what it would look like if it only had to work for those first five and no more. The key to the trick is the “and no more” bit — just to be clear.

Viewing the initial version through this lens suddenly gives the team (client and agency, together) inspiration to find all kinds of compromises, workarounds and shortcuts to use for now, while still maintaining a focus on User Experience.

Administrative niceties like automation, integration, advanced analytics and the mythical “scalability” can be de-prioritised in favour of a great product for founding users. Supporting complex business processes and hypothetical hordes can come later, if and when there are signs of success.

Win the battle, not the war

Now we see that the MVP is there to deliver value to a small group of initial users to prove that people like them will find the product useful and be willing to pay for it (literally or figuratively through time and attention).

If the MVP can achieve that you’re in a much better position to attract further investment or organisational sponsorship to support your product’s growth beyond launch — not to mention piquing the interest of talented individuals suddenly much more interested in working for you.

With the hypothesis proven, focus can shift to the never-ending set of “good problems to have” like being so overwhelmed with manually creating new user accounts that the need for automation becomes painfully unavoidable.

This article was originally published on FYI, the Picket newsletter. You can subscribe here and/or view previous issues here.

--

--