Shipulski On Design

Posts Tagged ‘Understanding Physics’

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

There are many definitions for creativity and innovation, but none add meaningfully to how the work is done. Though it’s clear why the work is important – creativity and innovation underpin corporate prosperity and longevity – it’s especially helpful to know how to do it.

At the most basic level, creativity and innovation are about problem solving.  But it’s a special flavor of problem solving.  Creativity and innovation are about problems solving new problems in new ways.  The glamorous part is ‘solving in new ways’ and the important part is solving new problems.

With continuous improvement the same problems are solved over and over. Change this to eliminate waste, tweak that to reduce variation, adjust the same old thing to make it work a little better.  Sure, the problems change a bit, but they’re close cousins to the problems to the same old problems from last decade. With discontinuous improvement (which requires high levels of creativity and innovation) new problems are solved.  But how to tell if the problem is new?

Solving new problems starts with seeing problems differently.

Systems are large and complicated, and problems know how to hide in the nooks and crannies. In a Where’s Waldo way, the nugget of the problem buries itself in complication and misuses all the moving parts as distraction. Problems use complication as a cloaking mechanism so they are not seen as problems, but as symptoms.

Telescope to microscope. To see problems differently, zoom in.  Create a hand sketch of the problem at the microscopic level.  Start at the system level if you want, but zoom in until all you see is the problem.  Three rules: 1. Zoom in until there are only two elements on the page. 2. The two elements must touch. 3. The problem must reside between the two elements.

Noun-verb-noun. Think hammer hits nail and hammer hits thumb.  Hitting the nail is the reason people buy hammers and hitting the thumb is the problem.

A problem between two things. The hand sketch of the problem would show the face of the hammer head in contact with the surface of the thumb, and that’s all.  The problem is at the interface between the face of the hammer head and the surface of the thumb. It’s now clear where the problem must be solved. Not where the hand holds the shaft of the hammer, not at the claw, but where the face of the hammer smashes the thumb.

Before-during-after. The problem can be solved before the hammer smashes the thumb, while the hammer smashes the thumb, or after the thumb is smashed.  Which is the best way to solve it? It depends, that’s why it must be solved at the three times.

Advil and ice. Solving the problem after the fact is like repair or cleanup. The thumb has been smashed and repercussions are handled in the most expedient way.

Put something between. Solving the problem while it happens requires a blocking or protecting action. The hammer still hits the thumb, but the protective element takes the beating so the thumb doesn’t.

Hand in pocket. Solving the problem before it happens requires separation in time and space. Before the hammer can smash the thumb it is moved to a safe place – far away from where the hammer hits the nail.

Nail gun. If there’s no way for the thumb to get near the hammer mechanism, there is no problem.

Cordless drill. If there are no nails, there are no hammers and no problem.

Concrete walls. If there’s no need for wood, there’s no need for nails or a hammer. No hammer, no nails, no problem.

Discerning between symptoms and problems can help solve new problems. Seeing problems at the micro level can result in new solutions. Looking closely at problems to separate them time and space can help see problems differently.

Eliminating the tool responsible for the problem can get rid of the problem of a smashed thumb, but it creates another – how to provide the useful action of the driven nail.  But if you’ve been trying to protect thumbs for the last decade, you now have a chance to design a new way to fasten one piece of wood to another, create new walls that don’t use wood, or design structures that self-assemble.

Image credit – Rodger Evans

When it’s time to innovate, the first task is usually to define the Idealized Future State (IFS).  The IFS is a word picture that captures what it looks like when the innovation work has succeeded beyond our wildest dreams. The IFS, so it goes, is directional so we can march toward the right mountain and inspirational so we can sustain our pace over the roughest territory.

For the IFS to be directional, it must be aimed at something – a destination.  But there’s a problem. In a sea of uncertainty, where the work has never been done before and where there are no existing products, services or customers, there are an infinite number of IFRs/destinations to guide our innovation work.  Open question – When the territory is unknown, how do we choose the right IFS?

For the IFS to be inspirational, it must create yearning for something better (the destination). And for the yearning to be real, we must believe the destination is right for us. Open question – How can we yearn for an IFS when we really can’t know it’s the right destination?

