Shipulski On Design

Archive for the ‘Constraints’ Category

What is to what isn’t.

What isn’t to what could.

What could to what should.

What should to what will.

What will to what is.

Repeat.

We all want to increase sales. But to do do this, our products must offer a better value proposition – they must increase the goodness-to-cost ratio. And to do this we increase goodness and decrease cost. (No argument here – this is how everyone does it.) When new technologies mature, we design them in to increase goodness and change manufacturing and materials to reduce cost. Then, we sell. This is the proven cowpath. But there’s a problem.

The problem is everyone is thinking this way. You’re watching/developing the same technologies as your competitors; improving the same manufacturing processes; and trying the same materials. On its own, this a recipe for hyper-competition. But with the sinking economy driving more focus on fewer consumers, price is the differentiator. With this cowpath it’s a race to the bottom.

But there’s a better way where there are no competitors and millions (maybe billions) of untapped consumers clamoring for new products. Yes, it’s based on the time-tested method of improving the goodness-to-cost ratio, but there’s a twist – instead of more it’s less. The ratio is increased with less goodness and far less cost. Since no one in their right mind will take this less-with-far-less approach, there is no competition – it’s just you. And because you will provide less goodness, you must sell where others don’t – into the untapped sea of yet-to-be consumers of developing world. With less-with-far-less it’s a race to the top.

Technology is the most important element of less-with-far-less. By reducing some goodness requirements and dropping others all together, immature technologies become viable.  You can incorporate fledgeling technologies sooner and commercialize products with their unreasonably large goodness-to-cost ratios. The trick – think less output and narrow-banded goodness.

Immature technologies have improved goodness-to-cost ratios (that’s why we like them), but their output is low. But when a product is designed to require less output, previously immature technologies become viable. Sure, there’s a little less goodness, but the cost structure is far less – just right for the developing world.

Immature technologies are more efficient and smaller, but their operating range is small. But when a product is designed to work within a narrow band of goodness, technologies become viable sooner. Yes, the product does less, but the cost structure is far less – a winning combination for the developing world.

Less-with-far-less makes the product fit the technology – that’s not the hard part. And less-with-far-less makes the product fit the developing world – not hard. In our all-you-can-eat world, where more is seen as the only way, we can’t comprehend how less can win the race to the top. The hard part is less.

Less-with-far-less is not limited by technology or market – it’s limited because we can’t see less as more.

The problem tree is big, old, and rugged with a fully developed branch network and the deepest roots. And nestled in its crown, set directly over the trunk, is the hidden tree house where the problem solvers play.

The problem tree has a left and right, with its why branches to the right and why-nots to the left. To the right, the biggest why limbs grow from the trunk then split into a series of smaller why branches which terminate at the why leaves. It’s the same on the left – big why-not limbs, why-not branches, why-not leaves.

To start their game, the problem solvers first agree on the biggest why limbs – the main reasons why to solve the problem. Once labeled, the team asks why again, and builds out the why side of the canopy – narrowing as they go. They continue their hierarchical why mapping until they get to the why leaves – the lowest-level whys. The last part is most tenuous because as the branches get smaller they can’t hold the weight and they sway in the political wind. But as the organization watches impatiently, the problem solvers know they must hang onto the smallest branches and stretch themselves hard to reach the leaves.

Once the whys are mapped the solvers know why they must solve the problem. They know who wants it solved (the biggest branches can have their own sponsor) and how the whys (and their sponsors) compliment or compete. And where the rubber meets the road (leaf level), they know why it must be solved – think manufacturing floor. Like a spider web, the why network sticks the solvers to the right problem.

Novice solvers think their ready to solve, but the seasoned climbers know it’s time swing on the wild side. It’s time to climb where few dare – the politically charged left side – the why-nots. Slowly, carefully, the climbers step from the safety of their tree house and explore why the company cannot, has not, or may not want to solve the problem. There are usually three big why-not branches – constraints, capability, and culture.

When the solvers shimmy out on the constraint branch, they usually find the smaller no-time-to-solve-it branch, with its leaves of – existing operating plans, product launches, other big problems, unfilled open positions, and reduced headcount. Though real, these branches are tough to talk about because the organization does not want to hear about them. And, sometimes, for all their dangerous climbing and shimmying, the solvers are accused of not being team players.

Their climb on the capability branch is challenging, but not for its complexity. There’s usually one branch – we don’t know how to do it, with a couple leaves – we’ve never done it before and we don’t do it that way. The capability branch is difficult because it causes the organization to overtly admit a fundamental gap. Also, it threatens the subject matter experts, who are important to the solution.

The culture branch is toughest of all. Its limbs can be slippery and sometimes have cover names (so it’s difficult for me to list them), but thematically, the best climbers know the branches represent the worn patterns of company behavior. Often, the behaviors (and the climate they create) have not been formalized, and shining a light on them may is too bright for some. But when the solvers find a why-not branch that cuts across one of these worn cowpaths, that’s just what they must do. Because without changing the behavioral pattern, there can be no solution.

