In my previous blog we looked at how customers look at your product. In essence, they don’t care about the product, they care about the problem they have and how your product can make it go away. If the problem goes away, so will your product. So the key lesson here is:
“a good Product Manager does not fall in love with his product, but with the problem”
Let’s dive into a simple technique to figure out if we are on the right path.
The job map
The job map is a map of all the steps that the solving the customers need (job) involves. So we look at the product as a tool that performs a “job” in order to solve the customer need. We can now look at how much or how good products are at satisfying these steps. Note that a job can be functional (as in our example) but also emotional (makes you feel good) or social (everyone else talking/doing this too). There might be a lot of steps involved, but the good news is you do not need to excel in everything.
A job map can be used to compare different products in the market and reveal unmet needs.
The example above compares 3 products that serve as an integrated development environment for software development.
Each of the products is good in solving a part of the the problem the user is trying to solve the job map is a simple way to map your product against a competitors product or better said: products that your users use to get the job done. Typically this reveals some new competition and opportunities.
In one workshop for example: we compared remote control Apps for your (multi color) lights. We discovered that users adapted the lights to their mood, but what if they would adapt automatically, e.g. by observing my playlist.
We can do a better job at solving the customers needs and that is where the real opportunity lies.
The only quadrant that matters
Still these are ill-defined needs, and that is usually the cause for confusion and different opinions about what we are trying to do. It is therefore crucial that we define needs in a better way:
- Describe what the user is trying to accomplish, not the solution
- Quantify how valuable this is to your user, if you can measure value you can control value creation
Needs are usually stable, they tend to stick around much longer than our solution. Remember our Dyson example?
There is no fixed template, but a sentence that starts with “minimize the time it takes to…” is not bad. Before you know it you have identified a whole bunch of needs, but how to quantify them? there is value in statistics (say N>100) and there is value in observation (N = 1).
If you go for a survey you will end up with a nice 2 by 2 quadrant which will make your presentations look very scientific:
Create a grid that maps how well your product solves the needs for your users, buyers and eco system. Let them also rank how important this functionality is for them.
Once you have plotted the needs, you can find those who are under served easily, they are in the bottom right. The over served needs are in the upper left.
The sample diagram shows that the product is not meeting the demands of the eco system, the buyers seem to get what they want, but users are not too happy. This will help to spot an opportunity for disruption, an open solution that solves at least one of the user needs better than the current product will.
Don’t forget to map out emotional and social needs. How well does this product make you feel? In IT products it is often a difficult differentiator, but phrases like: “no-one was every fired for hiring big blue (IBM)” have a deep rooted truth and you should be aware what your customers think of this.
This technique also helps if you have a product in the market, either you solve the customer need or some competitor will. Remember Apple cannibalized their successful iPod when it introduced a phone that could do the same.
- Slightly under served needs
Add features to the existing product, do the job better
- Highly underserved needs
Introduce a new product that does a significantly better job
- Mainly over served needs
Create a new low-cost product
- Well served needs
Add jobs, do more with the same product
The Kano model
Side-step: there are needs and then there are needs. Be careful how you interview your customers about their needs, they may not see them as you do.
Professor Noriaki Kano developed a model in 1980 which explains the different view users have on their needs.
There are one-dimensional needs. These are the known performance indicators and users usually are the key competition attributes. In eCommerce business this might be the size of your catalogue, delivery cost, delivery times, speed of the website etc. or in a car it’s fuel consumption rate. These needs need to be on par, but ultimately will not be the key factor. The choice when buying a new car, with two cars with a similar fuel consumption rate will not be made on that attribute. (Unless you’re considering a Prius and a Hummer )
There are also “must-be” needs, called basic needs. Users usually forget about these because these are table-stakes, they just assume they are there. I’ve never compared cars on their ability to brake, yet I’d be quite dissatisfied if they could not.
Delighters are needs you didn’t know you had. When Ford introduced active parking assist in 2013 we did not expect it. Blessed with a male ego I might even say I don’t need it. Then again, I said that about cruise control and can’t imagine life without it anymore.