The Mission Critical Core/Context Model For Product Managers

I’ve written previously about a few models for thinking about the process of managing products:

• Cynefin, which gives us the insight that product management is a “complex” process
• The Lean Startup, which tells us that “product discovery” is a matter of doing a lot of small tests (aka Minimum Viable Products)
• Doug Hall’s three Laws of Marketing Physics – Overt Benefit, Dramatic Difference, and Real Reason To Believe – and my somewhat different slice through the same concepts, the Product Management Rules of Thumb

In Dealing with Darwin Geoffrey Moore introduced a Mission Critical Core/Context model that I’ve also found helpful. (Although I’ve reinterpreted it slightly for my own purposes, apologies to Moore.) Moore talks about the model with respect to business operations, but it’s also applicable to products themselves.

The basic table looks like this, and from the perspective of a product management analysis, the top row is the most interesting.

Mission critical context is another way of saying “table stakes” – these are the capabilities that any product in this space must provide, or would be expected to provide. For example, for product management tools, a central repository of requirements is mission critical context because every tool will have it and there’s no reason to buy a PM tool that doesn’t have that.

Mission critical core is the differentiators that your product has against others. It’s another way of talking about Dramatic Difference, or the Order of Magnitude rule of thumb. In the product management tool space, mission critical core might be a particular kind of analytics that only your tool provides, or support for a particular methodology.

By definition mission critical context is not differentiating. Yet this is typically 80% of your product. And you have to do it. If your product doesn’t support the table stakes then it doesn’t matter what differentiators you have. (In other words, marketing your PM tool as being better than others because it has a central repository of requirements doesn’t make any sense.)

Features migrate around this model. Your differentiator today becomes table stakes tomorrow as other competitors start to provide that feature. The table stakes of today may become non-mission critical over time. This happened to “Microsoft Word integration” in the product management tool space. At one time it was very important that a tool could generate a PRD (Product Requirements Document) in Microsoft Word. This is much less important than it used to be. For some customers it might be a differentiator, but now we all live in the cloud via a web interface, and are much less concerned about being able to print out a paper PRD.

Why do use models like this? They help you in the following ways:

• Help you understand if you have all the features you need to have for the space
• Help you understand if you are able to differentiate from other products in the space
• Force you to articulate your benefits and differentiators
• Force you to pay attention to validating that your product provides the value it claims to

Over the next few weeks I will apply all these models to an analysis of product management tools as a category. Product management tools have not been terrible successful in the market, and I believe these models will help us understand why, and also how to fix them.

I believe – although we’ll see if it’s true – that it’s been a combination of a failure of marketing, and a failure of the products themselves. We’ll take insight from the Cynefin characterization of the product management process (i.e., “complex”), and the marketing rules of thumb and Three Laws, and then lay it all out on a mission critical core/context matrix. This will take several blog posts to accomplish, but I hope it will prove useful to both product managers looking for tools (and just trying to understand what they are doing) and PM tool vendors.