The CEO throws out the challenge – “Fix new product development.” Great idea, but not actionable. Can’t put a plan together.  Don’t know the problem.  Stepping back, who will lead the charge? Whose problem is it?

The goal of all projects is to solve problems.  And it’s no different when fixing product development – work is informed by problems. No problem, no fix. Sure you can put together one hell of a big improvement project, but there’s no value without the right problem. There’s nothing worse than spending lots of time on the wrong problem.  And it’s doubly bad with product development because while fixing the wrong problem engineers are not working on the new products.  Yikes.

Problems are informed by outcomes.  Make a short list of desired outcomes and show the CEO.  Your list won’t be right, but it will facilitate a meaningful discussion.  Listen to the input, go back and refine the list, and meet again with the CEO.  There will be immense pressure to start the improvement work, but resist.  Any improvement work done now will be wrong and will create momentum in the wrong direction.  Don’t move until outcomes are defined.

With outcomes in hand, get the band back together. You know who they are.  You’ve worked with them over the years. They’re influential and seasoned.  You trust them and so does the organization.  In an off-site location show them the outcomes and ask them for the problems. (To get their best thinking spend money on great food and a relaxing environment.)  If they’re the right folks, they’ll say they don’t know.  Then, they’ll craft the work to figure it out – to collect and analyze the data.  (The first part of problem definition is problem definition.) There will be immense pressure to start the improvement work, but resist.  Any work done now will be wrong.  Don’t move until problems are defined.

With outcomes and problems in hand, meet with the CEO.  Listen.  If outcomes change, get the band back together and repeat the previous paragraph. Then set up another meeting with the CEO.  Review outcomes and problems.  Listen.  If there’s agreement, it’s time to put a plan together.  If there’s disagreement, stop.  Don’t move until there’s agreement.  This is where it gets sticky.  It’s a battle to balance everyone’s thoughts and feelings, but that’s your challenge.  No words of wisdom on than – don’t move until outcomes and problems are defined.

There’s a lot of emotion around the product development process.  We argue about the right way to fix it – the right tools, training, and philosophies. But there’s no place for argument.  Analyze your process and define outcomes and problems.  The result will be a well informed improvement plan and alignment across the company.

It’s a simple formula, but it provides a framework to focus on fundamentals. While all parts of the organization contribute to profit in their own way, engineering’s work has a surprisingly broad impact on the equation.

The market sets price, but engineering creates function, and improved function increases the price the market will pay. Design the product to do more, and do it better, and customers will pay more. What’s missing for engineering is an objective measure of what is good to the customer.

To read the complete article, click this link.

It’s a waste of time to ask customers for the next big thing or get their thoughts on a radical technology. First off, it’s not their job to know the next big thing, it’s ours. The next big thing is bigger than their imagination, never mind what they do today. (That’s why it’s called the next big thing.) And if we wait for customers tell us the next big thing, we’re hosed. (Their time horizon is too short and ours is shorter.) In this case it’s best to declare failure; our competitors figured it out a long time ago (they didn’t wait for the customer) and are weeks from commercialization. We should get busy on the next, next big thing because we’ve already missed this next generation. Next time we’ll silence the voice of the customer (VOC) and listen to the voice of the technology (VOT).

As far as radical technology, if we wait for customers to understand the technology, it’s not radical. Radical means radical, it means game-changing, a change so radical it obsoletes business models and creates unrecognizable, ultra-profitable, new ones. That’s radical. If we don’t start technical work until our customers understand the new technology, it’s no longer radical, and our competitors have already cornered the market. Again, we’ve missed an entire generation. Next time we’ll silence the voice of the customer (VOC) and listen to the voice of the technology (VOT).

Technology has a life force; it has a direction; it knows what it wants to be when it grows up. It has a voice. Independent of customer, it knows where it wants to go and how it will get there. At the highest level it has character traits and preferred paths, a kind of evolutionary inevitability; this is the voice of technology (VOT).

Technology will evolve to complete itself; it will move toward natural periodicity among its elements; it will harmonize itself; it will become more controllable; it will shorten its neural flow paths;  it will do yoga to improve its flexibility; its feet will grow too fast and create adolescent imbalance; it will replicate into multiples selves; it will shrink itself;  it will improve its own DNA. This is VOT.

