Shipulski On Design

Posts Tagged ‘Understanding Physics’

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)

Everyone wants to do more innovation.  But how? To figure out what’s going on with their innovation programs, companies spend a lot of time to put projects into buckets but this generates nothing but arguments about whether projects are disruptive, radical innovation, discontinuous, or not.  Such a waste of energy and such a source of conflict.  Truth is, labels don’t matter.  The only thing that matters is if the projects, as a collection, meet corporate growth objectives.  Sure, there should be a short-medium-long look at the projects, but, for the three time horizons the question is the same – Do the projects meet the company’s growth objectives?

To create the causes and conditions for innovation, start with a clear growth objective by geography.  Innovation must be measured in dollars.

Good judgement is required to decide if a project is worthy of resources.  The incremental sales estimates are easy to put together.  The difficult parts are deciding if there’s enough sizzle to cause customers to buy and deciding if the company has the chops to do the work.  The difficulty isn’t with the caliber of judgement, rather it’s insufficient information provided to the people that must use their good judgement.  In shorth, there is poor clarity on what the projects are about. Any description of the projects blurry and done at a level of abstraction that’s too high.  Good judgement can’t be used when the picture is snowy, nor can it be effective with a flyby made in the stratosphere.

To create the causes and conditions for innovation, demand clarity and bedrock-level understanding.

To guarantee clarity and depth, use the framework of novel, useful, successful. Give the teams a tight requirement for clarity and depth and demand they meet it.  For each project, ask – What is the novelty? How is it useful? When the project is completed, how will everyone be successful?

A project must deliver novelty and the project leader must be able to define it on one page.  The best way to do this is to create physical (functional) model of the state-of-the-art system and modify it with the newness created by the project (novelty called out in red).  This model comes in the form of boxes that describe the system elements (simple nouns) and arrows that define the actions (simple verbs).  Think hammer (box – simple noun) hits (arrow -simple verb) nail (box – simple noun) as the state-of-the-art system and the novelty in red – a thumb protector (box) that blocks (arrow) hammer (box).  The project delivers a novel thumb protector that prevents a smashed thumb.  The novelty delivered by the project is clear, but does it pass the usefulness test?

To create the causes and conditions for innovation, demand a one-page functional model that defines and distills down to bedrock level the novelty created by the project.  And to help the project teams do it, hire a good teach teacher and give them the tools, time and training.

The novelty delivered by a project must be useful and the project leader must clearly define the usefulness on one page.  The best way to do this is with a one page hand sketch showing the customer actively using the novelty. In a jobs-to-be-done way, the sketch must define where, when and how the customer will realize the usefulness. And to force distillation blinding, demand they use a fat, felt tip marker. With this clarity, leaders with good judgement can use their judgement effectively. Good questions flow freely. Does every user of a hammer need this? Can a left-handed customer use the thumb guard? How does it stay on? Doesn’t it get in the way? Where do they put it when they’re done? Do they wear it all the time?  With this clarity, the questions are so good there is no escape.  If there are holes they will be uncovered.

To create the causes and conditions for innovation, demand a one-page hand sketch of the customer demonstrating the useful novelty.

To be successful, the useful novelty must be sufficiently meaningful that customers pay money for it.  The standard revenue projections are presented, but, because there is deep clarity on the novelty and usefulness, there is enough context for good judgement to be effective.  What fraction of hammer users hit their thumbs? How often? Don’t they smash their fingers too?  Why no finger protection?  Because of the clarity, there is no escape.

To create the causes and conditions, use the deep clarity to push hard on buying decisions and revenue projections.

The novel, useful, successful framework is a straightforward way to decide if the project portfolio will meet growth objectives.  It demands a clear understanding of the newness created by the project but, in return, provides context needed to use good judgement.  In that way, because projects cannot start without passing the usefulness and successfulness tests, resources are not allocated to unworthy projects.

But while clarity and this level of depth is a good start, it’s not enough.  It’s time for a deeper dive. The project must distill the novelty into a conflict diagram, another one-pager like the others, but deeper.  Like problem definition on steroids, a conflict must be defined in space – between two things (thumb and face of hammer head) – and time (just as the hammer hits thumb).  With that, leaders can ask before-during-after questions.  Why not break the conflict before it happens by making a holding mechanism that keeps the thumb out of the strike zone? Are you sure you want to solve it during the conflict time (when the hammer hits thumb)?  Why not solve it after the fact by selling ice packs for their swollen thumbs?

