Shipulski On Design

Archive for the ‘Product Development’ Category

For the past two decades, I’ve actively developed engineering leaders.  A good friend asked me how I do it, so I took some time to write it down.  Here is the curriculum in the form of How Tos:

How to build trust.  This is the first thing.  Always.  Done right, the trust-based informal networks are stronger than the formal organization chart. Done right, the informal networks can protect the company from bad decisions.  Done right, the right information flows among the right engineers at the right time so the right work happens in the right way.

How to decide what to do next. This is a broad one.  We start with a series of questions: What are we doing now?  What’s the problem? How do you know? What should we do more of?  What should we do less of?  What resources are available? When must we be done?

How to map the current state.  We don’t define the idealized future state or the North Star, we start with what’s happening now.  We make one-page maps of the territory.  We use drawings, flow charts, boxes/arrows, and the fewest words. And we take no action before there’s agreement on how things are.  The value of GPS isn’t to define your destination, it’s to establish your location.  That’s why we map the current state.

How to build momentum. It’s easy to jump onto a moving steam train, but a stationary one is difficult to get moving.  We define the active projects and ask – How might we hitch our wagon to a fast-moving train?

How to start something new. We start small and make a thought-provoking demo.  The prototype forces us to think through all the elements, makes things real, and helps others understand the concept. If that doesn’t work, we start smaller.

How to define problems so we can solve them easily. We define problems with blocks and arrows, and limit ourselves to one page.  The problem is defined as a region of contact between two things, and we identify it with the color red.  That helps us know where the problem is and when it occurs. If there are two problems on a page, we break it up into two pages with one problem.  Then we decide to solve the problem before, during, or after it occurs.

How to design products that work better and cost less. We create Pareto charts of the cost of the existing product (cost by subassembly and cost by part) and set a cost reduction goal.  We create Pareto charts of the part count of the existing product (part count by subassembly and part count by individual part number) and define a goal for part count reduction.  We define test protocols that capture the functionality customers care about. We test the existing product and set performance improvement goals for the new one.  We test the new product using the same protocols and show the data in a simple A-B format. We present all this data at formal design reviews.

How to define technology projects. We define how the customer does their work.  We then define the evolutionary history of our products and services, and project that history forward.  For lines of goodness with trajectories that predict improvement, we run projects to improve them.  For lines of goodness with stalled trajectories, we run projects to establish new technologies and jump to the next S-curve.  We assess our offerings for completeness and create technologies to fill the gap.

How to file the right patents.  We ask these questions: How quickly will the customer notice the new functionality or benefit? Once recognized, will they care? Will the patent protect high-volume / high-margin consumables? There are more questions, but these are the ones we start with.  And the patent team is an integral part of the technology reviews and product development process.

How to do the learning.   We start with the leader’s existing goals and deliverables and identify the necessary How Tos to get their work done. There are no special projects or extra work.

If you’re interested in learning more about the curriculum or how to enroll, send me an email mike@shipulski.com.

Image credit — Paul VanDerWerf

Business is about the effective allocation of resources.  Companies win when they do that better than their competitors.  Full stop.  If you believe that, the question is how to allocate resources effectively.  To me, everything starts with a map of the territory – a single-page map of today’s projects, the people you have, and the tools/infrastructure you have.  In short, before you can reallocate resources, map how you allocate them now.

Let the mapping begin.

The first step is to create a one-page summary (a map) of the resources on hand and the projects they work on (how they are allocated).  A simple spreadsheet is the way to go.  At the top, running left to right, list the names of all the people. Give each person their column.  On the left, running top to bottom, list the active projects, one project per row.  For each project, move left to right and ask if the person works on the project.  Put an X in their column if they contribute to the project in any way.  If they work on the project 2% of their time or more, X marks the spot.  You will be reluctant to do this, but the process is more meaningful if you do.

No fancy formats, no extra text, no headings, no footers, just columns of people against rows of projects.  And it MUST fit one page. MUST. Reduce the font size and the margins to fit it on one page. And if that doesn’t work, set the print area and choose the setting that scales the print area to fit on one page.  Put it on 11 by 17 paper if you must, but you must put it on one page.  You’ll have to squint to read the font when you do it right.

