Go with me on this one. It has to do with MVP, how that isn’t as immutable as everyone thinks, and how medical device regulation makes the problem worse.
MVP: How minimum are we talking? And how viable?
The idea of Minimum Viable Product (MVP) is well rehearsed: what is the easiest thing we can do to get ourselves to market meaningfully and ensure company survival and growth? It’s a really important idea for start-ups, especially in a space with a costly regulatory submission process prior to first sales.
The trouble is, while the most basic imaginable product may get to market fast and sell well initially, it may also be rapidly superseded and might not support the business in the longer term. MVP exists in a context comprising who the product must support and when, and both of those can be hard to define. For example, can MVP just consider the needs of our business today, and of our expected early adopters? Or must it incorporate requirements from our business, users, regulatory landscape and health body procurement conditions several years into the future, some of those being hard to predict? The context is obscure, so the MVP itself can also start out somewhat woolly and liable to change.
As is well recognised, it is much better that any changes to scope are made early in development, but we cannot always choose this. If they have to happen late, it is vastly preferable to make reductions rather than increases. This pushes us to aim a bit high and prefer to undershoot.
Luckily, we all have a tendency to be optimistic and ambitious, at least initially. And that’s no bad thing - it’s easier to take away capability than to add it (although we should still aim to do our subtracting as early as we can, for the sake of efficiency). It is also much harder to plan realistically for something we don’t really intend to do. It is fine to look at the broadest context and so set our MVP on the ambitious side, but…
We MUST plan an orderly retreat from our ideal requirements set!
THAT sounds a bit defeatist!
I’d call it a sensible precaution, rather than resignation to failure. Things go wrong. Resources (time, people, money) may become stretched. The contextual balance of long-term profitability and immediate survival built into our MVP may shift. This could mean letting go of something - features, polish, immediate access to some markets. It is sensible to keep this in mind. To always have an idea of routes of careful and considered withdrawal from our ideal target. But what can we do to keep these routes of tactical retreat open? Here are a some thoughts.
First, we can prioritise our requirements, even though they are all absolutely necessary. Then we can tend towards implementing the least important features last. A change in context may render even the most firm requirements negotiable, and at that point it’s much better that the ones you have to chop off are the ones you’ll miss the least, even if you will still miss them a lot. Put them at the back of the queue from the beginning but intend to finish them nonetheless. Plan for the unthinkable but hope for the best.
Along with prioritisation, we can group our requirements (brace yourself - here comes the confectionery analogy). Look for clusters of requirements where the loss of one makes others pointless or unachievable. Our vast slab of requirements, like a huge chocolate bar, needs to have imaginary grooves moulded into it. When we have to snap a bit off, we want the whole thing to break cleanly, in a nice, straight, predictable line rather than some unexpected wiggly diagonal. To ensure this, we add the weaknesses ourselves, exactly where we want them. If we don’t do that, the slab will snap wherever natural, hidden weaknesses in technology or team exist instead.
Preparing to chop your requirements up like this enables your team to pivot rapidly and relatively safely when scope has to change. For example, we can now give our software team a clear list of the wants that have suddenly gone away, rather than just telling them to spend 30% less money this month and hoping for an outcome supporting sensible compromise at the stakeholder level.
To stretch the analogy a little further, breaking a scored chocolate bar doesn’t take much force. It yields not only neatly but also at low stress. Breaking a smooth, grooveless slab of the same full thickness takes a far greater build-up of stress before it randomly and suddenly gives way. It is much easier to decide how to reduce scope early if your requirements are well grouped and prioritised. Otherwise, the tendency is to hold it off because the basis for the decision has not been thought through in advance, and none of the options stands out as more acceptable until stress has built to a maximum. Once things have become utterly dire, the breakage will surely happen, but it won’t be where you want it.
Ok, weaken the requirements slab. but how?
The best way to achieve this, I believe, is using requirements traceability. Start with a well-ordered top-level stakeholder needs specification, considering the MVP from the point of view not only of users but also regulators, the business, health body purchasing rules and so on. It should also look at the evolution of those stakeholders’ needs over distinct chronological stages. This top-level needs specification forms the basis for justification of detailed requirements for system features. If you trace all your system requirements properly and exhaustively to relevant stakeholder needs, determining what you should stop working on first when things go wrong is a simple case of deleting the top-level need and seeing what becomes completely orphaned. This can also help you to work out how much you save by getting rid of each expectation, and to choose the best balance of impact against benefit.
That sounds like a lot of work…
It really isn’t, but you don’t actually have to do it anway. You can choose pizza instead.
Uh-oh
By this, I mean you can make your reduction in effort across the board. There are two common approaches. The best is the controlled one: openly rushing, thrashing your engineering team through late, pizza-fuelled nights and otherwise sacrificing quality (with a small q). You’ll end up with a product that 90% satisfies 100% of the stakeholder needs, meaning it disappoints your entire market and also lets your business down. Now compare this with the approach based on prioritised requirements, which gives you something that 100% satisfies 90% of the needs: perfect for most people, and the other 10% just don’t have to buy it.
Sadly, even the open panic method is not necessarily the most common approach to scope reduction. The uncontrolled option is perhaps just as common, as product managers are not necessarily aware of the engineering shortfall before it is too late. In this case, stressed-out teams have already decided for themselves, in secret, how to let the program degrade, based on their general feeling each Monday morning. Some people think this is what “agile” means, but a) they’re wrong and b) my own view is that agile can’t really work quite like that for highly regulated products (that’s for another blog). Anyway, I hope I don’t have to point out the problems with management by nose-following on this one. I’d still say a tactical retreat is a far better idea.
In conclusion
Choose chocolate over pizza.
Use the chocolate bar view of requirements.
Insert weaknesses into your product definition precisely and with purpose, otherwise it will break late and wherever hidden weaknesses exist.