Shipulski On Design

Posts Tagged ‘Product Development Engine’

Our threshold for uncertainty is too low.

Early in projects, even before the first prototype is up and running, you know what the product must do, what it will cost, and, most problematic, when you’ll be done. Independent of work content, level of newness, and workloads, there’s no uncertainty in your launch date. It’s etched in stone and the consequences are devastating.

A zero tolerance policy on uncertainty forces irrational behavior. As soon as possible, engineering gets something running in the lab, and then doesn’t want to change it because there’s no time. The prototype is almost impossible to build and is hypersensitive to normal process variation, but these issues are not addressed because there’s no time.  Everyone agrees it’s important to fix it, and agrees to fix it after launch, but that never happens because the next project is already late before it starts. And the death cycle repeats project after project.

The root cause of this mess is the mistaken porting of manufacturing’s zero uncertainly mindset into design. The thinking goes like this – lean and Six Sigma have achieved magical success in manufacturing by eliminating uncertainty, so let’s do it in product design and achieve similar results. This is a fundamental mistake as the domains are fundamentally different.

In manufacturing the same product is made day-in and day-out – no uncertainty; in product design no two product development efforts are the same and there’s lots of stuff that’s done for the first time – uncertainty by definition. In manufacturing there’s a revision controlled engineering drawing that defines the right answer (the geometry and the material) – make it like the picture and it’s all good; in product design the material is chosen from many candidates and the geometry is created from scratch – the picture is created from nothing. By definition there’s more inherent uncertainty in product design, and to tighten the screws and fix the launch date at the start is inappropriate.

Design engineers must feel like there’s enough time to try new things because new products that provide new functionality require new technologies, new materials, and new geometries. With new comes inherent uncertainty, but there are ways to manage it.

To hold the timeline, give on the specification and cost. Design as fast as you can until you run out of time then launch. The product won’t work as well as you’d like and it will cost more than you’d like, but you’ll hit the schedule. A good way to do this is to de-feature a subassembly to reduce design time, and possibly reduce cost. Or, reuse a proven subassembly to reduce design time – take a hit in cost, but hit the timeline. The general idea – hold schedule but flex on performance and cost.

It feels like sacrilege to admit that something’s got to give, but it’s the truth. You’ve seen how it goes when you edict (in no uncertain terms) that the timeline will be met and there’ll be no give on performance and cost. It hasn’t worked, and it won’t – the inherent uncertainty of product design won’t let it.

Accept the uncertainty; be one with it; and manage it. It’s the only way.

At the start of projects, no one knows what to do.  Engineering complains the specification isn’t fully defined so they cannot start, and marketing returns fire with their complaint – they don’t yet fully understand the customer needs, can’t lock down the product requirements, and need more time.  Marketing wants to keep things flexible and engineering wants to lock things down; and the result is a lot of thrashing and flailing and not nearly enough starting.

Both camps are right – the spec is only partially formed and customer needs are only partially understood – but the project must start anyway.  But the situation isn’t as bad as it seems.  At the start of a project fully wrung out specs and fully validated customer needs aren’t needed.  What’s needed is definition of product attributes that set its character, definition of how those attributes will be measured, and definition of the competitive products.  The actual values of the performance attributes aren’t needed, just their name, their relative magnitude expressed as percent improvement, and how they’ll be measured.

And to do this the project manager asks the engineering and marketing groups to work together to create simple bar charts for the most important product attributes and then schedules the meeting where the group jointly presents their single set of bar charts.

This little trick is more powerful than it seems.  In order to choose competitive products, a high level characterization of the product must be roughed out; and once chosen they paint a picture of the landscape and set the context for the new product.  And in order to choose the most important performance (or design) attributes, there must be convergence on why customers will buy it; and once chosen they set the context for the required design work.

Here’s an example.  Audi wants to start developing a new car.  The marketing-engineering team is tasked to identify the competitive products.  If the competitive products are BMW 7 series, Mercedes S class, and the new monster Hyundai, the character of the new car and the character of the project are pretty clear.  If the competitive products are Ford Focus, Fiat F500, and Mini Cooper, that’s a different project altogether.  For both projects the team doesn’t know every specification, but it knows enough to start.  And once the competitive products are defined, the key performance attributes can be selected rather easily.

