Posts Tagged ‘Problem Definition’

With innovation, it depends.

By definition, when the work is new there is uncertainty.  And uncertainty can be stressful. But, instead of getting yourself all bound up, accept it.  More than that, relish in it.  Wear it as a badge of honor.  Not everyone gets the chance to work on something new – only the best do.  And, because you’ve been asked to do work with a strong tenor of uncertainty, someone thinks you’re the best.

But uncertainty is an unknown quantity, and our systems have been designed to reject it, not swim in it.  When companies want to get serious they drive toward a culture of accountability and the new work gets the back seat.  Accountability is mis-mapped to predictability, successful results and on time delivery.  Accountability, as we’ve mapped it, is the mortal enemy of new work.  When you’re working on a project with a strong element of uncertainty, the only certainty is the task you have in front of you.  There’s no certainty on how the task will turn out, rather, there’s only the simple certainty of the task.

With work with low uncertainty there are three year plans, launch timelines and predictable sales figures. Task one is well-defined and there’s a linear flow of standard work right behind it – task two through twenty-two are dialed in. But when working with uncertainty, the task at hand is all there is.  You don’t know the next task.  When someone asks what’s next the only thing you can say is “it depends.”  And that’s difficult in a culture of traditional accountability.

An “it depends” Gannt chart is an oxymoron, but with uncertainty step two is defined by step one.  If A, then B.  But if the wheels fall off, I’m not sure what we’ll do next.  The only thing worse than an “it depends” Gantt chart is an “I’m not sure” Gannt chart.  But with uncertainty, you can be sure you won’t be sure.  With uncertainty, traditional project planning goes out the window, and “it depends” project planning is the only way.

With uncertainty, traditional project planning is replaced by a clear distillation of the problem that must be solved.  Instead of a set of well-defined tasks, ask for a block diagram that defines the problem that must be solved.  And when there’s clarity and agreement on the problem that must be solved, the supporting tasks can be well-defined.  Step one – make a prototype like this and test it like that. Step two – it depends on how step one turns out.  If it goes like this then we’ll do that.  If it does that, we’ll do the other.  And if it does neither, we’re not sure what we’ll do.  You don’t have to like it, but that’s the way it is.

With uncertainty, the project plan isn’t the most important thing.  What’s most important is relentless effort to define the system as it is.  Here’s what the system is doing, here’s how we’d like it to behave and, based on our mechanism-based theory, here’s the prototype we’re going to build and here’s how we’re going to test it.  What are we going to do next?  It depends.

What’s next? It depends. What resources do you need? It depends. When will you be done? It depends.

Innovation is, by definition, work that is new.  And, innovation, by definition, is uncertain.  And that’s why with innovation, it depends.  And that’s why innovation is difficult.

And that’s why you’ve got to choose wisely when you choose the people that do your innovation work.

Image credit – Sara Biljana Gaon (off)

The Causes and Conditions for Innovation

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

Make it work.

square-pegIf 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

 

 

Moving Away from Best Practices

rotten-appleIf the work is new, there is no best practice.

When you read the best books you’ll understand what worked in situations that are different than yours.  When you read the case studies you’ll understand how one company succeeded in a way that won’t work in yours.  The best practices in the literature worked in a different situation, in a different time and a under different cultural framework.  They won’t work best for you.

Just because a practice worked last time doesn’t mean it’s a best practice this time.  More strongly, just because it worked last time doesn’t mean it was best last time. There may have been a better way.

When a problem has high urgency it should be solved in a fast way, but if urgency is low, the problem should be solved in an efficient way. Which way is best? If the consequences of getting it wrong are severe, analyses and parallel solutions are skillful, but if it’s not terribly important to get it right, a lower cost way is better.  But is either the best way?

The best practices found in books are usually described a high level of abstraction using action words, block diagrams and arrows.  And when described at such a high level, they’re not actionable.  You may know all the major steps, but you won’t know how each step should be done.  And if the detail is provided, the context of your situation is different and the prescriptive steps don’t apply.

Instead of best practices, think effective practices.  Effective because the people doing the work can do it effectively.  Effective because it fits with the capability and capacity of the people doing the work.  Effective because it meshes with existing processes and projects.  Effective because it fits with your budget, timeline and risk profile.  Effective because it fits with your company values.

Because all our systems are people systems, there are no best practices.

image credit — johnwayne2006

Diabolically Simple Questions

DiabolicalToday’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

Battle Success With No-To-Yes

no to yesEveryone says they want innovation, but they don’t – they want the results of innovation.

