Shipulski On Design

Archive for the ‘Problems’ Category

The 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

We spend too much time on the mundane. Every day people come to work, turn on their PCs, and the mundane magically happens on its own accord. Email gets sent, phones get answered, mail gets delivered, and processes get followed. And after lunch, the hamster wheel spins back up and the mundane consumes the rest of our day. Yet there’s no need because that stuff runs on its own. It’s time to leave it alone and manage the mundane by exception. If there’s a hiccup, give it a drink of water, and otherwise leave it alone. It’s time to recognize the massive opportunity cost of the mundane – mundane comes at the expense of meaningful.

But when the mundane withers and there’s finally time for meaningful, there’s another chasm to cross – no one asks for meaningful work. Because meaningful work makes a difference and making a difference threatens the legacy of success, no one asks you for it. Because it’s considered impossible, there’s no request to do it. And because it’s considered a strength of your business, no one suggests you dismantle it. Crazy, but it’s time to stop the mundane so you can start doing work no one is asking you to do.

But it’s not any old work no one is asking for, it’s a special flavor, a flavor that meets a tight set of criteria.

Don’t do it unless it will make a difference. But not any old difference, a difference of epic proportions. If you explain the concept to the customer and they want to buy ten, you’re on the right track. If after you show the prototype the customer won’t give it back to you with a wrestling match, that’s the right work. If you present the concept to the core business unit and they immediately try to scuttle it, you’re on to something.

Don’t do it unless it resonates with you, personally. As subject matter expert, it must make your hair stand on end. As the inventor who must swim against the tide of “you can’t do that”, it must fill your deep need to help others. As the pariah who threatens the success of the company, it must be more than an idea – it must be part of you.

Leaders – it’s time to ask your people to work on things that are meaningful to them. Give them four hours a week and ask for an informal fifteen minute presentation every other week. They’ll make extreme progress and amaze you. Magically, because they’ll be so charged up, there will be time for all the work. Morale will skyrocket, the best folks will ask to work on your team, and you’ll have working prototypes for all the things you should have asked for.

I’ve had some great teachers in my life, and I’m grateful for them.  They taught me their hard-earned secrets, their simple secrets.  Though each had their own special gifts, they all gave them in the same way – they asked the simplest questions.

Today’s world is complex – everything interacts with everything else; and today’s pace is blistering – it’s tough to make time to understand what’s really going on.  To battle the complexity and pace, force yourself to come up with the simplest questions.  Here are some of my favorites:

For new products:

• Who will buy it?
• What must it do?
• What should it cost?

For new technologies:

• What problem are you trying to solve?
• How will you know you solved it?
• What work hasn’t been done before?

For new business models:

• Why are you holding onto your decrepit business model?

For problems:

• Can you draw a picture of it on one page?
• Can you make it come and go?

For decisions:

• What is the minimum viable test?
• Why not test three or four options at the same time?

For people issues:

• Are you okay?
• How can I help you?

For most any situation:

• Why?

These questions are powerful because they cut through the noise, but their power couples them to fear and embarrassment – fear that if you ask you’ll embarrass someone.  These questions have the power to make it clear that all the activity and hype is nothing more than a big cloud of dust heading off in the wrong direction. And because of that, it’s scary to ask these questions.

It doesn’t matter if you steal these questions directly (you have my permission), twist them to make them your own, or come up with new ones altogether.  What matters is you spend the time to make them simple and you summon the courage to ask.

Image credit — Montecruz Foto.

What’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 H₂ and O: whether it’s H₂ without O or O without H₂ – 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.

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.

The technical stuff is the easy part. Technical systems respond predictably, but people don’t.

There’s nothing worse than solving the wrong problem, so before you start solving you’ve better done a whole lot of defining.

There is no exact answer; engineering is all about judgment.

Organizational structure is important.  Whatever the structure, see its strengths and make them work for you.  If you try to fight it, it will eat you.

Innovation isn’t about ideas, innovation is about commercializing ideas.

Engineering analysis can win minds, but not hearts. And hearts govern minds.

The engineer’s role is not to minimize risk; it’s to understand the commercial reward and take risk accordingly.

What people believe is far more powerful than what they think.

New technology threatens status quoers, and, in turn, they block it.

There is no problem unless someone important thinks there’s one.

All technical systems are really human systems masquerading as technical systems.

If you let it, fear dominates. Be afraid and do it anyway.  But along the way, keep in mind that others are too afraid to try.

Engineering is not sane and rational; engineering is about people.

I like Dave Snowden’s thinking on innovation – starvation, pressure, and perspective shift. Here’s what it means to me:

Starvation – Left to our own, we’ll do as we did before. Starvation of resources pushes thinking away from stale, worn paths. Almost in reverse, define what you don’t want, then construct intelligent constraints (the most difficult part of the whole deal) so it’s out of the design space. Constrain the team so they can’t use the most expensive material; constrain the team so they can’t use the same old technology; constrain them so they can’t use the tried and true business model. It’s reverse thinking, but constraints – telling them what they can’t do – frees up design space. Constraints say “Do anything you want, except this.” which constrains far less than specifications. Constrain them to free them.

Pressure – Left to our own, we’ll reuse old thinking. Time pressure drags thinking out of the ruts of our success. Define creative constraints then, to create pressure, give the team insufficient time to think it through. Force them to swim differently with the problem.  The best way I know is to explain the constraints then give the team fifteen minutes to build a prototype. (Yes, fifteen.) The prototype is non-functional, and can be made from whatever is on hand – cardboard, clay, duct tape, or packing peanuts. The short time frame creates pressure, and the pressure extrudes different thinking.  Building a prototype shifts from learning-in-the-brain to learning-with-the-hands. And since hands learn differently than brains, new thinking is cast.

Perspective Shift – Left to our own, we’ll do a remake. Perspective shift moves us to a different place to create a healthy disrespect for today’s thinking. Seen in the right new light, our successes should look problematic. (From the front a skunk isn’t so bad, but from behind things aren’t so good.) Building a bridge to a new perspective can shift things a little, but for a tectonic shift, formalize the consequences of inaction. Think – “If we don’t do this, a very bad thing will happen.” Perspective shift is all about creating action in a new direction.

You won’t get it right the first time, but, no matter.  The real enemy is inaction.

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.