Posts Tagged ‘Problem Definition’

Don’t boost innovation, burst it.

Burst you balloonThe most difficult part of innovation is starting, and the best way to start is the Innovation Burst Event, or IBE. The IBE is a short, focused event with three objectives: to learn innovation methods, to provide hands-on experience, and to generate actual results. In short, the IBE is a great way to get started.

There are a couple flavors of IBEs, but the most common is a single day even where a small, diverse group gets together to investigate some bounded design space and to create novel concepts. At the start, a respected company leader explains to the working group the importance of the day’s work, how it fits with company objectives, and sets expectations there will be a report out at the end of the day to review the results. During the event, the working group is given several design challenges, and using innovation tools/methods, creates new concepts and builds “thinking prototypes.” The IBE ends with a report out to company leaders, where the working group identifies patentable concepts and concepts worthy of follow-on work. Company leaders listen to the group’s recommendations and shape the go-forward actions.

The key to success is preparation. To prepare, interesting design space is identified using multiple inputs: company growth objectives, new market development, the state of the technology, competitive landscape and important projects that could benefit from new technology. And once the design space is identified, the right working group is selected. It’s best to keep the group small yet diverse, with several important business functions represented. In order to change the thinking, the IBE is held at location different than where the day-to-day work is done – at an off-site location. And good food is provided to help the working group feel the IBE is a bit special.

The most difficult and most important part of preparation is choosing the right design space. Since the selection process starts with your business objectives, the design space will be in line with company priorities, but it requires dialing in. The first step is to define the operational mechanism for the growth objective. Do you want a new product or process? A new market or business model? The next step is to choose if you want to radically improve what you have (discontinuous improvement) or obsolete your best work (disruption). Next, the current state is defined (knowing the starting point is more important than the destination) – Is the technology mature? What is the completion up to? What is the economy like in the region of interest? Then, with all that information, several important lines of evolution are chosen. From there, design challenges are created to exercise the design space. Now it’s time for the IBE.

The foundation of the IBE is the build-to-think approach and its building blocks are the design challenges. The working group is given a short presentation on an innovation tool, and then they immediately use the tool on a design challenge. The group is given a short description of the design challenge (which is specifically constructed to force the group from familiar thinking), and the group is given an unreasonably short time, maybe 15-20 minutes, to create solutions and build thinking prototypes. (The severe time limit is one of the methods to generate bursts of creativity.) The thinking prototype can be a story board, or a crude representation constructed with materials on hand – e.g., masking tape, paper, cardboard. The group then describes the idea behind the prototype and the problem it solves. A mobile phone is used to capture the thinking and the video is used at the report out session. The process is repeated one or two times, based on time constraints and nature of the design challenges.

About an hour before the report out, the working group organizes and rationalizes the new concepts and ranks them against impact and effort. They then recommend one or two concepts worthy of follow on work and pull together high level thoughts on next steps. And, they choose one or two concept that may be patentable. The selected concepts, the group’s recommendations, and their high level plans are presented at the report out.

At the report out, company leaders listen to the working group’s thoughts and give feedback. Their response to the group’s work is crucial. With right speech, the report out is an effective mechanism for leaders to create a healthy innovation culture. When new behaviors and new thinking are praised, the culture of innovation moves toward the praise. In that way, the desired culture can be built IBE by IBE and new behaviors become everyday behaviors.

Innovation is a lot more than Innovation Burst Events, but they’re certainly a central element. After the report out, the IBE’s output (novel concepts) must be funneled into follow on projects which must be planned, staffed, and executed. And then, as the new concepts converge on commercialization, and the intellectual comes on line, the focus of the work migrates to the factory and the sales force.

The IBE is designed to break through the three most common innovation blockers – no time to do innovation; lack of knowledge of how do innovation (though that one’s often unsaid); and pie-in-the-sky, brainstorming innovation is a waste of time. To address the time issue, the IBE is short – just one day. To address the knowledge gap, the training is part of the event. And to address the pie-in-the-sky – at the end of the day there is tangible output, and that output is directly in line with the company’s growth objectives.

It’s emotionally challenging to do work that destroys your business model and obsoletes your best products, but that’s how it is with innovation. But for motivation, think about this – if your business model is going away, it’s best if you make it go away, rather than your competition.  But your competition does end up changing the game and taking your business, I know how they’ll do it – with Innovation Burst Events.

Image credit – Pascal Bovet

Customer Value – the Crowned Jewel of Innovation

wolframite