With the problem tree fully built-out on a single page, it’s clear why the problem should be solved and what’s in the way (why-not). And when the solvers present it, the company decides if the whys are important enough to overcome the why-nots. If it’s a go, the first step is to prune the why-nots – resources to solve the constraint problems, tools and training to improve the capability problems, and a change in leadership behavior to solve the cultural problems. After those are taken care of, the problem definition phase comes to a close.

The problem tree defines the problem, it does not solve it. But through the process of building it out, the problem solvers (problem definers) help the company clear cut the forest of why-nots. Now, standing tall, standing alone, clearly seen for what it is, solving the problem is a breeze.

Problems get a bad rap. We’re all clear on the negativity around problems, but we don’t appreciate their positive character. It’s time we use their powers for good.

One of the least popular characteristics of problems is their selfishness. Like the friend who shows up for dinner unannounced, problems, left to their own, care only about their calendar. But to overcome this shortcoming and harness their energy, we can create them to fit our time table.

An important strong suit of problems is their ability to create focus. When the VP has a problem, everybody has a problem. And it’s this persuasive power of problems that focuses the organization on a solution – resources, alignment, and creativity on demand.

I propose we bring problems to life on our own terms to create new thinking; to creatively fabricate problems to generate laser-focused thinking in the direction of our choice; to imagine what could be and create the right problems to get us there. Creativity on demand.

The most provocative and productive problems to manufacture are those that remove inherent goodness of your products or that outlaw their physical fundamentals. Like putting your thumb over a hose, these problems spray high velocity thinking in unpredictable directions. Here are some examples:

1. Big coffee pot can make only one cup – single-cup brewer industry.
2. Speedboats cannot carry multiple passengers – personal water craft industry.
3. Lights must illuminate only a small area – LED proliferation.
4. Sturdy running shoes must be floppy – bare foot running shoe movement.
5. Desktop computers must be mobile – laptop industry.
6. Stiff, wear-like-iron dungarees must be worn out – faded/distressed jean movement.
7. Eye glasses cannot rest on the nose – contact lenses.
8. Pencils cannot be sharpened – mechanical pencils.
9. Laser printers must be slow – home printer industry.

Sure, these examples were reverse engineered. But take a minute to walk back in time and sit in those industries. What if back then you created those problems for yourself? What if you create them tomorrow?

The thinking in the post is strongly shaped by Jeffrey Paul Baumgartner’s Anti Conventional Thinking (ACT).

Things aren’t impossible on their own, our thinking makes them so.

Impossible is not about the thing itself, it’s a statement about our state of mind.

When we say impossible, we really say we lack confidence to try.

When we say impossible, we really say we are too afraid to try.

The mission of impossible is to shut down all possibility of possibility.

To soften it, we say almost impossible, but it’s the same thing.

When we say impossible, we make a big judgment – but not about the thing – about ourselves.

We don’t know the question, but the answer is innovation. And with innovation it’s more, more, more. Whether it’s more with less, or a lot more with a little more, it’s always more. It’s bigger, faster, stronger, or bust.  It’s an enhancement of what is, or an extrapolation of what we have. Or it’s the best of product one added to product two. But it’s always more.

More-on-more makes radical shifts hard because with more-on-more we hold onto all functionality then add features, or we retain all features then multiply output. This makes it hard to let go of constraints, both the fundamental ones – which we don’t even see as constraints because they masquerade as design rules – and the little-known second class constraints – which we can see, but don’t recognize their power to block first class improvements. (Second class constraints are baggage that come with tangential features which stop us from jumping onto new S-curves for the first class stuff.)

To break the unhealthy cycle of more-on-more addition, think subtraction. Take out features and function. Distill to the essence. Decree guilty until proven innocent, and make your marketers justify the addition of every feature and function. Starting from ground zero, ask your marketers, “If the product does just one thing, what should it do?” Write it down as input to the next step.

Next, instead of more-on-more multiplication, think division. Divide by ten the minimum output of your smallest product. (The intent it to rip your engineers and marketers out of the rut that is your core product line.) With this fractional output, ask what other technologies can enable the functionality? Look down. Look to little technologies, technologies that you could have never considered at full output. Congratulations. You’ve started on your migration toward with less-with-far-less.

On the surface, less-with-far-less doesn’t seem like a big deal. And at first, folks roll their eyes at the idea of taking out features and de-rating output by ten. But its magic is real. When product performance is clipped, constraints fall by the wayside. And when the product must do far less and constraints are dismissed, engineers are pushed away from known technologies toward the unfamiliar and unreasonable. These unfamiliar technologies are unreasonably small and enable functionality with far less real estate and far less inefficiency. The result is radically reduced cost, size, and weight.

Less-with-far-less enables cost reductions so radical, new markets become viable; it makes possible size and weight reductions so radical, new levels of portability open unimaginable markets; it facilitates power reductions so radical, new solar technologies become viable.

