Shipulski On Design

Posts Tagged ‘Problems’

The trouble with innovation is it’s risky.  Sure, the upside is nice (increased sales), but the downside (it doesn’t work) is distasteful. Everyone is looking for the magic pill to change the risk-reward ratio of innovation, but there is no pill.  Though there are some things you can do to tip the scale in your favor.

All problems are business problems.  Problem solving is the key to innovation, and all problems are business problems.  And as companies embrace the triple bottom line philosophy, where they strive to make progress in three areas – environmental, social and financial, there’s a clear framework to define business problems.

Start with a business objective.  It’s best to define a business problem in terms of a shortcoming in business results. And the holy grail of business objectives is the growth objective.  No one wants to be the obstacle, but, more importantly, everyone is happy to align their career with closing the gap in the growth objective.  In that way, if solving a problem is directly linked to achieving the growth objective, it will get solved.

Sell more.  The best way to achieve the growth objective is to sell more. Bottom line savings won’t get you there.  You need the sizzle of the top line. When solving a problem is linked to selling more, it will get solved.

Customers are the only people that buy things.  If you want to sell more, you’ve got to sell it to customers. And customers buy novel usefulness.  When solving a problem creates novel usefulness that customers like, the problem will get solved.  However, before trying to solve the problem, verify customers will buy what you’re selling.

No-To-Yes.  Small increases in efficiency and productivity don’t cause customers to radically change their buying habits.  For that your new product or service must do something new. In a No-To-Yes way, the old one couldn’t but the new one can. If solving the problem turns no to yes, it will get solved.

Would they buy it? Before solving, make sure customers will buy the useful novelty. (To know, clearly define the novelty in a hand sketch and ask them what they think.) If they say yes, see the next question.

Would it meet our growth objectives? Before solving, do the math. Does the solution result in incremental sales larger than the growth objective? If yes, see the next question.

Would we commercialize it? Before solving, map out the commercialization work. If there are no resources to commercialize, stop.  If the resources to commercialize would be freed up, solve it.

Defining is solving. Up until now, solving has been premature. And it’s still not time. Create a functional model of the existing product or service using blocks (nouns) and arrows (verbs). Then, to create the problem(s), add/modify/delete functions to enable the novel usefulness customers will buy.  There will be at least one problem – the system cannot perform the new function. Now it’s time to take a deep dive into the physics and bring the new function to life.  There will likely be other problems.  Existing functions may be blocked by the changes needed for the new function. Harmful actions may develop or some functions will be satisfied in an insufficient way.  The key is to understand the physics in the most complete way.  And solve one problem at a time.

Adaptation before creation. Most problems have been solved in another industry. Instead of reinventing the wheel, use TRIZ to find the solutions in other industries and adapt them to your product or service.  This is a powerful lever to reduce innovation risk.

There’s nothing worse than solving the wrong problem.  And you know it’s the wrong problem if the solution doesn’t: solve a business problem, achieve the growth objective, create more sales, provide No-To-Yes functionality customers will buy, and you won’t allocate the resources to commercialize.

And if the problem successfully runs the gauntlet and is worth solving, spend time to define it rigorously.  To understand the bedrock physics, create a functional of the system, add the new functionality and see what breaks.  Then use TRIZ to create a generic solution, search for the solution across other industries and adapt it.

The key to innovation is problem solving. But to reduce the risk, before solving, spend time and energy to make sure it’s the right problem to solve.

It’s far faster to solve the right problem slowly than to solve the wrong one quickly.

Image credit – Kate Ter Haar

With process improvement, the existing process is refined over time.  With innovation, the work is new. You can’t improve a process that does not yet exist.  Process creation, yes.  Process improvement, no.

Standard work, where the sequence of process steps has proven successful, is a pillar of the manufacturing mindset.  In manufacturing, if you’re not following standard work, you’re not doing it right.  But with innovation, when the work is done for the first time, there can be no standard work. In that way, if you’re following the standard work paradigm, you are not doing innovation.

In a well-established manufacturing process, problems are tightly scoped and constrained. There can be several ways to solve it and one of the ways is usually better than the others. Teams are asked to solve the problem three or four ways and explain the rationale for choosing one solution over the other. With innovation it’s different.  There may not be a solution, never mind three.  With innovation, it’s one-in-a-row solution.  And the real problem is to decide which problem to solve.  If you’re asked to use Fishbone diagrams to solve the problem three or four ways, you’re not doing innovation. Solve it one way, show a potential customer and decide what to do next.

