Shipulski On Design

Archive for the ‘Bottom Line Growth’ 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

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.

New ways to work are new because they have not been done before.

How many new ways to work have you demonstrated over the last year?

New customer value is new when it has not been shown before.

What new customer value have you demonstrated over the last year?

New ways to deliver customer value are new when you have not done it that way before.

How much customer value have you demonstrated through non-product solutions?

The success of old ways of working block new ways.

How many new ways to work have been blocked by your success?

The success of old customer value blocks new customer value.

How much new customer value has been blocked by your success with old customer value?

The success of tried and true ways to deliver customer value blocks new ways to deliver customer value.

Which new ways to deliver unique customer value have been blocked by your success?

Might you be more successful if you stop blocking yourself with your success?

How might you put your success behind you and create the next evolution of your success?

Image credit — Andy Morffew

You can solve problems that reduce the material costs of your products.

You can solve problems that reduce the number of people that work at your company.

You can solve problems that save your company money.

You can solve problems that help your customers make progress.

You can solve problems that make it easier for your customers to buy from you.

You can solve too many small problems and too few big problems.

You can solve problems that ripple profits through your whole organization.

You can solve local problems.

You can solve problems that obsolete your best products.

You can solve problems that extend and defend your existing products.

You can solve problems that spawn new businesses.

You can solve the wrong problems.

You can solve problems before their time or after it is too late.

You can solve problems that change your company or block it from change.

You are defined by the problems you solve.  So, which type of problems do you solve and how do you feel about that?

Image credit – Maureen Barlin

With inflation on the rise and sales on the decline, the time to reduce costs is now.

But before you can design out the cost you’ve got to know where it is.  And the best way to do that is to create a Pareto chart that defines product cost for each subassembly, with the highest cost subassemblies on the left and the lowest cost on the right.  Here’s a pro tip – Ignore the subassemblies on the right.

Use your costed Bill of Materials (BOMs) to create the Paretos.  You’ll be told that the BOMs are wrong (and they are), but they are right enough to learn where the cost is.

For each of the highest-cost subassemblies, create a lower-level Pareto chat that sorts the cost of each piece-part from highest to lowest.  The pro tip applies here, too – Ignore the parts on the right.

Because the design community designed in the cost, they are the ones who must design it out.  And to help them prioritize the work, they should be the ones who create the Pareto charts from the BOMs.  They won’t like this idea, but tell them they are the only ones who can secure the company’s future profits and buy them lots of pizza.

And when someone demands you reduce labor costs, don’t fall for it.  Labor cost is about 5% of the product cost, so reducing it by half doesn’t get you much.  Instead, make a Pareto chart of part count by subassembly.  Focus the design effort on reducing the part count of subassemblies on the left.  Pro tip – Ignore the subassemblies on the right.  The labor time to assemble parts that you design out is zero, so when demand returns, you’ll be able to pump out more products without growing the footprint of the factory.  But, more importantly, the cost of the parts you design out is also zero.  Designing out the parts is the best way to reduce product costs.

Pro tip – Set a cost reduction goal of 35%.  And when they complain, increase it to 40%.

In parallel to the design work to reduce part count and costs, design the test fixtures and test protocols you’ll use to make sure the new, lower-cost design outperforms the existing design.  Certainly, with fewer parts, the new one will be more reliable.  Pro tip – As soon as you can, test the existing design using the new protocols because the only way to know if the new one is better is to measure it against the test results of the old one.

And here’s the last pro tip – Start now.

Image credit — aisletwentytwo

It’s not a vacation unless you forget about work.

It’s not a holiday unless you leave your phone at home.

If you must check-in at work, you’re not on vacation.

If you feel guilty that you did not check-in at work, you’re not on holiday.

If you long for work while you’re on vacation, do something more interesting on vacation.

If you wish you were at work, you get no credit for taking a holiday.

If people know you won’t return their calls, they know you are on vacation.

If people would rather make a decision than call you, they know you’re on holiday.

If you check your voicemail, you’re not on vacation.

If you check your email, you’re not on holiday.

If your company asks you to check-in, they don’t understand vacation.

If people at your company invite you to a meeting, they don’t understand holiday.

Vacation is productive in that you return to work and you are more productive.

Holiday is not wasteful because when you return to work you don’t waste time.

Vacation is profitable because when you return you make fewer mistakes.

