Skip to content

Cheating to Reduce Risk

At a recent Q&A event the topic came up of how to get to the point of being fundable. Terms like traction were bandied about. But as a part of the discussion afterward I pointed out to one entrepreneur that they might be charting the wrong course for their company. Here’s the deal…

We’ve all heard of Lean Startup methodology and Minimum Viable Products (MVPs), but there’s often a misunderstanding of what’s involved in making an MVP and what the actual goal of the MVP is.

Fundamentally, what an early stage company is trying to do is prove that the idea that they have come up with is something that people will pay for (or at least use and share, if you’ve got that kind of idea). Most people, especially those with an engineering bent, will try to build up the MVP’s technology leaving out bells and whistles (that’s the “minimum” part) so that they can test product-market fit sooner. 

What this misses is that there are often some components of your MVP that can be simulated through brute force methods that avoid a good deal of development time. 

Just for example (NOT based on any true story!!), let’s look back at the early days of Amazon, when they were thinking of developing their recommendation engine for books. That’s probably a pretty complex algorithm to develop and get right. But it’s the sort of thing that a bookstore owner is pretty darn good at. So to test their hypothesis that customers would buy more books if they received recommendations based on what they bought and/or were looking at, Amazon could have built the UI for displaying the recommendations, but had a few bookish people populating those pages manually. This is clearly not a scalable solution, and it would be quite expensive, but it would prove or disprove the hypothesis much more quickly. Once Amazon had shown that the recommendations led to more sales, then they would automate the process. (Just to be clear, I’m not in any way suggesting that this was what Amazon did!)

This is what I call cheating: often it pays to look for ways that you can simulate a feature in an MVP without actually taking the time and energy to build the “real” version. 

As an investor, I’m more interested in whether your product has value at the price point you’ve modeled, so I want to see that answer as quickly and cheaply as possible.

I’ve got great confidence that over time you can build technology to replace your “cheats,” but much less in your ability to predict how customers will behave.

Most entrepreneurs will come in saying that they need money to build the tech so that they can start selling the service. Actually, that backward in many cases. The key is to cheat wherever possible.

So please keep this in mind as you think about your MVP: are there shortcuts that can help you prove product-market fit? 

Leave a Reply

Your email address will not be published. Required fields are marked *