Back
The following guest post was written by Roy Klieger, Products expert, Technology geek, Web enthusiast & soccer hooligan.
Whenever I use my microwave, I always wonder how many people use the many features available instead of just clicking “defrost” or “2 min”. It’s probably close to none, but despite that, thanks to fierce competition in consumer electronics, manufacturers usually feel the urge to add multiple features that demonstrate innovation, variety and some sort of added value (regardless of the fact that it will barely be used).
In contrast, in the world of consumer apps and online services, too many features can not only be risky but it can actually kill your product, hence “keeping it simple” is super important. Following many years of experience I’m now a big fan of simple solutions combined with even simpler features. But how do we know what our users really want and if our assumptions even makes sense? Well, that’s exactly why smart people introduced the MVP methodology.
“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
The definition’s use of the words “maximum” and “minimum” means that it is decidedly NOT formulaic. This term, coined and defined by Frank Robinson and later on popularized by Steve Blank and Eric Ries, has become the fundamental methodology for building products with minimum investment and risk.
This approach combined with the ability to measure everything simply and draw conclusions quickly should be viewed as a priceless tool for companies. Despite that, my years as a Product Manager have taught me that the difficulty with the MVP process is not the product itself but how it’s treated before, during and after the process.
There are many challenges when building an MVP version of a product. An experienced product manager recently told me that the biggest problem with defining the MVP is the V (viable) and not the M (minimum). Meaning, whilst most product managers face enormous difficulties deciding what the MVP content will be and experience real pains when vital features need to be cut, in my opinion the biggest challenge is to define whether what we’re building has enough value for the users and consequently will enable us to validate our assumptions.
I have noticed two main issues that hinder the MVP methodology, specifically in startups:
The first issue relates to how business decisions can influence the future of the MVP version after the launch. The reality is that small startups have limited amount of resources and therefore have to be opportunistic by nature. In many cases this will result in companies willing to accept almost any opportunity to work with “800 pound gorillas” in the hope of experiencing quick exposure and growth. However, this will almost always conflict with the company’s original roadmap as well as the resources they are able to allocate to it, which brings us to the popular decision to build an additional MVP just to validate this potential new partnership.
Since most of the startups don’t have the luxury of pushing a new feature to million users just to get some super quick analytical insight (like Facebook or Google can), the company needs to be prepared to support and maintain this product for a significant period of time. In many cases the unfortunate result will be a product that isn’t viable enough and too minimal. The outcome in most cases, will be disappointing numbers and almost immediately the company will lose interest in the partnership as well as the product, which is absurd, especially when you consider that in many cases this product was already validated. It also overlooks the fact that some partners might have a different customer base and therefore additional (but different) features might be required. However, most companies are reluctant to keep working on this supposedly failed product and would move on to their next project.
This becomes even a bigger issue when companies fail to consider the maintenance that this product will require over time. With every backend change, redesign or other substantial changes made in the core product, similar changes will need to be applied to that side product, which then becomes a distraction to the company’s goals.
The second issue is the MVP version of new features in the core product. In many cases companies will build an MVP and despite it not performing well, it may remain part of the core product forever. The fact that it isn’t used but remains visible is a silent testimony to our inner conflicts as humans who can’t let go.
Some companies (especially very large ones) are renowned for cutting product features that prove to be flops. Gmail’s “Grid View” for example – where selected users were able view their inbox in a grid format where each email was represented by an image (even when unopened) – lasted for a little over a year before Google decided to can it. Facebook launched its @facebook.com email service in 2010 and advertised it as a “Gmail killer”, but the service never really caught on so it was cancelled in March 2014. Admittedly, huge companies can trial features and even entire products a lot more easily than average-sized companies (and certainly startups), but the principle of “knowing when to let go” of something that isn’t working in order to concentrate on other features and products that do work or show great promise, is something that startups should be mindful of too.
My reason for mentioning this issue is that I believe that poorly-performing product features are usually kept due to psychological reasons rather than a business, marketing or other professional judgement call. It’s a combination between the “fear of missing out” and the difficulty of saying goodbye to a lot of code, design and teamwork that has gone to waste. Another reason may also be that there are some (not many) users who actually use it and we are reluctant to deprive them of that feature. These are all the wrong reasons as it basically means a company prefers not to make a decision rather than make the wrong one.
So the question is, how can we avoid this from happening?
A few ideas spring to mind:
1) Set KPIs for failures and not just successes. If you have specific numbers in mind that represent success, “signs we have hit gold” and that you’re on the right track, why not apply the same quantified measurement for when you’re not seeing these signs? Basically allowing you to acknowledge that this product/feature has failed.
2) Plan ahead. EVERY feature or product you build impacts the rest of the project, and yet we tend to forget that when we create a work-plan, sometimes – often due to sudden lack of time – we are forced to cut elements of the MVP and potentially reach a point where it’s indeed M (minimal) but not so much V (viable). So don’t forget to make sure that you always leave yourself with resources to build and maintain that product.
3) Work in complete transparency with your team. If the team knows what the KPI’s are for a certain product, they will understand why you had to let it go at some point, despite their investment.
4) Don’t be afraid to kill your product. This is probably the key point: If a product still doesn’t work after the number of iterations you initially planned using the resources you allocated to invest in it, KILL IT! No one will cry over it, trust me…
On a final note, here’s a short anecdote which is great reminder of why you always need to “keep it simple” when designing your product’s features:
Every time I give a lecture on Product, I ask the audience: When you buy a new car, how many of you arrive at the gas station and need to exit the car to check what side the gas tank is on? Probably most of you… right? Well years ago, I came across someone who worked at a car design studio, who told me that several options were considered to help solve this issue, such as a small bulge on the gas tank area. The solution that was eventually selected – a little arrow near the fuel pump icon pointing either left or right – became the standard for every car made since. So next time you get into your car have a peek (and yes, you can thank me later)!
