Classifying Market Problems

amphicar

Theodore Levitt may have developed the whole product model to help companies compete more effectively with their products. We wrote about the whole product game based on Mr. Levitt’s work. Recently, I’ve been using a variant of this model as a way to view a product and upcoming roadmap items. It is a powerful way to share a perspective on your product with the rest of the team, and frame conversations about where best to invest.

Whole Product Model

As a quick review, Mr. Levitt defined the following model:

Whole product model in bullseye format

Which works in that the center of the bullseye is the heart of the product, and as it grows, it reaches the potential of an imagined marvelous product. It also follows that your product would be hollow if you only focused on the outer rings and not the center.

I’ve found, over the last year or so of messing with the model, that I prefer to think of it as layers building upon one another.

levitt's model, in a tower orientation

Minor Term Revision

When introducing this way of framing a market space to a team, I have found that I get more traction with the following variation on the model.

alternate terms for levitt's model

And I think of them as follows:

  • Table Stakes – those problems your product addresses, which your customers view as mandatory. If you don’t address them, your product isn’t even considered as a possible solution.
  • Competitive Jockeying – these are the problems where one product is trying to provide “better” solutions than the other products, in a bit of a horse race for market leadership.
  • Differentiation – these are problems where, if solved, they would differentiate a product from the competition. Think “blue ocean strategy” here.
  • Disruption – these are problems where, if solved, effectively redefine the market – disrupting existing players. These are the game changers.

I believe this keeps with the spirit of what Mr. Levitt was getting at with his model. Or at least it aligns with what I took away from it. Any misrepresentations are my own, but please let me know in the comments if your brain went in a different direction after reading his article.

Classifying Problems Using This Model

I was doing an exercise with a team, reviewing their current roadmap as part of the budgeting cycle. The roadmap was what the team were proposing, and hoping to get funded. This is a team which historically was more “inside out” in their thinking, and needed to be outside-in (market driven).

The question I wanted the team to answer was how does this investment make your product more competitive?

Ultimately, that’s what you’re going for – either strategic positioning of some sort, or an investment driven to improve your product.

logjam viewed from overhead

I put the four categories on the whiteboard, and the team members identified market problems (which were part of their product) and mapped them to each area. At first, the team struggled to get started, with a bit of writer’s block. We broke the logjam by identifying a feature which the team would ordinarily focus on. Then we identified what market problem the feature was intended to address. Once we had a problem identified, we could add it to the board. Then we picked another feature, and did the same thing.

It would have been much easier to just identify the features. The problem is that customers don’t care about features – they care about solving problems. If you focus on the features, you can lose sight of the problems. You may also fail to identify a competitor, who addresses the same problem with a different feature.

tanning bed

As an example, someone who sells tanning booths may really focus on the features that maximize the surface area being tanned, or the air-flow in the booth, competing on speeds and feeds with other booth vendors, and companies who make tanning beds. They might easily be blindsided by the rub-on or spray-on tan products, who end up disrupting their markets. The problem is that the booth vendor focused on features (coverage, temperature, etc), instead of problems (skin is not dark enough).

A Holistic View of Your Market

In the whole product game, we’re using divergent thinking and brainstorming to explore a problem space. This exercise, classifying market problems is a convergent thinking exercise. We capture our current understanding of the market, for the purpose of seeing how well our product is positioned to address the known problems.

There are some interesting variations / analyses / discussions which come up during this exercise:

  • With the current plan, are we trying to get “a bit better” in many different directions, or really focusing on solving a single problem, for a specific market segment?
  • Now that we’ve classified these problems – which ones are more important than others, for our target customers?
  • How do we compare with our competition at providing solutions to the most important problems? Are we investing to catch up? Or to pull ahead? Or are we trying to disrupt an existing market with something new and compelling?

Goal Driven Benefits

Many teams struggle with backlogs or roadmaps which appear to be a collection of “a bunch of stuff.” Most teams try and address the problems that manifest from having a giant list of stuff by getting better at managing giant lists. This is treating the symptom, not the cause. If you’re trying to juggle hundreds of requirements, the problem isn’t that you have hundreds of requirements, the problem is that you don’t know why you have requirements.

The investments into improving a product should be intentional. Every item on the backlog improves an aspect of the product – but to what end? When you identify the problems the product is intended to solve – an outcome of doing this exercise – you have a framework for mapping or tracing every backlog item back to the goal (problem) it supports.

Those hundreds of requirements probably all trace back to a few specific tangible problems. As a fun tangent – that’s the basis for forming a good roadmap too.

Many Lenses

When you’re reviewing a roadmap in light of a strategy, there are several different ways you need to look at your plan. One of them is to understand how it is you’re trying to compete (by being better, being cheaper, inspiring aspiration, or something else). How complete are your solutions, how important are the problems you focus on? How does your product compare with competitors?

This is one of the views I use to get a sense of where a product plan “is” and very quickly identifies how (and how well) a team understands their market.

*Thanks Dontworry for the amphicar photo, usgs_elwhacams for the logjam photo

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

2 thoughts on “Classifying Market Problems

  1. Absolutely Anthony Oden, CSM, CSP,

    When we talk about product management and the problems that a product resolves we also have to look at what problems the product has itself.

    I recently consulted with a client that used a curriculum development tool. This tool solved the problem of how to serve up your courses with videos and support attachments. However, this solution had several irritating issues:

    1. It could not upload several files at a time. So it was tedious to load one file at a time and wait for it to process the upload then repeat taking you from the uploaded files to the browse for file page, save file, wait for it to upload, then add another file repeating the whole process over and over again. You can see what a real drag this was when you have many lessons to perform this task. My job was to update all the documents with a new logo, header and footer.

    2. It did not support an actual file search capability which also was irritating because you would have to build an HTML TOC in order to find a file rather than search a CLOB. I used an unordered list for what the student would learn and an ordered list for the support documents.

    3. It did not generate a Master TOC of all the courses so once you had a TOC for the course you would have to update the Master TOC with your changes. I was hoping for a Smart Tag features like RoboHelp had where you tag all of your key words and it generates an Index or TOC. WORD has this capability.

    Those are just some of the instances of a product that is good enough to compete in the “Generic” product market but from a user prospective still needs to meet the “Expected” features. From there, providing “Augmented” and “Potential” features mature the product to be a major player in the market.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.