Holiday is skillful because when you return your skills are dialed in.

Vacation is useful because when you return you are useful.

Holiday is fun because when you return you bring fun to your work.

If you skip your vacation, you cannot give your best to your company and to yourself.

If neglect your holiday, you neglect your responsibility to do your best work.

Don’t skip your vacation and don’t neglect your holiday.  Both are bad for business and for you.

“CatchingButterflies on Vacation” by OakleyOriginals is licensed under CC BY 2.0

All goals are arbitrary, but some are more arbitrary than others.

When your company treats goals like they’re not arbitrary, welcome to the US industrial complex.

What happens if you meet your year-end goals in June? Can you take off the rest of the year?

What happens if at year-end you meet only your mid-year goals? Can you retroactively declare your goals unreasonable?

What happens if at the start of the year you declare your year-end goals are unreasonable? Can you really know they’re unreasonable?

You can’t know a project’s completion date before the project is defined.  That’s a rule.

Why does the strategic planning process demand due dates for projects that are yet to be defined?

The ideal future state may be ideal, but it will never be real.

When the work hasn’t been done before, you can’t know when you’ll be done.

When you don’t know when the work will be done, any due date will do.

A project’s completion date should be governed by the work content, not someone’s year-end bonus.

Resources and progress are joined at the hip.  You can’t have one without the other.

If you are responsible for the work, you should be responsible for setting the completion date.

Goals are real, but they’re not really real.

“Arbitrary limitations II” by Marcin Wichary is licensed under CC BY 2.0

If you use fewer natural resources, your product costs less.

If you use recycled materials, your product costs less.

If you use less electricity, your product costs less.

If you use less water to make your product, your product costs less.

If you use less fuel to ship your product, your product costs less.

If you make your product lighter, your product costs less.

If you use less packaging, your product costs less.

If you don’t want to be environmentally responsible because you think it’s right, at least do it to be more profitable.

Image credit — Sandrine Néel

Patents are the currency of technology and profits are the currency of business.  And as it turns out, if you focus on creating technology you’ll get technology (and patents) and if you focus on profits you’ll get profits. But if no one buys your technology (in the form of the products or services that use it), you’ll go out of business.  And if you focus exclusively on profits you won’t create technology and you’ll go out of business.  I’m not sure which path is faster or more dangerous, but I don’t think it matters because either way you’re out of business.

It’s easy to measure the number of patents and easier to measure profits.  But there’s a problem.  Not all patents (technologies) are equal and not all profits are equal.  You can have a stockpile of low-level patents that make small improvements to existing products/services and you can have a stockpile of profits generated by short-term business practices, both of which are far less valuable than they appear. If you measure the number of patents without evaluating the level of inventiveness, you’re running your business without a true understanding of how things really are.  And if you’re looking at the pile of profits without evaluating the long-term viability of the engine that created them you’re likely living beyond your means.

In both cases, it’s important to be aware of your time horizon.  You can create incremental technologies that create short term wins and consume all your resource so you can’t work on the longer-term technologies that reinvent your industry.  And you can implement business practices that eliminate costs and squeeze customers for next-quarter sales at the expense of building trust-based engines of growth.  It’s all about opportunity cost.

It’s easy to develop technologies and implement business processes for the short term.  And it’s equally easy to invest in the long term at the expense of today’s bottom line and payroll.  The trick is to balance short against long.

And for patents, to achieve the right balance rate your patents on the level of inventiveness.

Image credit – NASA’s Solar Dynamics Observatory

When it’s time for a tough decision, it’s time to use data.  The idea is the data removes biases and opinions so the decision is grounded in the fundamentals.  But using the right data the right way takes a lot of disciple and care.

The most straightforward decision is a decision between two things – an either or – and here’s how it goes.

The first step is to agree on the test protocols and measure systems used to create the data.  To eliminate biases, this is done before any testing.  The test protocols are the actual procedural steps to run the tests and are revision controlled documents.  The measurement systems are also fully defined.  This includes the make and model of the machine/hardware, full definition of the fixtures and supporting equipment, and a measurement protocol (the steps to do the measurements).

The next step is to create the charts and graphs used to present the data. (Again, this is done before any testing.) The simplest and best is the bar chart – with one bar for A and one bar for B.  But for all formats, the axes are labeled (including units), the test protocol is referenced (with its document number and revision letter), and the title is created.  The title defines the type of test, important shared elements of the tested configurations and important input conditions.   The title helps make sure the tested configurations are the same in the ways they should be.  And to be doubly sure they’re the same, once the graph is populated with the actual test data, a small image of the tested configurations can be added next to each bar.

