Shipulski On Design

Posts Tagged ‘Problem Definition’

Hypothesis is a charged word – It has a scientific color; it smacks of sterility; it is thought to be done by academics; and it’s sometimes classified as special class of guessing. In thought and action, hypothesis is misunderstood.

We twist the word so it doesn’t apply in our situation; we label it to distance ourselves; we tag it with snarl connotations to protect ourselves. We do this because we’re afraid of the word’s power.

Replace hypothesis with “I think this will happen – [fill in the blank.]” and it’s clear why we’re afraid.  Hypothesis, as an activity, has the power to make it clear to everyone that you really don’t know what’s going on. Hypothesis demands you speculate based on your knowledge, and the fear is when you’re wrong (and you will be) people will think your knowledge (and you) is of a meager kind. Hypothesis demands you put yourself out there for the world to see. And that’s why it’s rarely done. And since it’s rarely done, its benefits are not understood.

Innovation is all the rage these days, and innovation is all about learning. And where necessity is the mother of invention, hypothesis is the father of learning. Hypothesis breeds learning by providing a comparison between what you thought would happen and what happened. The difference is a measure of your knowledge; and how the difference changes over time is a measure of your learning. If the difference widens over time, you’re getting cold; if it stays constant, you’re treading water; and if it converges, you’re learning.

Like a good parent, hypothesis knows which rules can be bent and which won’t be compromised. In the hypothesis household clarity and honesty are not optional – clarity around the problem at hand; clarity around how you’ll test and measure; and honesty around the limits of your knowledge.

Learning is important – no one can argue – and learning starts with a hypothesis. More strongly, learning is so important you should work through your fear around hypothesis and increase your learning rate.

Really, hypothesis isn’t the stern parent you think. Hypothesis will make time to teach you to ride your bike without training wheels, and be right there to bandage your skinned knees.

And, like a good parent, if you ask hypothesis for help, I think this will happen – [you’ll learn more and learn faster.]

Countries want their companies to create wealth and jobs, and to do it they want them to design products, make those products within their borders, and sell the products for more than the cost to make them. It’s a simple and sustainable recipe which makes for a highly competitive landscape, and it’s this competition that fuels innovation.

When companies do innovation they convert ideas into products which they make (jobs) and sell (wealth). But for innovation, not any old idea will do; innovation is about ideas that create novel and useful functionality. And standing squarely between ideas and commercialization are tough problems that must be solved. Solve them and products do new things (or do them better), become smaller, lighter, or faster, and people buy them (wealth).

But here’s the part to remember – problems are the precursor to innovation.

Before there can be an innovation you must have a problem. Before you develop new materials, you must have problems with your existing ones; before your new products do things better, you must have a problem with today’s; before your products are miniaturized, your existing ones must be too big. But problems aren’t acknowledged for their high station.

There are problems with problems – there’s an atmosphere of negativity around them, and you don’t like to admit you have them. And there’s power in problems – implicit in them are the need for change and consequence for inaction. But problems can be more powerful if you link them tightly and explicitly to innovation. If you do, problem solving becomes a far more popular sport, which, in turn, improves your problem solving ability.

But the best thing you can do to improve your problem solving is to spend more time doing problem definition. But for innovation not any old problem definition will. Innovation requires level 5 problem definition where you take the time to define problems narrowly and deeply, to define them between just two things, to define when and where problems occur, to define them with sketches and cartoons to eliminate words, and to dig for physical mechanisms.

With the deep dive of level 5 you avoid digging in the wrong dirt and solving the wrong problem because it pinpoints the problem in space and time and explicitly calls out its mechanism. Level 5 problem definition doesn’t define the problem, it defines the solution.

It’s not glamorous, it’s not popular, and it’s difficult, but this deep, mechanism-based problem definition, where the problem is confined tightly in space and time, is the most important thing you can do to improve innovation.

With level 5 problem definition you can transform your company’s profitability and your country’s economy. It does not get any more relevant than that.

