I wrote previously about the Product Ownership in my blog Product Ownership the great let down in that blog I discussed the importance of stage gates as a safeguard when developing products for a crowded marketplace, especially new or very different products.
The MRD is typically the final output of a Product Manager exploring a new product idea and it sets out the product vision along with the estimated demand for such a product by way of unmet needs in the market. It will size that market and make estimates of break-even and the likelihood of achieving it and going on to establish a healthy product lifespan. At the end it will make a recommendation. The stage gate will consist of a review when product, technical, financial and other strategic stakeholders will consider this information in the context of their own knowledge and risk appetite and a joint decision will be made to proceed or not. This not very different to the way an internal project might begin other than the type of information being considered and the type of risk and opportunity profiles involved. I find it very hard to visualise a situation where this work should not be done.
The risk are simply too great. Changes happen daily in global markets, finance, economics, local markets, disruptive entrants and so many other potential parameters that without serious initial and ongoing assessment the likelihood of burning large amounts of capital regularly is just too great.
Most product organisations now and in the past would have a series of stage gates which allowed them to develop the proposition in increments and then reconsider it based on the new information. For many, the extra security offered by this method is outweighed by the level of formality and constraint.
For those very reasons, agile can provide excellent solutions to fast moving environments, changing information and uncertainty. Agile follows an incremental method of developing the proposition and the product in tandem. I often refer to it as the Onion Plan.
It begins with the product owner defining a Minimal Viable Product ( MVP) or Minimal Marketable Product ( MMP).
Marty Cagan gives my favourite definition of this in his blog when he says “I have long defined minimum viable product as the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.”
I have also often heard it defined as the minimum product that delivers on the product vision. This is also good but it misses the important point about being marketable. Otherwise people won’t get it and it can do just because of that. E.g. A three wheel car works fine, but its hard to get customers excited about it and their reactions say nothing about the four wheel version you are planning later in the year
This initial product forms the core of the onion, at least as you initially see it. That does not mean t forms the core of the product, because the whole point in getting it out there is to react to feed-back and make changes, so the core could be moving this way or that before and while building up the further layers of the onion. Needs versus features
When we define products we discover a need in the market, it represents a pain point for our customer for example. E.g. Customer tell us they need their cars to burn less fuel, so we respond by designing a car that that runs on half the amount of fuel. Then we discover that thy are not willing to live with the smaller size and they must have a minimum accelerations so we revise our product to save 10% of fuel without losing any comfort or acceleration. They like this, but now it is more expensive than a better one from Japan and they won’t pay our price so we go back to the drawing board. Eventually we reach the right compromise and release a simple model that has a broad appeal to our most important segment of the target audience. We are able to sell this to real customers paying with real money and get their feedback. That in my view is when the Onion core has been built and now the layers start to be added as we address the extra needs of our more sophisticated segments, watching at all times for a change to the core proposition through a new competitor offer or an unexpected macroeconomic change etc. Either the need or the potential solutions can change in our market environment at any time as can the macro environment such as their ability and willingness to pay and all can have can rapid and serious consequences for our offering.
The skill of the product Owner in this circumstance was to identify the potential core product, address the right segment, get good feedback and understand it then come back rapidly with a better offer and keep doing this till he hit bulls eye before building on extra layers of features or addressing other segments. Understanding a need is a particular skill, but meeting that need in a competitive way that can drive strong market performance is another entirely separate skill and both are inseparable from each other.
This does not sound at all like a bunch of techies huddling over a wall covered in scribbles, but it is in fact a very effective use of all the principals of Scrum as long as there is enlightened and capable Product Ownership.