The Tyranny of the Minimum Viable Product | December 22, 2011

I first came across the term Minimum Viable Product when I dropped into a talk by Eric Reis at the Web 2.0 Expo in New Year a few year’s back. As a company that has always worked on variable scope projects, defining a MVP seemed like a great way of managing client expectations. Rather than clients worrying whether your team would deliver something useful, you’d work together to define the smallest thing you could release and it still be a success. You would then guarantee that the client would meet their core business needs, and everything else you manage to deliver in that time was a bonus.

MVP also appeared to be a great way to manage the inevitable project scope creep. When new requests appeared you could discuss whether they were part of the minimum viable product. If they were, you would update your planing and budget accordingly. If they weren’t, you would add them to a suitable point in your backlog and see whether you got round to implementing them or not.

In the continuous world of the start-up, this approach works well. Your MVP is just the starting point, and once that’s deployed you’ll continue to add new features and iterate as needed. MVP is about breaking something down to a manageable size and getting it to market quickly.

In the more periodic world of traditional businesses, this typically isn’t the case. Rather than working on a product continuously, things get broken down into bursts of activity known as “projects”. With numerous different products, it’s not uncommon for there to be long gaps of time between work on a single product, sometimes several years. As such, in a traditional business setting it’s all too common for the MVP to become the P. At least for a significant length of time.

So in the traditional business setting, when a feature gets pushed out of the MVP and into large backlog or future release, we’re actually witnessing a slight of hand. We’re saying that we realise the importance of this feature to the project and commit to implementing it at some stage in the future, while at the same time secretly knowing that it’ll probably never get built. Sometimes this process isn’t a conscious thing, but all too often it is. All too often I see the backlogs, MVPs and future iterations used as a deliberate attempt to ditch functionality that the design or development team don’t like, don’t want or feel is going to take too much of their time. It’s a way of saying no without actually having to say no.

In the start-up environment, it’s not as important to get the M and the V part of MVP right, as you’ll probably start adding new features as soon as it’s deployed. However in a world where MVP=P, getting the M and the V wrong can be disastrous.

As user experience designers we talk to users, talk to the business stakeholders, review competitors and build up models of behaviour in order to determine what a system needs to do to be a success. However it’s really difficult to pin down exactly why some people will use one product and not another. For new products it often comes down to functionality. However in more mature markets, quality and user experience are key. As such, it’s really difficult to put your finger on what minimum viable means, but it’s typically not something than can be easily expressed on a story card or as part of an acceptance test.

In the rush to deliver a minimum viable set of features (the threshold elements in the Kano model) we often ignore the elements that make the product really great (the exciters and delighters in the Kano model). As quality gets stripped back in preference for functionality, we slowly see our products become ever more minimal and ever less viable. It’s very rarely one thing that does it. Instead MVP often turns into death by a thousand paper cuts.

It takes a dedicated team with a strong vision to avoid this. Sadly in agency land, it’s all to common for the business interests of the agency or the personal interests of the team to come before the shared interests of the product.

I’m not necessarily proposing a better way. Just that we need to be conscious of the subtle effects our chosen methodology and business environment can have on a product.

Posted at December 22, 2011 2:04 PM

Comments

Leisa Reichelt said on December 22, 2011 2:28 PM

my experience has been that people are using MVP to mean ‘the least we can get away with building’ rather than what I understand its intention to be, which is, the least we can build to test an assumption/hypothesis.

If you don’t know what idea you’re testing, then you don’t know what the MVP should be, you are - as you suggest - randomly throwing a small set of achievable features together that may or may not be appealing to a customer that you can get out quickly and on the cheap.

For me, this is just another case of people taking the stuff that sounds good from the Lean method and ignoring (or being ignorant of) the ‘scientific’ (more challenging?) aspects of the method (testing assumptions/hypotheses before investing too much time/effort into something).

I really like MVPs, I think they’re great discipline from a design / ux perspective, but I only like them when I’m doing them to actively LEARN something, not when it’s just a different way of saying ‘phase one’.

Cristian Pascu said on December 22, 2011 2:43 PM

Andy, I don’t really see why a minimum set of functionality should exclude quality and a good user experience. Aren’t these a must for any bit of functionality you put in a product, even if it’s a minimum viable product?

Tom Hume said on December 22, 2011 3:16 PM

+1 to Christian. I can think of cases where your MVP might not need good UX; from what I’ve read, Zappos started like this, just to see whether people wanted to order shoes online.

But there’s no reason why MVP shouldn’t be high quality. I’ve worked on several products where we got a minimal set of stuff done to a high standard, launched, updated with more features 2 weeks later, and so on. I think this is easier if you’re actively keeping quality high throughout, or at least ensuring it’s strong at iteration boundaries. I’d consider it very risky to plan to add quality in any form (whether it be lack of bugs, decent UX, whatever) at the end.

It would also be naive for a team to expect to specify a user interface fully on the back of a story card. I don’t know anyone who does that successfully. At FP we used wireframes, whiteboard sketches, or prototypes for this; or just colocated design and dev so it was cheap and easy for (a) developers to ask questions and (b) designers to notice if things were slipping off the rails.

Alex Kearns said on December 22, 2011 3:37 PM

The beauty of ‘minimum viable product’ is that you can release a shitty piece of software and call yourself a tech entrepreneur!

Alex Cowell said on December 22, 2011 4:00 PM

Hi Andy - you’ve certainly got a point and as people more & more come to expect a pleasant user experience, focusing too much on a minimum viable feature set at the expense of the minimum viable user experience is short-sighted at best.

