Shipulski On Design

Posts Tagged ‘Understanding Physics’

Much like living organisms continually evolve to secure their place in the future, technological systems can be thought to display similar evolutionary behavior.  Viruses mutate so some of them can defeat the countermeasures of their host and live to fight another day. Technological systems, as an expression of a company’s desire to survive, evolve to defeat the competition and live to pay another dividend.

There are natural limits to evolutionary success in any single direction.  When one trait is improved it pushes on the natural limits imposed by the environment.  For example, a bacterium let loose in a friendly Petri dish will replicate until it eats all the food in the dish. Or, on a longer timescale, if the mass of a bird increases over generations when its food source is plentiful, the bird will get larger but will also get less agile. The predators who couldn’t catch the fast, little bird of old can easily catch and eat the sluggish heavyweight. In that way, there’s an edge condition created by the environmental Petri dishes and predators.  And it’s the same with technological systems.

Companies and their technological systems evolve within their competitive environment by scanning the fitness landscape and deciding where to try to improve.  The idea is to see preferential lines of improvement and create new technologies to take advantage of them.  Like their smaller biological counterparts, companies are minimum energy creatures and want to maximize reward (profit) with minimum effort (expense) and will continue to leverage successful lines of evolution until it senses diminishing returns.

The diminishing returns are a warning sign that the company is approaching an edge condition (a Petri dish of a finite size). In landscape lingo, there’s a cliff on the horizon. In technology lingo, the rate of improvement of the technology is slowing.  In either language, the edge is near and it’s time to evolve in a new direction because this current one is out of gas.

Like the bird whose mass increases over the generations when food is readily available, companies also get fat and slow when they successfully evolve in a single direction for too long.  And like the bird, they get eaten by a more agile competitor/predator. And just as the replication rate of the bacterium accelerates as the food in the Petri dish approaches zero, a company that doesn’t react to a slowing rate of technological improvement is sure to outlive its business model.

Biology and technology are similar in that they try new things (create variants of themselves) in order to live another day.  But there’s a big difference – where biology is blind (it doesn’t know what will work and what won’t), technology is sighted (people that create use their understanding to choose the variants they think will work best).  And another difference is that biological evolution can build only on viable variants where technology can use mental models as scaffolds to skip non-viable embodiments to cross a chasm.

There’s no need to fall off the cliff.  As a leading indicator, monitor the rate of improvement of your technology.  If its rate of improvement is still accelerating, it’s time to develop the next line of evolution. If its rate is declining, you waited too long. It’s time to double down on two new lines of evolution because you’re behind the curve. And remember, like with the population of bacteria in the Petri dish, sales will keep growing right up until the business model runs out of food or a competitor eats you.

Image credit — Amanda

When it’s time to create something new, most people try to imagine the future and then put a plan together to make it happen.  There’s lots of talk about the idealize future state, cries for a clean slate design or an edict for a greenfield solution.  Truth is, that’s a recipe for disaster. Truth is, there is no such thing as a clean slate or green field. And because there are an infinite number of future states, it’s highly improbable your idealized future state is the one the universe will choose to make real.

To create something new, don’t look to the future. Instead, sit in the present and understand the system as it is. Define the major elements and what they do.  Define connections among the elements.  Create a functional diagram using blocks for the major elements, using a noun to name each block, and use arrows to define the interactions between the elements, using a verb to label each arrow. This sounds like a complete waste of time because it’s assumed that everyone knows how the current state system behaves.  The system has been the backbone of our success, of course everyone knows the inputs, the outputs, who does what and why they do it.

I have created countless functional models of as-is systems and never has everyone agreed on how it works.  More strongly, most of the time the group of experts can’t even create a complete model of the as-is system without doing some digging. And even after three iterations of the model, some think it’s complete, some think it’s incomplete and others think it’s wrong. And, sometimes, the team must run experiments to determine how things work.  How can you imagine an idealized future state when you don’t understand the system as it is?  The short answer – you can’t.

