Shipulski On Design

Archive for the ‘Clarity’ Category

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

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

With innovation, novel solutions pay the bills – a new solution provides new value for the customer and the customer buys it from you.  The trick, however, is to come up with novel solutions.  To improve the rate and quality of novel solutions, there’s usually a focus on new tools, new problem-solving methods and training on both. The idea is get better at moving from problem to solution.  There’s certainly room for improvement in our problem-solving skills, but I think the pot of gold is hidden elsewhere.

Because novel solutions reside in uncharted design space, it follows that novel solutions will occur more frequently if the problem-solvers are pointed toward new design space.  And to make sure they don’t solve in the tired, old design space of success, constraints are used to wall it off.  Rule 1 – point the solvers toward new design space. Rule 2 – wall off the over-planted soil of success.

The best way to guide the problems solvers toward fertile design space is to create different problems for them to solve. And this guide-the-solvers thinking is a key to the success of the IBE (Innovation Burst Event), where Design Challenges are created in a way that forces the solvers from the familiar. And it’s these Design Challenges that ARE the new problems that bring the new solutions.  And to wall off old design space, the Design Challenges use creatively curated constraints to make it abundantly clear that old solutions won’t cut it.

Before improving the back-end problem solving process, why not change the front- end problem selecting process?

Chose to solve different problems, then learn to solve them differently.

Image credit – Rajarshi MITRA

Additive Manufacturing (AM) is technology/product space with ever-increasing performance and an ever-increasing collection of products. There are many different physical principles used to add material and there are a range of part sizes that can be made ranging from micrometers to tens of meters.  And there is an ever-increasing collection of materials that can be deposited from water soluble plastics to exotic metals to specialty ceramics.

But AM tools and technologies don’t deliver value on their own.  In order to deliver value, companies must deploy AM to solve problems and implement solutions.  But where to start? What to do next? And how do you know when you’ve arrived?

To help with your AM journey, below a maturity model for AM.  There are eight categories, each with descriptions of increasing levels of maturity.  To start, baseline your company in the eight categories and then, once positioned, look to the higher levels of maturity for suggestions on how to move forward.

For a more refined calibration, a formal on-site assessment is available as well as a facilitated process to create and deploy an AM build-out plan.  For information on on-site assessment and AM deployment, send me a note at mike@shipulski.com.

Execution

1. Specify AM machine – There a many types of AM machines. Learn to choose the right machine.
2. Justify AM machine – Define the problem to be solved and the benefit of solving it.
3. Budget for AM machine – Find a budget and create a line item.
4. Pay for machine –  Choose the supplier and payment method – buy it, rent to own, credit card.
5. Install machine – Choose location, provide necessary inputs and connectivity
6. Create shapes/add material – Choose the right CAD system for the job, make the parts.
7. Create support/service systems – Administer the job queue, change the consumables, maintenance.
8. Security – Create a system for CAD files and part files to move securely throughout the organization.
9. Standardize – Once the first machines are installed, converge on a small set of standard machines.
10. Teach/Train – Create training material for running AM machine and creating shapes.

Solution

1. Copy/Replace – Download a shape from the web and make a copy or replace a broken part.
2. Adapt/Improve – Add a new feature or function, change color, improve performance.
3. Create/Learn – Create something new, show your team, show your customers.
4. Sell Products/Services – Sell high volume AM-produced products for a profit. (Stretch goal.)

Volume

1. Make one part – Make one part and be done with it.
2. Make five parts – Make a small number of parts and learn support material is a challenge.
3. Make fifty parts – Make more than a handful of parts. Filament runs out, machines clog and jam.
4. Make parts with a complete manufacturing system – This topic deserves a post all its own.

Complexity

1. Make a single piece – Make one part.
2. Make a multi-part assembly – Make multiple parts and fasten them together.
3. Make a building block assembly – Make blocks that join to form an assembly larger than the build area.
4. Consolidate – Redesign an assembly to consolidate multiple parts into fewer.
5. Simplify – Redesign the consolidated assembly to eliminate features and simplify it.

Material

