The Innovators Studio with Phil McKinney

Why do people believe you can build an innovation team by hiring a few smart people and giving them a creative space? In my experience, teams built on this false premise die within eighteen months.
How do organizations get it so wrong? Innovation consultants have told them, or innovation books have taught them, that this is how you build an innovation team. Those experts have rarely built and led innovation teams that delivered.
So why is this episode any different?
I built and ran HP's Innovation Program Office (IPO), and the teams I led there were named to Fast Company's Most Innovative list three years running. For the last fourteen years, I've run CableLabs, the research and innovation lab for the global broadband industry, where our teams build technology that half a billion people use every day.
This episode is about what it takes to build innovation teams, based on my experience doing it at scale—multiple times.
By the end, you'll have the six steps I use, in the order they have to happen, what goes wrong when a team skips one, and a way to score your team today.
I'll start with a decision I almost got wrong.
In 2007, I was about to approve a 20 percent time policy at HP. Under what is called "20 percent time", employees spend about one day a week, a fifth of their working hours, on projects of their own choosing. Google had made it famous; everyone was talking about it, and it looked like the answer.
Chuck House stopped me. Chuck had spent decades at HP working for Dave Packard, who founded the company with Bill Hewlett. "Before you do anything," he said, "you need to talk to Art."
Art Fong was HP employee number nine. When I sat down with him, he told me something I didn't know. HP had already tried 20 percent time. In the 1950s. The company had watched Art work on his own ideas on Friday afternoons, so it gave everyone Friday afternoons. Most people sat around not knowing what to do with the time, and HP dropped it.
"The ones who were going to innovate, like me, were already doing it," Art told me. "The mandate didn't change behavior."
That was the lesson. You can't order people to innovate. The people who will innovate are already trying, and your job is to find them and clear the way.
I never approved the policy. Google killed its "20% time" policy in 2013.
What Art told me next shaped every innovation team I built after that, and we'll keep coming back to Art and his story.
Let's get into it.
The Innovation Team Fallacy
The innovation team fallacy is the belief that if you hire smart people and give them a creative space, innovation will follow. It's easy to believe, because every successful innovation team you've read about had smart people and a place to work. That's the part you can see from the outside. What you can't see is what had to be in place before the work began.
There's a second version of it, and it's the mistake I almost made with 20 percent time: copying what worked at another company and expecting it to work at yours. I'll come back to that later, with the story of a company that learned it the hard way.
Teams also fail when you build the pieces in the wrong order. Get the order wrong, and it doesn't matter how talented the people are.
Here are the six steps, in the order they have to happen:
Build the culture before you hire anyone

Recruit for specific roles, not just talent

Adapt the process, don't adopt someone else's

Fund it like innovation, not like operations

Measure what keeps leadership bought in

Lead it day to day

Step 1: Build the Culture Before You Hire Anyone
Culture is how people behave when nobody is telling them what to do, especially when something goes wrong. New hires don't learn it from what you say, or from the employee handbook. They learn it from what they see.
Art Fong didn't describe HP's culture with a policy. He taught me through stories.
One weekend, Bill Hewlett found a manager had locked the tool room with a padlock. Bill came back with bolt cutters, cut the lock off, and left a signed note on the door: "Never lock this again." He wanted his engineers to get to parts and equipment whenever an idea hit them. The note told every engineer at HP that the founders would remove anything that stood between them and their next idea.
When Art tried to buy a house in Palo Alto, and discrimination stood in the way, Bill and Dave bought it from the seller themselves and sold it to him. No memo or values poster builds that kind of trust. It's built by what leaders do.
Three things have to be in place before you hire your first person.
Permission to fail without penalty. Innovation means working on ideas that are too early, too unusual, or too risky for the company's normal processes. Most of them won't work, and nobody brings you ideas like that if failure costs them. People watch what happens to the first person whose project gets stopped. If that person's next performance review takes a hit, your team stops proposing anything that might fail.
Trust built through integrity. Trust gets built when a leader does the costly thing they didn't have to do. It gets destroyed when a leader says one thing and does another.
Leadership that protects the team from the rest of the organization. Every company has its own version of that padlock: approval chains, purchasing rules, a legal review that takes six weeks, a budget that only opens once a year. Most of them exist to protect the core business, and they do that job well. An innovation team can't work inside them.
What to do:
List the padlocks, then remove them. Take one idea and walk it through your organization on paper, from the first conversation to the first test with a customer. Write down every approval, every form, where the money comes from, and how many days each one takes. Then go back through and cut the ones your team doesn't need.

Write what happens to a person whose project gets stopped. Do it before the first project, not after, and be specific about the performance review and the next assignment. Then keep your word the first time it's tested, because that's the one everybody remembers.

Name the protector, and make sure everyone knows who it is. Pick the person with enough authority to tell the rest of the organization that a rule doesn't apply to this team. If nobody in your organization can play that role, you're not ready to build the team.

Go deeper: HP Won Innovation Awards. Then Killed What Made It True.
Step 2: Recruit for Specific Roles, Not Just Talent
Keep the team small. I've argued for years that the right size for an innovation team is six to eight people. Bigger than that, and people lose focus and stop feeling connected to the work.
Small means every seat matters. If you hire the eight smartest people you can find, you'll often end up with eight people who think alike. I look for four roles, and in my postmortems of teams that failed to innovate, they were missing at least one.
The visionary. This is the person who sees an idea before there's any evidence for it. They're rare, and often hard to work with, because they're living in a future the rest of the company can't see yet.
The leader, who usually isn't the visionary. This is the most common mistake I see. Somebody has a great idea, so they get put in charge. The leader's job is different: get the resources, protect the team, and stop a project when the evidence says it's time. The person who had the idea is the worst person to make that call to kill it.
The evangelist. The evangelist takes the team's work to the rest of the organization and explains it in the language of the people who will have to build it, sell it, or support it. Without one, a team builds good things that nobody adopts.
The radicals. These are the people a normal hiring process screens out. They're creative, they push back, and they can drive the people around them crazy. Remember what Art said: the ones who were going to innovate were already doing it. Your radicals are often inside your company right now, working on something nobody asked them to do.
At HP, my group became known as the place you could send your radicals. One of them was very creative, and he drove people crazy, especially the other executives. Every week, a senior executive called me to ask if I had fired him yet. I refused, and I spent a fair amount of time running interference so he could keep working. When he left HP, he started a company with some contacts. When it was acquired, he was worth several times what any executive at HP was worth.
The person the organization wants gone is often the one with the idea nobody else can see yet. If you want radicals on your team, you have to be willing to take those calls.
What to do:
Write the four roles on one page and put a name beside each. Use the names of real people, not job titles. Any blank is your first hire, and it tells you what to recruit for.

