Value Stream Maps in PD

I'm going to say something radical today: Most time spent on value stream mapping (VSM) in product development is waste. I saw an example of that come across my desk today: a beautiful VSM that a team had obviously spent a lot of time on - that told me absolutely nothing about the biggest things getting in the way of their product development performance.

Doing VSM in many product development organizations is like doing a three day kaizen event in a factory where the critical machine in the process is out of oil. I don't need a sophisticated tool, the whole production team or an entire day to see what the immediate problem is and recommend a solution: "Get some oil in the darned machine and put some changes in place to keep it from happening again!" If I took the analysis any further without fixing the obvious things first, the data I collected would only reflect the system as it runs while the critical machine is out of oil.

As a deeply experienced product development consultant, I've learned how to spot the "critical machines" and identify the problems that tend to get them backed up. I am remiss in my responsibilities if I insist upon leading my clients through any complex diagnostic tool when they've got something obvious that's clearly holding them back. That may meet my need for more personal involvement (and therefore more billing opportunities) but it doesn't meet my clients' need to achieve higher performance as expeditiously as possible.

I rarely encounter an organization that is truely clueless about the biggest barriers that keep them stuck at their current level of performance. Finding the issues is the easy part. It's harder to prioritize the challenges, and to identify solutions that will create sustainable high performance, and stick beyond the pilot program. That's where I have the opportunity to add the most value, and so that is where I focus.

The Customer's Value Stream

Anyone who has worked with me knows that I am not a big fan of value stream maps in product development. In my experience, they rarely identify the opportunities that have the potential to create dramatic improvements in product development performance. There is plenty of waste in most product development organizations, but a value stream map cannot find the major sources of product development waste: reinvention, design silos and fuzzy value propositions.

However, there is one value stream map that I think every product development team should draw: what is your customer's value stream? In other words, how do your customers use your product to get the value from it that they expected when they purchased the product? Then what additional steps must your customers perform that do not directly contribute to the value they receive?

Here are the steps that a typical consumer software user must undergo to extract value from the product:

• Install the product.
  
• Register the product.
  
• Update the product to the latest version.
  
• Configure preferences for the product.
  
• Learn how to use the product effectively.
  
• USE IT!
  
• Resolve problems.
  
• Install additional updates.
  

Only one of these steps creates value for the customer. All of the other steps are waste. Just as in other value streams, a customer's waste exists on a continuum from necessary waste (required to support value-creating activities) and unnecessary waste. Product updates are probably necessary - but we want to make them as easy and painless as possible. Resolving problems is unnecessary waste - we want to identify the sources of this waste and eliminate it.

I used this tool with a client today. No matter how many times I lead this exercise, the insights always fascinate me. It highlights quick wins to increase end user satisfaction, while it stimulates deeper thoughts about how to create customer value that make the product itself - with all of its "necessary" waste - unnecessary. The results can be exciting and sobering at the same time.