But, more on the conflict domain at another time.

For now, use novel, useful, successful to stop bad projects and start good ones.

Image credit – Natashi Jay

If you think something can’t be done, it won’t get done.  And if you think it may be possible, or is possible, it may get done.  Those are the rules.

If an expert says it will work, it will work.  If they say it won’t work, it might.  Experts can tell you will work, but can’t tell you what won’t.

If your boss tells you it won’t work, it might. Give it a try.  It will be fun if it works.

If you can’t make it work, make it worse and then do the opposite.

If you can’t explain the problem to your young kids, you don’t understand the situation and you won’t make it work.

If something didn’t work ten years ago, it may work now. Technology is better and we’re smarter.  More likely it would have worked ten years ago if they ran more than one crude experiment before they gave up.

If you can’t draw a one page sketch of the problem, it may never work.

If you can’t make it work, put it down for three days. Your brain may make it work while you’re sleeping.

If you don’t know the problem, you can’t make it work.  Be sure you’re trying to solve the right problem.

If your boss tells you it will work, it might.  If they tell you how to make it work, let them do it.

If none of your attempts have been fruitful and you’re out of tricks, purposely make one performance attribute worse to free up design space. That may work.

If you don’t know when the problem occurs, you don’t know much. Your solutions won’t work.

If you tried everything and nothing worked, ask someone for help whose specialty in an unrelated area.  They may have made it work in a different domain.

If you think everyone in the group understands the problem the same way, they don’t.  There’s no way they’ll agree on the best way to make it work. Don’t wait for consensus.

If you don’t try, that’s the only way to guarantee it won’t work.

Image credit – Simon Greig

If you don’t have a problem, there’s no problem. There are no resources without a problem and certainly no focus or momentum.  If you don’t know your problem, stop.  Take time to define your problem using a single page.  Make a sketch or make a block diagram but make it clear.  Make it so the problem description stands on its own. After you’ve defined your problem and someone calls it an “opportunity”, walk away because they can’t help you.  Taking advantage of opportunities is optional, but solving problems is mission critical.  No one worth their salt works on opportunities.  Rock stars solve problems.

After you’ve gnawed on a problem for a month and it hasn’t given in, what do you do?  When you’ve thrown everything at a problem and it still stands tall, what do you do?  When you’ve tried all your tricks and the intractable problem is still blocking an already overdue product launch, what do you do?  What you do is find someone who is unafraid trade an intractable problem for a solvable one, someone who will courageously give ground with the hope of opening up new design space, someone who will unabashedly take an anti-conventional (and hopefully controversial) approach.  What you do is find a rock star.

Intractable problems are not usually intractable; rather, intractable problems are either poorly-defined problems or are the wrong problem altogether.  Either way, it takes someone with courage, usually an outsider, to redefine the problem or see it differently.  But because of pride, an outsider can be brought in only after the team has exhausted all other possibilities.  Unless there’s a problem with the problem solving team (they can’t solve the problem), there’s no problem.  And without a problem, the team won’t accept help from an outsider.

At the rodeo when the cowboy is bucked off the raging bull, the cowboy runs away from the bull but the rodeo clown runs toward the bull to distract it.  Like the rodeo clown, the problem solving rock star runs toward raging problems at full tilt.  The rock star puts it all on the line as she grabs the problem by the scruff of the neck, wrestles it to the ground and hog ties it.  There’s no shyness, just well-practiced technique wrapped in implicit knowledge.  With courage and a cloud of dust, it’s no-holds-barred problem solving until the problem gives it up. Nothing is sacred, no assumptions go unchallenged, and no details are too small to ignore.  Like rodeo clowns, rock stars know their work looks funny from the outside, but they don’t care.  All they care about is solving the problem at hand. Right here, right now.

Before your next intractable problem, take a minute to scan your organization for the special people who have the courage to run toward even the most difficult problems.  Don’t be fooled by titles, positional power or how they dress.  Look deeply because like rodeo clowns, your magical problem solvers may not look the part on the outside.

Image credit – Ed Schipul

Today’s work is complicated with electronic and mechanical subsystems wrapped in cocoons of software; coordination of matrixed teams; shared resources serving multiple projects; providing world class services in seventeen languages on four continents. And the complexity isn’t limited to high level elements.  There is a living layer of complexity growing on all branches of the organization right down to the leaf level.