The half-life of constraints is long, and the magic from less-with-far-less builds slowly. Before they can let go of what was, engineers must marinate in the notion of less. But when the first connections are made, a cascade of ideas follow and things spin wonderfully out of control. It becomes a frenzy of ideas so exciting, the problem becomes cooling their jets without dampening their spirit.

Less-with-far-less is not dumbed-down work – engineers are pushed to solve new problems with new technologies. Thermal problems are more severe, dimensional variation must be better controlled, and failure modes are new. In fact, less-with-far-less creates steeper learning curves and demands higher-end technologies and even adolescent technologies.

Our thinking, in the form of constraints, limits our thinking. Less-with-far-less creates the scarcity that forces us to abandon our constraints. Less-with-far-less declares our existing technologies unviable and demands new thinking. And I think that’s just what we need.

Some thoughts on no:

• Yes is easy, no is hard.
• Sometimes slower is faster.
• Yes, and here’s what it will take:
• The best choose what they’ll not do.
• Judge people on what they say no to.
• Work and resources are a matched pair.
• Define the work you’ll do and do just that.
• Adding scope is easy, but taking it out is hard.
• Map yes to a project plan based on work content.
• Challenge yourself to challenge your thinking on no.
• Saying yes to something means saying no to something else.
• The best have chosen wrong before, that’s why they’re the best.
• It’s better to take one bite and swallow than take three and choke.

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

The CEO throws out the challenge – “Fix new product development.” Great idea, but not actionable. Can’t put a plan together.  Don’t know the problem.  Stepping back, who will lead the charge? Whose problem is it?

The goal of all projects is to solve problems.  And it’s no different when fixing product development – work is informed by problems. No problem, no fix. Sure you can put together one hell of a big improvement project, but there’s no value without the right problem. There’s nothing worse than spending lots of time on the wrong problem.  And it’s doubly bad with product development because while fixing the wrong problem engineers are not working on the new products.  Yikes.

Problems are informed by outcomes.  Make a short list of desired outcomes and show the CEO.  Your list won’t be right, but it will facilitate a meaningful discussion.  Listen to the input, go back and refine the list, and meet again with the CEO.  There will be immense pressure to start the improvement work, but resist.  Any improvement work done now will be wrong and will create momentum in the wrong direction.  Don’t move until outcomes are defined.

With outcomes in hand, get the band back together. You know who they are.  You’ve worked with them over the years. They’re influential and seasoned.  You trust them and so does the organization.  In an off-site location show them the outcomes and ask them for the problems. (To get their best thinking spend money on great food and a relaxing environment.)  If they’re the right folks, they’ll say they don’t know.  Then, they’ll craft the work to figure it out – to collect and analyze the data.  (The first part of problem definition is problem definition.) There will be immense pressure to start the improvement work, but resist.  Any work done now will be wrong.  Don’t move until problems are defined.

With outcomes and problems in hand, meet with the CEO.  Listen.  If outcomes change, get the band back together and repeat the previous paragraph. Then set up another meeting with the CEO.  Review outcomes and problems.  Listen.  If there’s agreement, it’s time to put a plan together.  If there’s disagreement, stop.  Don’t move until there’s agreement.  This is where it gets sticky.  It’s a battle to balance everyone’s thoughts and feelings, but that’s your challenge.  No words of wisdom on than – don’t move until outcomes and problems are defined.

There’s a lot of emotion around the product development process.  We argue about the right way to fix it – the right tools, training, and philosophies. But there’s no place for argument.  Analyze your process and define outcomes and problems.  The result will be a well informed improvement plan and alignment across the company.

What’s the risk?

What’s to lose?

What’s in the way?

What are you afraid of?

a

Try it.

Mental walls are more powerful than physical ones.

With physical walls you know where they start and end and know if you can bust them down. With mental walls, you’re not sure.

With physical walls you know they exist – that they’re real. With mental walls, you’re not sure.

With physical walls you can blame someone for bad workmanship. With mental walls, you’re the workman.

The only way to tell a real wall from a mental one is to to take a run at it, but even then, you’re never really sure.

We all have computer models – economic models, buying models, voting models, thermal, stress, and vibration. A strange thing happens when our models reside in the computer: their output becomes gospel, unchallengeable. And to set the hook, computerized output is bolstered by slick graphics, auto-generated graphs, and pretty colors.

Model fundamentals are usually well defined, proven, and grounded – not the problem. The problem is applicability. Do the fundamentals apply? Do they apply in the same way? Do different fundamentals apply? We never ask those questions. That’s the problem.

New folks don’t have the context to courageously challenge fundamentals and more experienced folks have had the imagination flogged out of them. So who’s left to challenge applicability of fundamentals? You know who’s left.

It’s smart folks with courage that challenge fundamentals; it’s people willing to contradict previous success (even theirs) that challenge fundamentals; it’s people willing to extend beyond that challenge fundamentals; it’s people willing to risk their career that challenge fundamentals.

Want to challenge fundamentals? Hire, engage, and support smart folks with courage.