Archive for the ‘CEO’ Category

In business and in life, one of the biggest choices is what to do next. Sounds simple, but it’s not.

The decision has many facets and drives many questions, for example: Does it fit with core competence? Does it fit with the brand? How many will we sell? What will the market look like after it’s launched? Do we have what it takes to pull it off?

These questions then explode into a series of complex financial analyses like – return on investment, return on capital, return on net assets (and all its flavors) and all sorts of yet-to-be created return on this’s and that’s. This return business is all about the golden ratio – how much will we make relative to how much it costs. All the calculations, regardless of their name, are variations on this theme. And all suffer the same fundamental flaw – they are based on an artificial system of financial accounting.

To me, especially when working in new territory, we must transcend the self-made biases and limitations of GAAP and ask the bedrock question – Is it worth it?

In the house of cards of our financial accounting, worth equals dollars. Nothing more, nothing less. And this simplistic, formulaic characterization has devastating consequence. Worth is broader than profit, it’s nuanced, it’s philosophical, it’s about people, it’s about planet. Yet we let our accounting systems lead us around by the nose as if people don’t matter, like the planet doesn’t matter, like what we stand for doesn’t matter. Simply put, worth is not dollars.

The single-most troubling artifact of our accounting systems is its unnatural bias toward immediacy. How much will we make next year? How about next quarter? What will we spend next month? If we push out the expense by a month how much will we save? What will it do to this quarter’s stock price? It’s like the work has no validity unless the return on investment isn’t measured in days, weeks or months. It seems the only work that makes it through the financial analysis gauntlet is work that costs nothing and returns almost nothing. Under the thumb of financial accounting, projects are small in scope, smaller in resource demands and predictable in time. This is a recipe for minimalist improvement and incrementalism.

What about the people doing the work? Why aren’t we concerned they can’t pay their mortgages? Why do we think it’s okay to demand they work weekends? Why don’t we hold their insurance co-pays at reasonable levels? Why do we think it’s okay to slash our investment in their development? What about their self-worth? Just because we can’t measure it in a financial sense, don’t we think it’s a liability to foster disenchantment and disengagement? If we considered our people an asset in a financial accounting sense, wouldn’t we invest in them to protect their output? Why do we preventive maintenance on our machines but not our people?

When doing innovative work, our financial accounting systems fail us. These systems were designed in an era when it was best to increase the maturity of immature systems. But now that our systems are mature, and our objective is to obsolete them, our ancient financial accounting systems hinder more than help. The domains of reinvention and disruption are dominated by judgement, not rigid accounting rules. Innovation is the domain of incomplete data and uncertain outcomes and not the domain of debits and credits.

Profit is important, but profit is a result. Financial accounting doesn’t create profit, people create profit. And the currency of people are thoughts, feelings and judgement.

With innovation, it’s better to create the conditions so people believe in the project and are fully engaged in their work. With creativity, it’s better to have empowered people who will move mountains to do what must be done. With work that’s new, it’s better to trust people and empower them to use their best judgement.

Whether you’re a country, company, organization, or team, revolution is your mortal enemy. And that’s why the systems of established organization are designed to prevent impending revolutions and squish those that grow legs. And that’s why revolutions are few and far between. (This is bad news for revolutionary innovation and radical change.)

With regard to revolutions, it’s easiest to describe the state of affairs for countries. Countries don’t want revolutions because they bring a change in leadership. After a revolution, the parties in power are no longer in power. And that’s why there are no revolutions spawned by those in power. For those in power it’s steady as she goes.

Revolutions are all about control. The people in control of a country want to preserve the power structure and the revolutionaries want to dismantle it. (Needless to say, country leaders and revolutionaries don’t consider each other good dinner company.) And when the control of a country is at stake, revolutions often result in violence and death. With countries, revolution is a dangerous game.

With regard to revolutions, companies are supposed to be different from countries. Companies are supposed to reinvent themselves to grow; they’re supposed to do radical innovation and obsolete their best products; and they’re supposed to abandon the old thinking of their success and create revolutionary business models. As it turns out, with regard to revolutions, companies have much more in common countries than they’re supposed to.