There’s a natural tendency to simplify, to reduce, to narrow. In the name of problem solving, it’s narrow the scope, break it into small bites, and don’t worry about the subtle complexities. And for a lot of situations that works. But after years of fixing things one bite at a time, there are fewer and fewer situations that fit the divide and conquer approach. (Actually, they’re still there, but their return on investment is super low.) And after years of serial discretization, what are left are situations that cannot be broken up, that cut across interfaces, that make up a continuum. What are left are big problems and big situations that have huge payoff if solved, but are interconnected.

Whether it’s cross-discipline, cross-organization, cross-cultural, or cross-best practice, the fundamental of these big kahunas is they cross interfaces. And that’s why they’ve never been attacked, and that’s why they’ve never been solved. But with payoffs so big, it’s time to take on connectedness.

For me, the most severe example of connectedness is woven around the product. To commercialize a product there are countless business process that cut across almost every interface. Here are a few: innovation, technology development, product development, robustness testing, product documentation, manufacturing engineering, marketing, sales, and service. Each of these processes is led by one organization and cuts across many; each cut across expertise-specialization interfaces; each requires information and knowledge from the other; and each new product development project must cooperate with all the others. They cannot be separated or broken into bits. Change one with intent and change the others with unintended consequences. No doubt – they’re connected.

Green thinking is much overdue, but with it comes connectedness squared. With pre-green product commercialization, the product flowed to the end user and that was about it. But with environmental movement there’s a whole new return path of interconnected business processes. Green thinking has turned the product life cycle into the circle of life – the product leaves, it lives it’s life, and it always comes back home.

And with this return path of connectedness, how the product goes together in manufacturing must be defined in conjunction with how it will be disassembled and recycled. Stress analysis must be coordinated with packaging design, regulations of banned substances, and material reuse of retired product. Marketing literature must be co-produced with regulatory strategy and recycling technologies. It’s connected more than ever.

But the bad news is the good news. Yes, things are more interwoven and the spider web is more tangled. But the upside – companies that can manage the complexity will have a significant advantage. Those that can navigate within connectedness will win.

The first step is to admit there’s a problem, and before connectedness can be managed, it must be recognized. And before it can become competitive advantage, it must be embraced.

How long will it take? The short answer – same as last time. How long do we want it to take? That’s a different question altogether.

If the last project took a year, so will the next one. Even if you want it to take six months, it will take a year. Unless, there’s a good reason it will be different. (And no, the simple fact you want it to take six months is not a good enough reason in itself.)

Some good reasons it will take longer than last time: more work, more newness, less reuse, more risk, and fewer resources. Some good reasons why it will go faster: less work, less newness, more reuse, less risk, more resources. Seems pretty tight and buttoned-up, but things aren’t that straight forward.

With resources, the core resources are usually under control.  It’s the shared resources that are the problem. With resources under their control (core resources) project teams typically do a good job – assign dedicated resources and get out of the way. Shared resources are named that way because they support multiple projects, and this is the problem. Shared resources create coupling among projects, and when one project runs long, resource backlogs ripple through the other projects. And it gets worse. The projects backlogged by the initial ripple splash back and reflect ripples back at each other. Understand the shared resources, and you understand a fundamental dynamic of all your projects.

Plain and simple – work content governs project timelines. And going forward I propose we never again ask “How long will it take?” and instead ask “How is the work content different than last time?” To estimate how long it will take, set up a short face-to-face meeting with the person who did it last time, and ask them how long it will take. Write it down, because that’s the best estimate of how long it will take.

It may be the best estimate, but it may not be a good one. The problem is uncertainty around newness. Two important questions to calibrate uncertainty: 1) How big of a stretch are you asking for? and 2) How much do you know about how you’ll get there? The first question drives focus, but it’s not always a good predictor of uncertainty.  Even seemingly small stretches can create huge problems. (A project that requires a 0.01% increase in the speed of light will be a long one.) What matters is if you can get there.

To start, use your best judgment to estimate the uncertainty, but as quickly as you can, put together a rude and crude experimental plan to reduce it. As fast as you can execute the experimental plan, and let the test results tell you if you can get there. If you can’t get there on the bench, you can’t get there, and you should work on a different project until you can.

