Shipulski On Design

Archive for the ‘Product Development’ Category

DEADLINE — I am holding a workshop tomorrow (October 29 at 11:00 am Eastern Time) on Designing Out Product Cost Using Product Simplification.  Over the last two decades, I’ve developed tools and methods to help engineers obsolete their best work.  The methods help engineers see their work differently and design new products with radically reduced cost signatures.  They also help non-technical leaders reduce risk in new product development projects.

In the workshop, we’ll review real analyses of real products and learn how to create design approaches that simplify products and reduce cost.  To register, click this link — REGISTER.

I look forward to seeing you at the workshop.

For those unfamiliar with me and my work, here’s a testimonial from Nick Dewhurst, CEO of Boothroyd Dewhurst, the inventors of Design for Manufacturing and Assembly (DFMA).  Nick and his crew are the OGs of product simplification.

I’ve known Mike Shipulski since 2005, and in twenty years of working with engineering leaders, I’ve met very few who get results like he does. At Hypertherm, Mike didn’t just adopt DFMA, he built it into how the company designs products. He tracked the results all the way from the design station to the shipping dock: profit per square foot up 7X, warranty cost per unit down 4X, and part counts cut in half. Mike is a no-nonsense, fact-based decision maker. He starts with the data, and he knows that getting engineers to believe radical simplification is possible is as important as the tools themselves. He is also a true thought leader. Through his writing and his talks at our DFMA Forum, he has shaped how engineers and executives think about product cost, and he has made the case for product simplification to a generation of engineers.

Nicholas P. Dewhurst, President, Boothroyd Dewhurst, Inc.

With product simplification, it’s a battle for hearts and minds.  You cannot simply ask the engineering community to design out half the parts because they don’t think it’s possible.  The first step is to help them believe it’s possible.

Customers buy products.  Manufacturing makes the products. Design engineering designs the products.  Engineering leaders guide and grow the engineers.  In a “start with the customer” way, engineering leaders are important to growing revenue and profitability.

Engineering leadership requires both technical leadership and people leadership.  You need to understand the technology, or you can’t use good professional judgement.  And you need to understand people, or you can’t create the conditions for them to do work they thought was impossible. (I call this the almost impossible.)

Is it 90% technical and 10% people? Or is it 90% people and 10% technical? Or is it split down the middle at 50-50? The answer is yes.  Sometimes it’s a 90/10 meeting followed by a 50/50 conversation in the hall.  Sometimes it’s 10/90 for a whole week.  Sometimes it’s 90/10 in the morning and 10/90 in the afternoon.  Once in a while it’s 100/0 for a hot minute or 0/100 on rare occasions.  (Most of the time, though, it feels like 75/75.)  A great engineering leader must know technology and people and must know how to set their balance based on the context.

I think the curriculum for an engineering leadership development program must be context-specific.  And because each company’s context is different, I think an engineering leadership development program should be company-specific.  The new product development process is unique. The products are unique. The analytical tools and how they’re used are unique.  The ins and outs of the design reviews are different.  So, when in doubt, I suggest you make your engineering leadership development process more company-specific and use context-specific artifacts and examples.

More specifically, I think the curriculum to teach new product development is the new product development projects themselves.  Junior engineering leaders work alongside senior engineering leaders during the actual projects in an apprenticeship way.  The senior leader demonstrates an activity, and the junior leader watches.  Next time, the senior leader demonstrates less, and the junior leader does more. This responsibility balance shifts over time until the junior leader demonstrates and the senior leader doesn’t have to watch anymore.  The junior leader is certified activity by activity under the guidance of a senior leader.  And when the junior leader has demonstrated all the necessary activities, they become a senior leader.  And the cycle continues.

Companies win when their customers buy their products.  And I think one of the best ways to do that is a formal (company-specific) program to develop engineering leaders.

Image credit – Willy Verhulst.

I had the best teachers.  They taught me to assess the situation as it is before trying to improve it.  Early in my career, my leaders did not understand the importance of spending the time to define the current state.  Hurry up and fix it!  Why are you spending time analyzing the existing product? Why do you want to create a functional analysis of the product we want to obsolete?  Why do you want to understand why customers purchased our legacy products?

By assessing the system/products as they are, I learned how to identify the elements to reuse, to improve, and to reinvent.  This has been a great way to focus the resources on the most important elements and increase the intensity the allocated resources.  When you don’t spend time on the 50% of the system that can be reused, you double the resource intensity over a complete redesign.

So, I ask you – how do you decide what can be reused, what must be improved, and what must be reinvented?

