VOC: What, Want, How & How Much

In this presentation I’ll discuss a decision modeling concept we’ve developed that is based on voice-of-the-customer prioritization models created with our clients and their customers.

We call this “What, Want, How, and How Much.” Many problems can be seen from this simple metric. The order of these are important, which you will see later.

“What” defines the problem, “Want” outlines the criteria by which you will solve it. These can also be called “objectives.” And “How” describes the tactics used to arrive at the solution. Of course, some alternatives are better than others, which is why we use a decision model to prioritize them. The final step is “how much will it cost?”

For example, take the problem of determining customer requirements for a new product; “What” is the broad statement of the customer’s problem that the product is going to solve, customer needs (or Wants) are really the problems the customer is trying to solve, and the “Hows” are the ways to fulfill those Needs. Later this prioritize list of features become the “product requirements.”

The problem is when these are done in reverse order. In technology development, we see people starting with “HOW” they are going to do it. In other words, “Here is my solution, what do you think?” Without an understanding of the customer’s problems, the out-of-context solution usually falls on deaf hears.

And in today’s difficult economic environment we see the driving force for most decisions being “how much will it cost?” Starting with this constraint can be dangerous when cost-based decisions today are made without an understanding of their implications to strategic options in the future.

Planning, "based on constraints," is the most common form we observe, regardless of the economic conditions. “This is what I have, therefore this is what I can do…” Rather than, “This is what I want to achieve, therefore this is what I have to do in order to make it happen…” Next, is to determine the gap between what “I want and what I can do,” and then use this information to make decisions that close the gap. This “before-the-fact” planning causes people to see possible solutions that they don’t normally see when they are wearing “constraint blinders.” This is a fundamental “mindset” difference between the high-performers and the norm.

The best-practice approach is something we call “planning based on needs.” Where one starts with the goal statement, then wants or needs are quantified and only then are the ways to meet those needs prioritized. These are how we are going to achieve the goal. This is a VOC-based approach that looks outward, rather than inward. It is also referred to as a “customer solution orientation.”

At this point we consider the implications of constraints. Once the gap is identified the process involves making trade-offs to align what can be done given those constraints and what trade-offs need to be made in order to align this with those overarching wants. If the gap is to great, don’t do the project.

If this thinking had been done in advance on many failed projects we’ve seen, a lot of money would not have been wasted and could have been redeployed on more effective projects. It is a counter-intuitive mindset, but it was one of the factors that differentiated those high performers we’ve work with over the years.

Lets take a look at an example of how this works.

It was thought, in this example, that the solution was to implement an automated update process. So we asked what problem was this automated process going to solve. This uncovered the real problem which was to maintain service level agreements with customer and reduce operating costs. This was the WHAT. Next we described the customer’s objectives in wanting to make the improvement. We came up with six. This was the customer’s WANTs. Then we brainstormed all of the possible solutions to this problem and came up with 13 more in addition to Automating the update process. These were, of course, the HOWs.

Next we prioritized the objectives, asking which was more important to achieving the goal. The comparison process resulted in a priority order with improving success rate of updates the clear winner, more than twice the second place objective. This weighting would influence the ranking of the alternative solutions which we did next by giving each solution a high-medium-low value as to how much that solution contributed the objective.

We wanted to see how sensitive each objective’s weight was to each solution alternative. As we simulated different weighting scenarios we could see how it influenced the priority of the solution. The winning solution varied as different objectives became more important.

We needed to also know HOW MUCH. We were working inside a budget constraint. What could we do for the $10M budget? This was less than half what all these things would cost if the did all of them. What solutions would add the greatest value toward meeting the customer’s objectives?

Applying the $10M constraint meant that three solutions dropped of the list and we could actually do it for about $8M. The next question was, “what impact did that solution mix have on achieving our objectives?” In fact, 85% of our most important objective, success rate of updates, would be met and an aggregate 85% of the overall benefit could be realized with the more cost effective mix.

Finally we wanted to know what the cost-benefit curve told us about which alternatives would give us the “biggest bang for the buck.” And for about 28% of our budget we could achieve almost 80% of the benefit. It also told us which solutions to fund.

The interesting learning for the team was the holistic solution focus that emerged, when we looked at the problem from the customer’s vantage point, in terms of the problem they were trying to solve. It turns out that the team had most of the skills to provide this holistic solution to the customer and hadn’t realized it.

What, want, how, and how much?