The best way to understand how long a project will take is to understand the work content. And the most important work content to understand is the new work content. Choose several of your best people and ask them to run fast and focused experiments around the newness. Then, instead of asking them how long it will take, look at the test results and decide for yourself.

That’s a best practice. Look, there’s another one. We need a best practice. What’s the best practice?  Let’s standardize on the best practice.  Arrrgh.  Enough, already, with best practices.

There are no best practices, only actions that have worked for others in other situations.  Yet we feverishly seek them out, apply them out of context, and expect they’ll solve a problem unrelated to their heritage.

To me, the right practices are today’s practices.  They’re the base camp from which to start a journey toward new ones.  To create the next evolution of today’s practices, for new practices to emerge, a destination must be defined. This destination is dictated by problems with what we do today.  Ultimately, at the highest level, problems with our practices are spawned by gaps, shortfalls, or problems in meeting company objectives.  Define the shortfall – 15% increase in profits – and emergent practices naturally diffuse to the surface.

There are two choices: choose someone else’s best practices and twist, prune, and bend them to fit, or define the incremental functionality you’d like to create and lay out the activities (practices) to make it happen. Either way, the key is starting with the problem.

The important part – the right practices, the new activities, the novel work, whatever you call it, emerges from the need.

It’s a problem hierarchy, a problem flow-down.  The company starts by declaring a problem – profits must increase by 15% – and the drill-down occurs until a set of new action (new behaviors, new processes, new activities) is defined that solves the low level problems. And when the low level problems are solved, the benefits avalanche to satisfy the declared problem – profits increased by 15%.

It’s all about clarity — clearly define the starting point, clearly define the destination, and express the gaps in a single page, picture-based problem statements.  With this type of problem definition, you can put your hand over your mouth, with the other hand point to the picture, and everyone understands it the same way. No words, just understanding.

And once everyone understands things clearly, the right next steps (new practices) emerge.

When engineers see a big opportunity, we want desperately to move the company in the direction of our thinking, but find it difficult to change the behavior of others. Our method of choice is usually a full frontal assault, explaining to anyone that will listen the opportunity as we understand it. Our approach is straightforward and ineffective. Our descriptions are long, convoluted, complicated, we use confusing technical language all our own, and omit much needed context that we expect others should know. The result – no one understands what we’re talking about and we don’t get the behavior we’re looking for (immediate company realignment with what we know to be true).  Then, we get frustrated and shut down – opportunity lost.

To change the behavior of others, we must first change our own. As engineers we see problems which, when solved, result in opportunity. And if we’re to be successful, we must go back to the problem domain and set things straight. Here’s a sequence of new behaviors we as engineers can take to improve our chances of changing the behavior of others:

Step 1. Create a block diagram of the physical system using simple nouns (blocks) and verbs (arrows). Blue arrows are good (useful actions) and red arrows are bad (harmful actions). Here’s a link to a PowerPoint file with a live template to create your own.

Step 2. Reduce the system block diagram down to its essence to create a distilled block diagram of the problem, showing only the system elements (blocks) with the problem (red arrow).For a live template, see the second page of the linked file. [Note – if there are two red arrows in the system block diagram, there are two problems which must be solved separately. Break them into two and solve the first one first. For an example, see page three of the linked file.]

Step 3. Create a hand sketch, or cartoon, showing the two system elements (blocks) of the distilled block diagram from step 2. Zoom in so only the two elements are visible, and denote where they touch (where the problem is), in red. For an example, see page four of the linked file.

Step 4. Now that you understand the real problem, use Google to learn how others have solved it.

Step 5. Choose one of Google’s most promising solutions and prototype it. (Don’t ask anyone, just build it.)

Step 6. Show the results to your engineering friends. If the problem is solved, it’s now clear how the opportunity can be realized. (There’s a big difference between a crazy engineer with a radically new market opportunity and a crazy engineer with test results demonstrating a new technology that will create a whole new market.)

Step 7. If the problem is not solved, or you solved the wrong problem, go back to step 1 and refine the problem

With step 1 you’ll find you really don’t understand the physical system, you don’t know which elements of the system have the problem, and you can’t figure out what the problem is. (I’ve created complicated system block diagrams only to realize there was no problem.)