Like with a country, the company’s leadership party is threatened by revolution. But the words are a bit different – where a country calls it revolution, a company calls it innovation. And there’s another important difference. Where the president of a country is supposed to prevent and squelch revolutions, the president of a company is supposed to foster and finance revolutionary innovation. The president of a country has an easier time of it because everyone in the party is aligned to block it. But, the president of the company wants to bring to life the much needed revolutionary innovation but the powerful parties of the org chart want to block it because it diminishes their power. And it’s even trickier because to finance the disruptive innovation, the company president must funnel profits generated by the dominant party to a ragtag band of revolutionaries.

Where revolutionaries that overthrow a country must use guerilla tactics and shoot generals off their horses, corporate revolutionaries must also mock convention. No VPs are shot, but corporate innovators must purposefully violate irrelevant “best practices” and disregard wasteful rigor that slows the campaign. And, again, the circumstances are more difficult for the company president. Where the country president doesn’t have to come up with the war chest to finance the revolutionaries overthrowing the country, the company president must allocate company profits for a state-funded revolution.

Just as revolutions threaten the power structure of countries, innovation threatens the power structure of companies. But where countries desperately want to stifle revolutions, companies should desperately want to enable them. And just as the rules of engagement for a revolution are different than government as usual, the rules of engagement for revolutionary innovation are different than profitability as usual. With revolution and innovation, it’s all about change.

Revolutions require belief – belief the status quo won’t cut it and belief there’s a better way. Innovation is no different. Revolutions require a band of zealots willing to risk everything and a benefactor willing to break with tradition and finance the shenanigans. And innovation is no different.

Our unhealthy fascination with ever-increasing shareholder value has officially gone too far. In some companies dishonesty is now more culturally acceptable than missing the numbers. (Unless, of course, you get caught. Then, it’s time for apologies.) The sacrosanct mission statement can’t save us. Even the most noble can be stomped dead by the dirty boots of profitability.

Though, legally, companies can self-regulate, practically, they cannot. There’s nothing to balance the one-sided, hedonistic pursuit of profitability. What’s needed is a counterbalancing mechanism of equal and opposite force. What’s needed is a new role that is missing from today’s org chart and does not have a name.

Ombudsman isn’t the right word, but part of it is right – the part that investigates. But the tense is wrong – the ombudsman has after-the-fact responsibility. The ombudsman gets to work after the bad deed is done. And another weakness – ombudsman don’t have equal-and-opposite power of the C-suite profitability monsters. But most important, and what can be built on, is the independent nature of the ombudsman.

Maybe it’s a proactive ombudsman with authority on par with the Board of Directors. And maybe their independence should be similar to a Supreme Court justice. But that’s not enough. This role requires hulk-like strength to smash through the organizational obfuscation fueled by incentive compensation and x-ray vision to see through the magical cloaking power of financial shenanigans. But there’s more. The role requires a deep understanding of complex adaptive systems (people systems), technology, patents and regulatory compliance; the nose of an experienced bloodhound to sniff out the foul; and the jaws of a pit bull that clamp down and don’t let go.

Ombudsman is more wrong than right. I think liability is better. Liability, as a word, has teeth. It sounds like it could jeopardize profitability, which gives it importance. And everyone knows liability is supposed to be avoided, so they’d expect the work to be proactive. And since liability can mean just about anything, it could provide the much needed latitude to follow the scent wherever it takes. Chief Liability Officer (CLO) has a nice ring to it.

[The Chief Do-The-Right-Thing Officer is probably the best name, but its acronym is too long.]

But the Chief Liability Officer (CLO) must be different than the Chief Innovation Officer (CIO), who has all the responsibility to do innovation with none of the authority to get it done. The CLO must have a gavel as loud as the Chief Justice’s, but the CLO does not wear the glasses of a lawyer. The CLO wears the saffron robes of morality and ethics.