When you look at the one-page printout, the first thing you will notice is that you have too many rows because you have too many projects. (And, yes, you should list the quiet projects no one knows about.) The second thing you will notice is that everyone has too many Xs because they work on too many projects.  The third thing is some people have far more Xs than everyone else’s too many Xs.  All the project managers want them on the projects because they are good at getting projects done.

Let the culling begin.

It’s time to stop.  The best way to stop is to set a maximum time threshold to deliver the first dollar of revenue.  Any project that cannot deliver revenue sooner than the threshold should stop.  The threshold method is crude, fast, and effective.  It’s a great way to do the first pass culling.  For those projects that are difficult to stop due to political factors, don’t stop them but, rather, strongly pause them.  Then, use the reallocation process (described later) to move resources to better projects and let the politically charged projects die a slow death.  Good process beats bad projects.

Strike the cancelled projects from the record, eliminate their rows, and reprint the one-page map.  If you have the right number of projects and they’re fully staffed (this is unlikely), execute the projects that made the cut.  If you have too few projects, the next step is to come up with a set of new projects that deliver revenue sooner than the culled projects.  If you still have too many projects (too many people with too many Xs), it’s time to thin the herd again.  Sort the projects by the revenue they will generate over the threshold period plus three years.  The best projects will bubble to the top, and the bad ones will sink to the bottom.

Let the reallocating begin.

Now, delete all the Xs from the spreadsheet so none of the projects are staffed and no one has a project.  Start with the top row (your best project), move left to right, and place an X in the columns until the project is fully staffed.  Allocate the resources to your best project and get after it right now. Because your best project was understaffed, incremental will flow to the project. This will increase the probability you will hit the launch date or even pull it in.

Next, move down one row to your second-best project and repeat the process.  Add Xs left to right until the project is fully staffed.  But this time there’s a constraint – each column can contain only one X.  Because the people are now fully allocated to and actively working on your best project, they cannot work on the second-best project.  With all the Xs in place and your second-best project fully staffed, work the project hard with the reallocated resources.  Pull in the timeline if you can.

Repeat the process project by project until you can no longer fully staff a project.  And here’s where the game gets interesting. Don’t work a project you cannot staff fully.  There.  I said it.  With new product development projects, there is no partial credit. They’re either 100% done or 0% done.  A project that’s 80% done delivers 0% of the revenue.  But it’s worse than that.  Making “progress” on a project that won’t launch because it’s understaffed consumes functional support resources and will slow down your most important projects.  Don’t do that. Don’t run the project. Just don’t.  You’re better off paying the people to stay home so they don’t consume functional resources needed by the more important projects.

Instead of paying the people to stay home, try to add them to the active projects so you can launch those sooner.  In theory, those projects are fully staffed, but old behaviors die hard, and you probably didn’t fully staff the most important projects.  For the people who still don’t have a project (they cannot speed up the projects), train them on the skills/tools they’ll need for the next round of projects.  This will help you do the next projects better and faster.  Or, they could start on more forward-looking projects that don’t consume resources needed by the more urgent projects.

The process to allocate people to the most important projects is the same for resources like infrastructure for reliability testing or product validation.  With the same fully-staff-the-project approach, allocate the infrastructure resources to the most important projects.  Once there is no more infrastructure capacity, don’t run an under-resourced project.  If you run the lesser project, it will consume those precious infrastructure resources and slow down your most important projects.

You likely won’t be able to staff projects such that each person works on a single project.  The concept is more directional than literal.  Working on three projects is better than working on four, and two is better than three.

I did not describe how to estimate the project revenues, how to create new projects that deliver more revenue sooner, or how to create the right mix of projects – short, medium, and long.  But in a first-things-first way, I suggest you start with a singular focus – reallocate resources to your best projects (and, likely, fewer of them), so those projects effectively deliver revenue your company needs.

I think more focus will bring you more effectiveness.

Image credit — Charlie Wales