Regardless of the system’s size or scope of the project, assessing the current state is the right first step.  For example, there is great interest in improving the business model.  First question (that no one can answer) – What is our business model?  There are tools to define business models visually to show the partners, competitors, customers, data flow, money flow, product flow.  The tools show who does what to whom and how, who helps whom and how, and what’s missing.  One of the tools I like is Wardley Maps.  While Simon (Wardley) doesn’t talk much about mapping business models, I’ve misused his maps for business model mapping.

A rule for business models:  If you can’t describe your business model visually on one page, you don’t know what your business model is and you can’t improve it.

And assessing the current state is effective at the leaf-level (the lowest level).  Mapping the system functionally (functional decomposition with Axiomatic Design) and defining a problem rigorously (TRIZ), allows the team to place the problem in the context of the whole system AND to define the problem at the smallest level possible (think telescope to microscope).

A rule for problems – There’s nothing worse than solving the wrong problem, so you better be sure you’re solving the right one.

A long time ago, I led a project that took the time to assess the baseline product (existing product) for cost, part count, and part type.  Using DFMA, ee knew where the parts were, and we designed them out and we knew where the cost was and we designed it out.  It took a “long time” to do that work, but we radically improved the profitability of the new product (7X improvement in profit per square foot of the factory).  We also did a full functional decomposition on the baseline product and learn that there was one subsystem that caused trouble with all the electronic systems and created problems for customers.  We hardened the design against that subsystem’s devilish energy.  And we created robustness tests where we tested the baseline product and demonstrated improved robustness on the new product. (We used TRIZ to solve the right problems.)  Those efforts reduced warranty cost per unit by 4X.

Rigorously assessing the current state (products, processes, systems, business models) seems too slow and a big waste of time.  It is my experience, though, that it’s faster and improves the outcomes of the new product development and improvement projects.

But don’t take my word for it.  Give it a try.  And if you need some help, let me know.

Image credit – Calsidyrose

Everything starts from what’s been done before.  Designing a new product starts with assessing the subassemblies of your existing product.  Here’s how the assessments go for the subassemblies.

First, make two Pareto charts: cost by subassembly and part count by subassembly.  Prioritize the subassemblies on the left of both charts.

If the functionality is sufficient and the cost is right, reuse it as-is.  This allows you to spend your time and energy elsewhere.

If the cost is right but the functionality needs to be adjusted, adjust it and move on.  The technical risk is low, and the cost will still be right.  Spend your energy where the problems are.

If functionality is good and the cost is high, simplify the product using part count reduction.  Create a bench test to verify functionality and robustness are better than the old one.

If the functionality is insufficient and the cost is too high, spend your energy here.  Create a bench test to quantify the performance of the existing subassembly.  Turn up the dials to increase the stress on the subassembly until it breaks.  Fix the part that breaks.  Repeat until you run out of time.  Create two Pareto charts for the subassembly: cost by part and part count by part type (main part, fastener, connector, protection, label).  Design out the highest cost parts and redesign the highest cost parts that remain.  Design out fasteners, connectors, protection parts, and labels.

Create a functional test for the product as a whole (think miles per gallon for a new car) and test the old one until it breaks.  Build the new product with the new subassemblies and test it until it breaks.  The performance must be better, and it must perform under stress longer than the baseline product.  Break the new product, fix the weakest link, and retest.  Do this until you run out of time and launch it.

This is The Way.

Image credit — George Redgrave

This is the third in a series of blog posts on transformation (changes that make a difference).  The first post described the power and benefit of focusing on the current state at the expense of the future state.  The second post described moving from dilution to distillation, where resources focus on fewer things to create intensity of resource allocation.  The topic of this third post is moving from process to product.

There is immense pressure on company leaders to grow their businesses.  And with new competitors and a faster pace of change, it’s harder than ever to grow. The growth from process-first thinking (Lean Manufacturing and Six Sigma) has reached maturity, and the returns have diminished.   It’s time to take a product-first approach.

Lean improves our processes by simplifying them; Six Sigma improves our processes by reducing variation.  But customers don’t buy our processes; they buy our products. Bad process and good product – sale.  Good process and bad product – no sale.  And more sales create top-line growth.

Products solve problems for customers and help them make progress, which is why customers buy our products.  Customers buy our products, not our processes, and that’s why I think we should take a product-first approach.

When your product works better than the competition, you sell more. When your internal process is better than the competition, customers don’t really care, and you don’t sell more.  Sell more, grow more.

The sales-driven growth described above is all about the top line.  And for top-line growth, I think product-first is far better than process-first.  But product-first is also far better for bottom-line growth.

Lean can reduce labor costs by 30%.  Labor cost is likely about 5% of your product cost.  Do the math, and that’s a cost reduction of 1.5%.  Note – labor savings can be realized only when people lose their jobs.  I won’t bother calculating the savings from Six Sigma because they are less than the savings from Lean.

