Shipulski On Design

Archive for the ‘Innovation’ Category

More-with-less is our mantra for innovation. But these three simple words are dangerous because they push us almost exclusively toward efficiency. On the surface, efficiency innovations sound good, and they can be, but more often than not efficiency innovations are about less and fewer. When you create a new technology that does more and costs less the cost reduction comes from fewer hours by fewer people. And if the cash created by the efficiency finances more efficiency, there are fewer jobs. When you create an innovative process that enables a move from machining to forming, hard tooling and molding machines reduce cost by reducing labor hours. And if the profits fund more efficiency, there are fewer jobs. When you create an innovative new material that does things better and costs less, the reduced costs come from fewer labor hours to process the material. And if more efficiency is funded, there are less people with jobs. (The cost reduction could also come from lower cost natural resources, but their costs are low partly because digging them up is done with fewer labor hours, or more efficiently.)

But more-with-less and the resulting efficiency improvements are helpful when their profits are used to fund disruptive innovation. With disruptive innovation the keywords are still less and fewer, but instead of less cost, the product’s output is less; and instead of fewer labor hours, the product does fewer things and satisfies fewer people.

It takes courage to run innovation projects that create products that do less, but that’s what has to happen. When disruptive technologies are young they don’t perform as well as established technologies, but they come with hidden benefits that ultimatley spawn new markets, and that’s what makes them special. But in order to see these translucent benefits you must have confidence in yourself, openness, and a deep personal desire to make a difference. But that’s not enough because disruptive innovations threaten the very thing that made you successful – the products you sell today and the people that made it happen. And that gets to the fundamental difference between efficiency innovations and disruptive innovations.

Efficiency innovations are about doing the familiar in a better way – same basic stuff, similar product functionality, and sold the same way to the same people. Disruptive innovations are about doing less than before, doing it with a less favorable cost signature, and doing it for different (and far fewer) people. Where efficiency innovation is familiar, disruptive innovation is contradictory. And this difference sets the the pace of the two innovations. Where efficiency innovation is governed by the speed of the technology, disruptive innovation is governed by the speed of people.

With efficiency innovations, when the technology is ready it jumps into the product and the product jumps into the market. With disruptive innovations, when the technology is ready it goes nowhere because people don’t think it’s ready – it doesn’t do enough. With efficiency innovations, the new technology serves existing customers so it launches; with disruptive, technology readiness is insufficient because people see no existing market and no existing customers so they make it languish in the corner. With efficiency, it launches when ready because margins are better than before; with disruptive, it’s blocked because people don’t see how the new technology will ultimately mature to overtake and replace the tired mainstream products (or maybe because they do.)

Done poorly efficiency innovation is a race to the bottom; done well it funds disruptive innovation and the race to the top. When coordinated the two play together nicely, but they are altogether different. One is about doing the familiar in a more efficient way, and the other is about disrupting and displacing the very thing (and people) that made you successful.

Most importantly, efficiency innovation moves at the speed of technology while disruptive innovation moves at the speed of people.

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.

Own your ideas, not the drama.

Own your words, not the gossip.

Own your vision, not the dogma.

Own your effort, not the heckling.

Own your vacation, not the email.

Own your behavior, not the strife.

Own your talent, not the cynicism.

Own your deeds, not the rhetoric.

Own your caring, not the criticism.

Own your sincerity, not the hot air.

Own your actions, not the response.

Own your insights, not the rejection.

Own your originality, not the critique.

Own your passion, not the nay saying.

Own your loneliness, not the back story.

Own your health, not the irrational workload.

Own your thinking, not the misunderstanding.

Own your stress level, not the arbitrary due date.

Own your happiness.

Everything is about speed – speed through process reengineering, waste elimination, standardization, modularity, design reuse. All valid, but not all that powerful. Real speed comes from avoiding rapid progress in the wrong direction, from avoiding a blistering pace on the wrong stuff. Real speed comes from saying no to the work that creates drag in order to say yes to work that accelerates.

It’s healthy to have time limits and due dates, finite resources, and budgets. These constraints are helpful because they force a cutoff decision: what work will get done and what won’t. And thankfully, all businesses have them – take them away and eliminate all hope of profitability and sustainability. But from a speed perspective, sometime we look at them in a backward way.

