Shipulski On Design

Archive for the ‘Intellectual Intertia’ Category

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

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

When companies want to innovate, there are three things they can change – products, services and business models. Products are usually the first, second and third priorities, services, though they have a tighter connection with customer and are more lasting and powerful, sadly, are fourth priority.  And business models are the superset and the most powerful of all, yet, as a source of innovation, are largely off limits.

It’s easy to improve products. Measure goodness using a standard test protocol, figure out what drives performance and improve it. Create the hard data, quantify the incremental performance and sell the difference.  A straightforward method to sell more – if you liked the last one, you’re going to like this one. But this is fleeting. Just as you are reverse engineering the competitors’ products, they’re doing it to you. Any incremental difference will be swallowed up by their next product. The half-life of your advantage is measured in months.

It’s easy for companies to run innovation projects to improve product performance because it’s easy to quantify the improvement and because we think customers are transactional. Truth is, customers are emotional, not rational. People don’t buy performance, they buy the story they create for themselves.

Innovating on services is more difficult because, unlike a product, it’s not a physical thing. You can’t touch it, smell it or taste it.  Some say you can measure a service, but you can’t. You can measure its footprints in the sand, but you can’t measure it directly. All the click data in the world won’t get you there because clicks, as measured, don’t capture intent – an unintentional click on the wrong image counts the same a premeditated click on the right one. Sure, you can count clicks, but if you can’t count the why’s, you don’t have causation. And, sure, you can measure customer satisfaction with an online survey, but the closest you can get is correlation and that’s not good enough.  It’s causation or bust.  You’ve got to figure out WHY they like your services. (Hint – it’s the people who interface directly with your customers and the latitude you give them to advocate on the customers’ behalf.)

Where services are difficult to innovate, the business model is almost impossible. No one is quite sure what the business model actually is an in-the-trenches-way, but they know it’s been responsible for the success of the company, and they don’t want to change it. Ultimately, if you want to innovate on the business model, you’ve got to know what it is, but before you spend the time and energy to define it, it’s best to figure out if it needs changing.  The question – what does it look like when the business model is out of gas?

If you do what you did last time and you get less in return, the business model is out of gas.

Successful models are limiting. Just like with the Prime Directive, where Captain Kirk could do anything he wanted as long as he didn’t interfere with the internal development of alien civilizations, do anything you want with the business model as long as you don’t change it. And that’s why you need external help to formally define the business model and experiment with it. The resource should understand your business first hand, yet be outside the chain of command so they can say the sacrilegious things that violate the Prime Directive without being fired.  For good candidates, look to trusted customers and suppliers.

To define the business model, use a simple block diagram (one page) where blocks are labelled with simple nouns and arrows are labelled with simple verbs. Start with a single block on the right of the page labelled “Customer” and draw a single arrow pointing to the block and label it.  Continue until you’ve defined the business model.  (Note – maximum number of blocks is 12.)  You’ll be surprised with the difficulty of the process.

After there’s consensus on the business model, the next step is to figure out how the environment changed around it and to identify and test the preferred evolutionary paths. But that’s for another time.

Image credit – Steven Depolo

If you can’t imagine it, it can’t be done.

But if it can’t be done, how can you imagine it?

No one is buying a product like the one you imagined. There’s no market.

No one can buy an imaginative product that doesn’t yet exist. There may be a market.

Imagine things are good, just as they are.

Imagine an upstart competitor will obsolete your best product.

Let’s fix what is.

Let’s imagine what isn’t, and build it.

Don’t waste time imagining radical new concepts. There’s no way to get there.

Use your imagination to create an unobtainable concept, then build a bridge to get there.

Imagine the future profits of our great recipe. Let’s replicate it.

Imagine our recipe has a half-life. Let’s disrupt it.

To be competitive, we’ve got to use our imagination to reduce the cost of our products.

To be competitive, we’ve got to use our imagination to obsolete our best work.

Put together a specification, a detailed Gannt chart and make it happen on time.

Imagine what could be, and make a prototype.