1. Plastic – Low temperature plastic, multicolor plastics, high performance plastics.
2. Metal – Low melting temperature with low conductivity, higher melting temps, higher conductivity
3. Ceramics – common materials with standard binders, crazy materials with crazy binders.
4. Hybrid – multiple types of plastics in a single part, multiple metals in one part, custom metal alloy.
5. Incompatible materials – Think oil and water.

Scale

1. 50 mm – Not too large and not too small. Fits the build area of medium-sized machine.
2. 500 mm – Larger than the build area of medium-sized machine.
3. 5 m – Requires a large machine or joining multiple parts in a building block way.
4. 0.5 mm – Tiny parts, tiny machines, superior motion control and material control.

Organizational Breadth

1. Individuals – Early adopters operate in isolation.
2. Teams – Teams of early adopters gang together and spread the word.
3. Functions – Functional groups band together to advance their trade.
4. Supply Chain – Suppliers and customers work together to solve joint problems.
5. Business Units – Whole business units spread AM throughout the body of their work.
6. Company – Whole company adopts AM and deploys it broadly.

Strategic Importance

1. Novelty – Early adopters think it’s cool and learn what AM can do.
2. Point Solution – AM solves an important problem.
3. Speed – AM speeds up the work.
4. Profitability – AM improves profitability.
5. Initiative – AM becomes an initiative and benefits are broadly multiplied.
6. Competitive Advantage – AM generates growth and delivers on Vital Business Objectives (VBOs).

Image credit – Cheryl

100% of the people won’t like your new idea, even if it’s a really good one like the airplane, mayonnaise or air conditioning.

I don’t know the right amount of conflict, but I know it’s not 0% or 100%.

If 100% is good, 110% isn’t better. Percentages don’t work that way.

100% alignment is not the best thing. Great things aren’t built on the back of consensus.

100% of the problems shouldn’t be solved.  Sometimes it’s best to let the problem blossom into something that cannot be dismissed, denied or avoided.

Fitting in can be good, but not 100% of the time. Sometimes the people in power need to hear the truth, even if you know they’ll choke on it.

If the system is in the way, work the rule. Follow it 100%, follow it to the letter, follow it until it’s absurd. But, keep in mind the system isn’t in the way 100% of the time.

Following the process 100% eliminates intellectual diversity. And, as Darwin said, that leads to extinction.  I think he was onto something.

Trying to fix 100% of the problems leads to dilution. Solve one at a time until you’re done.

The best tool isn’t best 100% of the time. Here’s a rule: If the work’s new, try a new tool. You can’t cut a board with a hammer.

I don’t know how frequently to make mistakes, but I know it’s not 0% or 100% of the time.

As a sport, leadership isn’t binary. That’s why we’re paid to use our good judgement.

Image credit – Joe Dyer

When the work is new, it can’t be defined and managed like work that has been done before.

Sometimes there’s a tendency to spend months to define the market, the detailed specification and the project timeline and release the package as a tidal wave that floods the organization with new work.  Instead, start with a high-level description of the market, a rough specification and the major project milestones, all of which will morph, grow and inform each other as the team learns.  Instead of a big batch, think bite-sized installments that build on each other. Think straw-man that gets its flesh as the various organizations define their learning objectives and learn them.

Instead of target customer segments and idealized personas, define how the customers will interact with the new product or service. Use the storyboard format to capture sequence of events (what they do), the questions they ask themselves and how they know they’ve done it right. Make a storyboard for the top three to five most important activities the customers must do.  There’s good learning just trying to decide on the top three to five activities, never mind the deep learning that comes when you try to capture real activities of real customers. [Hint – the best people to capture real customer activities are real customers.]

Instead of a detailed list of inputs and outputs, fill in the details of the storyboards.  Create close-ups of the user interfaces and label the dials, buttons and screens.  When done well, the required inputs and outputs bubble to the surface.  And define the customer’s navigation path, as it defines the sequence of things and where the various inputs come to be and the various outputs need to be.  What’s nice is learning by iteration can be done quickly since its done in the domain of whiteboards and markers.

Instead of defining everything, just define what’s new and declare everything else is the same as last time.

