Not an MVP

Work on our native re-platforming continues. The work is still moderately experimental but we’re inching closer to a plan for what the first release will be. It is likely that the first user-facing release will be quiet chunky, but I’ve been resisting calling this an “MVP”.

In general, I dislike the term for its over-used vagueness. I have yet to find two groups of people who use the term in exactly the same way. Most of the time when people say “MVP” they just mean “the first (small, slightly crappy) thing we intend to ship”. Last week, on the train, I read Scott Colfer’s “Escaping the product operating model trap” (very interesting on its own terms regarding where a “product operating model” fails in large organisations) and was reminded of the essence of an MVP:

‘Minimum viable product’ is a metaphor for ‘testing our assumptions before making a decision’. It’s about running experiments to manage risk.

That definition is coherent and useful, but it covers a few different working practices. The classic use of an MVP is to test assumptions as a way to figure out whether your product or service should exist at all, as you search for product-market fit. That’s not the situation we’re in. We know the NHS App should exist – it has users, it works, and it delivers value. Viability isn’t the constraint; quality is. The whole point of this re-platforming is to raise the bar for the user experience. We’re not asking “should we build this at all?” We’re asking “how do we make this better?” Treating these questions as if they were the same thing is one place where the confusion creeps in.

Some of what we’re doing now is, in effect, a translation: taking existing functionality and reimplementing it in a new architecture, with new components and patterns. For these parts of the work, we have high confidence about what the outcome should be because this stuff already works (mostly). The goal is to find a new way of expressing what we already have. Other parts of the work involve entirely new features – ideas from our alpha last year that we believe in and want to pursue, but which are simply too complicated to go after right now. That kind of work can be approached like a traditional MVP; we just don’t have the headspace for it while there is so much translation still to do. I mean, the app is rather big.

The translation work is also, in a deeper sense, the foundation work. The goal isn’t just to release something small – it’s to establish a structure that is coherent and clear on its own terms, so that each subsequent piece of work has somewhere sensible to attach. This means being deliberate about what we re-platform first. The elements we tackle now should, in theory, make it easier to pick off further changes one by one in a clean and logical fashion. It won’t be complete, but it will be a good start. Working this way has meant we can choose to defer some decisions and create optionality. We don’t need to resolve every detail upfront and our more ambitious ideas can wait until we have better foundations to build from.

Releasing changes incrementally creates its own challenge: for some indeterminate period of time, some parts of the app will be fully native and some parts won’t. Designing ways to handle that hybrid state as gracefully as possible is something we’ll be exploring further in our next round of research. I don’t think there’s a perfect solution, but we have hunches about how to minimise confusion and we have the kernel of a plan for how to proceed beyond an initial release.

In the end, I suppose you could argue that this work is an MVP. We’re planning to release something we can add to and iterate on. We’re leaving some decisions open, accepting that we’ll learn as we go. And yet the term still rankles. Even stripped of its worst connotations – shipping the worst thing you can get away with – it collapses two distinct and useful ideas into one: learning what to build and learning how to build it right. Both are valid and important, but they’re not interchangeable. We’re not trying to discover whether we’re building the right thing. We’re trying to lay a foundation: something coherent, something we can build from, something that makes the next thing easier. That’s not an MVP. It’s a start.