Posts Tagged ‘no-to-yes’

What Good Ideas Feel Like

If you have a reasonably good idea, someone will steal it, make it their own and take credit. No worries, this is what happens with reasonably good ideas.

If you have a really good idea, you’ll have to explain it several times before anyone understands it. Then, once they understand, you’ll have to help them figure out how to realize value from the idea. And after several failed attempts at implementation, you’ll have to help them adjust their approach so they can implement successfully. Then, after the success, someone will make it their own and take credit. No worries, this is what happens with really good ideas.

When you have an idea so good that it threatens the Status Quo, you’ll get ridiculed. You’ll have to present the idea once every three months for two years. The negativity will decrease slowly, and at the end of two years the threatening idea will get downgraded to a really good idea. Then it will follow the wandering path to success described above. Don’t feel special. This is how it goes with ideas good enough to threaten.

And then there’s the rarified category that few know about. This is the idea that’s so orthogonal it scares even you. This idea takes a year or two of festering before you can scratch the outer shell of it. Then it takes another year before you can describe it to yourself. And then it takes another year before you can bring yourself to speak of it. And then it takes another six months before you share it outside your trust network.  And where the very best ideas get ridiculed, with this type of idea people don’t talk about the idea at all, they just think you’ve gone off the deep end and become unhinged. This class of idea is so heretical it makes people uncomfortable just to be near you. Needless to say, this class of idea makes for a wild ride.

Good ideas make people uncomfortable. That’s just the way it is.  But don’t let this get in the way.  More than that, I urge you to see the push-back and discomfort as measures of the idea’s goodness.

If there’s no discomfort, ridicule or fear, the idea simply isn’t good enough.

Image credit – Mindaugas Danys

Transcending a Culture of Continuous Improvement

We’ve been too successful with continuous improvement. Year-on-year, we’ve improved productivity and costs.  We’ve improved on our existing products, making them slightly better and adding features.

Our recipe for success is the same as last year plus three percent. And because the customers liked the old one, they’ll like the new one just a bit more. And the sales can sell the new one because its sold the same way as the old one.  And the people that buy the new one are the same people that bought the old one.

Continuous improvement is a tried-and-true approach that has generated the profits and made us successful. And everyone knows how to do it.  Start with the old one and make it a little better. Do what you did last time (and what you did the time before). The trouble is that continuous improvement runs out of gas at some point. Each year it gets harder to squeeze out a little more and each year the return on investment diminishes. And at some point, the same old improvements don’t come. And if they do, customers don’t care because the product was already better than good enough.

But a bigger problem is that the company forgets to do innovative work. Though there’s recognition it’s time to do something different, the organization doesn’t have the muscles to pull it off. At every turn, the organization will revert to what it did last time.

It’s no small feat to inject new work into a company that has been successful with continuous improvement.  A company gets hooked on the predictable results of continuous which grows into an unnatural aversion to all things different.

To start turning the innovation flywheel, many things must change. To start, a team is created and separated from the continuously improving core.  Metrics are changed, leadership is changed and the projects are changed. In short, the people, processes, and tools must be built to deal with the inherent uncertainty that comes with new work.

Where continuous improvement is about the predictability of improving what is, innovation is about the uncertainty of creating what is yet to be. And the best way I know to battle uncertainty is to become a learning organization.  And the best way to start that journey is to create formal learning objectives.

Define what you want to learn but make sure you’re not trying to learn the same old things. Learn how to create new value  for customers; learn how to deliver that value to new customers; learn how to deliver that new value in new ways (new business models.)

If you’re learning the same old things in the same old way, you’re not doing innovation.

Innovation Truths

If it’s not different, it can’t be innovation.

With innovation, ideas are the easy part. The hard part is creating the engine that delivers novel value to customers.

The first goal of an innovation project is to earn the right to do the second hardest thing. Do the hardest thing first.

Innovation is 50% customer, 50% technology and 75% business model.

If you know how it will turn out, it’s not innovation.

Don’t invest in a functional prototype until customers have placed orders for the sell-able product.

If you don’t know how the customer will benefit from your innovation, you don’t know anything.

If your innovation work doesn’t threaten the status quo, you’re doing it wrong.

Innovation moves at the speed of people.