Let’s shore up our weaknesses and live to fight another day.

Let’s imagine our strength as a weakness and invent the future.

We are the best in the industry. Imagine how tough it is to be our competitor.

Imagine there’s a hungry start-up who will do whatever it takes to get the business.

We’ve got to protect our market share.

Imagine what we could create if we weren’t constrained by our success.

Imagine how productive we will be when we standardize the work.

Imagine how much fun we will have when we reinvent the industry.

Ask the customer what they want, built it and launch it.

Imagine what could be, build a prototype, show the customer, listen and refine.

Let’s follow the script. Imagine the profits.

Let’s burn the script and imagine a new one.

Image credit — Allegra Ricci

Ideas are all talk and no action.  Ideas are untested concepts that have yet to rise to the level of practicality.  You can’t sell an idea and you can’t barter with them. Ideas aren’t worth much.

A prototype is a physical manifestation of an idea. Where ideas are ethereal, prototypes are practical. Where ideas are fuzzy and subject to interpretation, prototypes are a sledge hammer right between the eyes.  There is no arguing with a prototype. It does what it does and that’s the end of that. You don’t have to like what a prototype stands for, but you can’t dismiss it. Where ideas aren’t worth a damn, prototypes are wholly worth every ounce of effort to create them.

If Camp A says it will work and Camp B says it won’t, a prototype will settle the disagreement pretty quickly.  It will work or it won’t.  And if it works, the idea behind it is valid.  And if it doesn’t, the idea may be valid, but a workable solution is yet-to-be discovered.  Either way, a prototype brings clarity.

Prototypes are not elegant.  Prototypes are ugly. The best ones do one thing – demonstrate the novel idea that underpins them. The good ones are simple, and the best ones are diabolically simple. It is difficult to make diabolically simple prototypes (DSPs), but it’s a skill that can be learned.  And it’s worth learning because DSPs come to life in record time. The approach with DSPs is to take the time up front to distill the concept down to its essence and then its all-hands-on-deck until it’s up and running in the lab.

But the real power of the DSP is that it drives rapid learning.  When a new idea comes, it’s only a partially formed.  The process of trying to make a DSP demands the holes are filled and blurry parts are brought into focus.  The DSP process demands a half-baked idea matures into fully-baked physical embodiment.  And it’s full-body learning.  Your hands learn, your eyes learn and your torso learns.

If you find yourself in a disagreement of ideas, stop talking and start making a prototype. If the DSP works, the disagreement is over.

Diabolically simple prototypes end arguments. But, more importantly, they radically increase the pace of learning.

Image credit – snippets101

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

All the scary words are grounded in change.  Innovation, by definition, is about change.  When something is innovative it’s novel, useful and successful.  Novel is another word for different and different means change.  That’s why innovation is scary.  And that’s why radical innovation is scarier.

Continuous improvement, where everything old is buffed and polished into something new, is about change.  When people have followed the same process for fifteen years and then it’s improved, people get scared.  In their minds improved isn’t improved, improved is different.  And different means change.  Continuous improvement is especially scary because it makes processes more productive and frees up people to do other things, unless, of course, there are no other things to do.  And when that happens their jobs go away.  Every continuous improvement expert knows when the first person loses their job due to process improvement the program is dead in the saddle, yet it happens.  And that’s scary on a number of fronts.

And then there’s disruption. While there’s disagreement on what it actually is, there is vicious agreement that after a disruption the campus will be unrecognizable. And unrecognizable things are unrecognizable because they are different from previous experience. And different means change.  With mortal innovation there are some limits, but with disruption everything is fair game. With disruption everything can change, including the venerable, yet decrepit, business model.  With self-disruption, the very thing responsible for success is made to go away by the people that that built it.  And that’s scary. And when a company is disrupted from the outside it can die. And, thankfully, that’s scary.

But change isn’t scary.  Thinking about change is scary.