Yes, that work would change the game, but we don’t have time. That argument is a little misleading. Truth is, there’s the same amount of time as last year – a week is still a week, and there are still 52 of them in a year. It’s not about time; it’s about the work done during that time. With a backwards view, the constraint calls attention to work won’t get done, but the constraint is really about work that will get done. If the work that doesn’t make the cut is less magical than the work that does, the constraint creates a speed problem – too slow on the game-changing work. The speed problem is realized when the new kid on the block makes magic and you don’t. If the constraint helps say yes to magic and no to lesser work, there’s no speed problem.

Yes, we could reinvent the industry, but we don’t have resources. No, we have resources. But the constraint isn’t really about resources, it’s about the work. And not any old work, the constraint is about the work that will get done. (Not the work that won’t.) If the constraint causes us to stuff our fingers in the holes in the dyke at the expense of eliminating it altogether, the constraint caused a speed problem. It’s a problem because while we’re plugging holes, an eager competitor will dismantle the need for the dyke. Speed problem.

Sure, we’d leapfrog the competition, but we don’t have the budget. No, we have a budget. But, like the other constraints, the budgetary one is also about the work that will get done. If the constraint prioritizes same-as-last-time over crazy, it creates a speed problem. New competitors who don’t have to protect the old guard products will work on crazy and bring it to market. And that’s a problem because you’ll have more of what you’ve always had and they’ll have crazy.

Yes, in all cases, choose the bigger bet. Choose crazy over sane, magical over mundane, and irregular over regular. And choose that way because it’s faster. And here’s why faster is king: The number of countries with a well educated work force is growing; there’s an ever increasing number of micro companies who can afford to bet on disruptive technologies; and the internet has shown the world how their lives could be and created several billion people who will use their parental fortitude to do whatever it takes to make life better for their kids. (And there’s no stronger force on earth.) And it all sums to an incredible amount of emotional energy relentlessly pushing the pace.

The world isn’t just getting faster, it’s accelerating – yes, next month will be faster than this month, but that’s not the real trick with acceleration. With acceleration the faster things get, the faster they get faster. Is there really any question how to use your constraints?

There are countless books, tools, processes, methodologies and frameworks for innovation.

And cutting across all theory and practice, the biggest fundamental of innovation is fear.

We define fear as bad because it limits new thinking and new actions, but there’s another way to look at it. We should look at fear as a leading indicator of innovation potential.

When inputs, outputs, or contexts are different than expectations, our bodies create physical symptoms we recognize as fear.  It’s this chemical change in the body, manifested as cold sweats, tingling hands, difficulty in breathing, or knotted stomachs, that’s the tell-tale sign innovation is in the house.

If things are predictable, knowable, understandable, there is no fear.  And if things are predictable, knowable, understandable there is no innovation.  By the associative theorem: no fear, no innovation.

We should learn to use our bodies as innovation barometers.  When pressure builds, especially when we don’t know why, we should recognize our fear, not as a blocker of innovation, but as a leading indicator of it.

Innovation, especially the type that reinvents, is not an in-the-head thing, it’s an in-the-chest thing.  It’s indescribable, un-scriptable, and almost spiritual. Just as migratory birds sense weak magnetic fields to guide themselves home, we can use our bodies to sense fear and guide ourselves along the flux lines of innovation.

Fear is scary and can be uncomfortable.  But for innovation, it’s scarier if there’s no fear.

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.

The system is big and complex and its output is outside your control. Trying to control these outputs is a depressing proposition, yet we’re routinely judged (and judge ourselves) on outputs.  I think it’s better to focus on system inputs, specifically your inputs to the system.

When the system responds with outputs different than desired, don’t get upset. It’s nothing personal. The system is just doing its job. It digests a smorgasbord of inputs from many agents just like you and does what it does. Certainly it’s alive, but it doesn’t know you. And certainly it doesn’t respond differently because you’re the one providing input. The system doesn’t take its output personally, and neither should you.