Innovation is about bringing to life things that are novel, useful and successful. Novel and useful are nice, but successful pays the bills.  Novel means new, and new means fear; useful means customers must find value in the newness we create, and that’s scary. No one likes fear, and, if possible, we’d skip novel and useful altogether, but we cannot.  Success isn’t a thing in itself, success is a result of something, and that something is novelty and usefulness.

Companies want success and they want it with as little work and risk as possible, and they do that with a focus on efficiency – do more with less and stock price increases.  With efficiency it’s all about getting more out of what you have – don’t buy new machines or tools, get more out of what you have.  And to reduce risk it’s all about reducing newness – do more of what you did, and do it more efficiently.  We’ve unnaturally mapped success with the same old tricks done in the same old way to do more of the same. And that’s a problem because, eventually, sameness runs out of gas.

Innovation starts with different, but past tense success locks us into future tense sameness.  And that’s the rub with success – success breeds sameness and sameness blocks innovation.  It’s a strange duality – success is the carrot for innovation and also its deterrent. To manage this strange duality, don’t limit success; limit how much it limits you.

The key to busting out of the shackles of your success is doing more things that are different, and the best way to do that is with no-to-yes.

If your product can’t do something then you change it so it can, that’s no-to-yes.  By definition, no-to-yes creates novelty, creates new design space and provides the means to enter (or create) new markets.  Here’s how to do it.

Scan all the products in your industry and identify the product that can operate with the smallest inputs.  (For example, the cell phone that can run on the smallest battery.)  Below this input level there are no products that can function – you’ve identified green field design space which you can have all to yourself.   Now, use the industry-low input to create a design constraint.  To do this, divide the input by two – this is the no-to-yes threshold.  Before you do you the work, your product cannot operate with this small input (no), but after your hard work, it can (yes).  By definition the new product will be novel.

Do the same thing for outputs.  Scan all the products in your industry to find the smallest output. (For example, the automobile with the smallest engine.)  Divide the output by two and this is your no-to-yes threshold.  Before you design the new car it does not have an engine smaller than the threshold (no), and after the hard work, it does (yes). By definition, the new car will be novel.

A strange thing happens when inputs and outputs are reduced – it becomes clear existing technologies don’t cut it, and new, smaller, lower cost technologies become viable.  The no-to-yes threshold (the constraint) breaks the shackles of success and guides thinking in a new directions.

Once the prototypes are built, the work shifts to finding a market the novel concept can satisfy.  The good news is you’re armed with prototypes that do things nothing else can do, and the bad news is your existing customers won’t like the prototypes so you’ll have to seek out new customers. (And, really, that’s not so bad because those new customers are the early adopters of the new market you just created.)

No-to-yes thinking is powerful, and though I described how it’s used with products, it’s equally powerful for services, business models and systems.

If you want innovation (and its results), use no-to-yes thinking to find the limits and work outside them.

To improve innovation, improve clarity.

Looking through binocularsIf I was CEO of a company that wanted to do innovation, the one thing I’d strive for is clarity.

For clarity on the innovative new product, here’s what the CEO needs.

Valuable Customer Outcomes – how the new product will be used.  This is done with a one page, hand sketched document that shows the user using the new product in the new way.  The tool of choice is a fat black permanent marker on an 81/2 x 11 sheet of paper in landscape orientation. The fat marker prohibits all but essential details and promotes clarity.  The new features/functions/finish are sketched with a fat red marker.  If it’s red, it’s new; and if you can’t sketch it, you don’t have it. That’s clarity.

The new value proposition – how the product will be sold. The marketing leader creates a one page sales sheet.  If it can’t be sold with one page, there’s nothing worth selling.  And if it can’t be drawn, there’s nothing there.

Customer classification – who will buy and use the new product.  Using a two column table on a single page, these are their attributes to define: Where the customer calls home; their ability to pay; minimum performance threshold; infrastructure gaps; literacy/capability; sustainability concerns; regulatory concerns; culture/tastes.

Market classification – how will it fit in the market.  Using  a four column table on a single page, define: At Whose Expense (AWE) your success will come; why they’ll be angry; what the customer will throw way, recycle or replace; market classification – market share, grow the market, disrupt a market, create a new market.

For clarity on the creative work, here’s what the CEO needs: For each novel concept generated by the Innovation Burst Event (IBE), a single PowerPoint slide with a picture of its thinking prototype and a word description (limited to 12 words).

For clarity on the problems to be solved the CEO needs a one page, image-based definition of the problem, where the problem is shown to occur between only two elements, where the problem’s spacial location is defined, along with when the problem occurs.

For clarity on the viability of the new technology, the CEO needs to see performance data for the functional prototypes, with each performance parameter expressed as a bar graph on a single page along with a hyperlink to the robustness surrogate (test rig), test protocol, and images of the tested hardware.