Improvement is progress.  Improvement is always measured against a baseline, so the first thing to do is to establish the baseline, the thing you make today, the thing you want to improve.  Create an environment to test what you make today, create the test fixtures, define the inputs, create the measurement systems, and write a formal test protocol.  Now you have what it takes to quantify an improvement objectively.  Test the existing product to define the baseline.  No, you haven’t improved anything, but you’ve done the right first thing.

Improving the right thing to make progress.  If the problem invalidates the business model, stop what you’re doing and solve it right away because you don’t have a business if you don’t solve it. Any other activity isn’t progress, it’s dilution.  Say no to everything else and solve it.  This is how rapid progress is made.  If the customer won’t buy the product if the problem isn’t solved, solve it.  Don’t argue about priorities, don’t use shared resources, don’t try to be efficient.  Be effective.  Do one thing.  Solve it.  This type of discipline reduces time to market.  No surprises here.

Avoiding improvement of the wrong thing to make progress.  For lesser problems, declare them nuisances and permit yourself to solve them later.   Nuisances don’t have to be solved immediately (if at all) so you can double down on the most important problems (speed, speed, speed).  Demoting problems to nuisances is probably the most effective way to accelerate progress.  Deciding what you won’t do frees up resources and emotional bandwidth to make rapid progress on things that matter.

Work the critical path to make progress. Know what work is on the critical path and what is not.  For work on the critical path, add resources.  Pull resources from non-critical path work and add them to the critical path until adding more slows things down.

Eliminate waiting to make progress.  There can be no progress while you wait.  Wait for a tool, no progress.  Wait for a part from a supplier, no progress.  Wait for raw material, no progress.  Wait for a shared resource, no progress.  Buy the right tools and keep them at the workstations to make progress.  Pay the supplier for priority service levels to make progress.  Buy inventory of raw materials to make progress.  Ensure shared resources are wildly underutilized so they’re available to make progress whenever you need to.  Think fire stations, fire trucks, and firefighters.

Help the team make progress. As a leader, jump right in and help the team know what progress looks like.  Praise the crudeness of their prototypes to help them make them cruder (and faster) next time.  Give them permission to make assumptions and use their judgment because that’s where speed comes from.  And when you see “activity” call it by name so they can recognize it for themselves, and teach them how to turn their effort into progress.

Be relentless and respectful to make progress. Apply constant pressure, but make it sustainable and fun.

Image credit — Clint Mason

Here are the top four blog posts from 2024 with a little summary of each.

It’s not the work, it’s the people. By far the most popular post.  Here are some important words from the post: hard work, share, struggle, elbow-to-elbow, fear, crew, extra load, friend, through the wringer, smile, sad, care, easier.  And I finished with a challenge.

For the most important people, take a minute and write down your shared experiences and what they mean to you. What would it mean to them if you shared your thoughts and feelings? Why not take a minute and find out? Wouldn’t work be more energizing and fun? If you agree, why not do it? What’s in the way? What’s stopping you?

Why not push through the discomfort and take things to the next level?

Projects, Products, People, and Problems.  The post was written within the tight context of product development systems, but I think the tight one-liners have broader applicability.  Here are a few of may favorites.

• To get more projects done, do fewer of them.
• Stop starting and start finishing.
• People grow when you create the conditions for their growth.
• When in doubt, help people.
• Trust is all-powerful.
• Whatever business you’re in, you’re in the people business.

Pro Tips for New Product Development Projects.  This one was one was narrow and deep. Here are the main themes:

• Effectiveness is more important than efficiency, but we behave otherwise.
• Everyone has too many projects and that’s why they take so long.
• Resources – too highly utilized.
• Novelty – too much of a good thing isn’t wonderful.

I’m thankful!  I wrote this for the Thanksgiving holiday.  There were four themes: family, health, time, and telling people about your thankfulness.  Family – straightforward. Health – appreciating our remaining health because we recognize it flowing away.  This one is a little backward, but the Stoics know.  And so does Buddha. Time – appreciation of our time, especially when others pull on us.  Telling people about our thankfulness – this a great way to multiply the impact of our thankfulness.