Technology cannot tell us its lower-level embodiments (we control that), but it does sing hymns of its high-level wants and desires, and we must listen. No need to wait for VOC, it’s time to listen to VOT.

Like a dog whistle, technologists can hear VOT while others cannot. We understand the genetics of technology and we understand its desires (because we understand its physics.) We can look back to its ancestors, see its trajectory of natural evolution, and predict attributes of its offspring. Before everyone else, we see what will be.

Next time, instead of VOC, ask your technologists what the voice of technology is saying, and listen.

WHY – Don’t start with WHAT. If you do, we’ll shut down. You don’t know the answer, we do. And you should let us tell you. Start with WHY. Give us the context, give us the problem, give us the business fundamentals, give us the WHY. Let us ask questions. Let us probe. Let us understand it from all our angles. Don’t bother moving on. You can’t. We need to kick the tires to make sure we understand WHY. (It does not matter if you understand WHY. We need understand it for ourselves, in our framework, so we can come up with a solution.)

WHAT – For God’s sake don’t ask HOW – it’s too soon. If you do, we’ll shut down. You don’t know the answer, we do. And, if you know what’s good for you, you should let us tell you. It’s WHAT time. Share your WHAT, give us your rationale, explain how your WHAT follows logically from your WHY, then let us ask questions. We’ll probe like hell and deconstruct your WHY-WHAT mapping and come up with our own, one that makes sense to us, one that fits our framework. (Don’t worry, off-line we’ll test the validity of our framework, though we won’t tell you we’re doing it.) We’ll tell you when our WHY-WHAT map holds water.

HOW – Don’t ask us WHEN! Why are you in such a hurry to do it wrong?! And for sanity’s sake, don’t share your HOW. You’re out of your element. You’ve got no right. Your HOW is not welcome here. HOW is our domain – exclusively. ASK US HOW. Listen. Ask us to explain our WHAT-HOW mapping. Let us come up with nothing (that’s best). Let us struggle. Probe on our map, push on it, come up with your own, one that fits your framework. Then, and only then, share how your HOW fits (or doesn’t) with ours. Let us compare our mapping with yours. Let us probe, let us question, let us contrast. (You’ve already succeeded because we no longer see ours versus yours, we simply see multiple HOWs for consideration.) We’ll come up with new HOWs, hybrid HOWs, all sorts of HOWs and give you the strengths and weaknesses of each. And if your HOW is best we’ll recommend it, though we won’t see it as yours because, thankfully, it has become ours. And we’ll move heaven and earth to make it happen. Engineering has new thinking.

Whether it’s my favorite new thinking (product simplification) or any other, the WHY, WHAT, HOW process works. It works because it’s respectful of our logic, of our nature. It fits us.

Though not as powerful a real Vulcan mind meld, WHY, WHAT, HOW is strong enough to carry the day.

Pretend you’re a manufacturer of jeans, the blue ones, the ones that feel so good when you put them on, the ones you’d like to wear to work if you could. (Maybe that’s just me.) Year-on-year your innovation efforts focus on adding pockets then removing them, adding holes then removing them, zippers here then there, dark wash then light, baggy then tight, and yellow stitching than red. What else can a jean innovator do?

Corporate sends the memo: “We’re going Green.” Green jeans. They hire the best sustainability consultants and you, the jean innovator, sit through the sustainability audit results. Their recommendation – reduce carbon footprint: use materials that consume less energy, reduce electricity in your factories, minimize distribution’s fuel costs, and reduce travel miles of your sales folks. Brilliant. Whatever we paid these guys, it was too much. But then they twist your brain. The carbon footprint from the use of your product dwarfs everything else. Your customers generate a massive carbon footprint when they wash and dry your jeans, and you have no control over it. Your jeans are made once and washed and dried countless times. Whoa. Your eyes roll back in your head. What’s a jean innovator to do? First thing – forget about the stupid pockets. Next, figure out how to reduce the carbon footprint generated by your customers. Define the problem and innovate. But what’s the problem?

Why do folks wash their jeans? The obvious answer – they’re dirty. Let’s figure a way to prevent jeans from getting dirty, right? No. The real answer – they stretch, they get baggy and don’t fit right; so we wash them to tighten things up. We wash CLEAN jeans because they get baggy, not because they’re dirty. Let’s fix that.