Maps aren’t the territory, but they are a collection of all possible destinations within the design space of the map.  If you have the right map, it contains your destination. And for a long time now, the old paper maps have helped people find their destinations. But on their own maps don’t tell us the direction to drive.  If you have a map of the US and you want to drive to Kansas, in which direction do you drive? It depends. If in California, drive east; if in Mississippi, drive north; if in New Hampshire, drive west; and in Minnesota, drive south. If Kansas is your idealized future state, the map alone won’t get your there.  The direction you drive depends on your location.

GPS has been a nice addition to maps. Enter the destination on the map, ask the satellites to position us globally and it’s clear which way to drive. (I drive west to reach Kansas.) But the magic of GPS isn’t in the electronic map, GPS is magic because it solves the location problem.

Before defining the idealized future state, define your location. It grounds the innovation work in the reality of what is, and people can rally around what is. And before setting the innovation direction with the IFS, define the next problems to solve and walk in their direction.

Image credit – Adrian Brady

When a hurricane is on the horizon, we are all glued to our TVs. We want to know where it track so we know we’ll be safe.  Will it track north and rumble over the top of us or will it track east and head out to sea?  This is not trivial. In one scenario we lose our house and in the other the crazy surfers get to ride huge waves.

The meteorologist shows us a time-lapse of the storm center hour-by-hour. It was one hundred miles off shore an hour ago, it’s fifty miles off shore now and it will hit the shoreline in an hour. Drawing a line from where it was, through its location in the moment, the meteorologist can extrapolate where it will be an hour from now.  In the short term, the storms trajectory will be unchanged and its momentum will help it maintain its pace.  It’s pretty clear to everyone where the storm will be in an hour. No magic here.

But the good meteorologists can forecast a hurricane’s path days in advance. In a phenomenological way, they use behavior models of past storms, assume this storm is like past storms, turn the crank and forecast its trajectory. And they’re right more times than not. And they’re right enough to determine who should evacuate and who should sit tight. This is borderline magic.

The best meteorologists know where hurricanes want go because they understand hurricanes. They know hurricanes want to run in straight lines, if not follow gentle curves. They know hurricanes get anxious when they hop from sea to land, and they know, given the choice, will skirt the coastline and head back home to the salt water.  Meteorologists know the rules hurricane’s live by and use that knowledge to tighten their forecast of the storm’s path.

Just as hurricanes have a desire to follow their hearts, technologies have a similar desire climb the evolutionary ladder. Just as hurricanes behave like their predecessors, technologies behave like their grandparents, aunts and uncles. And just as a meteorologist, using their knowledge of  historical patterns and an understanding of hurricane genetics can forecast the path of a hurricane, technologists can forecast the path of technologies using historical patterns and an understanding of what technologies want.

And like with hurricanes, the best way to forecast the path of a technology is to define where it was, draw a line through where it is and project its trajectory into the future.  Like hurricanes, technologies move in straight lines or gentle S-curves, so their next move is easy to forecast. If a technology has improved year-over-year, it will likely continue to improve. And if this year’s performance is the same as last year, it’s behavior will remain unchanged going forward.  That’s how it goes with technologies.

The best technologists are like horse whisperers in that they can hear the inner voice of technologies. They know when a technology is ready to grow from infant to adolescent and know when a technology is ready to retire. The best technologists can read the tea leaves of the patent landscape and, knowing the predisposition of technologies, can forecast the next evolution.  But just as some ranch owners don’t believe in horse whisperers, some company leaders don’t believe technology whisperers can forecast technologies.

But for believers and non-believers alike, it’s more effective to compare forecasting capabilities of technologists with the forecasting capabilities of meteorologists.  The notions of trajectory and momentum have clear physical interpretations for hurricanes and technologies, and historical models of storm trajectories map directly to evolutionary paths of technologies.

If you’re looking to forecast where the next big storm will make landfall, hire a great meteorologist. But if you’re looking to forecast when the next technology will rip the roof off your business model, hire a great technology whisperer.

Image credit – NASA

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.