With manufacturing and product development, it’s all about Gantt charts and hitting dates.  The tasks have a natural precedence and all of them have been done before.  There are branches in the plan, but behind them is clear if-then logic.  With innovation, the first task is well-defined.  And the second task – it depends on the outcome of the first.  And completion dates?  No way. If you can predict the completion date, you’re not doing innovation.  And if you’re asked for a fully built-out Gantt chart, you’re in trouble because that’s a misguided request.

Systems in manufacturing can be complicated, with lots of moving parts.  And the problems can be complicated. But given enough time, the experts can methodically figure it out. But with innovation, the systems can be complex, meaning they are not predictable.  Sometimes parts of the system interact strongly with other parts and sometimes they don’t interact at all. And it’s not that they do one or the other, it’s that they do both.  It’s like they have a will of their own, and, sometimes, they have a bad attitude. And if it’s a new system, even the basic rules of engagement are unknown, never mind the changing strength of the interactions.  And if the system is incomplete and you don’t know it, linear thinking of the experts can’t solve it.  If you’re using linear problem solving techniques, you’re not doing innovation.

Manufacturing is about making one thing a million times. Innovation is about choosing among the million possibilities and making one-in-a-row, and then, after the bugs are worked out, making the new thing a million times.  But one-in-a-row must come first.  If you can’t do it once, you can’t do it a million times, even with process improvement, standard work, Gantt charts and Fishbone diagrams.

Image credit jacinta lluch valero

There are many definitions for creativity and innovation, but none add meaningfully to how the work is done. Though it’s clear why the work is important – creativity and innovation underpin corporate prosperity and longevity – it’s especially helpful to know how to do it.

At the most basic level, creativity and innovation are about problem solving.  But it’s a special flavor of problem solving.  Creativity and innovation are about problems solving new problems in new ways.  The glamorous part is ‘solving in new ways’ and the important part is solving new problems.

With continuous improvement the same problems are solved over and over. Change this to eliminate waste, tweak that to reduce variation, adjust the same old thing to make it work a little better.  Sure, the problems change a bit, but they’re close cousins to the problems to the same old problems from last decade. With discontinuous improvement (which requires high levels of creativity and innovation) new problems are solved.  But how to tell if the problem is new?

Solving new problems starts with seeing problems differently.

Systems are large and complicated, and problems know how to hide in the nooks and crannies. In a Where’s Waldo way, the nugget of the problem buries itself in complication and misuses all the moving parts as distraction. Problems use complication as a cloaking mechanism so they are not seen as problems, but as symptoms.

Telescope to microscope. To see problems differently, zoom in.  Create a hand sketch of the problem at the microscopic level.  Start at the system level if you want, but zoom in until all you see is the problem.  Three rules: 1. Zoom in until there are only two elements on the page. 2. The two elements must touch. 3. The problem must reside between the two elements.

Noun-verb-noun. Think hammer hits nail and hammer hits thumb.  Hitting the nail is the reason people buy hammers and hitting the thumb is the problem.

A problem between two things. The hand sketch of the problem would show the face of the hammer head in contact with the surface of the thumb, and that’s all.  The problem is at the interface between the face of the hammer head and the surface of the thumb. It’s now clear where the problem must be solved. Not where the hand holds the shaft of the hammer, not at the claw, but where the face of the hammer smashes the thumb.

Before-during-after. The problem can be solved before the hammer smashes the thumb, while the hammer smashes the thumb, or after the thumb is smashed.  Which is the best way to solve it? It depends, that’s why it must be solved at the three times.

Advil and ice. Solving the problem after the fact is like repair or cleanup. The thumb has been smashed and repercussions are handled in the most expedient way.

Put something between. Solving the problem while it happens requires a blocking or protecting action. The hammer still hits the thumb, but the protective element takes the beating so the thumb doesn’t.

Hand in pocket. Solving the problem before it happens requires separation in time and space. Before the hammer can smash the thumb it is moved to a safe place – far away from where the hammer hits the nail.

Nail gun. If there’s no way for the thumb to get near the hammer mechanism, there is no problem.

Cordless drill. If there are no nails, there are no hammers and no problem.

Concrete walls. If there’s no need for wood, there’s no need for nails or a hammer. No hammer, no nails, no problem.

Discerning between symptoms and problems can help solve new problems. Seeing problems at the micro level can result in new solutions. Looking closely at problems to separate them time and space can help see problems differently.