If you know when you’ll be finished, you’re not doing innovation.

With innovation, the product isn’t your offering. Your offering is the business model.

If you’re focused on best practices, you’re not doing innovation. Innovation is about doing things for the first time.

If you think you know what the customer wants, you don’t.

Doing innovation within a successful company is seven times hard than doing it in a startup.

If you’re certain, it’s not innovation.

With innovation, ideas and prototypes are cheap, but building the commercialization engine is ultra-expensive.

If no one will buy it, do something else.

Technical roadblocks can be solved, but customer/market roadblocks can be insurmountable.

The first thing to do is learn if people will buy your innovation.

With innovation, customers know what they don’t want only after you show them your offering.

With innovation, if you’re not scared to death you’re not trying hard enough.

The biggest deterrent to innovation is success.

Image credit — Sherman Geronimo-Tan

Don’t change culture. Change behavior.

There’s always lots of talk about culture and how to change it.  There is culture dial to turn or culture level to pull. Culture isn’t a thing in itself, it’s a sentiment that’s generated by behavioral themes.  Culture is what we use to describe our worn paths of behavior.  If you want to change culture, change behavior.

At the highest level, you can make the biggest cultural change when you change how you spend your resources. Want to change culture? Say yes to projects that are different than last year’s and say no to the ones that rehash old themes.  And to provide guidance on how to choose those new projects create, formalize new ways you want to deliver new value to new customers.  When you change the criteria people use to choose projects you change the projects.  And when you change the projects people’s behaviors change. And when behavior changes, culture changes.

The other important class of resources is people.  When you change who runs the project, they change what work is done.  And when they prioritize a different task, they prioritize different behavior of the teams.  They ask for new work and get new behavior. And when those project leaders get to choose new people to do the work, they choose in a way that changes how the work is done.  New project leaders change the high-level behaviors of the project and the people doing the work change the day-to-day behavior within the projects.

Change how projects are chosen and culture changes. Change who runs the projects and culture changes. Change who does the project work and culture changes.

Image credit – Eric Sonstroem

Purposeful Procrastination

There’s a useful trick when you want to do new work. It has some of the characteristics of procrastination, but it’s different. With procrastination, the problem solver waits to start the solving until it’s almost impossible to meet the deadline. The the solver uses the unreasonable deadline to create internal pressure so they can let go of all the traditional solving approaches.  With no time for traditional approaches, the solver must let go of what worked and try a new approach.

Now, the mainstream procrastinator doesn’t wait with forethought as I described, but forethought isn’t the required element.  The internal pressure doesn’t care if it was forethought, it constrains out the tried-and-true, either way. Forethought or not, the results speak for themselves – unimaginable work done in far less time than reasonable.
But what if you could take the best parts of procrastination and supercharge it with purpose and process? What if you could help people achieve the results of procrastination – unimagined solutions done in an unreasonable time window – but without all the stress that comes with procrastination? What about a process for purposeful procrastination?
The IBE (Innovation Burst Event) was created to do just that – to systematize the goodness of procrastination without all the baggage that comes with it.

The heart of the IBE is the Design Challenge, where a team with diverse perspective is brought together by a facilitator to solve a problem in five minutes. The unreasonable time constraint generates all the goodness that comes with procrastination, but, because it’s a problem solving exercise, there’s no drama.  And like with procrastination, the teams deliver unimaginable results within an unrealistic time constraint.

The purposefulness of the IBE comes with up-front work to create Design Challenges that investigate design space that has high potential.  This can be driven by the Voice of the Customer (VOC) or Voice of the Technology (VOT). Either way, the choice of the design space is purposeful.
If you want to jump-start your innovation work, try the IBE.  And who knows, if you call it purposeful procrastination you may get a lot of people to participate.

The right time horizon for technology development

Patents are the currency of technology and profits are the currency of business.  And as it turns out, if you focus on creating technology you’ll get technology (and patents) and if you focus on profits you’ll get profits. But if no one buys your technology (in the form of the products or services that use it), you’ll go out of business.  And if you focus exclusively on profits you won’t create technology and you’ll go out of business.  I’m not sure which path is faster or more dangerous, but I don’t think it matters because either way you’re out of business.