Happy New Year and thanks for reading, Mike

Image credit — Anna Sofia Guerreirinho

Product simplification can radically improve profits and radically improve product robustness.  Here’s a graph of profit per square foot ($/ft^2) which improved by a factor of seven and warranty cost per unit ($/unit), a measure of product robustness), which improved by a factor of four.  The improvements are measured against the baseline data of the legacy product which was replaced by the simplified product.  Design for Assembly (DFA) was used to simplify the product and Robust Design methods were used to reduce warranty cost per unit.

I will go on record that everyone will notice when profit per square foot increases by a factor of seven.

And I will also go on record that no one will believe you when you predict product simplification will radically improve profit per square foot.

And I will go on record that when warranty cost per unit is radically reduced, customers will notice.  Simply put, the product doesn’t break and your customers love it.

But here’s the rub.  The graph shows data over five years, which is a long time.  And if the product development takes two years, that makes seven long years.  And in today’s world, seven years is at least four too many.  But take another look at the graph.  Profit per square foot doubled in the first two years after launch.  Two years isn’t too long to double profit per square foot.  I don’t know of a faster way,  More strongly, I don’t know of another way to get it done, regardless of the timeline.

I think your company would love to double the profit per square foot of its assembly area.  And I’ve shown you the data that proves it’s possible.  So, what’s in the way of giving it a try?

For the details about the work, here’s a link – Systematic DFMA Deployment, It Could Resurrect US Manufacturing.

Efficient – How do we do more projects with fewer people?

Effective – Let’s choose the right project.

Would you rather do more projects that miss the mark or fewer that excite the customer?

Efficient – How do we finish the project faster?

Effective – Let’s fully staff the project.

Would you rather burn out the project team or deliver on what the customer wants?

Efficient – How do we reduce product cost by 5%?

Effective – Let’s make customers’ lives easier.

Would you rather reduce the cost or delight the customer?

Efficient – How can we go faster?

Effective – Let’s get it right.

Would you rather go fast and break things or get it right for the customer?

Efficient – How many projects can we run in parallel?

Effective – Let’s fully staff the most important projects.

Would you rather get halfway through four projects or complete two?

Efficient – How do we make progress on as many tasks as possible?

Effective – Let’s work on the critical path.

Would you rather work on things that don’t matter or nail the things that do?

Efficient – How can we complete the most tasks?

Effective – Let’s work on the hardest thing first.

Would you rather learn the whole thing won’t work before or after you waste time on the irrelevant?

If there’s a choice between efficiency and effectiveness, I choose effectiveness.

Image credit — Antarctica Bound

When planning the projects for next year, how do you decide which projects are a go and which are a no?  One straightforward way is to say yes to projects when there are resources lined up to get them done and no to all others.  Sure, the projects must have a good return on investment but we’re pretty good at that part.  But we’re not good at saying no to projects based on real resource constraints – our people and our budgets.

It’s likely your big projects are well-defined and well-staffed.  The problem with these projects is usually the project timeline is disrespectful of the work content and the timeline is overly optimistic.  If the project timeline is shorter than that of a previously completed project of a similar flavor, with a similar level of novelty and similar resource loading, the timeline is overly optimistic and the project will be late.

Project delays in the big projects block shared resources from moving onto other projects within the appropriate time window which cascades delays into those other projects.  And the project resources themselves must stay on the big projects longer than planned (we knew this would happen even before the project started) which blocks the next project from starting on time and generates a second set of delays that rumble through the project portfolio.  But the big projects aren’t the worst delay-generating culprits.

The corporate initiatives and infrastructure projects are usually well-staffed with centralized resources but these projects require significant work from the business units and is an incremental demand for them.  And the only place the business units can get the resources is to pull them off the (too many) big projects they’ve already committed to.  And remember, the timelines for those projects are overly optimistic.  The big projects that were already late before the corporate initiatives and infrastructure projects are slathered on top of them are now later.

Then there are small projects that don’t look like they’ll take long to complete, but they do.  And though the project plan does not call for support resources (hey, this is a small project you know), support resources are needed.  These small projects drain resources from the big projects and the support resources they need.  Delay on delay on delay.

