Shipulski On Design

Posts Tagged ‘Product Development Engine’

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.

This one isn’t a blog post!

After more than sixteen years of blog posts, I’ll host my first live workshop on October 29 at 11:00 am Eastern Time!  This marks a new phase for me, and I’m super excited!

In the workshop, I’ll share the tools and approaches for Designing Out Product Cost that I’ve developed over the last 25+ years.  Using the methods, I increased profit per square foot by 7X and reduced warranty cost per unit by 4X (see results below), which earned a cover story in IE Magazine.  And my results have been published in Design News, ASSEMBLY Magazine, Digital Engineering, IE Magazine, ASME, and I’ve presented them at GE Research and Development, MIT, WPI, and Tuck.

In the workshop, you’ll see real before-and-after examples which will give you a feel for what’s possible; you’ll see real data on part count and cost; you’ll learn how to use data to create a design approach; and you’ll learn the ins and outs of a successful implementation.

And for the first 15 people to register, I am offering a complimentary strategy session after the workshop.  To book your 30-minute strategy session, a link will be provided in the registration confirmation email.

Workshop Details

• Topic: Designing Out Product Cost
• Date: 10/29/26 at 11 AM EST
• Price: $100.00

With companies, there are always competing demands and too few resources.  Always.  Don’t feel special. And there is always noise in the signals.  Always.  And it always comes down to a single question:

What do we do next?

Don’t believe me? Think about your meetings last week.  During the meetings, there was discussion about the current situation followed by discussion on what to do next.  And at the end of the meetings, there were lists of things to do next.  Those things may not get done, but there were lists of things to do next.

The competing demands create the set of possible problems to address.  And the problems are inputs to the critical decision: What do we do next?  The demands are not fully defined, which adds noise to the decision process, and there is no agreement on the underlying problem, if the problem is formulated at all.  This adds noise to the signal.  There are more demands/problems than resources, and they compete with each other for the small pool of unallocated resources and the sea of double-booked resources.  This creates emotional stress and also adds noise to the signal.

Situation Normal for all companies: Partially formed (competing) demands, disagreement on the relative priority of the ill-formed demands, incomplete (or missing) problem formulation, limited understanding of the required resources other than everyone knows there are more demands/problems than resources, and immense pressure to violate resource constraints.

I cannot give you a recipe to answer the all-important question (What do we do next?), but I can suggest ways to reduce the noise and better assess the options.

Spend some time formally fleshing out the demands before the meeting.  Dig in.  Bring data.  What is the output required? Who is asking for it? What are the inputs? What happens if we do it?  What happens if we don’t?  Come to the meeting with your analysis, but call it “a draft”.  Let others ask questions and challenge your assumptions.  Don’t be defensive.  They are not attacking you; they are trying to improve understanding to make a better decision.

The cost of making a bad decision is immense, so it makes sense to spend a lot of time preparing a good description/assessment.  The cost of over-preparing is low, so over-prepare.  Here’s a rule:

For big decisions, preparation time should be at least ten times longer than your first estimate.

Another type of assessment is often overlooked.  It’s the assessment of how well the opportunity fits with what you do well, with how you do things, and with the dispositional state of the larger system.  In short, you’re trying to answer: Is it easy?

Here are some things to consider to answer the “Is it easy?” question.  If the opportunity requires new knowledge, skills, and abilities, it will not be easy. If it requires you to work in different ways with new partners, it will not be easy.  If it cuts against an industry trend, it won’t be easy.  This is not an exhaustive list, and you should come up with your own assessment themes.  To be clear, though, these lines of assessment are different than “How many people do we need?”

Here’s a rule:

You can’t run a marathon wearing running shoes that are three sizes too small.

There is nothing wrong with having too many good opportunities and too many competing demands.  In fact, I think that’s a good sign.  I think it says you are in high demand.  And there is nothing wrong with having too few resources because, again, it means you’re in high demand.  I’ve never met a profitable company that had too few opportunities and too many resources.

Image credit — Mitchell Hirsch

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

I’ve built engineering teams that developed the world’s most successful products in their space.

At the start of the team’s migration to greatness, they don’t believe in themselves. And that’s why you, as their leader, have to believe in them.  Every day, you must tell them why you believe in them.  Every day, you must give them examples of their behaviors that justify your belief in them.  At the start of the journey, they don’t know how to do their work differently.  And that’s why you, as their leader, must show them how.  You can’t simply tell them how to do the new work because they won’t believe you.  And that’s why you must show them.  There are no half measures here.  You’ve got to be all in.

As their leader, you must set exceptionally challenging goals.  They cannot be impossible goals, but they can be almost impossible.  And when the team pushes back on your almost impossible request, you must explain HOW you will help them do the almost impossible.

None of this is free.  You must create the tools, training, and time for the exceptional performance to emerge.  You must give them the new tools, the training, and you must give them the time to learn the tools and use them appropriately.

Pro Tip: If you don’t give the team the tools, training, and time to use them, you’ll get what you got last time.

At the earliest sign of the new behaviors, you must praise them publicly.  “This is what I’m talking about!  This is great!  I like how you used the new tools.  Thank you.”  Tell everyone what they did.  Tell their spouse or partner.  Tell their kids.  Be proud.