And once there’s a common understanding of the system as it is, if there’s a call for a clean sheet design, run away.  A call for a clean sheet design is sure fire sign that company leadership doesn’t know what they’re doing.  When creating something new it’s best to inject the minimum level of novelty and reuse the rest (of the system as it is).  If you can get away with 1% novelty and 99% reuse, do it.  Novelty, by definition, hasn’t been done before. And things that have never been done before don’t happen quickly, if they happen at all. There’s no extra credit for maximizing novelty. Think of novelty like ghost pepper sauce – a little goes a long way.  If you want to know how to handle novelty, imagine a clean sheet design and do the opposite.

Greenfield designs should be avoided like the plague. The existing system has coevolved with its end users so that the system satisfies the right needs, the users know how to use the system and they know what to expect from it.  In a hand-in-glove way, the as-is system is comfortable for end users because it fits them.  And that’s a big deal.  Any deviation from baseline design (novelty) will create discomfort and stress for end users, even if that novelty is responsible for the enhancement you’re trying to deliver.  Novelty violates customer expectations and violating customer expectations is a dangerous game. Again, when you think novelty, think ghost peppers. If you want to know how to handle novelty, imagine a green field and do the opposite.

This approach is not incrementalism.  Where you need novelty, inject it.  And where you don’t need it, reuse. Design the system to maximize new value but do it with minimum novelty.  Or, better still, offer less with far less. Think 90% of the value with 10% of the cost.

Image credit – Laurie Rantala

If you don’t have a problem, you’ve got a big problem.

It’s important to know where a problem happens, but also when it happens.

Solutions are 90% defining and the other half is solving.

To solve a problem, you’ve got to understand things as they are.

Before you start solving a new problem, solve the one you have now.

It’s good to solve your problems, but it’s better to solve you customers’ problems.

Opportunities are problems in sheep’s clothing.

There’s nothing worse than solving the wrong problem – all the cost with none of the solution.

When you’re stumped by a problem, make it worse then do the opposite.

With problem definition, error on the side of clarity.

All problems are business problems, unless you care about society’s problems.

Odds are, your problem has been solved by someone else.  Your real problem is to find them.

Define your problem as narrowly as possible, but no narrower.

Problems are not a sign of weakness.

Before adding something to solve the problem, try removing something.

If your problem involves more than two things, you have more than one problem.

The problem you think you have is never the problem you actually have.

Problems can be solved before, during or after they happen and the solutions are different.

Start with the biggest problem, otherwise you’re only getting ready to solve the biggest problem.

If you can’t draw a closeup sketch of the problem, you don’t understand it well enough.

If you have an itchy backside and you scratch you head, you still have an itch. And it’s the same with problems.

If innovation is all about problem solving and problem solving is all about problem definition, well, there you have it.

Image credit – peasap

Innovation is all about learning.  And if the objective of innovation is learning, why not start with learning objectives?

Here’s a recipe for learning: define what you want to learn, figure how you want to learn, define what you’ll measure, work the learning plan, define what you learned and repeat.

With innovation, the learning is usually around what customers/users want, what new things (or processes) must be created to satisfy their needs and how to deliver the useful novelty to them.  Seems pretty straightforward, until you realize the three elements interact vigorously.  Customers’ wants change after you show them the new things you created. The constraints around how you can deliver the useful novelty (new product or service) limit the novelty you can create.  And if the customers don’t like the novelty you can create, well, don’t bother delivering it because they won’t buy it.

And that’s why it’s almost impossible to develop a formal innovation process with a firm sequence of operations.  Turns out, in reality the actual process looks more like a fur ball than a flow chart. With incomplete knowledge of the customer, you’ve got to define the target customer, knowing full-well you don’t have it right. And at the same time, and, again, with incomplete knowledge, you’ve got to assume you understand their problems and figure out how to solve them.  And at the same time, you’ve got to understand the limitations of the commercialization engine and decide which parts can be reused and which parts must be blown up and replaced with something new.  All three explore their domains like the proverbial drunken sailor, bumping into lampposts, tripping over curbs and stumbling over each other.  And with each iteration, they become less drunk.

If you create an innovation process that defines all the if-then statements, it’s too complicated to be useful.  And, because the if-thens are rearward-looking, they don’t apply the current project because every innovation project is different. (If it’s the same as last time, it’s not innovation.)  And if you step up the ladder of abstraction and write the process at a high level, the process steps are vague, poorly-defined and less than useful.  What’s a drunken sailor to do?

