icon-subscribeSubscribe.

Free issues of Inside Product Strategy™

See Latest Issue.

icon-registerRegister.

For webcasts, workshops and more.

See Calendar.

icon-loginLogin.
Find your peers, templates, and more.
Members Login Here
Home arrow Features arrow Setting priorities
Setting priorities Print E-mail

How do you know which product enhancements to put first?

Feature - January 16, 2007

When everything is a priority, nothing has priority.  But, according to Sage Software product manager Dave Jones, a modified version of a technique developed more than 20 years ago by Japanese engineer Noriaki Kano can quickly and easily help you sort through long lists of customer requirements and prospective enhancements to help you decide which features really need to be first in line.

By Peter Longini, Managing Editor

Let's say that you and your associates have done your homework and come up with a list of maybe three hundred features to consider including in a new release of your company's software.  At the same time though, you also know that your engineering and quality control resources are limited and that even if you're lucky, they may only be able to get 75 of them done in time for that next release.  How do you decide which projects to do?

In many companies, according to Sage Software product manager Dave Jones, whose own Tampa-based division of the business solutions giant creates software for managing physician practices, the decision is all too often made the old fashion way: "There's a lot of hand-wringing and heated discussions, where people get emotionally involved or attached to something.  They say ‘I think this should be in there!  I've talked to a client and he said this was critical!'  And at the end of the day, and once the product release goes out the door, they question themselves, saying, ‘Did we really get the right stuff in there?  Did I let So-and-So influence me because of his ability to articulate what he wanted in the product?  Did he get the better of me because I was less articulate or less emotional?"

But there are practical ways of squeezing the emotion out of setting product development priorities and infusing a potentially chaotic collection of potential improvements with a measure of order and discipline, according to Jones.  One of them is Kano Analysis, named for the Japanese engineer Noriaki Kano who created a simple scheme for categorizing product factors back in the 1980s.  Kano's system, which is now an integral element of the Six Sigma quality management process, looks at customer requirements in terms of their impact on customer satisfaction.

Four buckets

Every potential project can be sorted into one of four boxes under the Kano approach.  These boxes are ‘Surprise and Delight' factors; ‘More is Better' factors; ‘Must Be' things; and ‘Dissatisfiers.'  Each corresponds to the way customers react to a particular product characteristic and, by extension, tells the producer which ones are most important.  Those answers can change over time, as when a feature which is seen as a ‘Delight' at the time of its introduction morphs into a ‘Must Be' expectation after being around for a while.  Even so, it is a useful technique because it helps to cut across customer needs which vary in kind and importance, as well as from one market segment to another.

But, Jones points out, the method's utility is limited.  And those limitations become particularly acute when a large number of factors are being assessed.  "In the traditional Kano Analysis you threw it into one of four buckets, and at the end of the day, that's what you had," he said.  "When you don't disperse the items broadly enough, you find that one of those buckets overfills.  If we're looking at two or three hundred items to put into a release, all four buckets are all going to be filled, or at least two of them are going to be filled, because there's not enough separation between them. Somebody will be saying ‘this is really important,' or that ‘this is a surprise and delight,' or ‘this is an absolutely gotta have.'  So what you find is the must-have bucket fills up because everybody thinks the product should have everything."

Assigning scores

For Jones, that made it too hard to separate the nice-to-haves from the really important factors or to set priorities for development.  And that led him to formulate a modified version of the Kano analysis - one that not only assigns a score of 1 to 4 reflecting the relative importance of each item, it also re-defines the categories themselves to address the distinctive needs and circumstances of each specific marketplace.   

 "I work in health care IT.  So we're always looking at it with a view to how would this affect a patient?  And how quickly does it need to get into the product?" he said.  "When you talk about how it affects the patient, the term we throw against it is ‘Severity.' And when you're looking at how quickly it gets into the product, we term we use is ‘Priority.'  So think of ‘Severity' as having multiple layers.  Level One is ‘if we don't do this, a patient could die.'  Level 2 means ‘if we don't do this, a patient could get seriously harmed, but they probably won't die.'  Level 3 ‘a patient might get hurt,' and Level 4 Severity means ‘nobody's going to get hurt over this.'

"Think of the same four levels in Priority.  Priority Level 1 is ‘it has to be done right away, it's the most critical thing to get done right away.'  Level 2, ‘it's really important, it gets done right away,' Level 3, ‘well, it should get done pretty soon, but it doesn't have to be today or tomorrow,' and Level 4  is ‘hey, it'll get done whenever it gets done.' "  Once a value for each category is determined, you then simply multiply the two ratings to arrive at the project's Impact Score (IS).  Using the categories of "severity" and "priority", the equation for calculating the Impact Score would be S x P = IS.  Having four values for each category disperses the potential projects into one of nine possible levels, which makes choosing the most important projects much easier.  The entire list of potential projects is then sorted based upon the IS score.  And, as in golf, projects with the lowest scores make the cut!  The most important projects (those with an impact score of perhaps 1-3) will work their way to the top, the moderately important projects (with an impact score of perhaps 4-9) will lie somewhere in the middle, the least important projects (with an impact score greater than 10) will fall to the bottom.  And it's easy to keep track of them with a spreadsheet.  The determination of where to draw the line for "most important" can vary depending on your needs. 

"In a matter of about a few hours, we're able to go through several hundred of these enhancements, quickly calculate the values, come up with the top list, filter that list, and say ‘Ah-ha!  Now we see which ones are the most important.'  Now we can take those and tell our development group which are the most important items.  Not only does the development group appreciate that, they also participate in that ranking process.  So now they can see the manner of analysis that was being put against this, and they're able to appreciate it in a concrete, detached, less emotional fashion."

Who's counting?

Input for numerical values of project rankings can come from several places, according to Jones.  "One option is to use feedback that the client submitted.  Another is to have a group of subject matter experts within your own organization sit down and decide what the values should be.  In some organizations they call that group a Change Control Board.  They're the ones who look at changes for a product and say, ‘Let's evaluate these suggestions and determine which are the most critical or which are the most important that would do that.'  Another option could be a combination of those two, taking the feedback your customers give you, combing it with the internal review that your own change control board has given, and then come out with what the combined voice says.  But it more typically comes from within the supplier firm itself."

By using different categories, the same type of modified Kano analysis can be applied to entirely different industries.  "The model can be adapted.  It's flexible enough that it can be used in a finance world.  It can be used in software for hospitals.  It can be used for software in non-profit and charitable organizations.  The value is that it's quick, it's efficient and it removes the emotion," Jones said.  "I keep using the terms ‘Severity' and ‘Priority', but depending upon the industry, the categories for ranking could be ‘Security' or ‘Return on Investment'.  You might even ask yourself, what if there were three categories that were important to a company?  They can do that too." 

There is, however, a downside to using the method.  "I find that people don't want to change," he noted. "They want to continue doing things the way they always do.  But what they find is that continuing to do things the same old way leads them into mediocrity.  Why isn't every business out there extremely successful?  Because they continue to do the same things day in and day out without evaluating new or modified ways they could go about their business.  Using a new or creative approach can be very beneficial.  And in the two companies I've worked for, both of them have looked at this method and said, ‘you know what, this is perfect.  It's quick, it's easy, and it's efficient.  This provides a less emotional, more detached manner for determining what's the best thing to do.'"


About the Author:

Peter Longini is the Managing Editor for Inside Product Strategy™. He can be reached at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it .

To read our latest articles in Inside Product Strategyclick here.