Eliminating the tool responsible for the problem can get rid of the problem of a smashed thumb, but it creates another – how to provide the useful action of the driven nail.  But if you’ve been trying to protect thumbs for the last decade, you now have a chance to design a new way to fasten one piece of wood to another, create new walls that don’t use wood, or design structures that self-assemble.

Image credit – Rodger Evans

When it’s time to innovate, the first task is usually to define the Idealized Future State (IFS).  The IFS is a word picture that captures what it looks like when the innovation work has succeeded beyond our wildest dreams. The IFS, so it goes, is directional so we can march toward the right mountain and inspirational so we can sustain our pace over the roughest territory.

For the IFS to be directional, it must be aimed at something – a destination.  But there’s a problem. In a sea of uncertainty, where the work has never been done before and where there are no existing products, services or customers, there are an infinite number of IFRs/destinations to guide our innovation work.  Open question – When the territory is unknown, how do we choose the right IFS?

For the IFS to be inspirational, it must create yearning for something better (the destination). And for the yearning to be real, we must believe the destination is right for us. Open question – How can we yearn for an IFS when we really can’t know it’s the right destination?

Maps aren’t the territory, but they are a collection of all possible destinations within the design space of the map.  If you have the right map, it contains your destination. And for a long time now, the old paper maps have helped people find their destinations. But on their own maps don’t tell us the direction to drive.  If you have a map of the US and you want to drive to Kansas, in which direction do you drive? It depends. If in California, drive east; if in Mississippi, drive north; if in New Hampshire, drive west; and in Minnesota, drive south. If Kansas is your idealized future state, the map alone won’t get your there.  The direction you drive depends on your location.

GPS has been a nice addition to maps. Enter the destination on the map, ask the satellites to position us globally and it’s clear which way to drive. (I drive west to reach Kansas.) But the magic of GPS isn’t in the electronic map, GPS is magic because it solves the location problem.

Before defining the idealized future state, define your location. It grounds the innovation work in the reality of what is, and people can rally around what is. And before setting the innovation direction with the IFS, define the next problems to solve and walk in their direction.

Image credit – Adrian Brady

By definition, when the work is new there is uncertainty.  And uncertainty can be stressful. But, instead of getting yourself all bound up, accept it.  More than that, relish in it.  Wear it as a badge of honor.  Not everyone gets the chance to work on something new – only the best do.  And, because you’ve been asked to do work with a strong tenor of uncertainty, someone thinks you’re the best.

But uncertainty is an unknown quantity, and our systems have been designed to reject it, not swim in it.  When companies want to get serious they drive toward a culture of accountability and the new work gets the back seat.  Accountability is mis-mapped to predictability, successful results and on time delivery.  Accountability, as we’ve mapped it, is the mortal enemy of new work.  When you’re working on a project with a strong element of uncertainty, the only certainty is the task you have in front of you.  There’s no certainty on how the task will turn out, rather, there’s only the simple certainty of the task.

With work with low uncertainty there are three year plans, launch timelines and predictable sales figures. Task one is well-defined and there’s a linear flow of standard work right behind it – task two through twenty-two are dialed in. But when working with uncertainty, the task at hand is all there is.  You don’t know the next task.  When someone asks what’s next the only thing you can say is “it depends.”  And that’s difficult in a culture of traditional accountability.

An “it depends” Gannt chart is an oxymoron, but with uncertainty step two is defined by step one.  If A, then B.  But if the wheels fall off, I’m not sure what we’ll do next.  The only thing worse than an “it depends” Gantt chart is an “I’m not sure” Gannt chart.  But with uncertainty, you can be sure you won’t be sure.  With uncertainty, traditional project planning goes out the window, and “it depends” project planning is the only way.

With uncertainty, traditional project planning is replaced by a clear distillation of the problem that must be solved.  Instead of a set of well-defined tasks, ask for a block diagram that defines the problem that must be solved.  And when there’s clarity and agreement on the problem that must be solved, the supporting tasks can be well-defined.  Step one – make a prototype like this and test it like that. Step two – it depends on how step one turns out.  If it goes like this then we’ll do that.  If it does that, we’ll do the other.  And if it does neither, we’re not sure what we’ll do.  You don’t have to like it, but that’s the way it is.

With uncertainty, the project plan isn’t the most important thing.  What’s most important is relentless effort to define the system as it is.  Here’s what the system is doing, here’s how we’d like it to behave and, based on our mechanism-based theory, here’s the prototype we’re going to build and here’s how we’re going to test it.  What are we going to do next?  It depends.

What’s next? It depends. What resources do you need? It depends. When will you be done? It depends.