Complexity is real, and it complicates things.  To run projects and survive in the jungle of complexity it’s important to know how to put the right pieces together and provide the right answers.  But as a leader it’s more important to slash through the complexity and see things as they are.  And for that, it’s more important to know how ask diabolically simple questions (DSQ).

Project timelines are tight and project teams like to start as soon as they can.  Too often teams start without clarity on what they’re trying to achieve.  At these early stages the teams make record progress in the wrong direction.  The leader’s job is to point them in the right direction, and here’s the DSQ to set them on their way: What are you trying to achieve?

There will likely be some consternation, arm waiving and hand wringing.  After the dust settles, help the team further tighten down the project with this follow-on DSQ:  How will you know you achieved it?

For previous two questions there are variants that works equally well for work that closer to the fuzzy front end: What are you trying to learn? and How will you know you learned it?

There is no such thing as a clean-sheet project and even the most revolutionary work builds on the existing system.  Though the existing business model, service or product has been around for a long time, the project team doesn’t really know how it works.  They know they should know but they’re afraid to admit it. Let them off the hook with this beauty: How does it work today?

After the existing system is defined with a simple block diagram (which could take a couple weeks) it’s time to help the project team focus their work.  The best DSQ for the job: How is it different from the existing system?  If the list is too long there’s too much newness and if it’s too short there’s not enough novelty.  If they don’t know what’s different, ask them to come back when they know.

After the “what’s different” line of questioning, the team must be able to dive deeper.  For that it’s time one of the most powerful DSQs in the known universe: What problem are you trying to solve? Expect frustration and complicated answers.  Ask them to take some time and for each problem describe it on a single page using less than ten words.  Suggest a block diagram format and ask them to define where and when the problem occurs.  (Hint: a problem is always between two components/elements of the system.)  And the tricky follow-on DSQ: How will you know you solved it? No need to describe the reaction to that one.

Though not an exhaustive list, here are some of my other favorite DSQs:

Who will buy it, how much will they pay, and how do you know?

Have we done this before?

Have you shown it to a real customer?

How much will it cost and how do you know?

Whose help do we need?

If the prototype works, will we actually do anything with it?

Diabolically simple questions have the power to heal the project teams and get them back on track.  And over time, DSQs help the project teams adopt a healthy lifestyle.  In that way, DSQs are like medicine – they taste bad but soon enough you feel better.

Image credit – Daniela Hartmann

At the most basic level, business is about allocating resources to the best projects and executing those projects well.  Said another way, business is about deciding what to work on and then working effectively.  But how to go about deciding what to work on?  Here is a cascade of questions to start you on your journey.

What are your company’s guiding principles?  Why does it exist? How does it want to go about its life?   These questions create context from which to answer the questions that follow.  Once defined, all your actions should align with your context.

How has the business environment changed? This is a big one.  Everything is impermanent.  Change is the status quo.  What worked last time won’t work this time.  Your success is your enemy because it stunts intentions to work on new things.  Define new lines of customer goodness your competitors have developed; define how their technologies have increased performance; search YouTube to see the nascent technologies that will displace you; put yourself two years in the future where your customers will pay half what they pay today.  These answers, too, define the context for the questions that follow.

What are you working on? Define your fully-staffed projects. Distill each to a single page. Do they provide new customer value?  Are the projects aligned with your company’s guiding principles? For those that don’t, stop them.  How do your fully-staffed projects compare to the trajectory of your competitors’ offerings?  For those that compare poorly, stop them.

For projects that remain, do they meet your business objectives?  If yes, put your head down and execute.  If no, do you have better projects?  If yes, move the freed up resources (from the stopped projects) onto the new projects.  Do it now.  If you don’t have better projects, find some.  Use lines of evolution for technological systems to figure out what’s next, define new projects and move the resources.  Do it now.

The best leading indicator of innovation is your portfolio of fully-staffed projects.  Where other companies argue and complain about organizational structure, move your best resources to your best projects and execute.  Where other companies use politics to trump logic, move your best resources to your best projects and execute.  Where other successful companies hold on to tired business models and do-what-we-did-last-time projects, move your best resources to your best projects and execute.