Is Chief Liability Officer the right name? I don’t know. Does the CLO report to the CEO or the Board of Directors? Don’t know. How does the CLO become a natural part of how we do business? I don’t know that either.

Chief Innovation Officer is a glorious title, and seems like the best job imaginable. Just imagine – every-day-all-day it’s: think good thoughts, imagine the future, and bring new things to life. Sounds wonderful, but more than anything, it’s a lonely slog.

In theory it’s a great idea – help the company realize (and acknowledge) what it’s doing wrong (and has been for a long time now), take resources from powerful business units and move them to a fledgling business units that don’t yet sell anything, and do it without creating conflict. Sounds fun, doesn’t it?

Though there are several common problems with the role of Chief Innovation Officer (CIO), the most significant structural issue, by far, is the CIO has no direct control over how resources are allocated. Innovation creates products, services and business models that are novel, useful and successful. That means innovation starts with ideas and ends with commercialized products and services. And no getting around it, this work requires resources. The CIO is charged with making innovation come to be, yet authority to allocate resources is withheld. If you’re thinking about hiring a Chief Innovation Officer, here’s a rule to live by:

If resources are not moved to projects that generate novel ideas, convert those ideas into crazy prototypes and then into magical products that sell like hotcakes, even the best Chief Innovation Officer will be fired within two years.

Structurally, I think it’s best if the powerful business units (who control the resources) are charged with innovation and the CIO is charged with helping them. The CIO helps the business units create a forward-looking mindset, helps bring new thinking into the old equation, and provides subject matter expertise from outside the company. While this addresses the main structural issue, it does not address the loneliness.

The CIO’s view of what worked is diametrically opposed to those that made it happen. Where the business units want to do more of what worked, the CIO wants to dismantle the engine of success. Where the engineers that designed the last product want to do wring out more goodness out of the aging hulk that is your best product, the CIO wants to obsolete it. Where the business units see the tried-and-true business model as the recipe for success, the CIO sees it as a tired old cowpath leading to the same old dried up watering hole. If this sounds lonely, it’s because it is.

To combat this fundamental loneliness, the CIO needs to become part of a small group of trusted CIOs from non-competing companies. (NDAs required, of course.) The group provides its members much needed perspective, understanding and support. At the first meeting the CIO is comforted by the fact that loneliness is just part of the equation and, going forward, no longer takes it personally. Here are some example deliverables for the group.

Identify the person who can allocate resources and put together a plan to help that person have a big problem (no incentive compensation?) if results from the innovation work are not realized.

Make a list of the active, staffed technology projects and categorize them as: improving what already exists, no-to-yes (make a product/service do something it cannot), or yes-to-no (eliminate functionality to radically reduce the cost signature and create new markets).

To the person with the resources and the problem if the innovation work fizzles, present the portfolio of the active, staffed projects and its validated roll-up of net profit, and ask if portfolio meets the growth objectives for the company. If yes, help the business execute the projects and launch the products/services. If no, put a plan together to run Innovation Burst Events (IBEs) to come up with more creative ideas that will close the gap.

The burning question is – How to go about creating a CIO group from scratch? For that, you need to find the right impresario that can pull together a seemingly disparate group of highly talented CIOs, help them forge a trusting relationship and bring them the new thinking they need.

If 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.

There are three types of innovation: innovation that creates jobs, innovation that’s job neutral, and innovation that reduces jobs.

Innovation that reduces jobs is by far the most common. This innovation improves the efficiency of things that already exist – the mantra: do the same, but with less. No increase in sales, just fewer people employed.

Innovation that’s job neutral is less common. This innovation improves what you sell today so the customer will buy the new one instead of the old one. It’s a trade – instead of buying the old one they buy the new one. No increase in sales, same number of people employed.

Innovation that creates jobs is uncommon. This innovation radically changes what you sell today and moves it from expensive and complicated to affordable and accessible. Sell more, employ more.

The idea is the product that is sold to a relatively small customer base (due to its cost) is transformed into something new with far broader applicability (due to its hyper-low cost). Clay says to “look down” to see the new technologies that do less but have a super low cost structure which reduces the barrier to entry. And because more people can afford it, more people buy it. And these aren’t the folks that buy your existing products. They’re new customers.