It’s easy to measure the number of patents and easier to measure profits.  But there’s a problem.  Not all patents (technologies) are equal and not all profits are equal.  You can have a stockpile of low-level patents that make small improvements to existing products/services and you can have a stockpile of profits generated by short-term business practices, both of which are far less valuable than they appear. If you measure the number of patents without evaluating the level of inventiveness, you’re running your business without a true understanding of how things really are.  And if you’re looking at the pile of profits without evaluating the long-term viability of the engine that created them you’re likely living beyond your means.

In both cases, it’s important to be aware of your time horizon.  You can create incremental technologies that create short term wins and consume all your resource so you can’t work on the longer-term technologies that reinvent your industry.  And you can implement business practices that eliminate costs and squeeze customers for next-quarter sales at the expense of building trust-based engines of growth.  It’s all about opportunity cost.

It’s easy to develop technologies and implement business processes for the short term.  And it’s equally easy to invest in the long term at the expense of today’s bottom line and payroll.  The trick is to balance short against long.

And for patents, to achieve the right balance rate your patents on the level of inventiveness.

Image credit – NASA’s Solar Dynamics Observatory

Even entrepreneurial work must fit with the brand.

To meet ever-increasing growth objectives, established companies want to be more entrepreneurial.  And the thinking goes like this – launch new products and services to create new markets, do it quickly and do it on a shoestring.  Do that Lean Startup thing.  Build minimum viable prototypes (MVPs), show them to customers, incorporate their feedback, make new MVPs, show them again, and then thoselaunch.

For software products, that may work well, largely because it takes little time to create MVPs, customers can try the products without meeting face-to-face and updating the code doesn’t take all that long.  But for products and services that require new hardware, actual hardware, it’s a different story.  New hardware takes a long time to invent, a long time to convert into an MVP, a long time to show customers and a long time to incorporate feedback.  Creating new hardware and launching quickly in an entrepreneurial way don’t belong in the same sentence, unless there’s no new hardware.

For hardware, don’t think smartphones, think autonomous cars.  And how’s that going for Google and the other software companies? As it turns out, it seems that designing hardware and software are different.  Yes, there’s a whole lot of software in there, but there’s also a whole lot of new sensor systems (hardware).  And, what complicates things further is that it’s all packed into an integrated system of subsystems where the hardware and software must cooperate to make the good things happen.  And, when the consequences of a failure are severe, it’s more important to work out the bugs.

And that’s the rub with entrepreneurship and an established brand.  For quick adoption, there’s strong desire to leverage the established brand – GM, Ford, BMW – but the output of the entrepreneurial work (new product or service) has to fit with the brand.  GM can’t launch something that’s half-baked with the promise to fix it later. Ford can come out with a new app that is clunky and communicates intermittently with their hardware (cars) because it will reflect poorly on all their products.  In short, they’ll sell fewer cars.  And BMW can’t come out with an entrepreneurial all-electric car that handles poorly and is slow off the start.  If they do, they’ll sell fewer cars.  If you’re an established company with an established brand, the output of your entrepreneurial work must fit with the established brand.

If you’re a software startup, launch it when it’s half-baked and fix it later, as long as no one will die when it flakes out.  And because it’s software, iterate early and often. And, there’s no need to worry about what it will do to the brand, because you haven’t created it yet.  But if you’re a hardware startup, be careful not to launch before it’s ready because you won’t be able to move quickly and you’ll be stuck with your entrepreneurial work for longer than you want.  Maybe, even long enough to sink the brand before it ever learned to swim.  Developing hardware is slow.  And developing robust hardware-software systems is far slower.

If you’re an established company with an established brand, tread lightly with that Lean Startup thing, even when it’s just software.  An entrepreneurial software product that works poorly can take down the brand, if, of course, your brand stands for robust, predictable, value and safety.  And if the entrepreneurial product relies on new hardware, be doubly careful.  If it goes belly-up, it will be slow to go away and will put a lot of pressure on that wonderful brand you took so long to build.

If you’re an established brand, it may be best to buy your entrepreneurial products and services from the startups that took the risk and made it happen.  That way you can buy their successful track record and stand it on the shoulders of your hard-won brand.

Image credit – simpleinsomnia