For clarity on commercialization, the CEO should see the project in three phases – a front, a middle, and end.  The front is defined by a one page project timeline, one page sales sheet, and one page sales goals. The middle is defined by performance data (bar graphs) for the alpha units which are  hyperlinked to test protocols and tested hardware.  For the end it’s the same as the middle, except for beta units, and includes process capability data and capacity readiness.

It’s not easy to put things on one page, but when it’s done well clarity skyrockets.  And with improved clarity the right concepts are created, the right problems are solved, the right data is generated, and the right new product is launched.

And when clarity extends all the way to the CEO, resources are aligned, organizational confusion dissipates, and all elements of innovation work happen more smoothly.

Image credit – Kristina Alexanderson

Don’t boost innovation, burst it.

Burst you balloonThe most difficult part of innovation is starting, and the best way to start is the Innovation Burst Event, or IBE. The IBE is a short, focused event with three objectives: to learn innovation methods, to provide hands-on experience, and to generate actual results. In short, the IBE is a great way to get started.

There are a couple flavors of IBEs, but the most common is a single day even where a small, diverse group gets together to investigate some bounded design space and to create novel concepts. At the start, a respected company leader explains to the working group the importance of the day’s work, how it fits with company objectives, and sets expectations there will be a report out at the end of the day to review the results. During the event, the working group is given several design challenges, and using innovation tools/methods, creates new concepts and builds “thinking prototypes.” The IBE ends with a report out to company leaders, where the working group identifies patentable concepts and concepts worthy of follow-on work. Company leaders listen to the group’s recommendations and shape the go-forward actions.

The key to success is preparation. To prepare, interesting design space is identified using multiple inputs: company growth objectives, new market development, the state of the technology, competitive landscape and important projects that could benefit from new technology. And once the design space is identified, the right working group is selected. It’s best to keep the group small yet diverse, with several important business functions represented. In order to change the thinking, the IBE is held at location different than where the day-to-day work is done – at an off-site location. And good food is provided to help the working group feel the IBE is a bit special.

The most difficult and most important part of preparation is choosing the right design space. Since the selection process starts with your business objectives, the design space will be in line with company priorities, but it requires dialing in. The first step is to define the operational mechanism for the growth objective. Do you want a new product or process? A new market or business model? The next step is to choose if you want to radically improve what you have (discontinuous improvement) or obsolete your best work (disruption). Next, the current state is defined (knowing the starting point is more important than the destination) – Is the technology mature? What is the completion up to? What is the economy like in the region of interest? Then, with all that information, several important lines of evolution are chosen. From there, design challenges are created to exercise the design space. Now it’s time for the IBE.

The foundation of the IBE is the build-to-think approach and its building blocks are the design challenges. The working group is given a short presentation on an innovation tool, and then they immediately use the tool on a design challenge. The group is given a short description of the design challenge (which is specifically constructed to force the group from familiar thinking), and the group is given an unreasonably short time, maybe 15-20 minutes, to create solutions and build thinking prototypes. (The severe time limit is one of the methods to generate bursts of creativity.) The thinking prototype can be a story board, or a crude representation constructed with materials on hand – e.g., masking tape, paper, cardboard. The group then describes the idea behind the prototype and the problem it solves. A mobile phone is used to capture the thinking and the video is used at the report out session. The process is repeated one or two times, based on time constraints and nature of the design challenges.

About an hour before the report out, the working group organizes and rationalizes the new concepts and ranks them against impact and effort. They then recommend one or two concepts worthy of follow on work and pull together high level thoughts on next steps. And, they choose one or two concept that may be patentable. The selected concepts, the group’s recommendations, and their high level plans are presented at the report out.

At the report out, company leaders listen to the working group’s thoughts and give feedback. Their response to the group’s work is crucial. With right speech, the report out is an effective mechanism for leaders to create a healthy innovation culture. When new behaviors and new thinking are praised, the culture of innovation moves toward the praise. In that way, the desired culture can be built IBE by IBE and new behaviors become everyday behaviors.

Innovation is a lot more than Innovation Burst Events, but they’re certainly a central element. After the report out, the IBE’s output (novel concepts) must be funneled into follow on projects which must be planned, staffed, and executed. And then, as the new concepts converge on commercialization, and the intellectual comes on line, the focus of the work migrates to the factory and the sales force.

The IBE is designed to break through the three most common innovation blockers – no time to do innovation; lack of knowledge of how do innovation (though that one’s often unsaid); and pie-in-the-sky, brainstorming innovation is a waste of time. To address the time issue, the IBE is short – just one day. To address the knowledge gap, the training is part of the event. And to address the pie-in-the-sky – at the end of the day there is tangible output, and that output is directly in line with the company’s growth objectives.

