Not a Brain Cell to Waste

I've been fortunate since I started my consulting practice. I've met some amazing people. I've had a lot of fun in places as diverse as Quebec, Minneapolis, Penang, Amsterdam, Orlando, San Diego and Providence, RI to name just a few. I've done well financially and I have enough people coming to me that I don't need to "sell" so much as just ask good questions of the people who come my way.

But that's not what gets me into every morning. If it were just about the fun or about the money, I wouldn't do it - there are easier ways to do both. No, the thing that gets me up every morning is my commitment to the engine of innovation, and its ability to solve problems that make peoples' lives better.

In yesterday's New York Times, Thomas Friedman wrote an article Georgia on My Mind (registration required) where he questioned the two political candidates' commitment to driving the engines of innovation. He took an American perspective on this - claiming that the United States must continue to invest in new technology development to thrive.

I take a more global perspective. I believe that we need innovation to solve many problems that don't begin or end at the borders of any particular nation: eliminating the possibility of terrorism as a tactic while addressing the root causes that foster it, finding alternative clean energy sources, solving public health issues, providing food and clean water to six billion people, bringing developing nations into the global economy, etc, etc. We are here because the engine of innovation opened up lines of communication and possibilities that we could not even imagine at the beginning of the 20th century. We have so many challenges left to solve in the 21st century.

The principles and practices of lean product development help ensure that we use the best of our knowledge to make decisions and eliminate wasted effort, reinvention, unnecessary activities, etc. so that we can solve these problems at the pace we need to solve them.

Whatever product your company makes, your shareholders, executives and customers need you to do it as well and as fast as possible. However your products contribute to the greater good (and we all do, somehow, or our products would not deliver enough value to sell), we also need your best work.

For all of us to live in peace and prosperity, we truly don't have a brain cell to waste.

Target Costing must be in the air

I've been catching up on my reading about Target Costing - researching tools for an existing client and refreshing my knowledge as I create a proposal for a new one. This is an area within Lean Product Development that hasn't received the same level of attention as the A3 report and set-based concurrent engineering, probably because reducing product cost is not nearly as exciting or glamorous as cutting time to market in half.

However, it's an area that a product development manager cannot afford to ignore - Toyota certainly does not. The tools required to effectively manage cost include things such as conjoint analysis to understand the relative value of specific product parameters, cost modeling to make the cost implications of specific decisions more visible, and value engineering to drive out costs at the system level. Underlying it all is a mechanism for accurately predicting product cost and then monitoring changes as the new product moves through the development cycle.

My new client has used Target Costing by M. Bradford Clifton et al as their guide. I find it to be a nice introduction with good descriptions of the basic tools.

I've just been invited to speak at the Lean Accounting Summit this September in Orlando, Florida. I'll present "Lean Accounting for Product Development" which will provide an overview of the financial information that product development teams need to effectively manage product cost during the development process. I'm looking forward to more interaction with this dynamic community. I think it may represent the next frontier in lean product development.

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.

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?