Vijay says growth over the next decades will come from the developing world who today cannot afford the developed world’s product. But, when the price comes down (down by a factor of 10 then down by a factor of 100), you sell many more. And these folks, too, are new customers.

I say the design and marketing communities must get over their unnatural fascination with “more” thinking. To sell to new customers the best strategy is increase the number of people who can afford your product. And the best way to do that is to radically reduce the cost signature at the expense of features and function. If you can give ground a bit on the thing that makes your product successful, there is huge opportunity to reduce cost – think 80% less cost and 20% less function. Again, you sell new product to new customers.

Here’s a thought experiment to help put you in the right mental context: Create a plan to form a new business unit that cannot sell to your existing customers, must sell a product that does less (20%) and costs far less (80%), and must sell it in the developing world. Now, create a list of small projects to test new technologies with radically lower cost structures, likely from other industries. The constraint on the projects – you must be able to squeeze them into your existing workload and get them done with your existing budget and people. It doesn’t matter how long the projects take, but the investment must be below the radar.

The funny thing is, if you actually run a couple small projects (or even just one) to identify those new technologies, for short money you’ve started your journey to selling new products to new customers.

The new product development process creates more value than any other process. And because of this it’s a logical target for improvement. But it’s also the most complicated business process. No other process cuts across an organization like new product development. Improvement is difficult.

The CEO throws out the challenge – “Fix new product development.” Great idea, but not actionable. Can’t put a plan together. Don’t know the problem. Stepping back, who will lead the charge? Whose problem is it?

The goal of all projects is to solve problems. And it’s no different when fixing product development – work is informed by problems. No problem, no fix. Sure you can put together one hell of a big improvement project, but there’s no value without the right problem. There’s nothing worse than spending lots of time on the wrong problem. And it’s doubly bad with product development because while fixing the wrong problem engineers are not working on the new products. Yikes.

Problems are informed by outcomes. Make a short list of desired outcomes and show the CEO. Your list won’t be right, but it will facilitate a meaningful discussion. Listen to the input, go back and refine the list, and meet again with the CEO. There will be immense pressure to start the improvement work, but resist. Any improvement work done now will be wrong and will create momentum in the wrong direction. Don’t move until outcomes are defined.

With outcomes in hand, get the band back together. You know who they are. You’ve worked with them over the years. They’re influential and seasoned. You trust them and so does the organization. In an off-site location show them the outcomes and ask them for the problems. (To get their best thinking spend money on great food and a relaxing environment.) If they’re the right folks, they’ll say they don’t know. Then, they’ll craft the work to figure it out – to collect and analyze the data. (The first part of problem definition is problem definition.) There will be immense pressure to start the improvement work, but resist. Any work done now will be wrong. Don’t move until problems are defined.

With outcomes and problems in hand, meet with the CEO. Listen. If outcomes change, get the band back together and repeat the previous paragraph. Then set up another meeting with the CEO. Review outcomes and problems. Listen. If there’s agreement, it’s time to put a plan together. If there’s disagreement, stop. Don’t move until there’s agreement. This is where it gets sticky. It’s a battle to balance everyone’s thoughts and feelings, but that’s your challenge. No words of wisdom on than – don’t move until outcomes and problems are defined.

There’s a lot of emotion around the product development process. We argue about the right way to fix it – the right tools, training, and philosophies. But there’s no place for argument. Analyze your process and define outcomes and problems. The result will be a well informed improvement plan and alignment across the company.

With manufacturing change is easy – lean this, six sigma that, more with less year-on-year. With engineering, not so much. Why?

Manufacturing is about cost, waste, efficiency, and yield (how to make it), and engineering is about function (what it does) – fundamental differences but not the why. The consequence of failure is the why. If manufacturing doesn’t deliver, the product is made like last year (with a bit more waste and cost than planned), but the product still sells. With engineering, not so much. If engineering mistakenly designs the Fris out of the Frisbee or the Hula out of the Hoop, no sales. That’s the why.