When the system’s output is not helpful, instead of feeling badly about yourself, shift your focus from system output to the input you provide it. (Remember, that’s all you have control over.) Did you do what you said you’d do? Were you generous? We’re you thoughtful? We’re you insightful? Did you give it your all or did you hold back? If you’re happy with the answers you should feel happy with yourself. Your input, your behavior, was just as it was supposed to be.  Now is a good time to fall back on the insightful grade school mantra, “You get what you get, and you don’t get upset.”

If your input was not what you wanted, then it’s time to look inside and ask yourself why. At times like these it’s easy to blame others and outside factors for our behavior. But at times like these  we must own the input, we must own the behavior. Now, owning the behavior doesn’t mean we’ll behave the same way going forward, it just means we own it. In order to improve our future inputs we’ve got to understand why we behaved as we did, and the first step to better future inputs is owning our past behavior.

Now, replace “system” with “person”, and the argument is the same. You are responsible for your input to the person, and they are responsible for their output (their response). When someone’s output is nonlinear and offensive, you’re not responsible for it, they are. Were you kind? Thoughtful? Insightful? If yes, you get what you get, and you don’t get upset. But what if you weren’t? Shouldn’t you feel responsible for their response? In a word, no. You should feel badly about your input – your behavior – and you should apologize. But their output is about them. They, like the system, responded the way they chose. If you want to be critical, be critical of your behavior. Look deeply at why you behaved as you did, and decide how you want to change it. Taking responsibility for their response gets in the way of taking responsibility for your behavior.

With complex systems, by definition it’s impossible to predict their output. (That’s why they’re called complex.) And the only way to understand them is to perturb them with your input and look for patterns in their responses. What that means is your inputs are well intended and ill informed. This is an especially challenging situation for those of us that have been conditioned (or born with the condition) to mis-take responsibility for system outputs. Taking responsibility for unpredictable system outputs is guaranteed frustration and loss of self-esteem. And it’s guaranteed to reduce the quality of your input over time.

When working with new systems in new ways, it’s especially important to take responsibility for your inputs at the expense of taking responsibility for unknowable system outputs. With innovation, we must spend a little and learn a lot. We must figure out how to perturb the system with our inputs and intelligently sift its outputs for patterns of understanding. The only way to do it is to fearlessly take responsibility for our inputs and fearless let the system take responsibility for its output.

We must courageously engineer and own our behavioral plan of attack, and modify it as we learn. And we must learn to let the system be responsible for its own behavior.

They say job satisfaction is important for productivity and quality. The thinking goes something like this: A happy worker is a productive one, and a satisfied worker does good work. This may be true, but it’s not always the best way.

I think we may be better served by a therapeutic dose of job dissatisfaction. Though there are many strains of job satisfaction, the most beneficial one spawns from a healthy dissatisfaction with our success. The tell-tale symptom of dissatisfaction is loneliness, and the invasive bacterium is misunderstanding. When the disease is progressing well, people feel lonely because they’re misunderstood.

Recycled ideas are well understood; company dogma is well understood; ideas that have created success are well understood. In order to be misunderstood, there must be new ideas, ideas that are different. Different ideas don’t fit existing diagnoses and create misunderstanding which festers into loneliness. In contrast, when groupthink is the disease there is no loneliness because there are no new ideas.

For those that believe last year’s ideas are good enough, different ideas are not to be celebrated. But for those that believe otherwise, new ideas are vital, different is to be celebrated, and loneliness is an important precursor to innovation.

Yes, new ideas can grow misunderstanding, but misunderstanding on its own cannot grow loneliness. Loneliness is fueled by caring, and without it the helpful strain of loneliness cannot grow. Caring for a better future, caring for company longevity, caring for a better way – each can create the conditions for loneliness to grow.

When loneliness is the symptom, the prognosis is good. The loneliness means the organization has new ideas; it means the ideas are so good people are willing to endure personal suffering to make them a reality; and, most importantly, it means people care deeply about the company and its long term success.

I urge you to keep your eye out for the markers that define the helpful strain of loneliness. And when you spot it, I hope you will care enough to dig in a little. I urge you think of this loneliness as the genes of a potentially game-changing idea.  When ideas are powerful enough to grow loneliness, they’re powerful enough to move from evolutionary into revolutionary.