Innovation is, by definition, work that is new.  And, innovation, by definition, is uncertain.  And that’s why with innovation, it depends.  And that’s why innovation is difficult.

And that’s why you’ve got to choose wisely when you choose the people that do your innovation work.

Image credit – Sara Biljana Gaon (off)

Immediately after there’s an elegant solution to a previously intractable problem, the solution is obvious to others.  But, just before the solution those same folks said it was impossible to solve.  I don’t know if there’s a name for this phenomenon, but it certainly causes hart burn for those brave enough to take on the toughest problems.

Intractable problems are so fundamental they are no longer seen as problems.  Over the years experts simply accept these problems as constraints that must be complied with.   Just as the laws of physics can’t be broken, experts behave as if these self-made constraints are iron-clad and believe these self-build walls define the viable design space.  To experts, there is only viable design space or bust.

A long time ago these problems were intractable, but now they are not.  Today there are new materials, new analysis techniques, new understanding of physics, new measurement systems and new business models.. But, they won’t be solved.  When problems go unchallenged and constrain design space they weave themselves into the fabric of how things are done and they disappear.   No one will solve them until they are seen for what they are.

It takes time to slow down and look deeply at what’s really going on.  But, today’s frantic pace, unnatural fascination with productivity and confusion of activity with progress make it almost impossible to slow down enough to see things as they are.  It takes a calm, centered person to spot a fundamental problem masquerading as standard work and best practice.  And once seen for what they are it takes a courageous person to call things as they are.  It’s a steep emotional battle to convince others their butts have been wet all these years because they’ve been sitting in a mud puddle.

Once they see the mud puddle for what it is, they must then believe it’s actually possible to stand up and walk out of the puddle toward previously non-viable design space where there are dry towels and a change of clothes.  But when your butt has always been wet, it’s difficult to imagine having a dry one.

It’s difficult to slow down to see things as they are and it’s difficult to re-map the territory.   But it’s important.  As continuous improvement reaches the limit of diminishing returns, there are no other options.  It’s time to solve the intractable problems.

Image credit – Steven Depolo

Innovation starts with recognition of a big, meaningful problem. It can come from the strategic planning process; from an ongoing technology project that isn’t going well; an ongoing product development project that’s stuck in the trenches; or a competitor’s unforeseen action. But where it comes from isn’t the point. What matters is it’s recognized by someone important enough to allocate resources to make the problem go away. (If it’s recognized by someone who can’t muster the resources, it creates frustration, not progress.)

Once recognized, the importance of the problem is communicated to the organization. Usually, a problem is important because it blocks growth, e.g., a missing element of the new business model, technology that falls short of the distinctive value proposition (DVP), or products that can’t deliver on your promises. But whether something’s in the way or missing, the problem’s importance is best linked to a growth objective.

Company leaders then communicate to the organization, using one page. Here’s an example:

WHY – we have a problem. The company’s stock price cannot grow without meeting the growth goals, and currently we cannot meet them. Here’s what’s needed.
WHAT – grow sales by 30%.
WHERE – in emerging markets.
WHEN – in two years.
HOW – develop a new line of products for the developing world.

Along with recognition of importance, there must be recognition that old ways won’t cut it and new thinking is required. That way the company knows it’s okay to try new things.

Company leaders pull together a small group and charters them to spend a bit of time to develop concepts for the new product line and come back and report their go-forward reccommendations. But before any of the work is done, resources are set aside to work on the best ones, otherwise no one will work on them and everyone will know the company is not serious about innovation.

To create new concepts, the small group plans an Innovation Burst Event (IBE). On one page they define the DVP for the new product line, which describes how the new customers will use the new products in new ways. They use the one page DVP to select the right team for the IBE and to define fertile design space to investigate. To force new thinking, the planning group creates creative constraints and design challenges to guide divergence toward new design space.

The off-site location is selected; the good food is ordered; the IBE is scheduled; and the team is invited. The company leader who recognized the problem kicks off the IBE with a short description of the problem and its importance, and tells the team she can’t wait to hear their recoomendations at the report-out at the end of the day.

With too little time, the IBE team steps through the design challenges, creates new concepts, and builds thinking prototypes. The prototypes are the center of attention at the report-out.

At the report-out, company leaders allocate IP resources to file patents on the best concepts and commission a team of marketers, technologists, and IP staff to learn if viable technologies are possible, if they’re patentable, and if the DVP is viable.(Will it work, can we patent it, and will they buy it.)