It’s emotionally challenging to do work that destroys your business model and obsoletes your best products, but that’s how it is with innovation. But for motivation, think about this – if your business model is going away, it’s best if you make it go away, rather than your competition.  But your competition does end up changing the game and taking your business, I know how they’ll do it – with Innovation Burst Events.

Image credit – Pascal Bovet

Customer Value – the Crowned Jewel of Innovation

wolframite

Innovation results in things that are novel, useful, and successful. These things can be products, services, data, information, or business models, but regardless of the flavor, they’re all different from what’s been done before.

And when things are different, they’re new; and that means we don’t know how to do them. We don’t know how to start; don’t know how to measure; don’t know how they’ll be received; don’t know if they’ll be successful.

In the commercial domain, successful means customers buy your products and pay for your services. When customers value your new stuff more than they value their money, they pay; and when they pay it’s success. But first things first – before there can be success, before there can be innovation, there must be customer value. With innovation, customer value is front and center.

How do you come up with ideas that may have customer value? There’s a goldmine of ideas out there, with some veins better than others, and any dowsing you can use to pan the high grade ore is time well spent. There are two tools of choice: one that channels the voice of the customer and a second that channels the voice of the technology.

Your technology has evolved over time and has developed a trajectory which you can track. (Innovation On Demand, Fey and Riven.) But at the highest level, as a stand-in for technology, it’s best to track the trajectory of your products – how they’ve improved over time. You can evaluate how your products improved over multiple lines of evolution, and each line will help you to channel the future from a different perspective.

The voice of your customers is the second divining rod of choice. What they say about you, your company, and your products can help you glean what could be. But this isn’t the same as VOC. This is direct, unfiltered, continuous real time capture of self-signified micro stories. This is VOC without the soothsaying, this is direct connection with the customer. (Sensemaker.)

There are two nuggets to pan for: limiting cant’s and purposeful misuse. You seek out groups of customer stories where customers complain about things your product cannot do and how those cant’s limit them. These limiting cant’s are ripe for innovation since your customers already want them. Purposeful misuse is when the radical fringe of your customer base purposely uses your product in a way that’s different than you hoped. These customers have already looked into the future for you.

Do these ideas have customer value? The next step is to evaluate the value of your diamonds in the rough. The main point here is only customers can tell you if you’ve hit the mother lode. But, since your ideas are different than anything they’ve experienced, in order assay the ideas you’ve got to show them. You’ve got to make minimum viable prototypes and let them use their loop to judge the potential cut, color, clarity, and carat. As a prospector, it’s best to evaluate multiple raw gemstones in parallel, and whatever customers say, even if you disagree, the learning is better than gold.

How can we deliver on the customer value? With your innovations in the rough – ideas you know have customer value – it’s time to figure out what it will take to convert your pyrite prototypes into 24 carat products. There are missing elements to be identified and fundamental constraints to be overcome and backplane of the transmutation is problem definition. Done right, the technology development work is a series of well-defined problems with clear definitions of success. From the cleaving, blocking and cutting of technology development the work moves to the polishing of product development and commercialization.

Innovation can’t be fully defined with a three question framework. But, as long as customer value is the crowned jewel of your innovation work, most everything else will fall into place.

How do you choose what to work on?

Eagle Nebula M16There are always too many things to do, too much to work on. And because of this, we must choose. Some have more choice than others, but we all have choice. And to choose, there are several lenses we look through.

What’s good enough? If it’s good enough, there’s no need to work on it. “Good enough” means it’s not a constraint; it’s not in the way of where you want to go.

What’s not good enough? If it’s not good enough, it’s important to work on it. “Not good enough” means it IS a constraint; it IS in the way; it’s blocking your destination.

What’s not happening? If it’s not happening and the vacancy is blocking you from your destination, work on it. Implicit in the three lenses is the assumption of an idealized future state, a well-defined endpoint.

It’s the known endpoint that’s used to judge if there’s a blocking constraint or something missing. And there are two schools of thought on idealized future states – the systems, environment, competition, and interactions are well understood and idealized future states are the way to go, or things are too complex to predict how things will go. If you’re a member of the idealized-future-state-is-the-way-to-go camp, you’re home free – just use your best judgment to choose the most important constraints and hit them hard. If you’re a believer in complexity and its power to scuttle your predictions, things are a bit more nuanced.