Keep the visionary and the leader as two different people. If one person holds both roles today, decide which one they're better at and fill the other. The test is simple: can this person stop a project they fell in love with?

Choose the evangelist from the part of the business that will have to adopt the work. Their credibility with that group matters more than their innovation experience, because those people already trust them. Give the evangelist standing time with that group, not just a presentation at the end.

Go find your radicals, and decide in advance how you'll protect them. Ask managers who they would transfer out, and look for the people already working on something nobody asked for. Then agree with your own boss on what you'll say when the complaints start.

Skip this step, and you get a team that produces what the core business would have produced anyway, or one that builds good work nobody adopts.
Go deeper: What Is the Optimal Innovation Team Size?
Step 3: Adapt the Process, Don't Adopt Someone Else's
Once you have the culture and the people, you need a process: how ideas come in, how they get tested, and how you decide which ones get more money and which ones get stopped.
At HP, we funded innovation in stages. An idea had to earn its next round of money at a checkpoint we called a stage gate, where the team answered a set of questions before anything moved forward. We ran four gates: market validation, customer validation, a limited launch, and then a full launch. We called the journey through all four gates the innovation funnel.
Here is what that looked like in practice. From a pool of about three thousand idea submissions a year, we funded roughly twenty into market validation. Around twelve made it through to customer validation. Five or six were in a limited launch‌. Three or four became new products.
Now, remember the second version of the fallacy from the start of this episode, copying what worked at another company? A process like this one is exactly what people try to copy. Here is what happened when a grocery chain did it.
An executive at Kroger, the grocery chain, heard my podcast and emailed me to say his team wanted to use HP's innovation playbook as written. We had released it under a Creative Commons license, so anyone could use it for free. I said yes, they could use it, but I was clear: "It won't work as is."
They ran it anyway. They built an innovation lab next to a Kroger test store in Northern Kentucky and used HP's playbook without changing it. It cost them eighteen months, mostly building credibility with the store teams, who had to adopt anything the lab built for their stores. Their answer was always some version of "Our customer likes it this way."
Kroger got it wrong by copying the process. HP's process was built for a technology company. A grocery store is built to run the same way every day, and anything new disrupts that. So I went to Kentucky and helped them tailor it. That work is what the evangelist role exists for. Once they did, the team shipped Advantage Checkout, a scanning tunnel for groceries that was recognized at the National Retail Federation's annual show in 2011.
I've said it many times: adapt, don't adopt. That runs against what a lot of innovation consultants sell: a framework you can install. I had to follow my own advice when I moved from HP to CableLabs. What worked at HP wouldn't work at CableLabs without changing the language, processes, funding level, and who the customers for the innovations were.
What to do:
Write how your organization already makes decisions. Who approves spending, how long an approval takes, and the words people use for customers and products. Your process has to run inside that reality, or it gets rejected.

Keep the purpose of each piece and change the form. A stage gate decides whether an idea gets more money and resources or stops. Write your own gate questions, in your own vocabulary, and make them about where the market is going rather than what is happening today.

Translate it, then prove it in one place. Rewrite the process in the words the group that has to adopt it already uses. At Kroger, that meant the language of the merchants and category managers, who decide what goes on the shelves. Then try it with one team, on one idea, for ninety days, and let that team show the results to everyone else instead of presenting the framework.

Go deeper: Kroger Copied HP's Innovation Playbook Perfectly. It Failed Anyway.
Step 4: Fund It Like Innovation, Not Like Operations
Operations get budgeted once a year because operations are predictable. Ideas don't arrive on a budget schedule. Someone has an idea in March that needs a small amount of money to test, and the answer they get is to put it in next year's plan. By the time the money arrives, the opportunity has passed, or the person who had the idea has moved on.
At HP's Innovation Program Office, and again at CableLabs, I set up what I call the Idea Fund. It's a pool of money that isn't committed to any project. When a good idea comes up, we give it money from the pool, say $50,000 for seven months. Once committed, the project has that money for the full seven months, no matter where we are in the fiscal year or what happens in the next budget cycle. And because the pool stayed at the same level year after year, no one had to wait for next year's budget.
It takes a leader who can protect that pool, and that means having the CFO on your side. A pool of uncommitted money is an easy target when the numbers get tight.
What to do:
Set the pool once, and keep it at the same level year to year. Agree the number with your CFO up front, and agree that it stays in place, so it isn't swept up the first time the numbers get tight.

Commit money to a project for a set amount of time, not for a fiscal year. Write the amount and the end date together, and hold to both, so the team knows exactly what it has and can get to work.

Put a deadline on every commitment. If a project can't answer the questions for its next gate in the time it was given, find out why before you decide anything. Sometimes the team learns something that changes the question.

Decide whether to stop or pause. If the answer at the gate is no, stop the project and put the money back into the pool for the next idea. If the problem is market timing rather than the idea, pause it, so you don't keep investing before it has a real chance to launch.

Skip this step and every good idea waits for the next budget cycle, which is how innovation teams die of patience.
Go deeper: Are You Playing The Innovation Long Game? An HP Story.
Step 5: Measure What Keeps Leadership Bought In
A team that can't show its leaders what the innovation funding is buying gets cut at the first bad quarter. A team measured on the wrong thing stops taking risks, even if nobody tells it to. You need a small set of numbers that do both jobs: show what the money is buying, without killing the risk-taking.
Start with what not to measure: the number of ideas. The Innovation Program Office received over three thousand ideas and pitches a year, about sixty a week, and that sounded like success. But no team, however smart or well funded, can properly evaluate three thousand ideas a year. After reviewing a few thousand, I found myself skimming proposals that deserved hours and would catch myself looking for reasons to say no. We had built what we thought was the most sophisticated innovation evaluation process in corporate America, and it was filtering out the breakthroughs it was designed to find.
The number of ideas, or the size of your funnel, doesn't matter. What matters is ranking them well enough that the best ones get the proper attention. The goal isn't to evaluate everything. The goal is to evaluate the right things properly.
Then get the best ones into the funnel, so the ones that survive the gates have an impact. Leadership is not interested in the funnel. They want to see the impact from the innovations.
That is what you need to measure to keep leadership bought into innovation.
What to measure:
Percent of revenue from new products. Pick a time window, say products that didn't exist three years ago, and keep it the same. This answers the question, "What are we getting for this money?"

