The hidden cost of the Minimum Viable Product (MVP)

Recently we’ve been adopting a more disciplined approach to launching websites in their minimum viable execution and then iterating improvements based on feedback. The idea behind this approach is explained well in Eric Reis’ new book The Lean Startup (which I recommend). The basic concept is to get to a point where you can learn what people want as quickly as possible, without building non-essential features straight out of the gate. I believe there is a “cost” to this approach which isn’t often discussed. It involves haters. Let me explain.

The MVP approach appeals to me as it suggests a more organic and feedback driven approach to solving what are often inherently complex problems. As individuals, we can deal with a limited amount of shit before we decide that a problem is not worth pursuing, especially where we have a choice in the matter. Understanding ways to cope with the less desirable aspects of an iterative approach is vital to making this work.

Many of us in the web industry have an innate desire to solve problems, that’s why we do what we do. The hidden cost (and paradoxically also the key benefit) of the MVP approach is that a limited feature set will polarise people far more acutely than would have been the case if you released something that was more feature complete. It will polarise more quickly and do so repeatedly throughout the process. Some people really don’t like change, yet an MVP approach requires it. As sensitive individuals, it’s important that we understand this side of the MVP process and develop mechanisms to help us cope.

Releasing projects takes courage.

For those who are truly passionate about their work, releasing projects involves baring a part of yourself to the world and inviting them to trample it – I think this is probably why so many projects are left unfinished or unreleased. We’re afraid of the criticism because it’s not always delivered in the constructive way it should be.

The Haters

If you’re releasing any product, regardless of whether your using a MVP approach or not, people will always disagree with the features you’ve built and the choices you’ve made. There is a no solution to this – people have differences of opinion. Most can express their differences of opinion in a constructive way and this is the core of the MVP approach, however there is a certain class of people who have an inability to voice this disagreement nicely. Let’s call them haters. I think of them something like “smokers” from the zombie game Left4 Dead. They have nasty tongues and you will be called a “cretin” and worse for having the audacity to modify their world.

Haters have a tendency to redirect their general discontentment with their lives and the status-quo (or changes to the status-quo) towards the easiest available target with as much vitriol as they can muster. As you’re website is not “feature complete” it is an much bigger target for them to exploit. The MVP approach will expose you to haters. Don’t expect that labelling releases as a Alpha or Beta to matter – it’s not what they want and that’s all it takes. Most of the time, especially when they make use of their vitriolic skills, haters are easily identified by your project team and also by the rest of the world. This is great as people are generally good at disregarding comments made by people who are obviously unbalanced. This doesn’t mean that it doesn’t hurt you or your team.

**Solution: Be thick skinned. **

“Be thick skinned” is something it’s much easy to say than do, but I’m sure it’s a skill worth developing. I don’t know how you do this and I have to work constantly to stop myself from taking things personally. A large part of my drive to improve things comes from my ability to care about the projects I work on and perhaps this is why I find this so hard. I’d love to know if people have techniques for coping with this.

Some other solutions include:

*1. Take the high-road when responding to haters. *In my experience it doesn’t really pay to respond to haters with angry responses. That just reduces you to their level. It’s far more effective to simply thank them politely for their time, summarise their remarks (removing any emotive references they may have included) and let them know you will consider their feedback in future iterations.

NOTE: It always pays to have someone else to proof-read your writing with the specific goal of removing emotion.

After you’ve just been slammed by some douché for something you’ve slaved over, the last thing you want to do is be civil to them – they don’t deserve it. It helps to keep in mind (especially if you’re responding publicly) that the audience for your reply is not the hater. It’s everyone else you’re trying to encourage to give you feedback on your site. This group needs to know that they can provide you with negative feedback in a constructive way without being crushed by a vengeful creator. Rephrasing the feedback in a way that removes emotion shows others how you expect future feedback. That’s the whole point of releasing an MVP and it’s vital you maintain that openness. In my experience, others watching the exchange will respect you for this approach.

So, regarding the haters. Be thick-skinned. Some of them may have good points. They just suck at being a decent human being. Write their feedback down sans-”dick”, and move on.

*2. Show people that you’re being responsive to their feedback. *If you’re asking for feedback publicly or within an organisation it pays to show people that their feedback is being used to create improved iterations of a site. One way of doing this is to maintain a link to previous iterations on your current version site. This lets people step backwards and see the progress that’s been made. I haven’t found a slick way of doing this, but ideally you could have some visible notes about the improvements made each release and why.

IDEA: I think it’d be great to be able to pull and overlay the issues/features/bugs logged into github over an iteration to show exactly what was improved each release. I’ve started logging user-feedback directly into github as issues to try and make this possible.

*3. Accept that you will never please everyone. *This is hard. Within any project, there is usually a balance of time, money, feedback and effort to be struck. Within this balance there are only so many ways you can slice your iterations. Do you address X or Y? What happens if X and Y are contradictory? Some want more of X, some want less. At the end of the day, there are parts of any website that are subjective. Go with your gut and back yourself. Websites are strangely public beasts because it’s so easy for people to view and use them, however an iterative approach following an MVP launch is not a requirement to install a democratic process. Often compromise kills websites (think a busy corporate homepage) and with very few exceptions its difficult to think of truly great websites built by committee.

As professionals we need to back ourselves. Yes, anyone can use a website we create but its not true that they spend all day, every day thinking about web design, usability and development. That’s what we do, and that’s why we get paid to do it. Be accountable. Back yourself. You will be questioned.

This ended up being quite a long post, but I hope it contains some useful information. I’d love to know if anyone else has techniques for dealing with haters. If you do, I’m @tagell on twitter.