MVP: Don’t focus on the M!

Minimum Viable Product.

One of the core concepts of incremental development. The idea is simple: produce something of value as quickly as possible, get it to market, and keep developing. Tight feedback loops help you target the most-wanted functionality as you notch your product’s capabilities forwards.

That’s all good. But when you’re looking at a first release of a new product, perhaps you should de-focus “Minimum”. What you need is a viable product, including everything needed to make it viable.

If your clients are expecting a sports car, don’t deliver a skateboard!

That’s one of the common images used (and probably copyrighted, so I won’t put it up here) to demonstrate what’s meant by incremental development… starting with a skateboard, evolving through scooter, bicycle, motorbike and finally car. Seems reasonable, right? But the market need is for the car. If you tell the world you’re delivering an innovative exciting shiny new car, but show them a skateboard, you’ve lost. What you can’t afford to do is publicly release something half-baked. You only get one chance to make a first impression, and if you lose your audience here, you may never get it back.

You only get one first impression. There must be enough to get excited about.

So what can we do about it?

There are a few strategies to help keep you agile, and keep the product moving:

• Bend the rules. The key principles of Scrum and other iterative development methodologies call for a release at the end of every short effort-cycle. But if your project is a large, complex one where the truly valuable deliverable functionality won’t be available until later… don’t release. Just don’t. For sure, you should still follow your show-and-tell review-retro-plan process internally, incorporating feedback as you go. Absolutely, you still need to continuously check that you’re working on the right things in the right way and the right order. But your short-cycle releases, at least in the early stages, will be internal only. You “release” functionality to other developers or testers, product owners and other stakeholders, then pick up feedback, and roll it into the next cycle.
• Each release is self-contained. Release fully-completed, well-polished features. Even if you’ve only got two out of the nine features you want done, as long as they are valuable in their own right, well-tested, stable and fully functional: go for it. Rather this than releasing many almost-complete, mainly-usable features that still need some finalising and tidying up. Any seasoned developer will know that there’s seldom an opportunity to go back and finish something up when the money is in new products and features. Those “almost done” things end up on the tech-debt backlog and collect dust. Make it clear that this is an early version, with more to come, to pre-empt the possibility of the “oh, is that all?” feeling that your clients might get.
• Soft-launch. Keep your early releases confined to a target group of trusted beta customers, who will give you honest (and timely) feedback without slandering you in the marketplace. They should be fully on-board with the fact that you’re not done yet, and are just helping real-world-test small feature-sets. If you’re able to be truly agile, and involve these folks right through the development process, this is a lot easier to do!
• Manage expectations. If the market is expecting X, Y and Z, and you only deliver X and Y, you’ve lost ground (there’s that pesky first impression again). If they’re only expecting A, and you give them A, you’re onto a winner. If you manage to ship A and B, you’ve scored a bonus. “Pragmatic pessimism” can be a valuable tool here. Promise only what you’re certain of. Or reasonably certain of, given the lack of absolute predictability. Keep the “we think we might be able to deliver B” in your back pocket if there’s any doubt; then you get the opportunity to do a “but wait, there’s more!” at your release-point.

Predictability: Get over it.

One of the barriers I’ve come across during agile development transformations, is the perceived lack of predictability the shiny new methodology brings with it.

• Stay transparent. This is essential not only within your organisation, but also with your market. Unless you have a valid business reason to hide it (competitor-threat, for example), publish your road-map. Your clients (and potential clients) may be happy to take the first couple of features now, in the knowledge that more is coming shortly, and arrange their rollouts and training plans accordingly. If that information is kept hidden, they can’t make that decision, and may look to your competition for a more comprehensive offering. Having said that, be careful with dates on that road-map, as your client-base will hold you to it. Make it clear that it’s a living plan, driven by moving and evolving market demands.

In summary: focus on the Viable.

The postings on this site don’t necessarily represent the views or opinions of my employer, professional organisations, political party, family, car manufacturer or anybody at all, really. I don’t know where they come from. It scares me sometimes.