How long will it take? The short answer – same as last time. How long do we want it to take? That’s a different question altogether.

If the last project took a year, so will the next one. Even if you want it to take six months, it will take a year. Unless, there’s a good reason it will be different. (And no, the simple fact you want it to take six months is not a good enough reason in itself.)

Some good reasons it will take longer than last time: more work, more newness, less reuse, more risk, and fewer resources. Some good reasons why it will go faster: less work, less newness, more reuse, less risk, more resources. Seems pretty tight and buttoned-up, but things aren’t that straight forward.

With resources, the core resources are usually under control.  It’s the shared resources that are the problem. With resources under their control (core resources) project teams typically do a good job – assign dedicated resources and get out of the way. Shared resources are named that way because they support multiple projects, and this is the problem. Shared resources create coupling among projects, and when one project runs long, resource backlogs ripple through the other projects. And it gets worse. The projects backlogged by the initial ripple splash back and reflect ripples back at each other. Understand the shared resources, and you understand a fundamental dynamic of all your projects.

Plain and simple – work content governs project timelines. And going forward I propose we never again ask “How long will it take?” and instead ask “How is the work content different than last time?” To estimate how long it will take, set up a short face-to-face meeting with the person who did it last time, and ask them how long it will take. Write it down, because that’s the best estimate of how long it will take.

It may be the best estimate, but it may not be a good one. The problem is uncertainty around newness. Two important questions to calibrate uncertainty: 1) How big of a stretch are you asking for? and 2) How much do you know about how you’ll get there? The first question drives focus, but it’s not always a good predictor of uncertainty.  Even seemingly small stretches can create huge problems. (A project that requires a 0.01% increase in the speed of light will be a long one.) What matters is if you can get there.

To start, use your best judgment to estimate the uncertainty, but as quickly as you can, put together a rude and crude experimental plan to reduce it. As fast as you can execute the experimental plan, and let the test results tell you if you can get there. If you can’t get there on the bench, you can’t get there, and you should work on a different project until you can.

The best way to understand how long a project will take is to understand the work content. And the most important work content to understand is the new work content. Choose several of your best people and ask them to run fast and focused experiments around the newness. Then, instead of asking them how long it will take, look at the test results and decide for yourself.

If you want to learn, to really learn, experiment.

But I’m not talking about elaborate experiments; I’m talking about crude ones. Not simple ones, crude ones.

We were taught the best experiments maximize learning, but that’s dead wrong. The best experiments are fast, and the best way to be fast is to minimize the investment.

In the name of speed, don’t maximize learning, minimize the investment.

Let’s get right to it. One of the best tricks to minimize investment is to minimize learning – learning per experiment, that is. Define learning narrowly, design the minimum experiment, and run the trial. Learning per trial is low, but learning per month skyrockets because the number of trials per month skyrockets. But it gets better. There’s an interesting learning exponential at work. The first trial informs the second which shapes the third. But instead of three units of learning, it’s cubic. And minimizing learning doesn’t just half the time to run a trial, it reduces it by 100 or more. It’s earning to the hundredth power.

Another way to minimize investment is to minimize resolution. Don’t think nanometers, think thumbs up, thumbs down. Design the trial so the coarsest measuring stick gives an immediate and unambiguous response. There’s no investment in expensive measurement gear and no time invested in interpretation of results. Think sledgehammer to the forehead.

A third way to minimize investment is to evaluate relative differences. The best example is the simple, yet powerful, A-B test . Run two configurations, decide which is better, and run quickly in the direction of goodness.  No need to fret about how much better, just sprint toward it.  The same goes for trial 1 versus trial 2 comparisons. Here’s the tricky algorithm: If trial 2 is better, do more of that.  And the good news applies here too –  the learning exponential is still in play. Better to the hundredth power, in record time.

I don’t care what norms you have to bend or what rules you have to break. If you do one thing, run more trials.

But don’t take my word for it. Dr. Seuss had it right:

And I would run them in a boat!
And I would run them with a goat…
And I will run them in the rain.
And in the dark. And on a train.
And in a car. And in a tree.
They are so good so good you see!