Shipulski On Design

Posts Tagged ‘Understanding Physics’

We have too many ideas, but too few great ones.  We don’t need more ideas, we need a way to choose the best one or two ideas and run them to ground.

Before creating more ideas, make a list of the ones you already have.  Put them in two boxes.  In Box 1, list the ideas without a video of a functional prototype in action.  In Box 2, list the ideas that have a video showing a functional prototype demonstrating the idea in action.  For those ideas with a functional prototype and no video, put them in Box 1.

Next, throw away Box 1. If it’s not important enough to make a crude physical prototype and create a simple video, the idea isn’t worth a damn.  If someone isn’t willing to carve out the time to make a physical prototype, there’s no emotional energy behind the idea and it should be left to die.  And when people complain that it’s unfair to throw away all those good ideas in Box 1, tell them it’s unfair to spend valuable resources talking about ideas that aren’t worthy.  And suggest, if they want to have a discussion about an idea, they should build a physical prototype and send you the video.  Box 2, or bust.

Next, get the band together and watch the short videos in Box 2, and, as a group, put them in two boxes.  In Box 3, put the videos without customers actively using the functional prototype.  In Box 4, put the videos with customers actively using the functional prototype.

Next, throw way Box 3.  If it’s not important enough to make a trip to an important customer and create a short video, the idea isn’t worth a damn.  If you’re not willing to put yourself out there and take the idea to an important customer, the idea is all fizzle and no sizzle.  Meaningful ideas take immense personal energy to run through the gauntlet, and without a video of a customer using the functional prototype, there’s not enough energy behind it.  And when everyone argues that Box 3 ideas are worth pursuing, tell them to pursue a video showing a most important customer demonstrating the functional prototype.

Next, get the band back together to watch the Box 4 videos.  Again, put the videos in two boxes. In Box 5 put the videos where the customer didn’t say what they liked and how they’d use it.  In Box 6, put the videos where the customer enthusiastically said what they liked and how they’ll use it.

Next, throw away Box 5.  If the customer doesn’t think enough about the prototype to tell you how they’ll use it, it’s because they don’t think much of the idea.  And when the group says the customer is wrong or the customer doesn’t understand what the prototype is all about, suggest they create a video where a customer enthusiastically explains how they’d use it.

Next, get the band back in the room and watch the Box 6 videos.  Put them in two boxes.  In Box 7, put the videos that won’t radically grow the top line.  In Box 8, put the videos that will radically grow the top line.  Throw away Box 7.

For the videos in Box 8, rank them by the amount of top line growth they will create.  Put all the videos back into Box 8, except the video that will create the most top line growth.  Do NOT throw away Box 8.

The video in your hand IS your company’s best idea.  Immediately charter a project to commercialize the idea.  Staff it fully.  Add resources until adding resources doesn’t no longer pulls in the launch.  Only after the project is fully staffed do you put your hand back into Box 8 to select the next best idea.

Continually evaluate Boxes 1 through 8.  Continually throw out the boxes without the right videos.  Continually choose the best idea from Box 8.  And continually staff the projects fully, or don’t start them.

Image credit – joiseyshowaa

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