Where the future state folks look through the eyepiece of the telescope toward the chosen nebula, the complexity folks look through the other end of the telescope toward the atomic structure of where things are right now. Complexity thinkers think it’s best to understand where you are, how you got there, and the mindset that guided your journey. With that knowledge you can rough out the evolutionary potential of the future and use that to decide what to work on.

If you got here by holding on to what you had, it’s pretty clear you should try to do more of that, unless, of course, the rules have changed. And to figure out if the rules have changed? Well, you should run small experiments to test if the same rules apply in the same way. Then, do more of what worked and less of what didn’t. And if nothing works even on a small scale, you don’t have anything to hold onto and it’s time to try something altogether new.

If you got here with the hybrid approach – by holding on to what you had complimented with a healthy dose of doing new stuff (innovation), it’s clear you should try to do more of that, unless, of course, you’re trying to expand into new markets which have different needs, different customers, and different pocketbooks. To figure out what will work, runs small experiments, and do more of what worked and less of what didn’t. If nothing works, your next round of small experiments should be radically different. And again, more of what worked, less of what didn’t.

And if you’re a young company and have yet to arrive, you’re already running small experiments to see what will work, so keep going.

There’s a half-life to the things that got us here, and it’s difficult to predict their decay. That’s why it’s best to take small bets on a number of new fronts – small investment, broad investigation of markets, and fast learning. And there’s value in setting a rough course heading into the future, as long as we realize this type of celestial navigation must be informed by regular sextant sightings and course corrections they inform.

Image credit – Hubble Heritage.

Bridging The Chasm Between Technologists and Marketers

20140122-212144.jpgWhat’s a new market worth without a new technology to capture it? The same as a new technology without a new market – not much. Technology and market are a matched set, but not like peanut butter and jelly, (With enough milk, a peanut butter sandwich isn’t bad.) rather, more like H2 and O: whether it’s H2 without O or O without H2 – there’s no water. With technology and market, there’s no partial credit – there’s nothing without both.

You’d think with such a tight coupling, market and technology would be highly coordinated, but that’s not the case. There’s a deep organizational chasm between them. But worse, each has their own language, tools, and processes. Plain and simple, the two organizations don’t know how to talk to each other, and the result is the wrong technology for the right market (if you’re a marketer) or the right technology for the wrong market (if you’re a technologist.) Both ways, customers suffer and so do business results.

The biggest difference, however, is around customers. Where marketers pull, technologists push – can’t be more different than that. But neither is right, both are. There’s no sense arguing which is more important, which is right, or which worked better last time because you need both. No partial credit.

If you speak only French and have a meeting with someone who speaks only Portuguese, well, that’s like meeting between marketers and technologists. Both are busy as can be, and neither knows what the other is doing. There’s a huge need for translators – marketers that speak technologist and technologists that talk marketing. But how to develop them?

The first step is to develop a common understanding of why. Why do you want to develop the new market? Why hasn’t anyone been able to create the new market? Why can’t we develop a new technology to make it happen? It’s a good start when both sides have a common understanding of the whys.

To transcend the language barrier, don’t use words, use video. To help technologists understand unmet customer needs, show them a video of a real customer in action, a real customer with a real problem. No words, no sales pitch, just show the video. (Put your hand over your mouth if you have to.) Show them how the work is done, and straight away they’ll scurry to the lab and create the right new technologies to help you crack the new market. Technologists don’t believe marketers; technologists believe their own eyes, so let them.

To help marketers understand technology, don’t use words, use live demos. Technologists – set up a live demo to show what the technology can do. Put the marketer in front of the technology and let them drive, but you can’t tell them how to drive. You too must put your hand over your mouth. Let them understand it the way they want to understand it, the way a customer would understand it. They won’t use it the way you think they should, they’ll use it like a customer. Marketers don’t understand technology, they understand their own eyes, so let them.

And after the videos and the live demos, it’s time to agree on a customer surrogate. The customer surrogate usually takes the form of a fully defined test protocol and fully defined test results. And when done well, the surrogate generates test results that correlate with goodness needed to crack the new market. As the surrogate’s test results increase, so does goodness (as the customer defines it.) Instead of using words to agree on what the new technology must do, agreement is grounded in a well defined test protocol and a clear, repeatable set of test results. Everyone can use their eyes to watch the actual hardware being tested and see the actual test results. No words.

To close the loop and determine if everyone is on the same page, ask the marketers and technologist to co-create the marketing brochure for the new product. Since the brochure is written for the customer, it forces the team use plain language which can be understood by all. No marketing jargon or engineering speak – just plain language.

And now, with the marketing brochure written, it’s time to start creating the right new market and the right new technology.

Photo credit – TORLEY.

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner

Archives