The specification for the first prototypes is to bring the storyboards to life and to show the prototypes to real customers.  Refine and revise based on the learning, and rinse and repeat, as needed.

As the design migrates toward customer value and confidence builds, it’s then time to layer on the details and do a deep dive into the details – specs, test protocols, manufacturing, sales and distribution.

At early stages of innovation work, progress isn’t defined by activity, it’s defined by learning.  And it can look like nothing meaningful is happening as there is a lot of thinking and quiet time mixed in with infrequent bursts active activity.  But that’s what it takes to answer the big questions of the front end.

When in doubt, answer the big questions at the expense of the details.  And to stay on track, revisit and refine the learning objectives. And to improve confidence, show it to real customers.

And rinse and repeat, as needed.

Image credit – Jason Samfield

Everyone knows innovation is difficult, but there’s no best way to make it easier. And everyone knows there’s plenty of opportunities to make innovation more effective, but, again, there’s no best way.  Clearly, there are ways to improve the process, and new tools can help, but the right process improvements depend on the existing process and the specific project.  And it’s the same for tools – the next tool depends on the existing toolbox and the new work required by the project.  With regard to tools and processes, the right next steps are not universal.

But with all companies’ innovation processes, there is a common factor – the innovation process is run by people. Regardless of process maturity or completeness, people run the process.  And this fundamental cuts across language, geography and company culture.  And it cuts across products, services, and business models.  Like it or not, innovation is done by people.

At the highest level, innovation converts ideas into something customers value and delivers the value to them for a profit. At the front end, innovation is about ideas, in the middle, it’s about problems and at the back end, it’s about execution. At the front, people have ideas, define them, evaluate them and decide which ones to advance. In the middle, people define the problems and solve them. And at the back end, people define changes to existing business process and run the processes in a new way.

Tools are a specialized infrastructure that helps people run lower-level processes within the innovation framework. At the front, people have ideas about new tools, or how to use them in a new way, define the ideas, evaluate them, and decide which tools to advance. In the middle, people define problems with the tools and solve them. And at the back end, they run the new tools in new ways.

With innovation processes and tools, people choose the best ideas, people solve problems and people implement solutions.

In order to choose the best ideas, people must communicate the ideas to the decision makers in a clear, rich, nuanced way. The better the idea is communicated, the better the decision. But it’s difficult to communicate an idea, even when the idea is not new. For example, try to describe your business model using just words. And it’s more difficult when the idea is new. Try to describe a new (untested) business model using just your words. For me, words are not a good way to communicate new ideas.

Improved communication improves innovation. To improve communication of ideas, use fewer words. Draw a picture, create a cartoon, make a storyboard, or make a video.  Let the decision maker ask questions of your visuals and respond with another cartoon, a modified storyboard or a new sketch.  Repeat the process until the decision maker stops asking questions.  Because communication is improved, the quality of the decision is improved.

Improved problem solving improves innovation. To improve problem-solving, improve problem definition (the understanding of problem definition.) Create a block diagram of the problem – with elements of the system represented by blocks and labeled with nouns, and with actions and information flow represented by arrows labeled with verbs. Or create a sketch of the customer caught in the act of experiencing the problem.  Define the problem in time (when it happens) so it can be solved before, during or after. And in all cases, limit yourself to one page. Continue to modify the visuals until there’s a common definition of the problem (the words stop.)  When the problem is defined and communicated in this way, the problem solves itself. Problem-solving is seven-eighths problem definition.

Improved execution improves innovation. To improve execution, improve clarity of the definition of success.  And again, minimize the words. Draw a picture that defines success using charts or graphs and data. Create the axes and label them (don’t forget the units of measure). Include data from the baseline product (or process) and define the minimum performance criterion in red.  And add the sample size (number of tests.) Use one page for each definition of success and sequence them in order of importance. Start with the work that has never been done before.  And to go deeper, define the test protocol used to create the data.

For a new business model, the one-page picture could be a process diagram with new blocks for new customers or partners or new arrows for new information flows. There could be time requirements (response time) or throughput requirements (units per month). Or it could be a series of sketches of new deliverables provided by the business model, each with clearly defined criteria to judge success. When communicated clearly to the teams, definitions of success are beacons of light that guide the boats as the tide pulls them through the project or when uncharted rocks suddenly appear to starboard.

