Tuesday, April 12, 2011

Product Specification Hints, Part 2

Executive Summary:
The product specification is a powerful instrument for guiding the efforts and the focus of any development team.  Use it to its fullest advantage by identifying the opportunities to maximize performance and prioritizing the variable attributes.  Doing so will focus your team’s efforts where its creativity and effort will create the most value.

The Rest of the Story:
In Part 1 we discussed some classic elements of product specification writing, such as making sure specifications are specific and measureable, and avoiding the trap of specifying solutions instead of needs.  For Part 2, lets discuss how to get the most out of our product specifications.

A behavioral fallacy of traditional product specifications is that if you say I want it to be 33 centimeters long, your team will make it 33 centimeters long.  In other words, product specifications traditionally provide minimum or maximum thresholds and our design teams typically provide those minimums and maximums.   After all, we told them to do so.

However, what if we want something to be quiet, and the quieter, the better.  What we really want is to minimize sound to the best degree possible within the bounds of development time, product cost, and ability to meet the other requirements.  If this is what we want, then we need to say so in our product specifications, especially if it is a competitive advantage.

On the surface, it may sound like I just suggested we break one of the rules set forth in Part 1, to be specific and measurable.  Not so.  We still need to provide a maximum acceptable noise level of say 54 decibels, but we can go on to say that the noise level should be minimized below 54 decibels.

If your product development process or product definition methods include Kano models, Quality Function Deployment, Outcome-Driven Innovation techniques, or any other brew of voice-of-the-customer/requirements analysis, then chances are you identify requirements or opportunities where you want your design team to minimize or maximize performance to better satisfy customers.  Make sure that your product specification clearly translates that discovery.

Sometimes it is very expensive or difficult to maximize and minimize everything.  Some things just conflict and can’t always be optimized at the same time, horsepower and fuel economy for example.  A good practice for any product specification is to prioritize the key critical performance criteria.

Prioritization can be a tricky thing.  It used to drive me crazy when 150 requirements would be prioritized into three categories, must have, desired, and nice to have.  Thanks for nothing.  Such prioritization doesn’t help me find the correct balance of performance when 4 different must-have requirements conflict for performance.  It also meant that the nice-to-have requirements got so little attention that the author may as well have left them off the list.  What if one of those nice-to-haves would have made a competitive difference?

However, lining up 150 specifications in order of priority takes longer than writing the specifications in the first place, and will probably not really add value except for those that conflict.  We can borrow ideas from techniques such as Kano models and Quality Function Deployment to help make the prioritization process more pragmatic.

Break your requirements into basic needs, variables, and delighters.  Basic needs are those things that the product must have to get into the game, but are not things that you would invest extra product cost into improving.  Variables are those attributes that should be maximized or minimized to provide competitive advantage.  Hint: reduce the number of variables to make your product development move faster, turn as many as you can into basic needs.  Delighters are those things that the customer may not expect, but if they are present will distinguish the product from all others.

Once the subgroups for basic needs, variables, and delighters are identified, you can prioritize more effectively.  First, don’t prioritize the basic needs.  If they aren’t met, you shouldn’t go to market, so they all have equal necessity by definition. 

Absolutely, prioritize the variables.  If you work with your engineering team, you can probably quickly identify those attributes that will conflict and be sure to at least put those in priority order. 

Delighters can be treated however you choose, but I do have a suggestion, which I have found very helpful.  If you can do so without taking extraordinary amounts of time (and if it does, develop a way to do it faster), put a product cost value with every delighter.  It’s a way of saying, “if we can provide this delighter, for this cost, we want it in the product.” 

If your market and customer needs processes are reasonably precise, you should be able to estimate how much customers will pay for a delighter, or how much market share you will take from competition because of it (bearing in mind that such market and sales crystal balls are never perfect).  Do a cost-benefit trade estimation for the delighter.  If you can get an extra $2-million in sales from the feature and the reduction in margins still means that you pull and extra $1/2-million in profits from those sales, go for it.

Sometimes, you know you want or need the delighter to be present and don’t care to make the fancy calculations.  If so, say so.  Make it a basic need in the requirements document and set the expectation that it be satisfied within the product cost budgeted.

Separation of specifications into basic and variable needs and prioritizing the variables is a powerful way to keep your design team focused on the places where they should be creative.  By identifying the basic needs as such, the design team will naturally find the quickest, least expensive solution and move on to the variables, where their creative and analytical efforts should be spent.

The product specification is a very important and valuable tool in your product development process.  If it is poorly written, it will generate waste and potentially poor product results.  If it is written well, and you make the most of it by communicating the opportunities to build a better product by minimizing and maximizing attributes, and put a priority on those attributes, then your design team will be encouraged or inspired to build the best possible product.  It will also be naturally focused on creating where that creativity is best invested.

Few people realize just how much waste is created or prevented, and how much quality and performance can be influenced by the way a product specification is written.  From now on, don’t let your team treat your product specification as a formality.  Treat it like a treasure map that, if written properly, will lead your team to great success.  After all, it really is.

Stay wise, friends.

P.S.  I have made available a guideline for writing product specifications.  Find it in the Download Helpful Solutions section of the bar to the right.

No comments:

Post a Comment