Innovation results in things that are novel, useful, and successful. These things can be products, services, data, information, or business models, but regardless of the flavor, they’re all different from what’s been done before.

And when things are different, they’re new; and that means we don’t know how to do them. We don’t know how to start; don’t know how to measure; don’t know how they’ll be received; don’t know if they’ll be successful.

In the commercial domain, successful means customers buy your products and pay for your services. When customers value your new stuff more than they value their money, they pay; and when they pay it’s success. But first things first – before there can be success, before there can be innovation, there must be customer value. With innovation, customer value is front and center.

How do you come up with ideas that may have customer value? There’s a goldmine of ideas out there, with some veins better than others, and any dowsing you can use to pan the high grade ore is time well spent. There are two tools of choice: one that channels the voice of the customer and a second that channels the voice of the technology.

Your technology has evolved over time and has developed a trajectory which you can track. (Innovation On Demand, Fey and Riven.) But at the highest level, as a stand-in for technology, it’s best to track the trajectory of your products – how they’ve improved over time. You can evaluate how your products improved over multiple lines of evolution, and each line will help you to channel the future from a different perspective.

The voice of your customers is the second divining rod of choice. What they say about you, your company, and your products can help you glean what could be. But this isn’t the same as VOC. This is direct, unfiltered, continuous real time capture of self-signified micro stories. This is VOC without the soothsaying, this is direct connection with the customer. (Sensemaker.)

There are two nuggets to pan for: limiting cant’s and purposeful misuse. You seek out groups of customer stories where customers complain about things your product cannot do and how those cant’s limit them. These limiting cant’s are ripe for innovation since your customers already want them. Purposeful misuse is when the radical fringe of your customer base purposely uses your product in a way that’s different than you hoped. These customers have already looked into the future for you.

Do these ideas have customer value? The next step is to evaluate the value of your diamonds in the rough. The main point here is only customers can tell you if you’ve hit the mother lode. But, since your ideas are different than anything they’ve experienced, in order assay the ideas you’ve got to show them. You’ve got to make minimum viable prototypes and let them use their loop to judge the potential cut, color, clarity, and carat. As a prospector, it’s best to evaluate multiple raw gemstones in parallel, and whatever customers say, even if you disagree, the learning is better than gold.

How can we deliver on the customer value? With your innovations in the rough – ideas you know have customer value – it’s time to figure out what it will take to convert your pyrite prototypes into 24 carat products. There are missing elements to be identified and fundamental constraints to be overcome and backplane of the transmutation is problem definition. Done right, the technology development work is a series of well-defined problems with clear definitions of success. From the cleaving, blocking and cutting of technology development the work moves to the polishing of product development and commercialization.

Innovation can’t be fully defined with a three question framework. But, as long as customer value is the crowned jewel of your innovation work, most everything else will fall into place.

How do you choose what to work on?

Eagle Nebula M16There are always too many things to do, too much to work on. And because of this, we must choose. Some have more choice than others, but we all have choice. And to choose, there are several lenses we look through.

What’s good enough? If it’s good enough, there’s no need to work on it. “Good enough” means it’s not a constraint; it’s not in the way of where you want to go.

What’s not good enough? If it’s not good enough, it’s important to work on it. “Not good enough” means it IS a constraint; it IS in the way; it’s blocking your destination.

What’s not happening? If it’s not happening and the vacancy is blocking you from your destination, work on it. Implicit in the three lenses is the assumption of an idealized future state, a well-defined endpoint.

It’s the known endpoint that’s used to judge if there’s a blocking constraint or something missing. And there are two schools of thought on idealized future states – the systems, environment, competition, and interactions are well understood and idealized future states are the way to go, or things are too complex to predict how things will go. If you’re a member of the idealized-future-state-is-the-way-to-go camp, you’re home free – just use your best judgment to choose the most important constraints and hit them hard. If you’re a believer in complexity and its power to scuttle your predictions, things are a bit more nuanced.

Where the future state folks look through the eyepiece of the telescope toward the chosen nebula, the complexity folks look through the other end of the telescope toward the atomic structure of where things are right now. Complexity thinkers think it’s best to understand where you are, how you got there, and the mindset that guided your journey. With that knowledge you can rough out the evolutionary potential of the future and use that to decide what to work on.

If you got here by holding on to what you had, it’s pretty clear you should try to do more of that, unless, of course, the rules have changed. And to figure out if the rules have changed? Well, you should run small experiments to test if the same rules apply in the same way. Then, do more of what worked and less of what didn’t. And if nothing works even on a small scale, you don’t have anything to hold onto and it’s time to try something altogether new.