How many innovations ship each year. At HP, our target was two new global products a year. The Innovation Program Office averaged three to four.

Profit on what shipped. Bill Hewlett and Dave Packard considered a product successful only when its profit over time was six times what it cost to develop.

Any one of these on its own will push the team in the wrong direction. Measure only new-product revenue, and last year's product in a new color starts counting as new. Measure only how many products ship, and the team will ship small, safe ones. Together, they keep each other honest.
Skip this step and the first bad quarter ends the team, because nobody outside it can say what the money bought.
Go deeper: 6 Innovation Metrics and KPIs Every Organization Should Use
Step 6: Lead It Day to Day
Everything so far can be set up as a process once. This step never ends.
Art Fong told me one more story. One evening, while Art was working on a new piece of equipment, Dave Packard came in, sat down next to him, and looked at his notebook. "I'll tell you what," Packard said. "I'll write it down while you take the readings." The company's co-founder worked as Art's lab assistant until nearly midnight.
Packard was running a company. He could have asked for a report the next morning. Instead, he sat down and did the work alongside Art. A great example of an innovation leader who led.
Three behaviors hold an innovation team together.
Show up in the work. Not only in the meetings about it. The team needs to see that you understand what they're doing and care how it turns out.
Hold a vision that reaches past this quarter. Innovation takes longer than anyone expects. What your team is working on now will show up as a product long after this quarter has been judged. The team needs to hear where the work is going, from you, more often than feels necessary.
Take the pressure so the team doesn't have to. Every quarter, someone in an executive meeting will ask what the company is getting for this money. The leader answers that question, using the numbers we just covered, and keeps it from landing on the team every week. Those weekly calls asking whether I'd fired my radical were part of the job.
The team trusts you because you protect them, and that trust keeps them innovating when a project gets hard.
What to do:
Spend time every week on the work itself. Sit in on a test, join a customer call, or read the raw results before someone summarizes them for you. Put it on the calendar and protect it the way you'd protect a board meeting.

Write the three-to-five-year destination in one sentence, and repeat it. Say it in team meetings, in reviews, and in your own updates until everyone on the team can say it back to you without looking.

Take the executive questions yourself. Bring the numbers from the last step into the leadership review, and be willing to defend the innovation teams, especially when the organization is facing a tough quarter.

Protect your people in public. When someone complains about a member of your team, answer it yourself, in the room where it came up. The person being complained about should never have to defend themselves to the rest of the organization.

Skip this step, and the other five come undone. The padlocks come back, the radicals leave, and the idea fund gets raided.
Go deeper: 9 Leadership Behaviors for Innovation Leaders
The Payoff, Told Straight
When this worked at HP, the teams I led made Fast Company's Most Innovative list three years running, and the recognition credited the Innovation Program Office, the products it created, and the culture we were rebuilding. Stanford and Harvard both wrote teaching cases on how the team worked.
I retired from HP in December 2011. A few years later, HP shut down the Innovation Program Office. As of last fall, when I last wrote about it, HP hadn't been back on that Fast Company list in thirteen years.
That's the part of this playbook I'd underline. Leading the team day to day depends on one person. The culture is what has to survive when that leader leaves, so spread it widely enough that others defend and protect it.
At CableLabs, I used the same playbook, adapted to a unique organization. In the twenty-four years between CableLabs' founding in 1988 and my arrival in 2012, CableLabs had been granted approximately 70 patents in total. In the fourteen years since, we've added more than a thousand.
While I'm the CEO, innovation is a team sport.
Everyone in the organization owns CableLabs' innovation culture, not one person. To avoid repeating what happened at HP, we established a small council of employees, not executives, who champion the culture and corporate values.
The Innovation Team Scorecard
Building a high-impact innovation team starts with an honest assessment of the team you have. Not the one described in a board update. The one your people work in.
The first step is to honestly score yourself on the six steps. Then have someone on the team score it separately, and compare. The gap between your score and theirs is usually the most useful thing on the page.
Fix the earliest weak step first, because later steps rest on earlier ones, and adding people to a weak foundation only makes it fail faster.
You can run this on a sheet of paper today. I've built a scorecard as a free download you can fill in. For each of the six steps, the scorecard describes each step and what a 1 and a 5 look like.

Any team can fill a whiteboard with ideas in an hour. What most teams skip is the analytical thinking that tells them if they're solving the right problem.
An idea pointed at the wrong problem is wasted no matter how clever the idea is, and you usually don't discover this mistake for years.
By the end of this episode, you'll have four steps you can run on a real problem this week, the three thinking traps that can derail you, and a practice drill to sharpen your analytical thinking.
To help explain how and the power behind this skill, I will use a real-world example.
In the summer of 1854, cholera hit one small corner of London's Soho area, and by the time it burned out, 616 people were dead, most of them within a few streets of each other. The experts had an explanation ready. Cholera came from bad air, a poisonous vapor rising off filth and rot, called miasma, and that was the official position of the men in charge of public health.
A doctor named John Snow didn't argue with them. He walked to the General Register Office, asked for the list of the dead, took that list out into the streets, and knocked on doors until he found that nearly all of them had lived a short walk from one water pump on Broad Street.
We'll follow what he did as he applied each of the four steps I'm about to share. Let's get into it.
What Is Analytical Thinking?
Analytical thinking gets confused with critical thinking all the time, and the difference decides which skill you reach for. Critical thinking judges a claim: someone tells you something, and you ask whether it's true, who is saying it, and what they left out. I covered that in the critical thinking episode, and it's worth watching if you haven't already seen it.
Analytical thinking starts when there is no claim on the table yet, just a mess. Sales are down twelve percent. Your best people keep leaving. A project that looked healthy in March is three months late in September. Nobody has handed you an argument to evaluate, so there's nothing yet to be critical of. You have to work out what's going on.
Snow's story shows the gap. Critical thinking, applied carefully in 1854, points you straight at the Board of Health, because they were the credible source making a claim, and the credible source was wrong.
In the critical thinking episode, we briefly touched on breaking a problem into pieces. In today's episode, we focus on breaking the problem into pieces and then analyzing each one.
Why Analytical Thinking Is Eroding
Most people remember Snow for the famous cholera map, the one with little black bars stacked along the streets of Soho, piling up around the pump. That map didn't exist in September 1854. A mapmaker drew it for a book Snow published the following year. The real work involved a list of names and a lot of walking.
Today, most of us only ever see the finished map. We rarely do the work that produces it.
Think about the last dashboard you looked at. The numbers arrived already cut into pieces, by region, by quarter, by product line, and somebody chose those cuts, months ago, for a question they had then. When the slicing arrives pre-made, you've inherited someone else's answer and never noticed.
AI summaries go one step further. You ask what's going on, and you get back a paragraph shaped exactly like a conclusion: confident, organized, finished. It never asks you to decide where to look, and that decision is the skill. Like any skill, it only improves when you make it yourself.
Keep the dashboard. But you need to be able to do the same work yourself, by hand, when the dashboard doesn't answer your question.
The Four Steps
Snow's work, and the work of anyone good at analytical thinking, has four steps:
Break the problem into pieces