Be ruthless with your projects.  Stop the bad ones and start some good ones. Be clear about what your projects will deliver – define the novel customer value and the technical work to get there.  Use one page for each.  If you can’t define the novel customer value with a simple cartoon, it’s because there is none.  And if you can’t define how you’ll get there with a hand sketch, it’s because you don’t know how.

Define your company’s purpose and use that to decide what to work on.  If a project is misaligned, kill it. If a project is boring, don’t bother.  If it’s been done before, don’t do it.  And if you know how it will go, do something else.

If you’re not changing, you’re dying.

Image credit – David Flam

One of the best ways to improve your brand is to improve your products.  The most common way is to provide more goodness for less cost – think miles per gallon.  Usually it’s a straightforward battle between market leaders, where one claims quantifiable benefit over the other – Ours gets 40 mpg and theirs doesn’t.   And the numbers are tied to fully defined test protocols and testing agencies to bolster credibility.  Here’s the data.  Buy ours

But there’s a more powerful way to improve your brand, and that’s to map your products to reliability.  It’s far a more difficult game than the quantified head-to-head comparison of fuel economy and it’s a longer play, but done right, it’s a lasting play that is difficult to beat.  Run the thought experiment:  think about the brands you associate with reliability.  The brands that come to mind are strong, lasting brands, brands with staying power, brands whose products you want to buy, brands you don’t want to compete against.  When you buy their products you know what you’re going to get.  Your friends tell you stories about their products.

There’s a complete a complete tool set to create products that map to reliability, and they work.  But to work them, the commercialization team has to have the right mindset.  The team must have the patience to formally define how all the systems work and how they interact. (Sounds easy, but it can be painfully time consuming and the level of detail is excruciatingly extreme.)  And they have to be willing to work through the discomfort or developing a common understanding how things actually work. (Sounds like this shouldn’t be an issue, but it is – at the start, everyone has a different idea on how the system works.)  But more importantly, they’ve got to get over the natural tendency to blame the customer for using the product incorrectly and learn to design for unintended use.

The team has got to embrace the idea that the product must be designed for use in unpredictable ways in uncontrolled conditions. Where most teams want to narrow the inputs, this team designs for a wider range of inputs.  Where it’s natural to tighten the inputs, this team designs the product to handle a broader set of inputs.  Instead of assuming everything will work as intended, the team must assume things won’t work as intended (if at all) and redesign the product so it’s insensitive to things not going as planned.  It’s strange, but the team has to design for hypothetical situations and potential problems.  And more strangely, it’s not enough to design for potential problems the team knows about, they’ve got to design for potential problems they don’t know about. (That’s not a typo.  The team must design for failure modes it doesn’t know about.)

How does a team design for failure modes it doesn’t know about? They build a computer-based behavioral model of the system, right down to the nuts, bolts and washers, and they create inputs that represent the environment around the system.  They define what each element does and how it connects to the others in the system, capturing the governing physics and propagation paths of connections. Then they purposefully break the functions using various classes of failure types, run the analysis and review the potential causes.  Or, in the reverse direction, the team perturbs the system’s elements with inputs and, as the inputs ripple through the design, they find previously unknown undesirable (harmful) functions.

Purposefully breaking the functions in known ways creates previously unknown potential failure causes.  The physics-based characterization and the interconnection (interaction) of the system elements generate unpredicted potential failure causes that can be eliminated through design.  In that way, the software model helps find potential failures the team did not know about.  And, purposefully changing inputs to the system, again through the physics and interconnection of the elements, generates previously unknown harmful functions that can be designed out of the product.

If you care about the long-term staying power of your brand, you may want to take a look at TechScan, the software tool that makes all this possible.

Image credit — Chris Ford.

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

Work is never perfect, family life is never perfect and neither is the interaction between them.  Regardless of your expectations or control strategies, things go as they go.  That’s just what they do.

We have far less control than we think.  In the pure domain of physics the equations govern predictively – perturb the system with a known input in a controlled way and the output is predictable.  When the process is followed, the experimental results repeat, and that’s the acid test.  From a control standpoint this is as good as it gets. But even this level of control is more limited than it appears.

Physical laws have bounded applicability – change the inputs a little and the equation may not apply in the same way, if at all. Same goes for the environment. What at the surface looks controllable and predictable, may not be.  When the inputs change, all bets are off – the experimental results from one test condition may not be predictive in another, even for the simplest systems, In the cold, unemotional world of physical principles, prediction requires judgement, even in lab conditions.