How to Choose the Best Idea

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

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

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

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

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

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

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

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

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

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

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

Image credit – joiseyshowaa

For top line growth, think no-to-yes.

Bottom line growth is good, but top line growth is better.  But if you want to grow the bottom line, ignore labor costs and reduce material costs. Labor cost is only 5-10% of product cost. Stop chasing it, and, instead, teach your design community to simplify the product so it uses fewer parts and design out the highest cost elements.

Where the factory creates bottom line growth, top line growth is generated in the market/customer domain. The best way I know to grow the top line is to broaden the applicability of your products and services. But, before you can broaden applicability, you’ve got to define applicability as it is.  Define the limits of what your product can do – how much it can lift, how fast it can run a calculation and where it can be used.  And for your service, define who can use it, where it can be used and what elements without customer involvement. And with the limits defined, you know where top line growth won’t come from.

Radical top line growth comes only when your products and services can be used in new applications.  Sure, you can train your sales force to sell more of what you already have, but that runs out of gas soon enough. But, real top line growth comes when your services serve new customers in new ways.  By definition, if you’re not trying to make your product work in new ways, you’re not going to achieve meaningful top line growth.  And by definition, if you’re not creating new functionality for your services, you might as well be focusing on bottom line growth.

If your product couldn’t do it and now it can, you’re doing it right. If your service couldn’t be used by people that speak Chinese and now it can, you’re on your way.  If your product couldn’t be used in applications without electricity and now it can, you’re on to something.  If your service couldn’t run on a smartphone and now it can, well, you get the idea.

For the acid test, think no-to-yes.

If your product can’t work in application A, you can’t sell it to people who do that work. If your service can’t be used by visually impaired people, you’re not delivering value to them and they won’t buy it. Turning can’t into can is a big deal. But you’ve got to define can’t before you can turn it into can. If you want top line growth, take the time to define the limits of applicability.

No-to-yes is powerful because it creates clarity. It’s easy to know when a project will create no-to-yes functionality and when it won’t.  And that makes it easy to stop projects that don’t deliver no-to-yes value and start projects that do.

No-to-yes is the key element of a compete-with-no-one approach to business.

image credit – liebeslakritze

With novelty, less can be more.

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

A Barometer for Uncertainty

Novelty, or newness, can be a great way to assess the status of things.  The level of novelty is a barometer for the level of uncertainty and unpredictability.  If you haven’t done it before, it’s novel and you should expect the work to be uncertain and unpredictable. If you’ve done it before, it’s not novel and you should expect the work to go as it did last time. But like the barometer that measures a range of atmospheric pressures and gives an indication of the weather over the next hours, novelty ranges from high to low in small increments and so does the associated weather conditions.

Barometers have a standard scale that measures pressure.  When the summer air is clear and there are no clouds, the atmospheric pressure is high and on the rise and you should put on sun screen.  When it’s hurricane season and super-low system approaches, the drops to the floor and you should evacuate.  The nice thing about barometers is they are objective. On all continents, they can objectively measure the pressure and display it. No judgement, just read the scale. And regardless of the level of pressure and the number of times they measure it, the needle matches the pressure.  No Kentucky windage.  But novelty isn’t like that.

The only way to predict how things will go based on the level of novelty is to use judgement.  There is no universal scale for novelty that works on all projects and all continents.  Evaluating the level of novelty and predicting how the projects will go requires good judgement. And the only way to develop good judgment is to use bad judgment until it gets better.

All novelty isn’t created equal. And that’s the trouble.  Some novelty has a big impact on the weather and some doesn’t.  The trick is to know the difference.  And how to tell the difference? If when you make a change in one part of the system (add novelty) and the novelty causes a big change in the function or operation of the system, that novelty is important. The system is telling you to use a light hand on the tiller. If the novelty doesn’t make much difference in system performance, drive on. The trick is to test early and often – simple tests that give thumbs-up or thumbs-down results.  And if you try to run a test and you can’t get the test to run at all, there’s a hurricane is on the horizon.

When the work is new, you don’t really know which novelty will bite you. But there’s one rule: all novelty will bite you until proven otherwise.  Make a list of the novel elements of the and test them crudely and quickly.

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner

Archives