But the last part is the hardest – to define how the performance characteristics will be measured, right down to the test protocols and test equipment.  For the new Audi fuel economy will be measured using both the European and North American drive cycles and measured in liters per 100 kilometer and miles per gallon (using a pre-defined fuel with an 89 octane rating); interior noise will be measured in six defined locations using sound meter XYZ and expressed in decibels; and overall performance will be measured by the lap time around the Nuremburg Ring under full daylight, dry conditions, and 25 Centigrade ambient temperature, measured in minutes.

Bar charts are created with the names of the competitive vehicles (and the new Audi) below each bar and performance attribute (and units, e.g., miles per gallon) on the right.  Side-by-side, it’s pretty clear how the new car must perform.  Though the exact number is not know, there’s enough to get started.

At the start of a project the objective is to make sure you’re focusing on the most performance attributes and to create clarity on how the attributes (and therefore the product) will be measured.  There’s nothing worse than spending engineering resources in the wrong area.  And it’s doubly bad if your misplaced efforts actually create constraints that limit or reduce performance of the most important attributes. And that’s what’s to be avoided.

As the project progresses, marketing converges on a detailed understanding of customer needs, and engineering converges on a complete set of specifications.  But at the start, everything is incomplete and no part of the project is completely nailed down.

The trick is to define the most important things as clearly as possible, and start.

There’s a natural tendency to simplify, to reduce, to narrow. In the name of problem solving, it’s narrow the scope, break it into small bites, and don’t worry about the subtle complexities. And for a lot of situations that works. But after years of fixing things one bite at a time, there are fewer and fewer situations that fit the divide and conquer approach. (Actually, they’re still there, but their return on investment is super low.) And after years of serial discretization, what are left are situations that cannot be broken up, that cut across interfaces, that make up a continuum. What are left are big problems and big situations that have huge payoff if solved, but are interconnected.

Whether it’s cross-discipline, cross-organization, cross-cultural, or cross-best practice, the fundamental of these big kahunas is they cross interfaces. And that’s why they’ve never been attacked, and that’s why they’ve never been solved. But with payoffs so big, it’s time to take on connectedness.

For me, the most severe example of connectedness is woven around the product. To commercialize a product there are countless business process that cut across almost every interface. Here are a few: innovation, technology development, product development, robustness testing, product documentation, manufacturing engineering, marketing, sales, and service. Each of these processes is led by one organization and cuts across many; each cut across expertise-specialization interfaces; each requires information and knowledge from the other; and each new product development project must cooperate with all the others. They cannot be separated or broken into bits. Change one with intent and change the others with unintended consequences. No doubt – they’re connected.

Green thinking is much overdue, but with it comes connectedness squared. With pre-green product commercialization, the product flowed to the end user and that was about it. But with environmental movement there’s a whole new return path of interconnected business processes. Green thinking has turned the product life cycle into the circle of life – the product leaves, it lives it’s life, and it always comes back home.

And with this return path of connectedness, how the product goes together in manufacturing must be defined in conjunction with how it will be disassembled and recycled. Stress analysis must be coordinated with packaging design, regulations of banned substances, and material reuse of retired product. Marketing literature must be co-produced with regulatory strategy and recycling technologies. It’s connected more than ever.

But the bad news is the good news. Yes, things are more interwoven and the spider web is more tangled. But the upside – companies that can manage the complexity will have a significant advantage. Those that can navigate within connectedness will win.

The first step is to admit there’s a problem, and before connectedness can be managed, it must be recognized. And before it can become competitive advantage, it must be embraced.

How long will it take? The short answer – same as last time. How long do we want it to take? That’s a different question altogether.

If the last project took a year, so will the next one. Even if you want it to take six months, it will take a year. Unless, there’s a good reason it will be different. (And no, the simple fact you want it to take six months is not a good enough reason in itself.)

Some good reasons it will take longer than last time: more work, more newness, less reuse, more risk, and fewer resources. Some good reasons why it will go faster: less work, less newness, more reuse, less risk, more resources. Seems pretty tight and buttoned-up, but things aren’t that straight forward.

With resources, the core resources are usually under control.  It’s the shared resources that are the problem. With resources under their control (core resources) project teams typically do a good job – assign dedicated resources and get out of the way. Shared resources are named that way because they support multiple projects, and this is the problem. Shared resources create coupling among projects, and when one project runs long, resource backlogs ripple through the other projects. And it gets worse. The projects backlogged by the initial ripple splash back and reflect ripples back at each other. Understand the shared resources, and you understand a fundamental dynamic of all your projects.

Plain and simple – work content governs project timelines. And going forward I propose we never again ask “How long will it take?” and instead ask “How is the work content different than last time?” To estimate how long it will take, set up a short face-to-face meeting with the person who did it last time, and ask them how long it will take. Write it down, because that’s the best estimate of how long it will take.