Find the pattern inside them

Test whether your read is right

Look out for the thinking traps

Step 1: Break the Problem Into Pieces
A problem that feels overwhelming is a problem you haven't cut into pieces yet. The skill is deciding how to split it.
The steps to break a problem into pieces:
Write the problem down as a fact. "Renewals dropped from eighty percent to sixty-eight percent this year." Not "customers hate the new pricing." That one assumes the answer before you've done the work.

Split the problem into pieces that add up to the whole. New customers and existing ones. This region and that one. Online and in-store. If the pieces overlap or leave something out, you'll double-count or miss what matters.

Follow the piece that moved, and keep splitting it. If the drop sits almost entirely in one region, split that region again. If it's spread evenly across everything, that's a clue too, and it points you toward something that touches everything. Stop when a piece is small enough to act on or to ask a person about, because past that point more analysis just delays the decision.

Get the rows behind the chart. Snow didn't work from a death rate for the district. He worked from eighty-nine names and eighty-nine addresses, and the addresses were where the answer was.

How Snow split the problem made all the difference. Everyone else was sorting the neighborhood by what it smelled like. Snow sorted it by where people got their water.
Done honestly, this is twenty minutes and one sheet of paper. At the end, you want a short list of pieces that add up, with the one that moved circled.
Step 2: Find the Pattern
Step 1 tells you where the damage sits. This step is about what those pieces have in common and finding the exceptions.
Snow focused on the exceptions, starting with the ones that seemed to contradict him. There were only ten deaths in houses that sat closer to a different pump, so he visited those families. Five of them told him they always sent for water from Broad Street because they liked the taste better, and three more of the dead were children who went to school near the pump.
Then he looked at the places that should have been hit and weren't. A workhouse on Poland Street, nearly surrounded by houses where people had died, held more than five hundred people and lost five, but it had its own well. A brewery sat on Broad Street itself, seventy men working a few doors from the pump, and none of them died. The owner told Snow his men got a daily allowance of beer and never drank the water.
The cluster told Snow where to look, and the exceptions are what convinced him he was right.
The steps to find the pattern:
Hunt the exceptions in both directions. Who has the problem and shouldn't? Who should have it and doesn't? One exception, like the brewery, will usually teach you more than ten more examples that fit.

Ask what the cluster and the exceptions share that nothing else does. This is the moment the analysis reveals something, so slow down here. Write out what's true of the cases that have the problem: where they are, who touched them, what they use, when it started. Then cross off anything that's also true of the cases that don't have it. Snow could cross off the street, the smell, the crowding, and the poverty, because the workhouse and the brewery sat in all of it and stayed healthy. What survived was the water, and whatever survives your crossing-off is the candidate.

Keep asking why until you reach something you can change. Taiichi Ohno, the engineer behind the Toyota Production System, taught this with a machine that stopped. The fuse had blown, but it blew because a worn shaft had starved the bearing of oil, and the shaft wore out because nobody had fitted a strainer to keep scrap from getting into the machine and damaging the shaft. Stop at the first answer, and you replace the fuse, and the machine stops again next month.

Two questions do most of the work in this step:
What changed right before the numbers did?

Who is closest to the problem and hasn't been asked?

Snow's best evidence came from a brewery owner and a few families, and nobody had thought to ask any of them.
What you want at the end of this step is one sentence naming the likely cause, written so that somebody could go and prove it wrong. "People who drank from the Broad Street pump got cholera" can be checked. "Something in the environment is making people sick" can't be checked, which is part of why the miasma theory lasted so long.
Step 3: Test Your Explanation
A pattern is your best read, but it's still a bet. Testing is how you find out whether the bet is any good before you spend money, or reputation, or lives on it.
Snow's strongest evidence wasn't in Soho at all. A widow out in Hampstead, miles away, died of cholera on September 2nd. There was no cholera in Hampstead, and she hadn't been near Broad Street in months. But she'd lived there once, and she liked that pump's water so much she had a bottle of it brought out to her by cart. Her niece visited, drank the same water, went home to Islington, and died the next day. There was no cholera in Islington either.
That's powerful evidence: a case far from the outbreak that only the pump could explain.
On the evening of September 7th, Snow took his case to the parish authorities, and the next day the handle came off the pump. Here's the part people usually leave out. Snow wrote afterward that the deaths had already started to fall before the handle came off, so he couldn't claim the pump was still the source, and he refused to take credit the evidence didn't support.
A local clergyman, Henry Whitehead, closed the case. Whitehead set out to prove Snow wrong, went house to house on his own, and ended up tracing the first case: a five-month-old baby at 40 Broad Street, whose mother had rinsed the soiled cloths into a cesspool a few feet from the well.
Steps to test your explanation:
Write down what else has to be true if you're right, then go looking for the case that would embarrass you. If the pump is the cause, people who drank from it far from Soho should get sick, and people living beside it who drank elsewhere should stay healthy. The widow in Hampstead was exactly that case. Define the criteria that would prove you wrong before you go looking. Why? Because if you decide afterward, you'll find a way to rationalize what you already believed.