Innovation demands communication and communication demands mechanisms. In the domain of uncertainty, words are not the best communicators.  Create visual communication mechanisms that distill and converge on a common understanding.

A picture isn’t worth a thousand words, it gets rid of a thousand.

Image credit – Michael Coghlan

If you had a choice to make an extra year’s salary or live an extra year, which would you choose? If you had a choice to make an extra month’s salary or live an extra month, make the same choice? What about the trade between a week’s pay and a week of life? Does anything change when it’s a choice between ten years of salary and ten years of life? Does this thought experiment change anything for you? If not, no worries. It was a low-cost experiment.

If you decided you had enough money, how would you change your behavior? Would you spend more time with your kids? Would you take the time to decompress and enjoy what you have? Or would you spend more money so no longer had enough? What if next week you pretend you have enough money? Would things change? Is there a downside to spending more time with your family next week? Why not try it?

If every day you reminded yourself your lifespan was finite, would you live differently? If you reminded yourself every morning for the next week, would things change? It’s a low-cost experiment, and only the first two mornings are scary.  The experiment is free. Why not try?

What if you decided you didn’t want a promotion? Would you work differently? Would you use more judgment because the cost of failure is lower? Would you take more initiative? Would you say no more often? Or would you say yes more often? Would you choose to work on different projects? Why not try it for a week?  Who knows, you may get a promotion.

What if you decided you had enough stuff? What would you do with the extra money? Would give some to charity? Would you save up and buy more stuff? For the next week, why not remove one thing from your house and recycle it or give it away? You may teach yourself you have too much stuff; you may teach yourself your house looks better when it’s less cluttered, or you may feel good that your gift helped someone who didn’t have enough. There’s little downside to more pocket change, a decluttered house and helping others. Why not try it next week?

Every day we make trades between time and money, but we make them in a below-the-water-level way. And every day we choose between having enough or not, and, again, we make these choices in a less-than-fully-conscious way.  But these choices are far too important to make lightly.

Why not make some time every day to quiet yourself so you can be more aware of the day’s decisions?  It’s a low-cost experiment that could bring more clarity to your decision-making. Why not try it for a week?

image credit – Tax Credits

There are two domains – what is and what isn’t. We’re most comfortable in what is and we don’t know much about what isn’t. Neither domain is best and you can’t have one without the other. Sometimes it’s best to swim in what is and other times it’s better to splash around in what isn’t.  Though we want them, there are no hard and fast rules when to swim and when to splash.

Improvement lives in the domain of what is. If you’re running a Six Sigma project, a lean project or a continuous improvement program you’re knee deep in what is. Measure, analyze, improve, and control what is. Walk out to the production floor, count the machines, people and defects, measure the cycle time and eliminate the wasteful activities. Define the current state and continually (and incrementally) improve what is. Clear, unambiguous, measurable, analytical, rational.

The close cousins creativity and innovation live in the domain of what isn’t. They don’t see what is, they only see gaps, gulfs and gullies. They are drawn to the black hole of what’s missing. They define things in terms of difference.  They care about the negative, not the image. They live in the Bizarro world where strength is weakness and far less is better than less. Unclear, ambiguous, intuitive, irrational.

What is – productivity, utilization, standard work. What isn’t – imagination, unstructured time, daydreaming. Predictable – what is. Unknowable – what isn’t.

In the world of what is, it’s best to hire for experience.  What worked last time will work this time. The knowledge of the past is all powerful.  In the world of what isn’t, it’s best to hire young people that know more than you do. They know the latest technology you’ve never heard of and they know its limitations.

Improving what is pays the bills while creating what isn’t fumbles to find the future. But when what is runs out of gas, what isn’t rides to the rescue and refuels. Neither domain is better, and neither can survive without the other.

The magic question – what’s the best way to allocate resources between the domains? The unsatisfying answer – it depends. And the sextant to navigate the dependencies – good judgement.

Image credit – JD Hancock

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