Product simplification through part count reduction can reduce material cost by 20-40%, and material cost is likely around 80% of your product cost.  Do the math, and that’s a 16-32% cost reduction for the entire product.  This level of cost reduction can grow profit per unit by 50-100% (not a typo).  That is radical bottom-line growth.  Product beats process hands-down.

I bashed process-first thinking to make the point that product-first is more important.  But process thinking IS important, though I think it should come after product thinking.  Softening the message I delivered above, I think it’s product BEFORE process.

Here’s my recommendation.  Improve product function, design out half the parts, and introduce a low-waste design into the production system.  Then, use Lean to streamline the process, and then use Six Sigma to reduce variation.

Here’s the magic sequence that delivers growth: product function, product simplification, process waste reduction, process variation reduction.

This is The Way.

Image credit – Ray in Manila

The need to grow revenue and profit is ever-present.  And as the pace of change accelerates and competitors elevate their game, it’s getting more difficult.

Growth must be built on top of your best work.  To grow, you must develop new products and services that make your customers swap out the old offering they just bought from you for the new one you just launched.  And you must develop the new product with the team that developed the old one.  This is difficult.  You need to create the conditions for the team to see their best work as crap and prevent them from seeing themselves as crap.

For customers to replace an existing product with a new one, the new product must help customers make more progress than the old one.  In a word, the new one must be better, or customers won’t buy it.  And if they don’t buy the new one, there can be no growth.  But here’s the difficult part – when the team built the old one, they designed in as much goodness as possible, yet your task is to help the team design a better one.  Hey Team, congratulations on the wonderful success of the existing product.  You did new work in new ways; you stretched; you hustled; you sprinted.  Now, you must outdo yourselves, even though you just did that.  This is quite the balancing act for the engineering leader.

Growth comes when the team designs a product that works better than the one they designed last time.

Designing a new product that works better is only half of the profitability recipe.  It must also cost less.  Yes, it must work better AND cost less.  Yes, I said AND.  Most teams don’t believe they can design a new product that costs less, and they think you’re crazy when you tell them the new one must work better and cost less.  But this type of double-barreled profitability improvement is possible and proven.  But only if the engineering leader believes it.  And most don’t.

Growth is realized when the team designs a new product that works better AND costs less.

You can radically improve profitability with this double-barreled approach.  I’ve used it to more than double the profit per square foot of the assembly area.  And that makes the CFO smile and gets you lunch with the CEO.  It’s good for profitability and better for your career.

Radical growth comes from obsoleting your best work, but only if you think it’s possible.

Image credit — Don Miller – double rainbow

There is no such thing as losing time.  Time doesn’t reverse itself, at least outside the theoretical physics textbooks. We can spend time on things that will never go anywhere, but that’s wasted time, not lost time. The trick with this type of project is to learn that there’s a fundamental constraint BEFORE running the full project.  Here’s a rule:

If there is a fundamental constraint that blocks the project, work on a different project.

We can work on projects that generate zero customer value, but, again, that’s wasted time, not lost time. The trick with projects that deliver zero customer value is to verify there IS customer value BEFORE running the full project.  Here’s a rule:

If the project will not deliver customer value, work on a different project.

But, to be clear, it is insufficient to demonstrate that the project might deliver customer value.  You must demonstrate that the project delivered customer value.  You should now ask me, “Mike, how can we demonstrate the project delivered (past tense) customer value before we run the project in full?”  The answer is to demonstrate traction.  Traction is objective evidence that the customer spent time and energy in ways that are surrogates for “buying” the offering.

If you create a one-page sales tool, show it to a customer, and they want to buy five, that’s traction.  If, after you show them the one-pager and ask for a $200 deposit, and they give it to you, that’s traction. If you make a non-functional prototype, show it to a customer and describe how it helps them make progress, and they want to buy the prototype, that’s traction.

While, as I said, there is no such thing as losing time, there is another way to think about things that is, I think, closer to losing time.  When you use all your resources to do project A, you lose the opportunity to spend your time on project B. When you do a project that will never launch, you lose the opportunity to spend your time on a project that will.  And when you do a project that delivers zero customer value, you lose the opportunity to spend your time on a project that delivers massive customer value.  This perspective, I think, is preferred because it forces a value comparison among all candidate projects instead of simply evaluating the value of a single project.

And timing matters.  There is a viable time window for each project.  You can be too early and smash your head on a viability window that has not yet opened, or you can start a project too late, and the viability window slams shut on your fingers before you can launch.  And in that way, you can lose out on a project’s viable time window.  This isn’t losing time in the strict sense, but I think talking through time windows is helpful.