Believe it or not, there are many likely innovative solutions to make jeans de-baggy themselves, but that’s not the point. The point is we must innovate on jeans that reconfigure, and must not innovate on keeping jeans clean (though we may innovate on that down the road) and must not innovate on pockets, zippers, and stitching.

Green shaped our innovation work. We now have Green jeans that feel good and spring back after wearing and fit great on day two – no washing required. We now have Green jeans that save customers time and money while flattering their backside. But here’s the point – we would have never invented de-baggying jeans without opening our minds to Green as a way to grow our business, to Green as a way to make money. Reluctant compliance won’t get us there. Grab Green by the throat and shake it…before your competitors do.

Continuous improvement is a philosophy of minimization with a focus on cost and waste reduction, while discontinuous improvement is a philosophy of maximization with a focus on creation of new markets through product innovation. As of late, we’ve minimized waste at the expense of invention and innovation. I propose we flip this on its head and maximize through discontinuous improvement at the expense of continuous improvement. That’s right; I said do less lean and Six Sigma.

But we must ask ourselves if we’re capable of doing discontinuous improvement. Remember, we ignored or dismantled our innovation engines over the last years. And what about our big thinkers, our creative thinkers, our innovators? Do they still work for us, or have they just stopped talking about big ideas? I urge you to answer that question because your next actions depend on it.

If your innovative thinkers are gone, go out and hire the best you can find ASAP. If you were fortunate enough to retain your big thinkers, congratulations. Now it’s time to get the band back together, but first you’ve got to do some reconnaissance to ferret them out of their hiding places. Once you find them, invite them to a nice lunch – the nicer the better. Don’t push too hard at lunch, just start to  get reacquainted. In time you’ll get to talk about their ideas on new technologies and how to create new markets.

It will be difficult to get your company swing the pendulum away from continuous improvement, but you must try. Without discontinuous improvement your company will be destined to wrestle for nickels using lean and Six Sigma.

When does the product pipeline become too much for your product development engine to handle? We all know you can’t keep adding more new product development projects without adding capacity or improving productivity. Sure you can ask your product development engine to do more (and more), and it will try; but at some point it will run out of gas. So, ask yourself: Has your product development engine run out of gas? How can you tell? If it hasn’t, do you know how many miles are left in the tank?

If you don’t measure it you can’t improve it, that’s what the black belts say. But what to measure? What are the right metrics to tell you if your product development engine is out of gas? One of the best books on the subject is Managing the Design Factory, by Don Reinertsen. The rest of the post is strongly shaped by Don’s book, if not taken directly from it. Remember, genius steals.

The best metrics are simple, relevant to the objective, and are leading indicators. Simple so they’re easy to interpret; relevant so they move you toward the objective, in this case launching more new products; and are leading indicators, in that they are predictors of outcomes, so you can take action before catastrophic outcomes occur.  Here are three good ones.

Metric 1 – Turnover. When people leave the projects, development capacity is reduced and trouble will follow. Simply put, there are fewer people to do the work, but the project timelines are not pushed out. The new products will hit the market much later than usual.

Metric 2 – Staffing Level Relative to Project Plan. When project plans are created, the number of people needed to execute the project is defined. Read the project plan and write down that number, then compare it to the actual number of people working on the project. As the ratio drops, so will the number of new products launched.

Metric 3 – Queue Size. When you’re waiting in a line of cars at the drive through that’s a queue. The number of cars in the line is the queue size. The queue size (number of cars) is a great predictor of waiting time – long lines predict long wait times. You don’t even have to get in line to know the wait will be long. Best of all it’s easy to see the number of cars in the queue, so it’s easy to predict wait time by looking at queue size. In product development, queues are not lines of cars, but rather piles of stacked up tasks waiting for resources. Big piles mean long waits which will result in fewer product launches. Are there more cars lined up in your product development drive through?

Metric 1 and 2 are straightforward, but Metric 3 – Queue Size – is not. Big queues are a result of taking on too many product development projects resulting in an over-full pipeline. Capacity utilization soars and so does the waiting. It’s backwards: the desire to launch more products increases wait times resulting in fewer products launched, not more. So, decrease capacity utilization and the queues shrink. How to do that? Increase capacity.

Here’s a short list of actions to increase product development capacity.