As to why this might happen in agency land, you say that the reasons for a “less viable” product are the “business interests of the agency or the personal interests of the team” coming first. This may be true on occasion, but I would suggest, as the founder of a digital agency which builds big apps, that, more commonly, issues with products are down to the capability of the project manager / producer / product owner (or whoever owns that vision internally).

I think increasingly you need talented generalists in these roles - or people with “T-shaped skills” if you are familiar with Tim Brown of IDEO’s thinking. Ideally you want someone who has business nous, appreciates good design, has enough technical knowledge, can keep a client happy and knows how to keep a project on track. These sorts of people are the keystone of a great end product. They do exist, but the problem is these people are exceptionally hard to find. If I had a pound for every agency I’ve heard say “we struggle finding a good PM / producer / product owner”…

So maybe the question to agency world is how do we help skill up more of these types of people?

Mat Walker said on December 23, 2011 9:05 AM

It doesn’t matter if you are talking about traditional waterfall processes or Agile. If the process is badly implemented then its going to fail! Assuming that the backlog is a dumping ground for features that will never get built is just plain wrong. If that is your experience so far then I’d point the finger of blame at the product owner not the process.

There is still plenty of room for delighters to get included into the product and if the organisation has correctly adopted UX and Agile then the prioritisation of these features will depend not only on the business but also user need through constant testing and iteration. Agile gives you the ability to constantly question the worth of all the features of the product from the user and business perspective which can only be a good thing.

Its not perfect but given the alternative I’d take Agile as a process any day.

Cheap said on December 23, 2011 9:17 AM

in a traditional business setting itís all too common for the MVP to become the P. At least for a significant length of time.

Andy Budd said on December 23, 2011 10:14 AM

I do find it funny how so many Agile enthusiasts are happy to demonise the traditional “waterfall” process but when somebody criticises agile methodology the answer is always, “don’t blame the process, blame the people/implementation”. Just one more example of the dogmatic and quasi-religion leanings of many agile practitioners.

I also find it interesting how most agile practitioners seem to feel that their process is faultless. This is odd as one of the core tenants of agile seems to be understanding where the faults lie and iterating. So either everybody has tweaked their process to perfection (which isn’t possible) or people are not willing to discuss the short fallings for some bizarre reasons.

I’m not trying to say that Agile is wrong. I fully buy into the agile manifesto. I just think that a lot for formalised agile processes have been optimised from the developer/delivery point of view and have ignored a lot of what makes truly great products.

It’s easy to argue in a slightly defensive way that “oh, but of course the design team should have done X” but that doesn’t seem especially helpful. Not from an industry and a process that’s supposed to skilled at running retrospectives and interrogating their own methodology. So I’d prefer a slightly more open and honest discussion around agile, rather than the typical knee-jerk defensive attitude any reasonable criticism invokes.

Andy Budd said on December 23, 2011 10:34 AM

Both Tom and Cristian are right that an MVP doesn’t theoretically mean “low quality”. What’ I’m saying is that in a lot of cases, this is how things end up (although I fully realised that my definition of quality may be different from other people’s).

I think it’s a psychological issue around framing. If you start out with the concept that you’re going to build a Maximin Viable Product, it’s easy to feel as though you can cut things and still produce something good. If you start out with the concept that you’re building a Minimum Viable Product, it’s the nature of all projects than things will get cut or de-scoped. So a MVP can very quickly turn into an UVP (un-viable product) without the team noticing.

Tom Hume said on December 23, 2011 11:04 AM

I think one problem criticising agile methodology in-the-large is that there isn’t one method to criticise - there are many, with shared principles. e.g. if you argue that retrospectives are a waste of time, you’ll have a few XP folk pop up and say “ah, but we don’t do them”.

I tend to find agile folks quite self-critical; the notion of a regular retrospective, where you look at what’s gone wrong regularly, is enshrined in quite a few agile processes and encourages examination of flaws. I don’t know any agile practitioners who think their process is faultless.

MVP turning into UVP? A project can fail irrespective of its methodology. I don’t think it’s a critique of the Lean approach that when it’s not done correctly, it fails. If practitioners don’t bother to understand what terms like MVP really mean, I don’t see how the labelling can be blamed.

Can you explain why timeboxed iterations, regular demos, close collaboration and being self-critical are good for development but not for design? Or is it other aspects of agile you’ve found problematic? From Twitter it sounds like you’ve experienced some bad implementations (I don’t know what a “QA Story” is, sounds v iffy) as well as some good ones.

What’s marked the good from the bad, in your experience?

P.S. the demonisation of waterfall started long before agile arrived :) . Its creator, Winston Royce, first described it as an example of what not to do: http://en.wikipedia.org/wiki/Waterfall_model

Gail Swanson said on December 27, 2011 8:21 PM

Traditional ‘large’ businesses have a difficult time stating their goals in any actionable way before starting their effort. If the desired result is largely undefined, you can’t determine which features need to be included to get you there. It won’t matter if you are creating an MVP or a Phased Project, you’ll get a similar result. Feature bloat, bare minimum, bad UX…basically an UVP.

Don’t forget, the user experience is designed to fulfill specific user needs related to the business goals. Even the delightful bits in a great interaction design are there for a product specific purpose. It’s not altruistic window dressing. If you don’t know the goal or purpose of what you are creating, you’re wandering in the dessert until the 40 years of your project come to an end and you can enter the promised land of moving on to the next thing.

Tom Hume said on January 2, 2012 6:00 PM

This article from Mike Cohn reminded me of this thread:

http://blog.mountaingoatsoftware.com/recommendations-not-rules

Mike tends to be pretty spot-on IMHO, and his tome “Agile Estimating and Planning” is brilliant - probably the best single book on the topic.