Define the learning objectives, define the learning plan, define what you’ll measure, execute the learning plan, define what you learned and repeat.

When the objective is learning, start with the learning objectives.

Image credit Jean L.

At first glance, it seems easy to run a good test, but nothing can be further from the truth.

The first step is to define the idea/concept you want to validate or invalidate.  The best way is to complete one of these two sentences: I want to learn that [type your idea here] is true. Or, I want to learn that [enter your idea here] is false.

Next, ask yourself this question: What information do I need to validate (or invalidate) [type your idea here]?  Write down the information you need.  In the engineering domain, this is straightforward: I need the temperature of this, the pressure of that, the force generated on part xyz or the time (in seconds) before the system catches fire.  But for people-related ideas, things aren’t so straightforward. Some things you may want to know are: how much will you pay for this new thing, how many will you buy, on a scale of 1 to 5 how much do you like it?

Now the tough part – how will you judge pass or fail?  What is the maximum acceptable temperature? What is the minimum pressure? What is the maximum force that can be tolerated? How many seconds must the system survive before catching fire?  And for people: What is the minimum price that can support a viable business? How many must they buy before the company can prosper? And if they like it at level 3, it’s a go. And here’s the most importance sentence of the entire post:

The decision criteria must be defined BEFORE running the test.

If you wait to define the go/no-go criteria until after you run the test and review the data, you’ll adjust the decision criteria so you make the decision you wanted to make before running the test. If you’re not going to define the decision criteria before running the test, don’t bother running the test and follow your gut.  Your decision will be a bad one, but at least you’ll save the time and money associated with the test.

And before running the test, define the test protocol.  Think recipe in a cookbook: a pinch of this, a quart of that, mix it together and bake at 350 degrees Fahrenheit for 40 minutes.  The best protocols are simple and clear and result in the same sequence of events regardless of who runs the test.  And make sure the measurement method is part of the protocol – use this thermocouple, use that pressure gauge, use the script to ask the questions about price and the number they’d buy.

And even with all this rigor, good judgement is still part of the equation.  But the judgment is limited to questions like: did we follow the protocol? Did the measurement system function properly? Do the initial assumptions still hold? Did anything change since we defined the learning objective and defined the test protocol?

To create formal learning objectives, to write well-defined test protocols and to formalize the decision criteria before running the test require rigor, discipline, time and money.  But, because the cost of making a bad decision is so high, the cost of running good tests is a bargain at twice the price.

Image credit – NASA Goddard Flight Center

It’s easy to complain about how things are going, especially when they’re not going well. But even with the best intentions, complaining doesn’t move the organization in a new direction.  Sometimes people complain to attract attention to an important issue. Sometimes it’s out of frustration, sometimes out of sadness and sometimes out of fear, but it’s never the best mechanism.

If the intention is to convey importance, why not convey the importance by explaining why it’s important? Why not strip the issue of its charge and use an approach and language that help people understand why it’s important? It’s a simple shift from complaining to explaining, but it can make all the difference. Where complaining distracts, explaining brings people together. And if it’s truly important, why not take the time to have a give-and-take conversation and listen to what others have to say? Instead of listening to respond, why not listen to understand?

If you’re not willing to understand someone else’s position it’s not a conversation.

And if you’re on the receiving end of a complaint, how can you learn to see it as a sign of importance and not as an attack? As the receiver, why not strip it of its charge and ask questions of clarification? Why not deescalate and move things from complaint to conversation? Understanding is not agreeing, but it still a step forward for everyone.

When two sides are divided, complaining doesn’t help, even if it’s well-intentioned. When two sides are divided and there’s strong emotion, the first step is to take responsibility to deescalate. And once emotions are calmed, the next step is to take responsibility to understand the other side.  At this stage, there is no requirement to agree, but there can be no hint of disagreement as it will elevate emotions and set progress back to zero.  It’s a slow process, but when the issues are highly charged, it’s the fastest way to come together.

If you’re dissatisfied with the negativity, demonstrate positivity. If you want to come together, take the first step toward the middle. If you want to generate the trust needed to move things forward, take action that builds trust.