If you got here with the hybrid approach – by holding on to what you had complimented with a healthy dose of doing new stuff (innovation), it’s clear you should try to do more of that, unless, of course, you’re trying to expand into new markets which have different needs, different customers, and different pocketbooks. To figure out what will work, runs small experiments, and do more of what worked and less of what didn’t. If nothing works, your next round of small experiments should be radically different. And again, more of what worked, less of what didn’t.

And if you’re a young company and have yet to arrive, you’re already running small experiments to see what will work, so keep going.

There’s a half-life to the things that got us here, and it’s difficult to predict their decay. That’s why it’s best to take small bets on a number of new fronts – small investment, broad investigation of markets, and fast learning. And there’s value in setting a rough course heading into the future, as long as we realize this type of celestial navigation must be informed by regular sextant sightings and course corrections they inform.

Image credit – Hubble Heritage.

Bridging The Chasm Between Technologists and Marketers

20140122-212144.jpgWhat’s a new market worth without a new technology to capture it? The same as a new technology without a new market – not much. Technology and market are a matched set, but not like peanut butter and jelly, (With enough milk, a peanut butter sandwich isn’t bad.) rather, more like H2 and O: whether it’s H2 without O or O without H2 – there’s no water. With technology and market, there’s no partial credit – there’s nothing without both.

You’d think with such a tight coupling, market and technology would be highly coordinated, but that’s not the case. There’s a deep organizational chasm between them. But worse, each has their own language, tools, and processes. Plain and simple, the two organizations don’t know how to talk to each other, and the result is the wrong technology for the right market (if you’re a marketer) or the right technology for the wrong market (if you’re a technologist.) Both ways, customers suffer and so do business results.

The biggest difference, however, is around customers. Where marketers pull, technologists push – can’t be more different than that. But neither is right, both are. There’s no sense arguing which is more important, which is right, or which worked better last time because you need both. No partial credit.

If you speak only French and have a meeting with someone who speaks only Portuguese, well, that’s like meeting between marketers and technologists. Both are busy as can be, and neither knows what the other is doing. There’s a huge need for translators – marketers that speak technologist and technologists that talk marketing. But how to develop them?

The first step is to develop a common understanding of why. Why do you want to develop the new market? Why hasn’t anyone been able to create the new market? Why can’t we develop a new technology to make it happen? It’s a good start when both sides have a common understanding of the whys.

To transcend the language barrier, don’t use words, use video. To help technologists understand unmet customer needs, show them a video of a real customer in action, a real customer with a real problem. No words, no sales pitch, just show the video. (Put your hand over your mouth if you have to.) Show them how the work is done, and straight away they’ll scurry to the lab and create the right new technologies to help you crack the new market. Technologists don’t believe marketers; technologists believe their own eyes, so let them.

To help marketers understand technology, don’t use words, use live demos. Technologists – set up a live demo to show what the technology can do. Put the marketer in front of the technology and let them drive, but you can’t tell them how to drive. You too must put your hand over your mouth. Let them understand it the way they want to understand it, the way a customer would understand it. They won’t use it the way you think they should, they’ll use it like a customer. Marketers don’t understand technology, they understand their own eyes, so let them.

And after the videos and the live demos, it’s time to agree on a customer surrogate. The customer surrogate usually takes the form of a fully defined test protocol and fully defined test results. And when done well, the surrogate generates test results that correlate with goodness needed to crack the new market. As the surrogate’s test results increase, so does goodness (as the customer defines it.) Instead of using words to agree on what the new technology must do, agreement is grounded in a well defined test protocol and a clear, repeatable set of test results. Everyone can use their eyes to watch the actual hardware being tested and see the actual test results. No words.

To close the loop and determine if everyone is on the same page, ask the marketers and technologist to co-create the marketing brochure for the new product. Since the brochure is written for the customer, it forces the team use plain language which can be understood by all. No marketing jargon or engineering speak – just plain language.

And now, with the marketing brochure written, it’s time to start creating the right new market and the right new technology.

Photo credit – TORLEY.

The Parent of Learning

elbowHypothesis 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.]

Define To Solve

problem definitionCountries 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.

It’s All Connected

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?

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.

There Are No Best Practices

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.

How Engineers Create New Markets

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.

Climbing The Branches Of The Problem Tree

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.

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner

Archives