It may be the best estimate, but it may not be a good one. The problem is uncertainty around newness. Two important questions to calibrate uncertainty: 1) How big of a stretch are you asking for? and 2) How much do you know about how you’ll get there? The first question drives focus, but it’s not always a good predictor of uncertainty.  Even seemingly small stretches can create huge problems. (A project that requires a 0.01% increase in the speed of light will be a long one.) What matters is if you can get there.

To start, use your best judgment to estimate the uncertainty, but as quickly as you can, put together a rude and crude experimental plan to reduce it. As fast as you can execute the experimental plan, and let the test results tell you if you can get there. If you can’t get there on the bench, you can’t get there, and you should work on a different project until you can.

The best way to understand how long a project will take is to understand the work content. And the most important work content to understand is the new work content. Choose several of your best people and ask them to run fast and focused experiments around the newness. Then, instead of asking them how long it will take, look at the test results and decide for yourself.

Engineering is more important than manufacturing – without engineering there is nothing to make, and engineering is more important than marketing – without it there is nothing to market.

If I could choose my competitive advantage, it would be an unreasonably strong engineering team.

Ideas have no value unless they’re morphed into winning products, and that’s what engineering does. Technology has no value unless it’s twisted into killer products. Guess who does that?

We have fully built out methodologies for marketing, finance, and general management, each with all the necessary logic and matching toolsets, and manufacturing has lean. But there is no such thing for engineering. Stress analysis or thermal modeling? Built a prototype or do more thinking? Plastic or aluminum? Use an existing technology or invent a new one? What new technology should be invented? Launch the new product as it stands or improve product robustness? How is product robustness improved? Will the new product meet the specification? How will you know? Will it hit the cost target? Will it be manufacturable? Good luck scripting all that.

A comprehensive, step-by-step program for engineering is not possible.

Lean says process drives process, but that’s not right. The product dictates to the factory, and engineers dictate the product. The factory looks as it does because the product demands it, and the product looks as it does because engineers said so.

I’d rather have a product that is difficult to make but works great rather than one that jumps together but works poorly.

And what of innovation? The rhetoric says everyone innovates, but that’s just a nice story that helps everyone feel good. Some innovations are more equal than others. The most important innovations create the killer products, and the most important innovators are the ones that create them – the engineers.

Engineering as a cost center is a race to the bottom; engineering as a market creator will set you free.

The only question: How are you going to create a magical engineering team that changes the game?

The new product development process creates more value than any other process. And because of this it’s a logical target for improvement.  But it’s also the most complicated business process.  No other process cuts across an organization like new product development. Improvement is difficult.

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.

Pent up demand is everywhere.  After almost two years of cutting inventories and pushing out purchases, companies are ready to buy. And with credit coming back on line, they’re ready to buy in bulk.  Good news?  No, great news.  We’re back on our growth path. And that’s good because Wall Street now expects growth. But, together this wicked couple of pent up demand and Wall Street’s appetite for immediate growth has created a powder keg that’s ready to blow.

Companies want more new products to satisfy the pent up demand (and Wall Street).  Growth through new products is a theme heard around the globe; there’s a relentless push for more products – early and often. Resources be damned, best practices be damned, we’re going to launch more products. Were going to market and will fix it later. The battle cry – Don’t launch, don’t sell!. However, the real battle cry is more aptly – Ready, fire, aim!  We’re going too fast.

I’m all for productivity, but we’re heading for a cliff, a cliff some have already accelerated off of, albeit in an unintended way.

a

We’ve forgotten the golden rule – provide value to customers, or you’re hosed.

a

Customers value function, or “what it does”.  Function first. But in this need-for-speed environment that’s just what’s at risk. To reduce time to market, we eliminate tasks (best practices?) in our product development processes. All good unless we eliminate tasks that make the product function as intended.  All good unless we load our engineers so heavily they don’t have time to design in functionality.  We must be careful here.  If you’re first to market and your product doesn’t work, you should have waited.

I believe launching too early is worse than launching too late because a botched launch can damage your brand, the brand you’ve taken years to build. (Click this link to see a post on brand damaging.) As we know, word gets around when your product doesn’t work (or accelerates on its own).

Satisfying the siren of pent up demand can run you into the rocks if you’re not careful.  So block your ears to her song, and take the time to get your products right.

2009 is a tough year, especially for CEOs.

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?  Read the rest of this entry »