Coming out of the planning process, all teams are over-booked with too many projects, too few resources, and timelines that are too short. And then the real fun begins.

Over the course of the year, new projects arise and are started even though there are already too few resources to deliver on the existing projects.  Here’s a rule no one follows:  If the teams are fully-loaded, new projects cannot start before old ones finish.

It makes less than no sense to start projects when resources are already triple-double booked on existing projects.  This behavior has all the downside of starting a project (consumption of resources) with none of the upside (progress).  And there’s another significant downside that most don’t see.   The inappropriate “starting” of the new project allows the company to tell itself that progress is being made when it isn’t.  All that happens is existing projects are further starved for resources and the slow pace of progress is slowed further.

It’s bad form to play Tetris with your project portfolio.

Running too many projects in parallel is not faster.  In fact, it’s far slower than matching the projects to the resources on-hand to do them.  It’s essential to keep in mind that there is no partial credit for starting a project.  There is 100% credit for finishing a project and 0% credit for starting and running a project.

With projects, there are two simple rules.  1) Limit the number of projects by the available resources.  2) Finish a project before starting one.

Image credit – gerlos

When there are too many projects, all the projects move too slowly.

When there are too many projects, adding resources doesn’t help much and may make things worse.

To speed up the important projects, stop the less important projects. There’s no better way.

When there are too many projects, stopping comes before starting.

All projects are important, it’s just that some are more important than others.  Stop the lesser ones.

When someone says all projects are equally important, they don’t understand projects.

If all projects are equally important, then they are also equally unimportant and it does not matter which projects are stopped.  This twist of thinking can help people choose the right projects to stop.

When there are too many projects, stop two before starting another.

Finishing a project is the best way to stop a project, but that takes too long.  Stop projects in their tracks.

There is no partial credit for a project that is 80% complete and blocking other projects.  It’s okay to stop the project so others can finish.

Queueing theory says wait times increase dramatically when utilization of shared resources reaches 85%.  The math says projects should be stopped well before shared resources are fully booked.

If you want to go faster, stop the lesser projects.

Image credit – Rodrigo Olivera

If you want your new product development projects to go faster, reduce the number of active projects.  Full stop.

A rule to live by: If the new product development project is 90% complete, the company gets 0% of the value.  When it comes to new product development projects, there’s no partial credit.

Improving the capabilities of your project managers can help you go faster, but not if you have too many active projects.

If you want to improve the speed of decision-making around the projects, reduce the number of required decisions by reducing the number of active projects.

Resource conflicts increase radically as the number of active projects increases.  To fix this, you guessed it, reduce the number of active projects.

A project that is run under the radar is the worst type of active project. It sucks resources from the official projects and prevents truth telling because no one can admit the dark project exists.

With fewer active projects, resource intensity increases, the work is done faster, and the projects launch sooner.

Shared resources serve the projects better and faster when there are fewer active projects.

If you want to go faster, there’s no question about what you should do.  You should stop the lesser projects to accelerate the most important ones.  Full stop.

And if you want to stop some projects, I suggest you try to answer this question: Why does your company think it’s a good idea to have far too many active new product development projects?

Image credit — JOHN K THORNE

Companies that are good at planning their projects create roadmaps spanning about three years, where individual projects are sequenced to create a coordinated set of projects that fit with each other.  The roadmap helps everyone know what’s important and helps the resources flow to those most important projects.

Through the planning process, the collection of potential projects is assessed and the best ones are elevated to the product roadmap.  And by best, I mean the projects that will generate the most incremental profit.  The projects on the roadmap generate the profits that underpin the company’s financial plan and the company is fanatically committed to the financial plan. The importance of these projects cannot be overstated.  And what that means is once a project makes it to the roadmap, there’s only one way to get it off the roadmap, and that’s to complete it successfully.

For the next three years, everyone knows what they’ll work on.  And they also know what they won’t work on.