Hand your work to someone who wants you to be wrong. Whitehead set out to disprove Snow and ended up strengthening his case.

Run the cheapest test you can. Pulling a pump handle costs nothing and can be undone tomorrow. Most business problems have a small, cheap test: a price change in one region, one week with a different process, one customer call.

By the end of this step, you want a test you can run in a week and a result that would make you drop the idea.
Step 4: Avoid the Analytical Traps
Three failures show up again and again, and all three look like good analysis from the outside.
The steps to stay out of the traps:
Set the decision date before you start. The first trap is paralysis. You keep splitting and keep asking for more data, because deciding feels riskier than analyzing. Snow didn't wait for proof. He had a strong case and a cheap, reversible action, so he acted. Match the proof you need to the cost of being wrong: pulling a pump handle needs a strong case, and a decision you can't walk back needs a much stronger one.

Round the number back to what you actually know. The second trap is false precision. A forecast of 23.4 percent growth sounds more rigorous than "somewhere between fifteen and thirty." If the inputs were guesses, the precision is invented, and everyone who sees it trusts the number more than they should. Carry the uncertainty through to the answer.

Go find the numbers that disagree with you. The third trap is confirmation bias dressed up as data, and it's the most dangerous because it looks like evidence. You already believe the answer, so you find the slice of the numbers that agrees. The miasma camp had real observations on its side. Cholera did hit the poorest, most crowded, worst-smelling streets hardest. That was true, and it pointed at the wrong thing. I did a full episode on confirmation bias, and the short version is this: when the evidence against you is hard to find, that's when you need to look hardest.

Three things to have in hand before you act:
The date you'll decide

An honest range instead of a false decimal

The strongest evidence you could find against your own answer

Practice Exercise: The Root-Cause Drill
In the critical thinking episode, the exercise was a debate. This one is a drill, and you'll need a partner, because you'll see the structure of someone else's problem more clearly than your own.
Each of you brings one real problem with a number attached. Something current, where you don't know the answer. For example: turnover on your team, or a metric that went the wrong way.

Swap problems and break each one into pieces on a single sheet of paper, with the pieces adding back up to the whole. Give it fifteen minutes.

Circle where the problem concentrates, then find one exception. If you can't find one, you haven't split finely enough.

Ask why until you hit something changeable. Write the pattern as one sentence that could turn out to be wrong.

Hand it back. The owner designs one test they can run within a week that could prove the pattern false.

Meet again after the test. Compare what you expected with what happened. The gap between the two is where you learn the most.

The first time, it'll feel slow. By the third, you'll catch yourself taking problems apart in meetings before anyone has finished describing them.
The Rewards
After the outbreak passed, the authorities put the handle back on the Broad Street pump, and the official inquiry blamed the epidemic on bad air. Snow's analysis was right; it was on paper, and the people in charge rejected it anyway. It took years for everyone else to catch up with what he had worked out from a list of names and a few weeks of knocking on doors.
This is the reality of what analytical thinking will and won't do for you.
It won't make people believe you, and on its own it won't win the room. What it does is get you to the right answer while everyone else is still debating which expert to believe, and give you the evidence to back it up.
It gives you the early insight that others are missing.
The next time a number goes the wrong way, don't start by guessing at the cause. Get the details, break the problem into pieces, and work from there.

Recognizing failure patterns is the closest thing an innovator has to seeing the future.
 
If you can recognize the patterns, you can change the future, because most failures are not original. They repeat, and that repetition is the pattern: the same handful of patterns reappearing in one organization after another, decade after decade.
 
This one stings a little.
 
In 2011, Bill Geiser told me, almost word for word, how the project we had spent the past two years building was going to fail. He saw the pattern before I did; I heard him say it, and I never forgot it.
 
The failure still happened.
 
This is not a pre-mortem. A pre-mortem imagines new ways your plan could fail. Recognizing failure patterns means learning from failures that have already happened elsewhere and spotting the early signals before you repeat them, while there is still time to act.
 
By the end of this episode, you will have four patterns in your own library, a five-minute way to check any project against them, and the four steps to take when you find one.
 
Let's get into it.
The Smartwatch We Killed
In 2004, Fossil hired a watch-technology executive named Bill Geiser to help build innovative technology for their watches. A few years later, he and I started spending real time together, me as HP's CTO, him running watch technology at Fossil. Between us, we had an idea we both believed in: a connected wearable, years before anyone used that phrase, co-innovated by HP and Fossil, with each bringing its expertise.
 
Fossil named the resulting platform the MetaWatch. It ran an ultra-low-power processor with a 96 by 96 display, an accelerometer, and Bluetooth. It was designed to last a week on a charge, and it shipped with a full developer kit so anyone could build apps for it. We revealed the partnership in March 2011, at an HP event in China. And between us, we had the one thing Apple did not have in 2011: distribution. HP held roughly ten percent of consumer-electronics shelf space. Fossil sold through twenty thousand retail stores that carried its watches.
 
Bill saw the ending before anyone. He told me in 2011: "Phil, I wouldn't be shocked if Apple evolved the Nano to take advantage of this space. They'll legitimize it in consumers' minds worldwide."
 
So the man building the watch spotted the failure in advance, out loud. And naming it changed nothing.
 
The signs kept arriving in plain sight. HP went through three CEOs in thirteen months. In August 2011, Leo Apotheker killed HP's consumer mobile strategy and WebOS, which removed the platform that made a smartwatch matter to HP at all. The battery lasted three to four hours against the original target of a week. We ran month-long approval cycles for changes that startups could implement in days.
 
Then I went out on medical leave. When I came back six weeks later, HP had killed Palm, WebOS, and the connected wearable project.
 
Here is what the ignored warning turned into. The Apple Watch shipped in April 2015. It sold 4.2 million units in its first quarter, and by that fall Apple was selling three out of every four smartwatches on the planet. The market we walked away from grew from three hundred thousand units in 2012 to forty-five million by 2018, and Apple held fifty-one percent of the market share.
 
The idea was never the hard part. It never is. The hard part is committing.
What Recognizing Failure Patterns Means
Nothing that killed the MetaWatch was new, and none of the signals were faint. They were loud; they were ignored, and each one was a pattern that has killed projects for decades.
 