The domains of business and life are nothing like controlled lab conditions.  And they’re and not governed by physical laws.  These domains are a collection of complex people systems which are governed by emotional laws.  Where physics systems delivers predictable outputs for known inputs, people systems do not.  Scenario 1. Your group’s best performer is overworked, tired, and hasn’t exercised in four weeks.  With no warning you ask them to take on an urgent and important task for the CEO.  Scenario 2. Your group’s best performer has a reasonable workload (and even a little discretionary time), is well rested and maintains a regular exercise schedule, and you ask for the same deliverable in the same way.  The inputs are the same (the urgent request for the CEO), the outputs are far different.

At the level of the individual – the building block level – people systems are complex and adaptive,  The first time you ask a person to do a task, their response is unpredictable.  The next day, when you ask them to do a different task, they adapt their response based on yesterday’s request-response interaction, which results in a thicker layer of unpredictability.  Like pushing on a bag of water, their response is squishy and it’s difficult to capture the nuance of the interaction.  And it’s worse because it takes a while for them to dampen the reactionary waves within them.

One person interacts with another and groups react to other groups.  Push on them and there’s really no telling how things will go.  One cylo competes with another for shared resources and complexity is further confounded.  The culture of a customer smashes against your standard operating procedures and the seismic pressure changes the already unpredictable transfer functions of both companies.  And what about the customer that’s also your competitor?  And what about the big customer you both share?  Can you really predict how things will go? Do you really have control?

What does all this complexity, ambiguity, unpredictability and general lack of control mean when you’re trying to build a culture of accountability?  If people are accountable for executing well, that’s fine.  But if they’re held accountable for the results of those actions, they will fail and your culture of accountability will turn into a culture of avoiding responsibility and finding another place to work.

People know uncertainty is always part of the equation, and they know it results in unpredictability.  And when you demand predictability in a system that’s uncertain by it’s nature, as a  leader you lose credibility and trust.

As we swim together in the storm of complexity, trust is the life boat.  Trust brings people together and makes it easier to row in the same direction.  And after a hard day of mistakenly rowing in the wrong direction, trust helps everyone get back in the boat the next day and pull hard in the new direction you point them.

Image credit – NASA

Innovation starts with different, and when you propose something that’s different from the recipe responsible for success, innovation becomes the enemy of success. And because innovation and different are always joined at the hip, the conflict between success and innovation is always part of the equation. Nothing good can come from pretending the conflict does not exist, and it’s impossible to circumvent. The only way to deal with the conflict is to push through it.

Emotional energy is the forcing function that pushes through conflict, and the only people that can generate it are the people doing the work. As a leader, your job is to create and harness this invisible power, and for that, you need mechanisms.

To start, you must map innovation to “different”.  The first trick is to ask for ideas that are different. Where brainstorming asks for quantity, firmly and formally discredit it and ask for ideas that are different. And the more different, the better. Jeffrey Baumgartner has it right with his Anticonventional Thinking (ACT) methodology where he pushes even further and asks for ideas that are anti-conventional.

The intent is to create emotional energy, and to do that there’s nothing better than telling the innovation team their ideas are far too conventional. When you dismiss their best ideas because they’re not different enough, you provide clear contrast between the ideas they created and the ones you want. And this contrast creates internal conflict between their best thinking and the thinking you want.  This internal conflict generates the magical emotional energy needed to push through the conflict between innovation and success.  In that way, you create intrinsic conflict to overpower the extrinsic conflict.

Because innovation is powered by emotional energy, conflict is the right word.  Yes, it feels too strong and connotes quarrel and combat, but it’s the right word because it captures the much needed energy and intensity around the work. Just as when “opportunity” is used in place of “problem” and the urgency, importance, and emotion of the situation wanes, emotional energy is squandered when other words are used in place of “conflict”.

And it’s also the right word when it comes to solutions. Anti-conventional ideas demand anti-conventional solutions, both of which are powered by emotional energy. In the case of solutions, though, the emotional energy around “conflict” is used to overcome intellectual inertia.

Solving problems won’t get you mind-bending solutions, but breaking conflicts will. The idea is to use mechanisms and language to move from solving problems to breaking conflicts. Solving problems is regular work done as a matter of course and regular work creates regular solutions.  But with innovation, regular solutions won’t cut it.  We need irregular solutions that break from the worn tracks of predictable thinking. And do to this, all convention must be stripped away and all attachments broken to see and think differently.  And, to jolt people out of their comfort zone, contrast must be clearly defined and purposefully amplified.