Before running a full project, learn that there’s no fundamental constraint.

Before allocating significant project resources, demonstrate enormous customer value.

Before starting a project, assess the relative value of all the viable projects. Think opportunity cost.

Before going all in on a project, make sure the timing is right.  Think viable time window.

Image credit — Tsutomu Taksu

When you have more projects than people, you have far more activity but far less progress.

Pro Tip: Activity doesn’t pay the bills. Progress does.

Would you rather make lightning progress on two projects or tortoise progress on four?  I prefer lightning.

But isn’t four projects better than two?  It is, if you get compensated for the number of active projects. But it’s not, if you get compensated for finishing projects.

Pro tip: There’s no partial credit for a project that’s less than 100% done.

But how to protect your resources from four projects when you have the resources to deliver on two? This is not a complicated answer: block the extra project from entering the pipeline until you finish one.

Pro Tip: Finish one before you start one, not the other way around.

But what about the efficiency that comes from shared resources that can be spread over four projects?  Don Reintertsen would say “Shared resources create waiting and waiting is the enemy.”  I agree with Don, but I think his language is too reserved.  I say “If you’re focused on the efficiency that comes from shared resources, you don’t know what you’re doing.”

Pro Tip:  Waiting kills progress.  Don’t do it.

Here’s a process to consider.

1. Define the resources you have on hand to work on projects.
2. Choose the most important project and fully staff the project. If the project is fully staffed, start the project.
3. Define the remaining unallocated resources.
4. Choose the next most important project and fully staff the project. If the project is fully staffed, start the project.  If the project is not fully staffed, don’t start a project until you finish one, or you can hire the incremental resources to fully staff a project.
5. Repeat.

Image credit – KIUKO (Elephant Tortoise)

Companies make progress through projects.

Projects have objectives that are defined by the company’s growth or improvement objectives.

Projects have quantifiable goals that are, hopefully, time-bound.

Projects require resources, and those resources limit the number of projects that are completed.

Projects are run with the resources allocated, not with the resources we want to allocate.

Projects have timelines that are governed by the work content, novelty, and resources.

Project timelines cannot violate the governing constraints of work content, novelty, and resources.

Projects have project managers, or they’re not projects.

Projects can be accelerated by eliminating waiting.  To find the waiting, look for the work queued up in front of the bottleneck resources.  Those resources are usually resources that support multiple projects (shared resources).  When it comes to waiting, shared resources are almost always the culprit.

Projects have a critical path.  A one-day delay (waiting) on the critical path delays project completion by a day.  That’s how you know it’s the critical path.

If you don’t know the project’s critical path, you don’t know much.

When it comes to projects, effectiveness is far more important than efficiency, yet we fixate on efficiency.  Would you rather run the wrong project efficiently (ineffective) or run the right project inefficiently (effective)?

Regardless of the business you’re in, it’s all about the projects.

Image credit — State Library of South Australia

Good new product development projects deliver value to customers.  Bad ones create value for your company, not for customers.  Can you discern between custom value and company value?  What do you do when there’s an abundance of company value and a shortfall of customer value?  Do you run the project anyway or pull the emergency brake as soon as possible?

Customers decide if the new product has value.  That’s a rule. No one likes that rule, but it’s still a rule. The loudest voice doesn’t decide; it only drowns out the customer’s voice.

Having too many projects is worse than having too few.  With too few, you finish projects quickly because shared resources are not overutilized.  With too many, shared resources are overbooked, their service times blossom, and projects are late.   Would you rather start two projects and finish two or start seven and finish none? That’s how it goes with projects.

Three enemies of new product development: waiting, waiting, waiting.  Waiting that extends the critical path is the worst flavor of all.   Can you tell when the waiting is on the critical path?  If you calculate the cost of delay, it’s possible to spend money to eliminate waiting that’s on the critical path and make more money for your company.  H/T to Don Rienertsen.

For projects, effectiveness is more important than efficiency.  Yes, you read that correctly.  Would you rather efficiently run the wrong project (low effectiveness) or run the right project inefficiently?  Do you spend more mental energy on efficiency or effectiveness? (You don’t have to say your answer out loud.)

I think post-mortems of projects have no value.  The next project will be different, and the learning will not be applicable or forgotten altogether.  However, I think pre-mortems are powerful and can improve the effectiveness of a project BEFORE it is started.  I suggest you try it on your next project.

Strategy is realized through projects. Projects generate growth.  Cost savings come to life through projects.  I think building a deeper understanding of your projects is the most important thing you can do.

Image credit — Mike Keeling (one too many head on collisions)