Recognizing failure patterns has two halves. The first is building a library of how failures repeat. The second is matching the situation in front of you against that library, and forcing what you find into an actual decision while the fix is still cheap. Bill did the first half. Neither of our companies did the second, and the gap between those halves is where the Apple Watch came from.
 
Here are four entries for your library, straight from this one failure. Each one ends with a test question. By the end, you will have a four-question checklist, and then I will show you what to do when a pattern shows up.
Pattern 1: Success Protects Itself
Fossil's traditional watch business grew from $950 million in 2004 to $3.25 billion by 2013. It was tripling while we were building the thing that might replace it, and that growth made cannibalizing it politically impossible. Fossil never had to kill the MetaWatch outright. Fossil positioned the watch as a two-hundred-dollar development platform, something no ordinary customer would ever be handed at a retail counter.
 
When we constrain what we're innovating so it doesn't risk the present, we've lost the future.
 
Test it: Is the new thing priced, staffed, or positioned so that it cannot hurt the current thing? If the answer is yes, this pattern is already running.
Pattern 2: The Warning That Changes Nothing
Bill's warning was specific, early, and exactly right, and it still changed nothing. I heard it directly, and hearing is not the same as deciding: nobody re-ran the plan with "Apple arrives and legitimizes the category" as an input, no roadmap changed, and no budget moved.
 
Test it: What decision changed after the warning? If the honest answer is none, the warning was never acted on, no matter how many people remember hearing it.
Pattern 3: The Problem Nobody Owns
A week of battery life was the MetaWatch's central promise, and it shipped at three to four hours. Both companies saw the gap. No one owned fixing it. The hardest problem on the project sat on the seam between two companies, and problems that sit on seams get reported, tracked, and carried forward without ever belonging to anyone who can be asked why the problem is still there. We ran that partnership for two years and never settled whose job it was to lose sleep over the one number that mattered most.
 
Test it: Who owns the hardest problem, by name? If the answer is a partnership, a committee, or a pause, then nobody owns it.
Pattern 4: The Pace Mismatch
Earlier, I shared that we ran month-long approval cycles for changes a startup could implement in days. That is a pacing problem: the organization's internal pace versus the market's. A smartwatch in 2011 was a fast-moving product running through slow-moving machinery, and no amount of talent inside the project could close that gap. The delay was structural, not personal.
 
Test it: How long does one small change take to approve, against how fast the market moves? Time a real one. Do not estimate it.
Five Minutes on a Project That Died
The four patterns are the start of your library. Before you use it on a live decision, test it on a dead one.
 
You have a dead project in your past. Everybody does. Pick the one that still stings and give it five minutes against the four test questions.
 
Was an existing success being protected while the project starved, in pricing, staffing, or positioning?

Did people raise a warning, and what decision changed after it was said?

Who owned the hardest problem, and can you name the person?

And how long did a small change take to approve, against how fast the market was moving?

 
When I run the MetaWatch through those four questions, I find all four patterns. Your project will probably show fewer. Every pattern you find is one you will now recognize as it happens on the project you are working on right now.
The Four Steps When You Spot a Failure Pattern
Which brings up the harder half of the skill, because recognition alone did not save us. Suppose you had been standing next to me in 2011, holding all four of these patterns. It would not have been enough. Being right about the future means nothing without the organizational machinery to act on that insight.
 
So when a failure pattern appears on a live project, follow this sequence.
 
Step one: Say the failure pattern out loud, in the room where the decision lives. Not in the hallway afterward. Use the pattern's name.
 
Step two: Get it onto the decision memo. A warning that lives only in conversation changes nothing. Write the pattern and what it costs into a document that will drive a decision.
 
Step three: Attach an owner. If you identify a critical problem, assign it to one person. Not a team or an organization. Someone you can ask next sprint why the problem is still there.
 
Step four: Attach a date. Being early provides an advantage, and a failure pattern without a date on it fades unnoticed.
 
Bill was right for four years, and Apple was the one who acted on it. That could have been us if we'd had the organizational courage to back our vision with meaningful resources.
Conclusion
You now have what nobody handed me in 2011: four patterns of failure, a five-minute check, and the four steps to run when you spot one. What you do in the room where the decision lives is the part Bill's warning never got.
Additional Resources
How HP and Fossil Handed Apple the Smartwatch Market: The inside story of vision without execution: why being right about the future means nothing without the courage to act on breakthrough insights. https://www.philmckinney.com/how-hp-and-fossil-handed-apple-the-smartwatch-market/
The story of MetaWatch with its founder, Bill Geiser: https://www.philmckinney.com/the-difference-between-a-good-idea-and-a-great-idea-is-the-timing-s11-ep25/

Sherlock Holmes never once used deduction.
 
Open any of the stories and watch what he actually does. He notices a tan line on a wrist or mud dried on a boot and leaps to the best-fitting explanation. Then he went looking for evidence. Deduction guarantees its conclusions. What Holmes did was guess. He was better at it than everyone around him because he treated guessing as a discipline.
 
The discipline of guessing is one of the most useful thinking skills nobody ever taught you.
 
Let's get into it.
What Is Abductive Reasoning?
There are three kinds of reasoning. School taught you two of them.
 
Deduction moves from a general rule to a specific conclusion. For example, all mammals have hearts. Dogs are mammals. So dogs have hearts. If the starting statements are true, the conclusion must be true.
 
Induction goes the other way, from specific observations to a general pattern. For example, if you see a thousand white swans, you conclude all swans are white. Probably right, but never guaranteed. Europeans believed exactly that until they reached Australia and found black swans. I covered both in an earlier episode on logical reasoning skills.
 
Abduction is the third kind, the one school skipped, and it runs reasoning backward. You start at the far end, with the result or fact in front of you, then you work back to whatever would explain it. For example, the lawn is wet at six in the morning. You didn't see it rain, and nothing rules out a broken sprinkler. But rain explains it best, so you accept it for now and get on with your day.
 
Notice that you did that without deciding to. You are running abductive reasoning constantly, on faces and sales numbers and to explain the silence after you finish talking in a meeting. We all leap from evidence to an explanation and then treat the explanation as fact. You already know how to do this. What you don't have is the habit of catching yourself at it and doing it deliberately when it matters.
 