The marketer-technologist-IP team builds prototypes and tests them in the market. The prototypes are barely functional, if at all, and their job is to learn if the DVP resonates. (Think minimum viable prototype.) It’s all about build-test-learn, and the learning loops are fast and furious at the expese of statistical significance. (Judgement carries the day in this phase.)

With viable technology, patentable ideas, and DVP in hand, the tri-lobed team reports out to company leaders who sanctioned their work. And, like with the IBE, the leaders allocate more IP resources to file more patents and commission the commercialization team.

The commercialization team is the tried-and-true group that launches products. Design engineering makes it reliable; manufacturing makes it repeatable; marketing makes it irresistible; sales makes it successful. At the design reviews more patents are filed and at manufacturing readiness reviews it’s all about process capability and throughput.

Because the work is driven by problems that limit growth, the result of the innovation work is exactly what’s needed to fuel growth – in this case a successful product line for the developing world. Start with the right problem and end up with the right solution. (Always a good idea.)

With innovation programs, all the talk is about tools and methods, but the two things that really make the difference are lightning fast learning loops and resources to do the innovation work. And there’s an important philosophical chasm to cross – because patents are usually left out of the innovation equation – like an afterthought chasing a quota – innovation should become the umbrella over patents and technology. But because IP reports into finance and technology into engineering, it will be a tough chasm to bridge.

It’s clear fast learning loops are important for fast learning, but they’re also important for building culture. At the end of a cycle, the teams report back to leadership, and each report-out is an opportunity to shape the innovation culture. Praise the good stuff and ignore the rest, and the innovation culture moves toward the praise.

There’s a natural progression of the work. Start – do one project; spread – use the learning to do the next ones; systematize – embed the new behaviors into existing business processes; sustain – praise the best performers and promote them.

When innovation starts with business objectives, the objectives are met; when innovation starts with company leadership, resources are allocated and the work gets done; and when the work shapes the culture, the work accelerates. Anything less isn’t innovation.

Image credit – Jaybird

Here’s how innovation goes:
(Words uttered. // Internal thoughts.)

That won’t work. Yes, this is a novel idea, but it won’t work. You’re a heretic. Don’t bring that up again. // Wow, that scares me, and I can’t go there.

Yes, the first experiment seemed to work, but the test protocol was wrong, and the results don’t mean much. And, by the way, you’re nuts. // Wow. I didn’t believe that thing would ever get off the ground.

Yes, you modified the test protocol as I suggested, but that was only one test and there are lots of far more stressful protocols that surely cannot be overcome. // Wow. They listened to me and changed the protocol as I suggested, and it actually worked!

Yes, the prototype seemed to do okay on the new battery of tests, but there’s no market for that thing. // I thought they were kidding when they said they’d run all the tests I suggested, but they really took my input seriously. And, I can’t believe it, but it worked. This thing may have legs.

Yes, the end users liked the prototypes, but the sample size was small and some of them don’t buy any of our exiting products. I think we should make these two changes and take it to more end users. // This could be exciting, and I want to be part of this.

Yes, they liked the prototypes better once my changes were incorporated, but the cost is too high. // Sweet! They liked my design! I hope we can reduce the cost.

I made some design changes that reduce the cost and my design is viable from a cost standpoint, but manufacturing has other priorities and can’t work on it. // I’m glad I was able to reduce the cost, and I sure hope we can free up manufacting resources to launch my product.

Wow, it was difficult to get manufacturing to knuckle down, but I did it, and my product will make a big difference for the company. // Thanks for securing resources for me, and I’m glad you did the early concept work when I was too afraid.

Yes, my product has been a huge commercial success, and it all strarted with this crazy idea I had. You remember, right? // Thank you for not giving up on me. I know it was your idea. I know I was a stick-in-the-mud. I was scared. And thanks for kindly and effectively teaching me how to change my thinking. Maybe we can do it again sometime.
________________

There’s nothing wrong with this process; in fact, everything is right about it because that’s what people do. We’ve taught them to avoid risk at all costs, and even still, they manage to walk gingerly toward new thinking.

I think it’s important to learn to see the small shifts in attitude as progress, to see the downgrade from an impossible problem to a really big problem as progress.

Instead of grabbing the throat of radical innovation and disrupting yourself, I suggest a waterfall approach of a stepwise ratchet toward problems of a lesser degree. This way you can claim small victories right from the start, and help make it safe to try new things. And from there, you can stack them one on top of another to build your great pyramid of disruption.

And don’t forget to praise the sorceres and heretics who bravely advance their business model-busting ideas without the safety net of approval.

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.