There’s one condition where change is guaranteed – when the pain of the current situation is stronger than the fear of changing it.  One source of pain could be from a realization the ship will run aground if a new course isn’t taken.  When pain of the immanent shipwreck (caused by fear) overpowers the fear of uncharted waters, the captain readily pulls hard to starboard. And when the crew realizes it’s sink or swim, they swim.

Change doesn’t happen before it’s time. And before things get bad enough, it’s not time.

When the cruise ship is chugging along in fair seas, change won’t happen. Right before the fuel runs out and the generators quit, it’s all you can eat and margaritas for everyone.  And right after, when the air conditioning kicks out and the ice cream melts, it’s bedlam.  But bedlam is not the best way to go.  No sense waiting until the fuel’s gone to make change. Maybe someone should keep an eye the fuel gauge and let the captain know when there’s only a quarter tank.  That way there’s some time to point the ship toward the closest port.

There’s no reason to wait for a mutiny to turn the ship, but sometimes an almost mutiny is just the thing.

As a captain, it’s difficult to let things get worse so they can get better. But if there’s insufficient emotional energy to power change, things must get worse.  The best captains run close to the reef and scrape the hull.  The buffet tables shimmy, the smoked salmon fouls the deck and the liquor bottles rattle.  And when done well, there’s a deep groan from the bowels of the ship that makes it clear this is no drill.  And if there’s a loud call for all hands on deck and a cry for bilge pumps at the ready, all the better.

To pull hard in a new direction, sometimes the crew needs help to see things as they are, not as they were.

Image credit – Francis Bijl

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

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

There are countless books and articles on innovation.  You can read how others have done it, what worked and what didn’t, how best to organize the company and how to define it.  But I have not read much about how it feels to do innovation.

Before anything meaningful can happen, there must be discontent or anger.  And for that there needs to be a realization that doing things like last time is a bad idea.   This realization is the natural outcome of looking deeply at how things really are and testing the assumptions of the status quo.  And the best way to set all this in motion is to do things that generate immense boredom.

Boredom can be created in two ways.  1. Doing the same boring work in the same boring way.  2. Stopping all activity for 30 minutes a day and swimming in the sea of your boring thoughts.  Both work well, but the second one works faster.

Next, with your discontent in hand, it’s time birth the right question.  Some think this the time for answers, but with innovation the real work is to figure out the question.  The discomfort of trying to discover the right question is seven times more uncomfortable the discomfort of figuring out the right answer.  And once you have the right question, the organization rejects you as a heretic. If the organization doesn’t dismiss you in a visceral way, you know you don’t have the right question.  You will feel afraid, but repeat the cycle until your question threatens the very thing that has made the company successful.   When people treat you like you threaten them, you know you’re on to something.

To answer your question, you need help from the organization, but the organization withholds them from you.  If you are ignored, blocked or discredited, you’re on the right path.  Break the rules, disregard best practices, and partner with an old friend who trusts you.  Together, rally against the organization and do the work to answer your question.  If you feel isolated, keep going.  You will feel afraid and you will second guess yourself.  Proceed to the next step.

Make a prototype that shows the organization that your question has an answer.  Don’t ask, just build.  Show the prototype to three people and prepare for rejection.  You and your prototype will be misunderstood and devalued.  Not to worry, as this is a good sign.  Revise the prototype and repeat.

Do anything you can to show the prototype to a customer.  Video the customer as they interact with the prototype.  You will feel afraid because you are breaking the rules.  This is how you should feel.  Keep going.

Set up a meeting with a leader who can allocate resources.  If you have to, set up the meeting under false pretenses (the organization is still in rejection mode) and show the video.  Because of the uncertainty of their response, you will feel afraid.  Show the video anyway.

The organization is comfortable working in the domains of certainty and control, but innovation is done in the domain of uncertainty.  By definition, the organization will reject your novel work.  If you are rejected, keep going.  Revise your heretical question, build a prototype to answer it, show a customer, show someone who can allocate resources, and be afraid all along the way.  And repeat, as needed.

With innovation, mostly you feel afraid.

Image credit – Tybo