Now go back to Holmes. In A Study in Scarlet, the first thing he ever does on the page is shake hands with a stranger and say, "You have been in Afghanistan, I perceive." Holmes explains it later. The man had a medical look but a soldier's bearing. His face was dark, but his wrists were fair, so the tan came from somewhere hot. His left arm hung stiffly, so it had been injured. None of those clues proves anything on its own. Holmes asked which single story would cover them all: an army doctor, wounded and sent home from the Afghan war. That is abduction, not deduction, and Conan Doyle used the wrong word for it his entire career.
Why AI Can't Do Abductive Reasoning
Abduction is the only one of the three that creates a new idea. Deduction draws out what was already inside the starting statements, and induction stretches a pattern you already saw. That difference used to be a philosopher's distinction. It matters now because AI has gotten very good at the other two. AI finds patterns in billions of examples and extends them, induction at a scale no human can match. What it cannot reliably do is face a fact that fits no pattern and come up with an explanation worth betting on. That leap is still uniquely human, and the people who make it well are getting more valuable every year.
 
Meanwhile, abduction as a skill is getting harder to keep, because search engines and chatbots now answer most questions in under a minute, and abduction doesn't work that way. It asks you to live with "probably" for a while, holding an answer you know might be wrong and working anyway.
How to Improve Your Abductive Reasoning Skills
None of this is a talent you either have or don't have. Watch a good doctor or a talented designer at work, and you will see the same four moves. Each one can be practiced.
1. Notice What Doesn't Fit
In 1847, a Hungarian doctor named Ignaz Semmelweis ran a maternity clinic in Vienna. It had two wards, one staffed by doctors and one by midwives, and in the doctors' ward new mothers were dying of fever at three times the rate. Some women gave birth in the street rather than be admitted, and the street births survived at a better rate.
 
Everyone was ignoring the numbers. Semmelweis treated the numbers as the question. What could explain the best-trained people in the hospital losing the most patients? His answer came when a colleague cut his finger during an autopsy and died of the same fever. Doctors went from dissecting corpses straight to delivering babies. Midwives never touched corpses. He ordered handwashing in chlorine, and the deaths collapsed decades before anyone had heard of germ theory.
 
Charles Sanders Peirce, the philosopher who gave the skill its name, built that noticing into his own definition of abduction. The surprising fact is observed, he wrote, and only then does the search for an explanation begin. When something fits what you already believe, we accept it without noticing. Surprise is the alarm that the automatic version has failed. It means the failure that matters happens before any of the reasoning starts. The risk is that you cannot explain a surprise you never see. We have spent years learning to rationalize them away.
 
When reality does something you didn't predict, write it down before you talk yourself out of it.
2. Generate More Than One Explanation
Last week I told you about the chrome-looking keyboard snafu. An HP laptop was running below plan, and none of the data would say why. Before anybody knew about the keyboard, I asked the product team what they thought was happening.
 
I got three answers. It needs more memory. It needs a bigger hard drive. It needs longer battery life. Each one arrived with a competitor's machine held up beside ours. That one has more memory. That one has the bigger drive. Every comparison was accurate, and each one had been picked because it supported the answer.
 
Three explanations sounded like the work was done. All three said the same thing: that we were losing on specifications, which is what the team was already organized to believe. None of the explanations would have sent someone into a store on a Saturday to watch a customer make the purchase decision.
 
So when you catch a genuine surprise, run it through this sequence instead:
 
State the surprise in one sentence. "Sales dropped 15% in a quarter when we improved the product." If you can't state it cleanly, you don't yet know what you're explaining.

Force at least three explanations. The third is usually where the thinking starts, because the first two are the ones everybody already believes.

Include one explanation you don't want to be true. If every explanation on your list flatters you and your team, the list isn't finished.

Write down what each explanation would predict. If A is true, what else should you be able to see? That turns a guess into something you can check.

3. Choose the Best Explanation, Not the First One
Philosophers call abduction "inference to the best explanation," and the key word is "best." Best doesn't mean first, and it rarely means the cleverest.
 
The one you want covers the most facts while assuming the least. Then, before you commit, decide what evidence would make you drop it. A doctor hearing chest pain does this out loud, ruling out the dangerous explanation first even when she expects it to be something ordinary.
4. Hold It Loosely and Test It Cheaply
The best explanation is still a bet, nothing stronger. The moment you forget the word "bet," the skill starts working against you. Many will make a sharp abductive leap, fall in love with it, and then spend six months protecting it instead of testing it.
 
Designers handle this better than almost anyone. A prototype is an abductive test, the cheapest way to let the world argue with your guess before you commit real money. Whatever your field, find your version of the prototype. Good innovators are wrong as often as everyone else. They just find out sooner, and it costs them less. 
Try This Before Friday
Think of the last thing at work that went differently than you expected. A deal that died, a number that moved the wrong way, a good person who quit. You already have an explanation for it. Notice how fast it came. Somebody asked what happened, and you had an answer before they finished the question, and everyone nodded, because it was reasonable, and reasonable answers end conversations.
 
Go back to it this week. Not to find out whether you were right, because you were probably close enough. Go back because two other explanations fit those same facts and you never considered either one. Find them, and make one something you would rather not be true.
 
Then find the smallest test that would tell them apart. A phone call. One question to somebody who was in the room. It is almost never expensive, and that is the part worth sitting with, because it means the answer has been sitting there the whole time and nobody went and got it.
Conclusion
Abductive reasoning is how new ideas enter the world, and Holmes made a career of it under the wrong name. The more leaps you make and test, the sharper the next one gets.