If you want things to be different, look inside.

Image credit – Ireen2005

We live in a resource constrained world where there’s always more work than time.  Resources are always tighter than tight and tough choices must be made. The first choice is to figure out what change you want to make in the world. How do you want put a dent in the universe? What injustice do you want to put to rest? Which paradigm do you want to turn on its head?

In business and in life, the question is the same – How do you want to spend your time?

Before you can move in the right direction, you need a direction. At this stage, the best way to allocate your resources is to define the system as it is. What’s going on right now? What are the fundamentals? What are the incentives? Who has power?  Who benefits when things move left and who loses when things go right?  What are the main elements of the system? How do they interact? What information passes between them? You know you’ve arrived when you have a functional model of the system with all the elements, all the interactions and all the information flows.

With an understanding of how things are, how do you want to spend your time? Do you want to validate your functional model? If yes, allocate your resources to test your model. Run small experiments to validate (or invalidate) your worldview.  If you have sufficient confidence in your model, allocate your resources to define how things could be.  How do you want the fundamentals to change? What are the new incentives? Who do you want to have the power? And what are the new system elements, their new interactions and new information flows?

When working in the domain of ‘what could be’ the only thing to worry about is what’s next. What’s after the next step?  Not sure. How many resources will be required to reach the finish line? Don’t know. What do we do after the next step? It depends on how it goes with this step. For those that are used to working within an efficiency framework this phase is a challenge, as there can be no grand plan, no way to predict when more resources will be needed and no way to guarantee resources will work efficiently. For the ‘what could be’ phase, it’s better to use a framework of effectiveness.

In a one-foot-in-front-of-the-other way, the only thing that matters in the ‘what could be’ domain is effectively achieving the next learning objective. It’s not important that the learning is done most efficiently, it matters that the learning is done well and done quickly.  Efficiently learning the wrong thing is not effective. Running experiments efficiently without learning what you need to is not effective. And learning slowly but efficiently is not effective.

Allocate resources to learn what needs to be learned. Allocate resources to learn effectively, not efficiently. Allocate your best people and give them the time they need.  And don’t expect an efficient path. There will be unplanned lefts and rights. There will be U-turns. There will times when there’s lots of thinking and little activity, but at this stage activity isn’t progress, thinking is. It may look like a drunkard’s walk, but that’s how it goes with this work.

When the objective of the work isn’t to solve the problem but to come up with the right question, allocate resources in a way that prioritizes effectiveness over efficiency. When working in the domain of ‘what could be’ allocate resources on the learning objective at hand. Don’t worry too much about the follow-on learning objectives because you may never earn the right to take them on.

In the domain of uncertainty, the best way to allocate the resources is to learn what you need to learn and then figure out what to learn next.

Image credit – John Flannery

It’s not the tools. Innovation is not hampered by a lack of tools (See The Innovator’s Toolkit for 50 great ones.), it’s hampered because people don’t know how to start.  And it’s hampered because people don’t know how to choose the right tool for the job. How to start? It depends. If you have a technology and no market there are a set of tools to learn if there’s a market. Which tool is best? It depends on the context and learning objective. If you have a market and no technology there’s a different set of tools.  Which tool is best?  You guessed it.  It depends on the work. And the antidote for ‘it depends’ is good judgement.

It’s not the process.  There are at least several hundred documented innovation processes. Which one is best? There isn’t a best one – there can be no best practice (or process) for work that hasn’t been done before. So how to choose among the good practices? It depends on the culture, depends on the resources, depends on company strengths. Really, it depends on good judgment exercised by the project leader and the people that do the work.  Seasoned project leaders know the process is different every time because the context and work are different every time. And they do the work differently every time, even as standard work is thrust on them. With new work, good judgement eats standardization for lunch.

It’s not the organizational structure. Innovation is not limited by a lack of novel organizational structures. (For some of the best thinking, see Ralph Ohr’s writing.) For any and all organizational structures, innovation effectiveness is limited by people’s ability to ride the waves and swim against the organizational cross currents. In that way, innovation effectiveness is governed by their organizational good judgement.