No function, no sales, no company, this is fear. This is why it feels dangerous to push on engineering; push on engineering and the wheels may fall off. This why the organization treads lightly; this is why the CEO does not push.

As technical leaders we are the ones who push directly on engineers. We stretch them to create novel technology that creates customer value and drive sales. (If, of course, customers value the technology.) We spend our days in the domain of stress, strain, printed circuit boards, programming languages, thermal models, and egos. As technologists, it’s daunting to push effectively on engineering; as non-technologists even more. How can a CEO do it without the subject matter expertise? The answer is one-page thinking.

One-page thinking forces engineers to describe our work in plain English, simple English, simple language, pictures, images. This cuts clutter and cleans our thinking so non-technologists can understand what’s happening, what’s going on, what we’re thinking, and shape us in the direction of customer, of market, of sales. The result is a hybrid of strong technology, strong technical thinking, and strong product, all with a customer focus, a market focus. A winning combination.

There are several rules to one-page thinking, but start with this one:

Use one page.

As CEO, ask your technical leaders (even the VP or SVP kind) to define each of their product development (or technology) projects on one page, but don’t tell them how. (The struggle creates learning.) When they come back with fifteen PowerPoint slides (a nice reduction from fifty), read just the first one, and send them away. When they come back with five, just read the first. They’ll get the idea. But be patient. To use just one page makes things remarkably clear, but it’s remarkably difficult.

Once the new product (or technology) is defined on one page, it’s time to reduce the fear of pushing on engineering – one-page thinking at the problem level. First, ask the technical leaders for a one-page description of each problem that must be overcome (one page per problem and address only the fundamental problems). Next, for each problem ask for baseline data (test data) on the product you make today. (For each problem they’ll likely have to create a robustness surrogate, a test rig to evaluate product performance.) The problem is solved (and the product will function well) when the new one out-performs the old one. The fear is gone.

When your engineers don’t understand, they can’t explain things on one page. But when they can, you understand.

I can’t believe everyone isn’t doing Design for Assembly (DFA), especially in these tough economic times. It’s almost like CEOs really don’t want to grow stock price. DFA, where the product design is changed to reduce the cost of putting things together, routinely achieves savings of 20-50% in material cost, and the same for labor cost. And the beauty of the material savings is that it falls right to the bottom line. For a product that costs $1000 with 60% material cost ($600) and 10% profit margin ($100), a 10% reduction in material cost increases bottom line contribution by 60% (from $100 to $160). That sounds pretty good to me. But, remember, DFA can reduce material cost by 50%. Do that math and, when you get up off the floor, read on.

Unfortunately for DFA, the savings are a problem – they’re too big to be believed. That’s right, I said too big. Here’s how it goes. An engineer (usually an older one who doesn’t mind getting fired, or a young one who doesn’t know any better) brings up DFA in a meeting and says something like, “There’s this crazy guy on the web writing about DFA who says we can design out 20-50% of our material cost. That’s just what we need.” A pained silence floods the room. One of the leaders says something like, “Listen, kid, the only part you got right is calling that guy crazy. We’re the world leaders in our field. Don’t you think we would have done that already if it was possible? We struggle to take out 2-3% material cost per year. Don’t talk about 20-50% because is not possible.” DFA is down for the count.

Also unfortunate is the name – DFA. You’ve got to admit DFA doesn’t roll off the tongue like six sigma which also happens to sound like sex sigma, where DFA does not. I think we should follow the lean sigma trend and glom some letters onto DFA so it can ride the coat tails of the better known methodologies. Here are some letters that could help:

Its pedigree is also a problem – it’s not from Toyota, so it can’t be worth a damn. Maybe we should make up a story that Deming brought it to Japan because no one in the west would listen to him, and it’s the real secret behind Toyota’s success. Or, we can call it Toyota DFA. That may work.

Though there is some truth to the previous paragraphs, the main reason no one is doing DFA is simple:

No one is asking the design community to do DFA.