The best method I know to break intellectual inertia is ARIZ and algorithmic method for innovative solutions built on the foundation of TRIZ.  With ARIZ, a functional model of the system is created using verb-noun pairs with the constraint that no industry jargon can be used. (Jargon links the mind to traditional thinking.) Then, for clarity, the functional model is then reduced to a conflict between two system elements and defined in time and place (the conflict domain.)  The conflict is then made generic to create further distance from the familiar.  From there the conflict is purposefully amplified to create a situation where one of the conflicting elements must be in two states at the same time (conflicting states) – hot and cold; large and small; stiff and flexible.  The conflicting states make it impossible to rely on preexisting solutions (familiar thinking.)  Though this short description of ARIZ doesn’t do it justice, it does make clear ARIZ’s intention – to use conflicts to break intellectual inertia.

Innovation butts heads and creates conflict with almost everything, but it’s not destructive conflict.  Innovation has the best intentions and wants only to create constructive conflict that leads to continued success. Innovation knows your tired business model is almost out of gas and desperately wants to create its replacement, but it knows your successful business model and its tried-and-true thinking are deeply rooted in the organization.  And innovation knows the roots are grounded in emotion and  it’s not about pruning it’s about  emotional uprooting.

Conflict is a powerful word, but the right word.  Use the ACT mechanism to ask for ideas that constructively conflict with your success and use the ARIZ mechanism to ask for solutions that constructively conflict with your best thinking.

With innovation there is always conflict.  You might as well make it constructive conflict and pull your organization into the future kicking and screaming.

Image credit – Kevin Thai

If I was CEO of a company that wanted to do innovation, the one thing I’d strive for is clarity.

For clarity on the innovative new product, here’s what the CEO needs.

Valuable Customer Outcomes – how the new product will be used.  This is done with a one page, hand sketched document that shows the user using the new product in the new way.  The tool of choice is a fat black permanent marker on an 81/2 x 11 sheet of paper in landscape orientation. The fat marker prohibits all but essential details and promotes clarity.  The new features/functions/finish are sketched with a fat red marker.  If it’s red, it’s new; and if you can’t sketch it, you don’t have it. That’s clarity.

The new value proposition – how the product will be sold. The marketing leader creates a one page sales sheet.  If it can’t be sold with one page, there’s nothing worth selling.  And if it can’t be drawn, there’s nothing there.

Customer classification – who will buy and use the new product.  Using a two column table on a single page, these are their attributes to define: Where the customer calls home; their ability to pay; minimum performance threshold; infrastructure gaps; literacy/capability; sustainability concerns; regulatory concerns; culture/tastes.

Market classification – how will it fit in the market.  Using  a four column table on a single page, define: At Whose Expense (AWE) your success will come; why they’ll be angry; what the customer will throw way, recycle or replace; market classification – market share, grow the market, disrupt a market, create a new market.

For clarity on the creative work, here’s what the CEO needs: For each novel concept generated by the Innovation Burst Event (IBE), a single PowerPoint slide with a picture of its thinking prototype and a word description (limited to 12 words).

For clarity on the problems to be solved the CEO needs a one page, image-based definition of the problem, where the problem is shown to occur between only two elements, where the problem’s spacial location is defined, along with when the problem occurs.

For clarity on the viability of the new technology, the CEO needs to see performance data for the functional prototypes, with each performance parameter expressed as a bar graph on a single page along with a hyperlink to the robustness surrogate (test rig), test protocol, and images of the tested hardware.

For clarity on commercialization, the CEO should see the project in three phases – a front, a middle, and end.  The front is defined by a one page project timeline, one page sales sheet, and one page sales goals. The middle is defined by performance data (bar graphs) for the alpha units which are  hyperlinked to test protocols and tested hardware.  For the end it’s the same as the middle, except for beta units, and includes process capability data and capacity readiness.

It’s not easy to put things on one page, but when it’s done well clarity skyrockets.  And with improved clarity the right concepts are created, the right problems are solved, the right data is generated, and the right new product is launched.

And when clarity extends all the way to the CEO, resources are aligned, organizational confusion dissipates, and all elements of innovation work happen more smoothly.

Image credit – Kristina Alexanderson