With step 2, you’ll continue to struggle to zoom in on the problem. And, likely, as you try to define the problem, you’ll go back to step 1 and refine the system block diagram. Then, you’ll struggle to distill the problem down to two blocks (system elements). You’ll want to retain the complexity (many blocks) because you still don’t understand the real problem.

If you’ve done step 2 correctly, step 3 is easy, though you’ll still want to complicate the cartoon (too many system elements) and you won’t zoom in close enough.

Step 4 is powerful. Google can quickly and inexpensively help you see how the world has already solved your problem.

Step 5 is more powerful still.

Step 6 shows Marketing what the future product will do so they can figure out how to create the new market.

Step 7 is how problems are really solved and opportunities actually realized.

When you solve the real problem, you create real opportunities.

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).

The more work I do with innovation, the more I believe mindset is the most important thing.  Here’s what I believe:

Doing new doesn’t take a lot of time; it’s getting your mind ready that takes time.

Engineers must get over their fear of doing new.

Without a problem there can be no newness.

Problem definition is the most important part of problem solving.

If you believe it can work or it can’t, you’re right.

Activity is different from progress.

Thinking is progress.

In short, I believe state-of-the-art is limited by state-of-mind.

There is a healthy tension between level of improvement, or level of innovation, and time to market. Marketing wants radical improvement, infinitely short project schedules, and no change to the product. Engineers want to sign up for the minimum level of improvement, project schedules sufficiently long to study everything to death, and want to change everything about the new product. It’s healthy because there is balance – both are pulling equally hard in opposite directions and things end up somewhere in the middle. It’s not a stress-free environment, but it’s not too bad. But, sometimes the tension is unhealthy.

There are two flavors of unhealthy tension. First is when engineering has too much pull; they (we) sandbag on product performance and project timelines and change the design willy-nilly simply because they can (and it’s fun). The results are long project timelines, highly innovative designs that don’t work well, a lack of product robustness, and a boatload of new parts and assemblies. (Product complexity.) Second is when Marketing has too much pull; they ask for radical improvement in product functionality with project timelines too short for the level of innovation, and tightly constrain product changes such that solutions are not within the constraints. The results are long project timelines and un-innovative designs that don’t meet product specifications. (The solutions are outside the constraints.) Both sides are at fault in both scenarios. There are no clean hands.

What are the fundamentals behind all this gamesmanship? For engineering it’s technical risk; for marketing it’s schedule risk. Engineering minimizes what it signs up for in order to reduce technical risk and petitions for long project timelines to reduce it. Marketing minimizes product changes (constraints) to reduce schedule risk and petitions for short project timelines to reduce it. (Product development teams work harder with short schedules.) Something’s got to change. Read the rest of this entry »

Like you, I have been thinking a lot about the recession.  We all want to know how to move ourselves to the other side, where things are somewhat normal (the old normal, not the new one).  Like usual, my mind immediately goes to products.  To me, having the right products is vital to pulling ourselves out of this thing.  There is nothing novel in this thinking;  I think we all agree that products are important.  But, there are two follow-on questions that are important.  First, what makes products “right” to move you quickly to the other side?  Second, do you have the capability to engineer the “right” products?

The first question – what makes products “right” for these times?  Capacity is important to understanding what makes products right.  Capacity utilization is at record lows with most industries suffering from a significant capacity glut.  With decreased sales and idle machines, customers are no longer interested in products that improve productivity of their existing product lines because they can simply run their idle machines more.  And, they are not interested in buying more capacity (your products) at a reduced price.  They will simply run their idle machines more.  You can’t offer an improvement of your same old product that enables customers to make their same old products a bit faster and you can’t offer them your same old products at a lower price.  However, you can sell them products that enable them to capture business they currently do not have.  For example, enable them to manufacture products that their idle machines CANNOT make at all.  To do that means your new products must do something radically different than before; they must have radically improved functionality or radically new features.  This is what makes products right for these times.

On to the second question – do you have the capability to engineer the right products?  Read the rest of this entry »