Truth is, things have changed. Gone are the rigid, static processes. Gone are the fixed set of tools. Gone are the black-and-white, do-this-then-do-that prescriptive recipes. Going forward, static must become dynamic and rigid must become fluid. One-size-fits-all must evolve into adaptable. But, fortunately, gone are the illusions that the dominant player is too big to fail. And gone are the blinders that blocked us from taking the upstarts seriously.

This blog post was inspired by a recent blog post by Paul Hobcraft, a friend and grounded innovation professional. For a deeper perspective on the ever-increasing complexity and dynamic nature of innovation, his post is worth the read.

After I read Paul’s post, we talked about the import role judgement plays in innovation.  Though good judgement is not usually called out as an important factor that governs innovation effectiveness, we think it’s vitally important. And, as the pressure increases to deliver tangible innovation results, its importance will increase.

Some open questions on judgement: How to help people use their judgement more effectively? How to help them use it sooner? How to judge if someone has the right level of good judgement?

Image credit – Michael Coghlan

Disruption, as a word, doesn’t tell us what to do or how to do it.  Disruption, as a word, it’s not helpful and should be struck from the innovation lexicon.  But without the word, what’s an innovator to do?

If you have a superpower, misuse it. Your brand’s special capability is well known in your industry, but not in others. Thrust your uniqueness into an unsuspecting industry and provide novel value in novel ways. Take it by storm. Contradict the established players. Build momentum quickly and quietly.  Create a step function improvement. Create new lines of customer goodness. Do things that haven’t been done. Turn no to yes.

Don’t adapt your special capability, use it as-is. Adaptation is good, but it’s better to flop the whole thing into the new space.  Don’t think graft, think transplant.  Adaptation brings only continuous improvement.  It’s better to serve up your secret sauce uncut and unfiltered because that brings discontinuous improvement.

Know the needs your product fulfills and meet those needs in another industry.  Some say it’s better to adapt your product to other industries, and to achieve a reasonable CAGR, adaptation is good.  But if you’re looking for an unreasonable CAGR, if you’re looking to stand things on their head, try to use your product as-is. When you can use your product as-is in another industry, you connect dots only you can connect and meet needs in ways only you can.  You bring non-intuitive solutions. You violate routines of accepted practice and your trajectory is not limited by the incumbents’ ruts of success. You’ll have a whole new space for yourself. No sharing required.

But how?

Simply and succinctly, define what your product does.  Then, make it generic and look to misapply the goodness in a different application. For example, manufacturers of large and expensive furniture wrap their products in huge plastic bags to keep the furniture dry and clean during shipping. Generically, the function becomes: use large plastic bags to temporarily protect large and expensive products from becoming wet.  Using that goodness in a new application, people who live in flood areas use the large furniture bags to temporarily protect their cars from water damage.  Just before the flood arrives, they drive their cars into large plastic bags and tie them off.  The bags keep their car dry when the water comes.  Same bag, same goodness, completely unrelated application.

And there’s another way.  Your product has a primary function that provides value to your customers. But, there is unrealized value in your product that your existing customers don’t value. For example, if your company has a proprietary process to paint products in a way that results in a high gloss finish, your customers buy your coating because it looks good. But, the coating may also create a hard layer and increase wear resistance that could be important in another application. Because your coating is environmentally friendly and your process is low-cost, new customers may want you to coat their parts so they can be used in a previously non-viable application.  There is unrealized value in your products that new customers will pay for.

To see the unrealized value, use the strength-as-a-weakness method.  Define two constraints: you must sell to new customers in a new industry and the primary goodness, why people buy your product, must be a weakness.  For example, if your product is fast, you’ve got to use unrealized value to sell a slow one. If it’s heavy, the new one must be light. If small, the new one must be large.  In that way, you are forced to rely on new lines of goodness and unrealized value to sell your product.

Don’t stop continuous improvement and product adaptation.  They’re valuable. But, start some discontinuous improvement, step function increases and purposeful misuse.  Keep selling to the same value to the same customers, but start selling to new customers with previously unrealized value that has been hiding quietly in your product for years.

Evolution is good, but exaptation is probably better.

Image credit – Sor Betto

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Image credit – Kate Ter Haar

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

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

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

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

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

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

Image credit jacinta lluch valero