1. Improve your engineering tools. As engineering productivity increases the same number of engineers can put out more design work – more capacity.
2. Increase support resources. Most often it’s the shared resources of the support teams that cause the waiting. Increase support resources so your engineers don’t wait – more capacity.
3. Reduce non-value added activity. Overlap tasks and streamline your product development process. Less waste frees up capacity.
4. Invest in training. Better trained engineers do work faster and better (less re-work). Both free up capacity.
5. Cross train. The added flexibility from cross training allows the engineers to move to the work. More effective use of resources increases capacity.

Increasing capacity is easy to talk about, but difficult to do. All options require investment which, as we know, is difficult to come by. However, new products are a key to profitability. Do the math – compare the cost of the investment and the value of the new products, and hopefully you’ll budget for some investment to increase your product development capacity.

CEOs have a strong desire to do what it takes to deliver shareholder value, but that’s coupled with a deep concern that tough decisions may dismantle the company in the process.

Here is the state-of-affairs:

Sales are down and money is tight.  There is severe pressure to cut costs including those that are linked to sales – marketing budgets, sales budgets, travel – and things that directly impact customers – technical service, product manuals, translations, and warranty.

Pricing pressure is staggering.  Customers are exerting their buying power – since so few are buying they want to name their price (and can).  Suppliers, especially the big ones, are using their muscle to raise prices.

Capacity utilization is ultra-low, so the bounce-back of new equipment sales is a long way off.

Everyone wants to expand into new markets to increase sales, but this is a particularly daunting task with competitors hunkering down to retain market share, cuts in sales and marketing budgets, and hobbled product development engines.

There is a desire to improve factory efficiency to cut costs (rather than to increase throughput like in 2008), but no one wants to spend money to make money – payback must be measured in milliseconds.

So what’s a CEO to do? 

Focus on product.  Selling into new markets requires new products; even with full marketing and sales budgets, new products are required.  But, hobbled product development engines aren’t going to get it done – they can’t even do what they used to, never mind do more with high levels of innovation.  Here are some steps that can get things on track.

First, some investment must be made to understand the new markets.  They’re called new markets because they’re new – previous experience is not valid and new experience must be created.  So get some experience by watching customers use the leading products and talking directly with them about what they like and what they don’t.  A list of new functions and features is the desired outcome, along with a sale price and target cost.

The new features, functions, and cost target are the input to the product development engine.  The existing product with the strongest overlap with the new features and functions is used as the platform for the new design.  To make a splash, functionality and cost must be improved at the same time (remember, customers are naming their price).  Hopefully the engineering team has the chops to do the new work.  If not, some investment must be made to bolster their capability in the new areas.  Don’t skimp here or the new product will come out wrong (if at all) falling short of functionality and cost goals.

There is another deliverable from the product development engine.  The engine must create A/B performance data from which data-driven sales tools are created.  The best product in the new market is chosen as the baseline product (A) and tested to define the performance specification (maybe 20% better than the baseline product).  The new product (B) is tested under the same test protocol and its performance is plotted relative to the performance specification (20% better than the baseline product [product A]).  If the product development engine does its job, the new produce will have a competitive advantage over the best product in the market, with more function and less cost.

Some investment is needed to develop (and translate?) the data-driven sales tools and some spending is needed to get the sales force (and their new tools) in front of customers.  Don’t forget the sales tracking systems.

Improving the product development engine is vital.  Designing higher functioning products with low cost signatures is not natural for engineers, so care must be taken when defining the challenge.  And the morale of the engineering teams is likely low due to the recent cost cutting.  They may not be in the right frame of mind to accept their challenge, so a thoughtful delivery makes a difference.  A modest training plan to develop their capability goes a long way to putting them in the right frame of mind.

There is no free lunch here, and little new thinking.  Solid blocking-and-tackling is needed from marketing, sales, engineering, and manufacturing along with improved capability in engineering.  Even in a recession, this approach can grow sales in new markets, especially when coupled with strong focus.

Next time you see your CEO, give a smile, a hand shake, and a thank you.