The best companies want to be efficient so they staff their projects in a way that results in high utilization.  The most common way to do this is to load up the roadmap with too many projects and staff the projects with too few people.  The result is a significant fraction of people’s time (sometimes more than 100%) is pre-allocated to the projects on the roadmap.  The efficiency metrics look good and it may actually result in many successful launches.  But the downside of ultra-high utilization of resources is often forgotten.

When all your people are booked for the next three years on high-value projects, they cannot respond to new opportunities as they arise.  When someone comes back from a customer visit and says, “There’s an exciting new opportunity to grow the business significantly!” the best response is “We can’t do that because all our people are committed to the three-year plan.”.  The worst response is “Let’s put together a team to create a project plan and do the project.”.  With the first response, the project doesn’t get done and zero resources are wasted trying to figure out how to do the project without the needed resources.  With the second response, the project doesn’t get done but only after significant resources are wasted trying to figure out how to do the project without the needed resources.

Starting new projects is difficult because everyone is over-booked and over-committed on projects that the company thinks will generate significant (and predictable) profits.  What this means is to start a new project in this high-utilization environment, the new project must displace a project on the three-year plan.  And remember, the projects that must be displaced are the projects the company has chosen to generate the company’s future profits.  So, to become an active project (and make it to the three-year plan) the candidate project must be shown to create more profits, use fewer resources and launch sooner than the projects already on the three-year plan.  And this is taller than a tall order.

So, is there a solution?  Not really, because the only possible solution is to reduce resource utilization to create unallocated resources that can respond to emergent opportunities when they arise.  And that’s not possible because good companies have a deep and unskillful attachment efficiency.

Image credit — Bernard Spragg NZ

X: We need to decrease the time to market for our new products.

Me: So, you want to decrease the time it takes to go from an idea to a commercialized product?

X: Yes.

Me: Okay.  That’s pretty easy.  Here’s my idea.  Put some new stickers on the old product and relaunch it.  If we change the stickers every month, we can relaunch the product every month.  That will reduce the time to market to one month.  The metrics will go through the roof and you’ll get promoted.

X: That won’t work.  The customers will see right through that and we won’t sell more products and we won’t make more money.

Me: You never said anything about making more money.  You said you wanted to reduce the time to market.

X: We want to make more money by reducing time to market.

Me: Hmm.  So, you think reducing time to market is the best way to make more money?

X: Yes. Everyone knows that.

Me: Everyone?  That’s a lot of people.

X: Are you going to help us make more money by reducing time to market?

Me: I won’t help you with both.  If you had to choose between making more money and reducing time to market, which would you choose?

X: Making money, of course.

Me: Well, then why did you start this whole thing by asking me for help improving time to market?

X: I thought it was the best way to make more money.

Me: Can we agree that if we focus on making more money, we have a good chance of making more money?

X: Yes.

Me:  Okay.  Good.  Do you agree we make more money when more customers buy more products from us?

X: Everyone knows that.

Me:  Maybe not everyone, but let’s not split hairs because we’re on a roll here.  Do you agree we make more money when customers pay more for our products?

X: Of course.

Me: There you have it.  All we have to do is get more customers to buy more products and pay a higher price.

X: And you think that will work better than reducing time to market?

Me: Yes.

X: And you know how to do it?

Me: Sure do.  We create new products that solve our customers’ most important problems.

X: That’s totally different than reducing time to market.

Me: Thankfully, yes.  And far more profitable.

X: Will that also reduce the time to market?

Me: I thought you said you’d choose to make more money over reducing time to market. Why do you ask?

X: Well, my bonus is contingent on reducing time to market.

Me: Listen, if the previous new product development projects took two years, and you reduce the time to market to one and half years, there’s no way for you to decrease time to market by the end of the year to meet your year-end metrics and get your bonus.

X: So, the metrics for my bonus are wrong?

Me: Right.

X: What should I do?

Me: Let’s work together to launch products that solve important customer problems.

X:  And what about my bonus?

Me: Let’s not worry about the bonus.  Let’s worry about solving important customer problems, and the bonuses will take care of themselves.

Image credit — Quinn Dombrowski

X: Me: format stolen from @swardley.  Thank you, Simon.