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.

Commitment, Patience and Value

Over at Evolving Excellence Kevin Meyer had an interesting post about value from a worker perspective: The Value in Jobs which was itself a reaction to a post at Cafe Hayek by Don Boudreaux: Creating Value. These two posts fit in nicely with my current theme of value in product development change initiatives.

Don kicked off the conversation by describing the world of work as divided between two camps: those who think of their jobs as boxes with levers inside that trigger salaries, and those who thought of their jobs as opportunities to create value for customers - for pay that is tied to the value delivered. He then characterized corporate managers as people clearly in the second camp but who provide essential coordination and direction for those in the first camp so that their activities also create value. Kevin used Don's description of the role of management to support his belief that top management must have patient commitment for a lean transformation to succeed.

However, Kevin makes the mistake that I see so often in the lean community: any activity - including a lean transformation - must deliver clear, measurable results. Patience and commitment are not enough if the lean transformation accomplishes very little for the customer or for the business in proportion to the investment required within a reasonable timeframe.

Kevin argues that lean transformations fail because management lacks patience and commitment. But my observations tell me otherwise. I have observed that lean transformations that deliver clear, timely results tend to succeed - sometimes in spite of management commitment to give things time - and that lean efforts that promise benefits too far in the future tend to fail - sometimes because managers were so patient for results that they didn't question the lean transformation's direction.

How Long Before We See Results?

Do you have anyone telling you that you won't see any benefit from efforts to change product development for many years - or until the products now at the very beginning of development have made it all the way to product release?

That's both incorrect and dangerous. No matter how long your product development lifecycles are, you should be able to see real improvement in the metrics that matter to you within one year. This is important, because publicly-run companies have notoriously short attention spans. Any change initiative that spans more than two years, but produces no tangible results until Year 3 is an initiative living on borrowed time.

If your product development lifecycles are longer than that (especially if they are very long - three to five years) you should be diligent about looking for opportunities to increase flow in product development at every phase of the lifecycle. No product development program should be exempt from the need to rethink things. Even the products that were developed almost entirely under the old paradigm should benefit in ways that lead to lower product costs, especially warranty costs and a smoother transition to manufacturing.

It is true that completely reinventing product development takes several complete product lifecycles - especially if the goal is to achieve Toyota's level of competence. But it does not follow that the business must have faith and patiently wait for results.

In fact, if significant results are not forthcoming in the first year, that's an indicator to me that the change initiative is not gaining traction. The longer it takes before the numbers start to move, the long-awaited results become less and less likely to materialize.

Market Pull Signals and Time-To-Market

How much does customer demand for new products drive your development process? The answer will tell you how important time-to-market is relative to other indicators of product development performance.

"Market pull" is an indicator of customer demand for new products. An effective product development organization times its product releases to synchronize with market pull signals.

Some products have very strong pull signals - such as any product that sells best in the summer or at Christmas. A successful company in such a market will have already figured out how to deliver products on time to meet that market window. Others have only weak signals, such as mature products with long lifespans of five years or more. In those markets, product developers may choose to invest extra resources into lowering product costs or adding more features than rushing to market with a product that is only a marginal improvement over an existing product.

Depending on the nature of the pull signal, speeding up time to market may or may not have any impact on the product's return on investment. If it doesn't, then you will need other measures to translate increased R & D productivity into business results, such as number of new products released, lower warranty cost or cost to manufacture. If you insist upon an effort to reduce time-to-market in such an environment, don't be surprised if the product development teams display disinterest.

How to Talk to Product Developers about Value

I have a hint for those of you working in "lean six sigma change agent" roles or similar areas where you are expected to evangelize lean into product development: you need to stop talking like manufacturing people, and start talking value in terms that are meaningful to product developers.

Let's take "takt time" or "cycle time" for instance. A typical product development project takes months, if not years - unlike the hours or days a manufacturing process takes. A product development organization can usually tell you how long it will take to develop a "typical" product with a given scope. Better ones can give a pretty accurate estimate for the time from the end of feasibility to the beginning of production for several different types of projects.

But the term "cycle time" doesn't reflect the way product development managers think about time. These managers develop and execute product strategies that detail the products to be delivered into specific markets at specific points in time. Development managers think in terms of how far in advance the projects need to start in order to finish on time. This metric is called "time to market" or "speed to market" to reflect the managers' focus on delivering the product.

"Takt time" is even worse because it implies regularity and consistency that simply doesn't reflect realities in product development. We may do a simple refresh on last year's product for 2008 so that we can leapfrog the competition with a completely new product in 2009. Not even Toyota, with its annual demand for new car models, is as consistent as a takt time would indicate.

You need to be similarly careful when talking about costs. When you talk about cost reductions, do you mean development cost, tooling cost, direct material cost, cost to manufacture, cost to service and support, or sales and marketing costs? If you use a value stream map as your primary tool, the only cost you can impact is development cost, but that is usually only a small part of the overall product cost. If you are focused on Design for Manufacture and Assembly (DFMA) or of of its variants, then how are you measuring the impact to total product cost?

Allen Ward's Lean Product and Process Development

I'm pleased to tell you that the Lean Enterprise Institute has finally published Dr. Allen Ward's book on Lean Product Development. Although the HP team only knew Allen for a very short time, his impact on our work was immense and I am happy to see that his ideas are living on.

Dr. Ward's work was left unfinished when he died in a plane crash on May 31, 2004. The manuscript for this book was written mostly in 2001, and it doesn't reflect some of the major insights from the last years of his work, such as the LAMDA cycle to organize Plan-Do-Check-Act for knowledge workers. Some terms have evolved - the 'entrepreneurial system designer' is now commonly known as the Chief Engineer.

True to his spirit, Allen begins the book with a challenge: "How can you make all of your development projects make a lot more money -- and have more fun at the same time?" His voice filled with "tough love" for engineering managers and his passion for excellence shines through every page of the book.

Durward Sobek and John Shook helped organize his unfinished manuscript, and the result is much better than I would have expected. They have filled in a couple of missing pieces and provided much-needed context in the foreward, leaving the rest as Allen had it.

This is now the first book I would recommend to someone to learn about Lean Product Development.

Welcome!

This is the long-planned replacement to the Lean Product Development newsletter I started last year. Since that time, a few things have happened that make this blog a better format for continuing our conversation:

• Blogging software finally has all the features it needs to support blogging the way I want to do it - as a moderated conversation with others in the product development community.
  
• My consulting work has broadened beyond Lean Product Development as a methodology for improving product development performance, and I want the freedom to write about everything I see, whether or not the topics are specifically Lean.
  

I appreciate all the subscribers I accumulated in the last year who have been eager to learn more about Lean Product Development. I think you will find the new material to be just as interesting, even if it's not always purely Lean. We are all interested in learning more about how to dramatically improve product development performance, and increasing our ability to deliver customer value.