The first question – what makes products “right” for these times?  Capacity is important to understanding what makes products right.  Capacity utilization is at record lows with most industries suffering from a significant capacity glut.  With decreased sales and idle machines, customers are no longer interested in products that improve productivity of their existing product lines because they can simply run their idle machines more.  And, they are not interested in buying more capacity (your products) at a reduced price.  They will simply run their idle machines more.  You can’t offer an improvement of your same old product that enables customers to make their same old products a bit faster and you can’t offer them your same old products at a lower price.  However, you can sell them products that enable them to capture business they currently do not have.  For example, enable them to manufacture products that their idle machines CANNOT make at all.  To do that means your new products must do something radically different than before; they must have radically improved functionality or radically new features.  This is what makes products right for these times.

On to the second question – do you have the capability to engineer the right products?  It’s always a great idea to ask for products with radical improvements in functionality, but it’s another thing altogether to create products with radical improvements – to engineer them.  You must have good engineers if you are to create these types of products.  It’s good if you have been able to hold onto your engineers through the recession, that’s a good start.  If you were not, that’s bad — you must get some.

Designing products with radical improvements is difficult even for the best engineers.  Your engineers are bright but have not been taught how to design these products.  Usually they design them by instinct which is a root cause for the low hit rate and schedule misses.  Everyone is afraid of falling short of the specification and missing the schedule; going after radical improvements is a scary business.  It is scary because success rides on the instinctive skills of the engineer.  But there is a better way.  Engineers can be taught to do this work.

It is my experience that the toughest part of solving technical problems is defining the right problem to solve.  Yet, we don’t take the time to define the problem well enough.  It’s usually a ready-fire-aim approach to problem solving that is long on activity but short on progress.  Paradoxically, the engineers must slow down in order to make faster progress.  The engineers must be taught to painstakingly define the physics of technical problems using simple language (simple nouns and verbs) and simple block diagrams.  This is not easy.  It takes a lot of work to help (force) the engineers to shed the complexity to reveal the simple truth.  And, it takes a lot of energy to calm the managers who think nothing is going on during the problem definition phase.  Managers are more comfortable watching activity than watching thinking. 

In these difficult times it is especially important (and especially difficult) to give your engineers the tools, time, and training to achieve radical improvements.  But take comfort in an engineering paradox – sometimes slower is faster.

As we all know, that’s a bunch of crap.  Many manufactures are still in survival mode where cost cutting has crossed into the ridiculous; where the best talent has been cut; and where the product development flywheel is motionless.  We are far from coming out of this thing, and the bad stuff we had to do to survive will take time to undo.

However, some companies are considering options to accelerate themselves out of the soup.  They are asking the big question - what is the fastest way out? 

To me, the fastest way out is all about three things: product, product, product – do you have the right products coming to market?  Or, if not, how can you get your product development flywheel moving so the right products hit the market as quickly as possible?  But, what are the attributes of the “right product”?

I think there are two components of the right product: the top line component and the bottom line component.  The top line component (which drives top line growth) is all about function and features.  More function equals increased sales through market share and price.  The bottom line component (bottom line growth) is all about cost.  Pretty basic.  But, if your resources are limited (like most of us) and can improve only one, which should you improve?

Bottom line cost reduction is not glamorous, but the balance sheet improvment is surprisingly good.  Let me give an example.  Product A is an existing product that sells for $1000 and it costs you $800 to produce, providing $200 profit per unit.  You spend your product development resources on a bottom line effort and reduce product cost by 20%.  Still selling for $1000 but with a cost of $640 (0.8 * $800), profit dollars increase by 80% ($360 vs. $200).  Not bad especially since sales have not increased.

Top line growth has a strong emotional component which energizes people, and the upside potential is huge.  Here is an example using the same product as above.  Product A still sells for $1000, costs you $800, and you make $200 per unit.  You spend your product development resources on a top line project to add better functionality and more features.  Because you don’t have time to address the bottom line component, your costs go up 10% (to $880).  But, you do get the function and features you wanted, and the market can support a 10% price increase to $1100.  Profit per unit is up 10% t0 $220 ($1100 – $880).  Your engineering really came through and the market likes your new product and sales increase by 20%.  With all that, profit dollars increase by 32% ($220*1.2 = $264 vs. $200).

Clearly the examples are contrived to illustrate a point: bottom line cost reduction is powerful and so are top line sales growth and price increase.  And the best answer is not to choose between top line and bottom line components.  It makes a lot of sense to do a little of both, because it’s the fastest way out of the soup.