Think about the last thing you almost bought and did not.
You picked it up, you looked at it, you put it back down. You had a reason for choosing one item over its competitors, and you know exactly what it was.
Did anybody ever ask you why you didn't choose the loser?
Of course not. And somebody did the same thing to you this week. Something you made, or wrote, or suggested. An idea you put into a meeting that got a polite nod and then went nowhere. They considered it, decided against it, and you never found out the real reason.
Almost everything that comes back to you comes from the people who said yes. Inside a business, the machinery makes that official. Satisfaction surveys go to people who have bought. Reviews come from people who have bought. The customer list is a list of people who have bought. The one who put it back down is invisible to all of it, and that person is holding the answer.
So, where do you point a question to reach somebody who is not there?
Last week, we took a question apart and rebuilt it. But a well-made question aimed at the wrong thing comes back empty. Where you point a question is the other half of the skill.
Forty-two cards of Killer Questions
A killer question is one that has been tested and proven to spark ideas beyond the obvious. The name comes from the old phrase "killer app," where "killer" meant standout, not lethal. I built this collection of questions the slow way.
I designed structured tests into my innovation workshops, which I was running: specific questions put to specific groups, and a record of what each produced. The rule for keeping a question was that it had to trigger something in that room. Did somebody walk out seeing their customer, their product, or the way they work differently than when they walked in? If nothing moved, the question was cut. If there was a good idea underneath one and I had simply worded it badly, I rewrote it and ran it again in another workshop.
There were hundreds of questions, and most did not survive. Forty-two did.
When I sorted the survivors, they fell into three groups. Not by subject. By where they aim your thinking. 
Three places to aim
Every question in the deck points to one of three things. Who, what, and how.
WHO is the person or organization who will benefit from what you make. Usually, your customer, though the gap between "usually" and "always" is where a lot of new business hides.
WHAT is the product, the service, the solution that creates the value for the WHO.
HOW is the way your organization builds, delivers, and supports the WHAT for the WHO.
Three places an idea can come from, and the questions exist to send you into each one on purpose rather than by accident.
The cards all say "product." Read that as whatever you make for somebody else. A service counts. So does a proposal you hand to your boss.
Thirteen of my cards aim at WHO. Thirteen at WHAT. Sixteen at HOW. That split was never a plan. It is where the questions that kept surviving pointed, and eventually, I stopped arguing with it.
WHO
What are your unshakable beliefs about what your customers want?
The phone companies believed their customers wanted reliability above all else, and they were right. For a century, they built toward 99.999 percent uptime. A dial tone that worked in a storm, in a power failure, always.
Then somebody turned that belief over and looked at it with no assumptions about what the customer wanted. Where were there people who would give up call quality for something else?
That is the question that led to voice over IP, a phone call carried over the internet. In the early days, it sounded terrible. Calls dropped. By the standard the old industry had spent a century perfecting, VoIP was not a serious product. But underneath it sat an idea nobody in that industry had allowed themselves to consider: that many people would trade call quality for price and mobility, and would do so happily.
They did. That market opportunity existed before anyone built it, waiting for someone willing to challenge the old standard on its head. 
WHAT
What is surprisingly inconvenient about my product?
It does not ask whether the product is good. Your team will defend that all day, and they will be partly right, which will only make the conversation worse.
Surprisingly inconvenient means some part of using your product that nobody inside your company has ever seen a real person struggle with. The fifteen minutes with the instructions. The step everyone on your team skips automatically because they built the thing.
On the back of that card sits the shortest useful question I own: "Do you use your own product yourself?"
Hold on to this one. In a few minutes, it turns up at a Best Buy, and the strange part is that I wasn't aiming at it when I found it.
HOW
What do people not like about the buying experience for my product?
For the whole time I was CTO at HP, I spent nearly every Saturday in a Best Buy. While traveling, I found a local electronics store in whatever country I was in. I was not shopping. I was standing in the aisle watching strangers choose, because this question has no other answer. You cannot survey somebody who did not buy. 
My family called it my "digital stalking". My kids would have done almost anything else rather than be seen with me in a Best Buy on a Saturday.
When somebody picked up a competitor's product and headed for the checkout, I would walk over, introduce myself, and ask what made them choose that one.
I did it long enough that the sales staff around Silicon Valley knew me, and would change how they talked to a customer if they saw me standing there. Stay somewhere long enough, and you stop being an observer. You influence what you are measuring.
Then came the Saturday that changed a product.
A customer set down an HP laptop and bought a competitor's. I asked him why. He told me he could not see the keys. This was during the stretch when every laptop was going aluminum, and somebody in our laptop group had given ours a chrome-looking keyboard. High gloss. On a store shelf, it looked expensive, which is exactly what it was designed to do.
It also meant that anyone whose eyesight had started to go could not read the letters on it.
Sales on that product had been running under plan, and nothing in the data said why. We changed the keyboard back to matte black with high contrast white lettering. Sales went up on that one change.
No survey would have revealed the issue. By the time he told me, he was already somebody else's customer.
Notice what that question actually turned up. I went into the store carrying a HOW question about the buying experience. What came back was a WHAT answer, something surprisingly. Inconvenient about the product itself. You choose where to aim. You do not choose where the answer comes from.
Testing for Great Questions
How do you find and test great questions?
Ask the question, then watch what happens in the next four seconds.
If the room goes quiet, and then somebody says, "Hang on," you are holding a good one. That pause is the sound of a person arriving somewhere they have not been. You just unleashed a great question.
If someone answers immediately and confidently, the question isn't that great. A fast answer means you aimed where the team has already been, and they are reciting. I threw away hundreds that way and got down to the questions that caused impact.
Practice Exercise 
Take a decision you are facing this month and give it ninety minutes.
Start with whichever of the three you are least comfortable with, which for most people is HOW. Take a question from it at random. Do not hunt for the one you like, because the one you like is the one you have already answered. Set a timer for thirty minutes and write down every idea that question produces. No judging, no editing, just quantity.
Then do the same thing with a question aimed at your customer, and again with one aimed at the product. When you have worked through all three, read back over everything and pick the best three ideas to start on.
That is how you run it on your own. If you would rather do it with a team, there is a second version designed for groups of 4 to 6 people. Both are written out step by step on killerquestions.com, so you are not working from memory.
You can buy the deck at innovation.tools, either as printed cards or as a digital download for your phone, tablet, or PC. 
Send me the question that worked best for you. I am also still on the search for new questions for volume 2 of the card deck. Send your suggestions, and they might just be included.
That closes out this three-part series on questions. If you came in at the end, part one is about why you cannot stop yourself from answering a question, and part two is about how a single word inside a question steers the answer you get back.
The next episode is about abductive thinking. Deduction hands you a conclusion you can prove. Induction hands you a pattern you can bet on. Abduction is what you reach for when you have neither and still have to decide, which is most of the time. It is how a doctor arrives at a diagnosis, and it is how most real innovation actually happens.
Subscribe wherever you watch or listen, and you will get that one when it lands.