And as the new behaviors build on each other (and they will), continue to show them your happiness.  Turn up your excitement for their remarkable work.  Tell them what they did because they won’t know.  Tell them why it was so good.  And push them for more.  Tell them you know they can do more.  And now they’ll believe you because they’ve seen what’s possible.  And they’ll believe in themselves. And once they believe in themselves, it’s off to the races.

The products will work better, will sell more, will cost less, and won’t break.  They will be easy to build, easy to test, and easy to troubleshoot.  And they will be profitable as hell.  But that’s not the real value.  The real value is that you helped build a team that believes they can do it better next time.

I have helped engineering teams do work they could not imagine.  I have helped technicians elevate their performance and outperform engineers. I have helped Ph.Ds. learn from customers.  And I have helped engineers grow into Principal Engineers, Engineering Directors, GMs, and CEOs.

This has been the most rewarding work of my life.

Image credit — Mikhail Esteves – Piggy Back

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

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)

Plans are good, until they’re not.  The key is knowing when to stay the course and when to adjust the plan.

The time horizons for strategic plans or corporate initiatives can range from two to five years.  To ensure we create the best plans, we assign the work to our best people, we provide them with the best information, and we ask them to use their best judgment.  As input, we assess market fundamentals, technology trends, customer segments, our internal talent, our partners, our infrastructure, and our processes.  We then set revenue targets and create project plans and resource allocation plans to realize the revenue goals.  And then it’s go time.

We initiate the projects, work the plans, and report regularly on the progress.  If the progress meets the monthly goal, we keep going.  And if the progress doesn’t meet the monthly goal, we keep going.  We invested significant time and effort into the plan, and it can be politically difficult, if not bad for your career, to change the plan.  It takes confidence and courage to call for a change to a strategic plan or a corporate initiative.  But two to five years is a long time, and things can (and do) change over the life of a plan.

A plan is created with the best knowledge available at the time.  We assess the environment and use the knowledge to set the financial requirements for the plan.  When the environment and requirements change, the plan should change.

Before considering any changes, if we learn that the assumptions used to create the plan are invalid, the plan should change.  For example, if the resource allocation is insufficient, the timelines should be extended, resources should be added, or the scope of the work should be reduced. I think changing the plan is responsible management, and I think it’s irresponsible management to stay the course.

The environment can change in many ways.  Here are five categories of change: tariffs, competition, internal talent (key people move on), new customer learning, and new technical learning (e.g., more technical risk than anticipated).  Significant changes in any of these categories should trigger an assessment of the plan’s viability.  This is not a sign of weakness.  This is responsible management.  And if the change in the environment invalidates the plan’s assumptions, the plan should change.

The specification (revenue targets) for the plans can change.  There are at least two flavors of change: an increase in revenue goals or a shorter timeline to achieve revenue goals, which are usually caused by changes to the environment.  And when there’s a need for more revenue or to deliver it sooner, the plans should be assessed and changed.  Again, I think this is good management practice and not a sign of failure or weakness.  When we realize the plan won’t meet the new specification, we should modify the plan.

When we learn the assumptions are wrong, we should change the plan.  When the environment changes, we should change the plan.  And when the specification changes, we should change the plan.

Image credit — Charlie Day 

With new product development projects, there is no partial credit.  If you’re less than 100% done, there are zero sales.  90% done, zero sales.  95% done, zero sales. We all understand the concept, but our behavior often contradicts our understanding.  You have too many projects, and our focus on efficiency is to blame.

Under the banner of efficiency, we run too many projects in parallel, and our limited resources become spread too thinly over too many projects.  Project timelines grow, launch dates are pushed out, and revenue generation is delayed.  And because there’s a shortfall in revenue, we start more projects to close the gap.  That’s funny.

In short, we’ve morphed Start, Stop, Continue into Start, Start, Start.

Here’s a process to help you stop starting and start finishing.

Open a spreadsheet and list all your projects for the year.  At the top of the column, list the projects you’ve completed.  Below the completed projects, list your active projects, and below them, list your future (not yet started) projects.  Highlight the completed projects and the active projects, and set the print area.  Then, select “print on both sides of the page.”  When you print the file, the future projects will be printed on the back of the page.  This will help you focus on the completed and active projects and block you from trying to start a project before finishing one.

Now, go back to the top of the spreadsheet and select the completed projects and change the font to “strike through.”  This will allow you to read the project names and remind yourself of the projects you completed.  You can use this list to justify a strong performance rating at your upcoming performance review.

Skip down to the active projects and categorize them as fully staffed or partially staffed.  Change the font color to red for the partially staffed projects and move them to the second page with the future projects.  Print out the spreadsheet.

The completed projects will be at the top of the page in strike-through font, and the short list of fully staffed projects is listed below them in normal font.  On the back of the page, the partially staffed projects are listed in red, and the future projects are listed below them. And now you’re ready to realize the power of the two-sided printout.

Step 1. Ignore the projects on the back of the page (under-staffed and yet to be started projects).  They’re still on the do-do list, but they’ll wait patiently on the back of the page until resources are freed up and allocated.

Step 2. Finish the fully staffed projects on the front page.

Step 3. When you finish a project, change the font to “strike-through” and create a list of the freed-up resources.

Step 4. Flip to the back of the page, allocate the freed-up resources to one of the projects, and move the fully staffed project to the front of the page.

Step 5. Proceed to Step 2.

This is a straightforward process, but it requires great discipline.

Here’s a mantra to repeat daily –  I will finish a project before I start the next one.

Image credit — iggyshoot