Here is the rationalization: The design community is busy and behind schedule (late product launches). If we bother them with DFA, they may rebel and the product will never launch. If we leave them alone and cross our fingers, maybe things will be all right. That is a decision made in fear, which, by definition, is a mistake.

The design community needs greatness thrust upon them. It’s the only way.

Just as the manufacturing community was given no choice about doing six sigma and lean, so should the design community be given no choice about doing DFA.

No way around it, the first DFA effort is a leap of faith. The only way to get it off the ground is for a leader in the organization to stand up and say “I want to do DFA.” and then rally the troops to make it happen.

I urge you to think about DFA in the same light as six sigma or lean: If your company had a lean or six sigma project that would save you 20-50% on your product cost, would you do it? I think so.

There are many definitions of product robustness and just as many formally trained specialists willing to argue about them. I get confused by all that complexity, I don’t like to argue, and I am not a specialist, I am a generalist. I like simplicity so I use operational definitions every chance I get. Here’s one for product robustness:

A customer walks up to your product, turns it on, and it works without breaking or getting in its own way.

Bad product robustness is bad for your brand. Very bad. Customers do not like when they pay money for a product and it doesn’t work, especially when they rely on those products to make money for themselves. And they remember the experience in a visceral way.

You can’t fix bad product robustness with great marketing; you can’t fix it with spin selling; you can’t tell customers you fixed it when you didn’t (since they use your product, they know the truth); and you can’t hide it because customers talk (so do competitors). There is no quick fix – it takes tools, time, training, and new thinking to improve product robustness. And when you do manage to fix it, customers won’t believe you until the see it for themselves. They don’t want to get burned again.

No product is infinitely robust, nor should it be. It doesn’t make financial sense. The product would be infinitely expensive and would take an infinite amount time to develop. But how much robustness is enough? An easier, and possibly more important, question to answer is – how much is too little? Or, stated another way, what is the minimum level of product robustness?

The specialists won’t agree with my assertion that there is a minimum threshold for product robustness, but I don’t care. I think there is one. I call this minimum value the brand-damaging threshold. Here’s an operational definition of product robustness that’s below the brand-damaging threshold:

Customers don’t buy your product because they know it breaks or gets in its own way and they go out of their way to tell others about it.

It is difficult to know when customers don’t buy, never mind know why they don’t. But there are some tell-tale signs that product robustness is below the brand-damaging threshold. Here are a few.

The CEO takes enough direct calls about products that don’t work to feel obligated to send you a thoughtfully-crafted, four word email saying something like “Fix that @#&% thing!” Customers have to be really pissed off to call the CEO directly, so the situation is bad. It’s also bad for a reason that’s closer to home – the CEO sent the email to you.

You get a little sick to your stomach when sales increase. You know you should be happy, but you’re not. Deep down you know you’ll see many of those products again because they’ll be sent back by angry customers, in pieces.

The volume of returns is so significant you create a refurbishment department. Or you create a new group to scavenge the reusable stuff off the piles of returned product. Not good signs.

Everyone laughs at the person who says “We don’t have problems, we have opportunities.” Why do we say that? We know that’s crap. We have problems; problems are real; and it’s okay to call them by name. In fact, it’s healthy. Problems are good. Problems focus our thinking. There is a serious and important nature to the word problem, and it sets the right tone. Everyone knows if the situation has risen to the level of a problem it’s important and action must be taken. People feel good about organizing themselves around a problem – problems help rally the troops.

In a previous post on innovation, I talked about the tight linkage between problems and innovation. In the pre-innovation state there is a problem; in the post-innovation state there is no problem. The work in the middle is a good description of the thing we call innovation. It could also be called problem solving.

Behind every successful product launch is a collection of solved problems. The engineering team defines the problems, understands the physics, changed the design, and makes problems go away. Behind every unsuccessful product launch is at least one unsolved problem. These unsolved problems disrupt product launches – limiting product function, delaying launches, and cancelling others altogether. All this can be caused by a single unsolved problem. Read the rest of this entry »