The configurations under test change over time, and it’s important to maintain linkage between the test data and the tested configuration.  This can be accomplished with descriptive titles and formal revision numbers of the test configurations.  When you choose design concept A over concept B but unknowingly use data from the wrong revisions it’s still a data-driven decision, it’s just wrong one.

But the most important problem to guard against is a mismatch between the tested configuration and the configuration used to create the cost estimate.  To increase profit, test results want to increase and costs wants to decrease, and this natural pressure can create divergence between the tested and costed configurations. Test results predict how the configuration under test will perform in the field.  The cost estimate predicts how much the costed configuration will cost.  Though there’s strong desire to have the performance of one configuration and the cost of another, things don’t work that way.  When you launch you’ll get the performance of AND cost of the configuration you launched.  You might as well choose the configuration to launch using performance data and cost as a matched pair.

All this detail may feel like overkill, but it’s not because the consequences of getting it wrong can decimate profitability. Here’s why:

Profit = (price – cost) x volume.

Test results predict goodness, and goodness defines what the customer will pay (price) and how many they’ll buy (volume).  And cost is cost.  And when it comes to profit, if you make the right decision with the wrong data, the wheels fall off.

Image credit – alabaster crow photographic

If you’re working in a company you like, and you want it to be around in the future, you want to know if it will grow.  If you’re looking to move to a new company, you want to know if it has legs – you want to know if it will grow. If you own stock, you want to know if the company will grow, and it’s the same if you want to buy stock.  And it’s certainly the case if you want to buy the whole company – if it can grow, it’s worth more.

To grow, a company has to differentiate itself from its competitors.  In the past, continuous improvement (CI) was a differentiator, but today CI is the minimum expectation, the cost of doing business.  The differentiator for growth is discontinuous improvement (DI).

With DI, there’s an unhealthy fascination with idea generation.  While idea generation is important, companies aren’t short on ideas, they’re short on execution.  But the one DI differentiator is the flavor of the ideas.  To do DI a company needs ideas that are radically different than the ones they’re selling now.  If the ideas are slightly twisted variants of today’s products and business models, that’s a sure sign continuous improvement has infiltrated and polluted the growth engine. The gears of the DI engine are gummed up and there’s no way the company can sustain growth.  For objective evidence the company has the chops to generate the right ideas, look for a process that forces their thinking from the familiar, something like Jeffrey Baumgartner’s Anticonventional Thinking (ACT).

For DI-driven growth, the ability to execute is most important.  With execution, the first differentiator is how the company investigates radically new ideas.  There are three differentiators – a focus on speed, a “market first” approach, and the use of minimum viable tests (MVTs).  With new ideas, it’s all about how fast you can learn, so speed should come through loud and clear.  Without a market, the best idea is worthless, so look for “market first” thinking.  Idea evaluation starts with a hypothesis that a specific market exists (the market is clearly defined in the hypothesis) which is evaluated with a minimum viable test (MVT) to prove or disprove the market’s existence.  MVTs should error on the side of speed – small, localized testing.  The more familiar minimum viable product (MVP) is often an important part of the market evaluation work.  It’s all about learning about the market as fast as possible.

Now, with a validated market, the differentiator is how fast company can rally around the radically new idea and start the technology and product work.  The companies that can’t execute slot the new project at the end of their queue and get to it when they get to it.  The ones that can execute stop an existing (lower value) project and start the new project yesterday.  This stop-to-start behavior is a huge differentiator.

The company’s that can’t execute take a ready-fire-aim approach – they just start.  The companies that differentiate themselves use systems thinking to identify gaps in resources and capabilities and close them. They do the tough work of prioritizing one project over another and fully staff the important ones at the expense of the lesser projects.  Rather than starting three projects and finishing none, the companies that know how to do DI start one, finish one, and repeat.  They know with DI, there’s no partial credit for a project that’s half done.

All companies have growth plans, and at the highest level they all hang together, but some growth plans are better than others.  To judge the goodness of the growth plan takes a deeper look, a look into the work itself.  And once you know about the work, the real differentiator is whether the company has the chops to execute it.

Image credit – John Leach.