Advertise on podcast: The Innovators Studio with Phil McKinney

I cried on stage this week, in front of thousands of people. In front of the entire industry. The press in the room wrote about it. I couldn't believe it. Some people will tell you it isn't becoming for a CEO to cry in public, much less in front of the entire industry. They'll tell you it isn't good executive presence. So let me explain what happened in Atlanta last week. Let's get into it. On the Main Stage in Atlanta Last Tuesday I was in Atlanta for SCTE TechExpo, on the main stage for the opening session. Three of us were on stage: Chris Winfrey, chairman of the CableLabs board and chairman and CEO of Charter Spectrum; Mark Bridges, who takes over as CEO of CableLabs in January; and me.  Let me give you a little context on how I got here. I was previously the CTO at HP, and I left at the end of 2011 thinking I was retiring. A week later, CableLabs called. Over the next five months, retiring turned into moving to Colorado to run CableLabs.  I didn't come from cable. That wasn't my background. I'm grateful the board took a chance on an outsider, and glad I said yes when I wasn't sure what I was jumping into. The last two times I retired, from Teligent after the IPO and from HP, the next role came looking for me. This time, if anyone comes looking, I'll tell you right now: the answer is no. Innovation Is a Team Sport I've said this many times, here on the show and in the innovation boot camp courses I teach. Innovation is a team sport. That means the CableLabs team, the operators who fund the research lab, and our vendor partners. We could not have achieved our success without that community and the effort of everybody in it.  Some of the articles are highlighting things that happened over my fourteen years, but none of it happened because of one person.  This is by far the best job I have ever had, bar none. That's also why it is so hard to step away. That's what hit me on stage. It felt like I was saying goodbye to an industry and a CableLabs team I've been part of for fourteen years. Then I looked over and saw my grandson in the front row. Good Succession Plans Take Time I never wanted to be the leader gripping the desk, where someone has to pry his fingers off and push him out the door. I wanted to make the transition when I felt my successor was ready. Good transitions are not single events. It isn't the press release where you announce the new person and ride off into the sunset. A good succession plan is deliberate, and it takes time. Ours started 18 months ago, with me talking to the board of directors about my personal intent and about who I felt was ready. At CableLabs, we run a world-class succession process. For the last eight years, we've met with the board once a year and reviewed successors for every executive function at CableLabs. So the board knew our bench, how deep it was, and our plan to prepare people to step up into the next role.  Mark Bridges is my successor as CableLabs CEO, and he is absolutely the right guy. He's been with CableLabs longer than I have - 16 years - and we've worked as a team for a decade. He's been our CTO for the last three years, and on August 1, he became president. He knows the organization and the CEOs of all our member companies. The board is unanimously united behind him, and so am I.  I'm handing off roles and functions as we go, so that on January 1 he takes over the CEO title. I've also committed to both the board and Mark that I'll stay available to advise them throughout 2027. Who Is Ready to Step In for You? Let me ask you a question.   If you left your role in 90 days, who is ready to step in and take on your function?  If you think holding on to information makes you harder to replace, you're thinking it wrong. Strong leaders plan for their succession. You may have to leave for a medical reason or a family reason. Either way, you do not want to leave your organization in the lurch. So, who is ready? If you don't have anybody, start working on it now.  The other question: which relationships exist only in your head or on your phone? Are you hoarding them, or are you sharing them with the person you've identified as your successor?  If you want to be remembered as a model leader long after your career, leave the organization stronger than you found it, and hand it to somebody ready to take it further. Why Now? The question everybody asks is, why now, Phil? Why retire now?  Age is part of it. I'm 66. But the real reason is my grandkids. I have five, ages 10 to 14, and I want to go do things with them. The oldest leaves for college in a handful of years, and I know how fast that clock runs. My 14 years at CableLabs flew by, and the years are going even faster now. I want to spend the time I have left with them. What's Next What I'm committing myself to is building the next generation of innovators. The YouTube channel and the podcast are staying. That's my investment in innovators out in the world. I'm also making that investment at home, in my grandkids.  I have two book projects underway: one on critical thinking and one on innovation. The first four chapters of the critical thinking book, Mindjacking, are available to paid subscribers on Substack.  I'm not disappearing. I'll still be here regularly doing shows. I may take a break here and there, depending on what my grandkids are up to. But I'll be on the YouTube channel, putting out the podcast, and writing on the blog. Liam on the Show Floor Atlanta had a unique twist. I brought one of my grandkids with me: Liam, my second oldest, who is 13. I brought him to Expo to show people what was driving my decision, and he spent the entire week at the show. Liam is outgoing and personable. He isn't shy, and he engages with adults all the time. He went around to the booths, and many vendors on the show floor came up to tell me the hardest questions they'd ever been asked came from my grandson. Questions like: What's your product about? How does it work? Can I see how it works? Who are your competitors, and how are you different from them? What problem are you trying to solve for your customer? I was sitting back chuckling. Liam watches every episode of this show on YouTube, and he drills me on the details and the background over our Sunday family lunches. Somewhere in those conversations, he learned the power of a good question. At Expo, he put it to work, using questions to engage the people in the booths and learn from them. He made an impression on many people. Chris Winfrey commented on how impressive Liam was when they met: a firm handshake and good eye contact. I'll admit my bias here. All five of my grandkids are pretty great, and I'm excited for January, when I get to devote my time to them. What Is Your Legacy? I want to use all of this to help you think something through. What is your legacy? Do you think it's your career and the products you introduced? Who will talk about you two generations from now? My grandfather taught me to ride horses during our summer visits to Kentucky. He instilled in me the saying, "A job worth doing is worth doing right." He died when I was 7, far too young, and I still think about what else I could have learned from him. I came to a realization while telling my grandkids stories about him. I am my grandfather's legacy. I tell them about the impact he had on my life, and I want to be that for them. My grandkids are my legacy. I don't want them to have the same regret I do. So what are you building that someone else can take further? It might be your grandkids. It might be the person who will succeed you in your job, whether you have to leave or you decide to retire. Think it through. Don't wait and don't let things just happen.

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 Els

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 heal

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.

In 1974, a psychologist named Elizabeth Loftus showed a group of people a film of a car accident. Afterward, she asked half the group one question: how fast were the cars going when they hit each other? The other half got the same question with a single word swapped: smashed instead of hit. The smashed group estimated higher speeds. Same film. Same crash. One word.   A week later, everyone came back and answered a new question: Did you see broken glass? There was no broken glass in the film. The smashed group remembered it anyway. One word inside one question changed what people reported seeing. Then it reached back and rewrote what they remembered. Somebody did this to you this week. A question steered your answer, and you never noticed. Last week, I showed you that your brain cannot refuse a question. You hear one, you start answering, whether you agreed to or not. This week is the other side of that power. If every question forces an answer, then how the question is built decides which answer you get back. Questions have an anatomy. Almost nobody looks at it. Before we're done, a motorcycle taxi in Bangkok is going to show you what a question built right can find.  Let's get into it. ===== Every question you ask carries three things, whether you put them there on purpose or not. It carries assumptions, the things it treats as already settled. Ask "Why did the launch fail?" and you've ruled the launch a failure before anyone speaks.   It carries scope, the range of answers it permits. "Coffee or tea?" permits exactly two answers. "What should we drink?" opens the room.   And it carries a load, the specific words that steer the answer. That's what "smashed" did. Nobody in that study felt steered. The steering is invisible to the person answering, and most of the time to the person asking too.   Once you see the parts, you can take any question apart. Take "why did the launch fail?" one more time: it assumes failure before anyone answers, its scope is only explanations, and "fail" is the loaded word doing the steering. Hold on to that one; we'll rebuild it later. Let's start with the ones built to do damage. The worst question in business "That presentation was fantastic, wasn't it?" That's a tag question: a statement dressed up as a question, built so every answer is closed off except agreement. The person asking isn't really asking, not in any way that risks hearing something different. They're collecting a signature. When lawyers use them in court, it's called leading the witness. When managers use them in conference rooms, it's called alignment. Tag questions did damage for years at HP, in the design reviews, every product went through before customer briefings. One review was for a prototype, one of our first laptops in what's now called the "thin and light" category. The product team wanted to lead that category without straying too far from what already sold. That's the tradeoff tag questions live in. Nobody wants to sound negative about it. So the pushback arrived dressed as agreement: "We'll still have four USB ports, right?" You don't get thin and light with a case full of legacy ports, and the designer knew it. I watched the exasperation cross his face. Before it became a battle, I stepped in and rebuilt the question: "What's the right mix of ports for this segment, and why?" Then: "Have we tested that mix with the target customers?" The answer came back fast. "No need. We know what the customer wants." I nearly smacked my forehead. One rebuilt question had uncovered the real problem, and it wasn't ports. It was an untested assumption sitting in the middle of a flagship product plan. That's what tag questions cost you. The entire point of asking a question is to get information, input, or ideas. A tag question collects compliance instead. Enough of them, and people stop bringing you anything you don't already believe. The two kinds of good questions Real questions are split into two categories: factual and investigative. A factual question retrieves information. How many units did we sell last week? You may not know the answer, but you know exactly how to get it: one phone call. Factual questions keep the world running. They just can't uncover anything because they only retrieve what somebody already knows. An investigative question can't be answered with a yes, a no, or a lookup. It's divergent: more than one correct answer exists, so the person answering has to go investigate. You felt this difference last week. "What is half of thirteen?" is a factual question. "How many ways could you answer: what is half of thirteen?" is an investigative question. One is arithmetic. The other is the one that a classroom answered thirty-two different ways. Socrates built his entire way of teaching on investigative questions, pushing every student past "I've heard it said that..." until they could say what they themselves thought, and why. The first step toward knowledge, he insisted, is admitting yours is incomplete. So here's the definition I've worked from for years. A great question makes the other person genuinely think before they answer, and it surfaces an insight that had been eluding them. Both halves matter. The first half costs you real effort. The second half is the payoff: you see something you've been looking at for years and never actually seen, and it surfaces possibilities you'd never have found on your own. How to build one How I build them is with four moves, in the order I use them. You already watched three of them work in that design review. Strip the answer out. Read your question and find the smuggled conclusion. "Right?" and "wasn't it?" come off first. Then the buried assumptions. "Why did the launch fail?" becomes "what happened when we launched?"   Open the exits. If it can be answered with yes, no, or a single lookup, it's factual. That's fine when information is all you need. When you want discovery, rebuild it until more than one correct answer exists. The rebuild is usually small. "Should we do this?" becomes "what are the ways this could work, and what are the ways it dies?"   Weigh every word. This is Loftus's lesson. "How do we make this cheaper?" and "what happens if we triple the price?" point at the same product, and they will never produce the same ideas. There is no neutral wording. Every word carries load, so choose it deliberately instead of inheriting it.   Aim it where nobody is looking. If you can already predict the answer, the question is just decoration. Point it at something unexamined: the assumption everyone stopped checking, the customer nobody ever talks to. A great question should surprise you.   What a well-built question uncovers Late 1994, Bangkok. Half an hour stuck in traffic, twenty-eight minutes until a critical meeting. At eighteen minutes, I gave up, jumped out of the limo, and hailed a motorcycle taxi. 125ccs of terror, flat out through the heat, my briefcase clutched to my chest. Somewhere between the tuk-tuks, I started thinking about the machine underneath me. Cheap, efficient transportation. The streets were flooded with them. And on the other side of the world, Harley-Davidson was selling motorcycles as big-ticket luxury. A product that began as cheap transportation for the American working man had become a premium item that people waited months for. In that evolution, somebody had to ask a question like this: What if we stop trying to make this cheaper and go the other way? Everything needed to see that opportunity had been lying in plain sight for decades, waiting for someone to ask for it. That's the payoff of this craft. The next discovery in your business is probably sitting in an assumption nobody's checked in years, waiting on the right question to find it. Practice Exercise: Before your next meeting, write down the one question you most need to ask, exactly as you'd naturally say it. Then take it apart on paper. What does it assume? What answers does it permit? Which words are steering, and in what direction? Rebuild it with the four moves and ask for the rebuilt version instead. Pay attention to what comes back that the original never would have surfaced. Conclusion This is part 2 of a three-part series on questions as the skill behind better thinking, better ideas, and better innovation. Next in on the specific questions I spent twenty years collecting and testing, the ones that reliably uncover what everyone else misses. Full show notes for this episode are up at philmckinney.com. And if you want more than the show episodes, check out my articles over on Substack, including the first four chapters of my next book.  Subscribe on YouTube or wherever you get your podcasts so you don't miss the next episode, and don't forget to hit the notification bell if you want to know the moment it's up.

What is half of thirteen? Stop. Answer it. Don't think ahead, just answer. You said 6.5. I know you did, because everyone does. Nobody chose to answer that question. Your brain solved it before you decided whether you even wanted to play along. That's the power of a question: whoever hears it cannot stop themselves from answering. Ask a person something and their mind starts working on it right away, whether they wanted to or not.  If you gave that answer on a math test, it would get ‌marked as correct. Give that same answer on a test of innovation, and you're average, because that's where everyone stops. Push beyond the obvious answer, and that's what puts you top of the class. Here's the version of the question that changes everything: How many ways could you answer "what is half of thirteen?" Sit with that for a second, because the honest reaction most people have is mild panic. There's the obvious one. Then what? Split the number down the middle and you get a 1 and a 3. Split the word into syllables and you get "thir" and "teen." Every one of those is a real answer. None of them occurred to you the first time, because the first time, your brain wasn't looking for options. It was looking for an answer to the question. I've run this exercise for years in my Innovation Boot Camp and the Innovation Essentials Workshop. One professor who uses my book in their class now opens every semester of her course with it. The class brainstorms as many answers to the question as possible. The record so far is thirty two different ways to answer that one question. And remember, asked the first way, that same question only gives you one answer. This isn't just a classroom trick. Researchers have measured this exact mental muscle since the 1960s, asking people how many uses they could find for a brick. Some people list four. Some list forty. The gap between those two people has nothing to do with intelligence. It's whether their mind treats the first answer as the end of the search or the beginning of one. Practice Exercise: Take one recurring question: a decision at work, a plan for the weekend, even "what should I make for dinner." Before you settle for the obvious answer, ask "how many ways could I answer this?" and write down at least ten. Not ten good ones, just ten. See where the eleventh one takes you. This part 1 of a three-part series on how to use questions as the skill behind better thinking, better ideas, and better innovation. Next week, we get into what actually separates an average question from a great one.

You trust your gut because it's been right before. But "right" is exactly the thing you've been measuring wrong. A hitter never has this problem. His batting average is honest. It counts hits, nothing else, across a whole season, and he can't argue with the number. Your gut is supposed to work the same way: every decision an at-bat, every result feedback, a career sharpening your instincts the way a season hands a hitter a real number. But you keep your own scorebook. You mark every win as good judgment the second it lands. The trouble is that a skilled call and a lucky one produce the same win. In your book they look identical. Train your gut on that for thirty years and it grows certain about things that were never true. I know, because I trained mine that way. The Award and the Bankruptcy At twenty-eight, I won, and the win felt like proof. I was at a company called ThumbScan, and I took a piece of government security technology and repackaged it for the business PC market. We called it PCBoot. PC World named it Security Product of the Year at COMDEX in Las Vegas, in front of the whole industry. I drew the obvious conclusion. My gut was good. I could see what the market wanted before the market did. Except I didn't see it coming. In early 1988, computer viruses became front-page news. The New York Times ran it on the front of the business section, the story spread to nearly every paper in the country, and overnight every company in America decided it needed security. My product was already built and sitting on the shelf when the panic arrived. I had built a solution that needed a problem, and the people writing and spreading those viruses are the ones who handed it one. It was nothing I did. I hit the timing right, and the timing was luck. It took an honest audit, years later, to admit that, and the same look turned up the opposite story. The other ThumbScan product was the one I was proudest of. It put fingerprint security on a personal computer, the first one under a thousand dollars you could attach to a PC. Your thumb instead of your password. The reasoning was sound and the technology worked. The market wanted none of it. PCs were barely in homes yet, biometrics sounded like science fiction, and the company bled cash and folded. That product wasn't worse thinking than the one that won the award. It was the same thinking, aimed at an idea that turned out to be twenty-five years early. Today it sits on every phone, and hundreds of millions of people use it before breakfast. I wasn't wrong about the concept. I was wrong about the clock, and the clock runs mostly on luck. The award and the bankruptcy came out of one gut, separated only by the year each idea landed in. What I did, years later, has a name. I ran the version of events that didn't happen, stripped the result off each decision, and looked at the call cold. That's counterfactual thinking, and it's the whole skill. It's uncomfortable, because the result already handed you a verdict and now you're reopening it. It's also the only feedback that makes you better. Why Your Results Lie to You None of this is your fault. It's a measurement problem. Your gut got trained on bad data, and it had no way of knowing. The more decisions you've stacked up, the more confident it's become, and confidence built on a bad stat is worse than no confidence at all. A junior person knows they're guessing. Twenty years in, the guessing feels like knowing. Your own record is full of the same thing. Wins you credited to your own judgment when they really came down to timing, or to a competitor's mistake you had nothing to do with. Good calls you stopped making because one of them lost, even though losing was always on the table and the call was still right. None of that is carelessness. You recorded every result accurately. You just recorded the wrong thing, and then you trained on it. The world isn't helping. Every outcome now arrives with its explanation already attached, ten confident takes by lunchtime, most written backward from the result. I covered that warning in "Hindsight Is Not 20/20." So go back and run the audit on yourself. Rebuild what you knew on the day you decided, set the result aside, and ask whether the call still holds up without it. The hard part is doing this to wins, because taking apart a success while you're still proud of it feels like bad manners and bad luck at once. That's the reason your wins are where your worst lessons hide. Read Your Competitors' Moves You just watched me run this backward, over my own record. It points two other directions too. The first is sideways, at everyone else. The same move works just as well on decisions that aren't yours. When a rival's bet pays off, the instinct is to copy it. When it craters, the instinct is to swear it off. Both stop at the result. So rebuild their decision the way you rebuilt your own. Say a competitor ships a feature and it takes off, and three teams in your space scramble to copy it. What they miss is that the feature didn't carry the launch. It landed the week the category leader had an outage, and every angry customer went shopping. Copy that same feature into a calm market a year later and nothing happens, because you copied the move and not the moment. You're hunting for the hinge, the single thing the outcome really swung on, and it's rarely what the headlines credited. Get this wrong and you don't copy a rival's strategy. You copy the luck that came with it, and luck doesn't travel. Pressure-Test Your Next Decision The other direction is forward, into a choice still in front of you, and it's where the skill pays you back the most. Most of us pick options by their best case. You picture each road going well and take the one that goes best. Turn that around. Walk each option forward until it falls apart, because every option falls apart somewhere, and the one you can't picture breaking is just the one you haven't looked at hard enough. Pull in the alternatives you've already talked yourself out of, and count doing nothing, since that's a choice too. Then decide on the part nobody likes to look at: the downside you'd have to live with. A modest plan you can walk away from beats a brilliant one that takes you down with it. Most decisions that seem obvious stop seeming that way once you walk the alternatives all the way out. The ones that still look right after that walk are the ones worth making. Practice Exercise: Audit a Win You're Proud Of This is the drill that matters most, and the one you'll want to skip. Pick a win from the last year. Not a loss. Something that worked, that you've been glad to take credit for. Write down what you knew the day you decided. Only that, nothing you picked up afterward. Run the version where it went the other way. How close did it come, and what would have had to break differently? Answer straight. Good decision, or good result? If it's hard to sit with, you're doing it right. The wins you can't bring yourself to examine honestly are the ones costing you the most. A good decision and a lucky one keep looking identical until you do the work to tell them apart. Do that work often enough and you stop mistaking the breaks that fell your way for things you did well. Over a career, that is most of the gap between people who get reliably good and people who just had a good run.

Everyone collects weak signals now. Most of what they collect predicts nothing. A weak signal isn't a thing you spot, it's a prediction you make, and the edge goes to whoever bets on it while being wrong is still cheap. So how do you become the one placing the bet, not the one still collecting reports? Let's get into it. What a Weak Signal Actually Is A weak signal is a faint piece of evidence that points to something a customer will want before they can name it, and before the market has priced it in. Faint, because if it were loud, everyone would already be acting on it. Deniable, because you can always explain it away as noise, and most people do. That deniability is the whole point. The moment it becomes undeniable, the advantage is gone and the price has moved. Why Noticing Stopped Being the Edge Ten years ago, noticing was hard. You needed sources, a network, time to read widely, a feel for the edges of your industry. That was the moat. It isn't anymore. Every team has a trend report and three newsletters and an AI tool surfacing emerging behaviors on a schedule. The noticing got automated. What didn't get automated is the judgment about which signal predicts a structural change and which points to nothing real, and the nerve to act early. Inside Roche's Innovation Board I sat on Roche's diagnostics innovation board, the only outsider in the room, helping decide which ideas got funded. At one point we took on diabetes care. I am not diabetic. So I had Roche ship me every meter and test strip they made, and I pricked my finger up to a dozen times a day to feel what their customers felt. You cannot innovate for a customer whose day you have never lived. Skip that, and everything after is a guess. Roche was a leader in blood glucose testing with its Accu-Chek meters, and the math looked obvious. Someone with type 1 diabetes tests around eight times a day, every day, for life. A big, stable business. Type 2 was the smaller story per patient. Those patients tested once, maybe twice a day, so each one looked worth less, and we filed the category under "less interesting." We could already see type 2 climbing. We weighed it against the per-patient math and explained it away. Then type 2 diagnoses exploded into one of the fastest-growing chronic conditions in the world. And the category stopped being about counting tests per day at all, because monitoring went continuous, the always-on sensors people wear today. We had seen the early edge of both shifts. We even predicted them. We just didn't move fast enough, and the reason is the one that kills most weak signals inside a big company. Project approval and annual budgets are built to fund what's already proven, not to chase something still faint. Roche got there. Accu-Chek SmartGuide, its real-time continuous monitor, is on the market now. I just wish we had moved the moment we saw it, instead of waiting for the next budget cycle to make it safe. How to Read a Weak Signal We didn't miss the type 2 signal for lack of noticing. We noticed. We missed it on the three things that come after, and those you can train. The moves start once you've got a signal you can't quite dismiss, and the skill is what you do with it. Tell the Canary From the Costume A canary in a coal mine matters because the air changed. It signals something structural, a shift in the environment that affects everyone in it, whether they've noticed yet or not. A costume is the opposite. A few people put it on, it's striking, it spreads for a season, then they take it off and the room is exactly as it was. On day one the two look identical. A behavior appears, it's unusual, it's spreading. The only question that matters is whether it predicts a change a customer can't reverse, or a moment that will pass. Back in 2018 I wrote about telling a trend from a fad, and the test still holds: ask what need the behavior reveals. Type 2 was a canary, and we read it as a costume, because we counted testing frequency instead of the need underneath it. That need, millions of people learning to manage a lifestyle disease, only grew. The discipline is refusing to let the size of the spike tell you which one you're looking at. Costumes spike too, sometimes higher. You're reading for the need, not the noise. Read the Window A signal's window is short. Too early, you can't tell it from noise and you waste resources chasing ghosts. Too late, it's obvious, everyone sees it, and the advantage is already priced in. The value lives in the narrow gap between. Waiting for more evidence feels like better judgment, but the evidence that finally convinces you has already reached your competitors. Certainty and advantage move in opposite directions, so by the time you're sure, sure is just another word for too late. The question isn't whether the signal is real yet. It's how much longer you can be the only one taking it seriously. Act While Being Wrong Is Cheap This is the move that separates the people who read signals from the people who collect them, and almost nobody is willing to make it. A signal you predict but never act on is still just watching. Ideas without execution are a hobby, and I'm not in the hobby business. The whole value of an early signal is that you move before it's confirmed. Wait for proof and you've waited too long. So you act on thin evidence. And thin evidence is wrong a lot, which means you will be wrong a lot. People hear that and freeze, because they picture the cost of being wrong as the failed product, the wasted year, the budget burned on a guess. People call that caution. It isn't. The skill is structuring the bet so that being wrong is cheap. You don't commit a product line to a deniable signal. You commit a prototype. A landing page. One conversation with ten customers. A two-week test that costs you a sprint and buys you information you can't get any other way. Being early and wrong should cost you a week. Being early and right should put you a year ahead. You're not betting on being right. You're buying the option to be right, cheap enough that being wrong doesn't hurt, and you scale up only as the signal firms up. That's why the noticing crowd never gets here. Noticing carries no risk, so it never builds the muscle for cheap commitment. They watch, they report, they wait for certainty, and they call it foresight. It's the safe choice, and it's worth nothing. Practice Exercise: Run a Signal Through All Three Pick one behavior you've been dismissing as noise. Something you've seen more than once, in your customers, your kids, your own habits, that you waved off because it looked too small or too strange to matter. Then run it through the three moves. Canary or costume. What need does the behavior reveal? A need the person can't go back from, or a novelty they'll set down in a season? Write the answer in one sentence. If you can't, you don't understand the signal yet. Find the window. How much longer does this stay deniable? Who else is likely seeing it? If the honest answer is "it already feels obvious," pick a different signal. You're late on this one. Design the cheap bet. What's the smallest thing you could do this month to test whether you're right, where being wrong costs a week and being right puts you ahead? Name the bet. Name the cost. Name what you'd learn. Do this with one real signal and you'll feel the difference between collecting signals and using them. Collecting is comfortable. Using one costs you a decision. If you want a sparring partner for that, I built one. From Signal to Bet is a set of AI prompts that run a signal through these same three moves and argue with your read at each one. It's free at innovation.tools. The exercise teaches you the moves. The prompts make you defend them. The signal was always there, for you and for everyone reading the same reports you read. The edge was never in seeing it. It was in what you were willing to do before it was safe to do anything at all. Get good at that, and you stop reacting to the future and start arriving early.

In 2000, Toys R Us paid Amazon $50 million a year to sell their toys online. It looked like a great deal. The company that defined toy retail for two generations was solving the internet problem in one move. Four years later they were suing each other. Seventeen years later Toys R Us was gone. Every store closed. Every job lost. And every step of what happened was visible from the day the deal was signed. Nobody at Toys R Us saw it. What Is Second-Order Thinking? First-order thinking asks what happens next. Second-order thinking asks what happens to the people who see what happened next. The skill isn't caution. It's the willingness to keep looking after the room has stopped. Inside HP, 2006 In 2005, HP launched Halo, a premium telepresence system co-developed with DreamWorks. For a brief period it reported into my organization. The next year, Cisco launched TelePresence and went straight at us. I called the HP team closest to Cisco and asked what they made of it. The answer was reassuring: Cisco is aiming down-market, we're fine. We were premium; they were chasing volume. That answer satisfied the room. It did not satisfy me. The room was asking "will Cisco hurt Halo?" That was the wrong question. The right one was sitting underneath: why did our partner of twenty years decide to do this without us? Nobody had an answer to that one. The HP team didn't think it was the question. They were focused on the product collision, and I kept coming back to the partnership. A company that had cooperated with us for two decades had just decided they didn't need to anymore. The product was the surface. The relationship had quietly ended, and we were the only ones who hadn't noticed. Three years later, Cisco launched a direct attack on HP's core server business with Unified Computing System. HP responded by acquiring 3Com and going after Cisco's core networking business. A twenty-year alliance ended in under two years. Neither side ran the second-order analysis at any point along the way. By the time the right question got asked, the partnership was already gone. The Three Skills These three skills stand on their own. Each one solves a different problem most decision frameworks miss. The first picks up signals before there's even a decision to analyze. The second uncovers what's actually driving the other party's timing. The third shows you what people will do once they see your decision land. If you've watched the November 2025 episode on the basics of second-order thinking, these skills add to that foundation. If you haven't, you can still apply all three starting today. Sense the Weak Signal, Not the Loud Event Most failures don't announce themselves. The loud event, the launch, the lawsuit, the lost customer, is usually the visible end of something that started much earlier as a quiet shift somebody noticed and explained away. A weak signal is a small piece of information that doesn't fit the story you're already telling. A customer's casual comment that contradicts your data. A team member's evasive answer in a status meeting. A supplier missing a deadline they've never missed before. The reflex is to make it fit the story you already believe. The skill is to refuse. Go looking before you have one. Once a week, scan three places where weak signals live. Customer-facing teams. Data points that surprised you and got brushed off. Topics that smart people you respect are paying attention to, but you aren't. You're not looking for problems. You're looking for things that don't quite fit. Name the thing that doesn't fit. Be specific. "Their CFO made a comment about the budget that didn't match what we were told last quarter." Not "something feels off." The more specific the signal, the more useful it becomes. List the stories that would make the signal make sense. At least three. Force yourself to consider explanations that don't fit your current assumptions. Ask which of those stories you'd act on if it were true. If one of them would change a decision you're about to make, that's the signal you can't afford to ignore. Find one more data point before you decide. A single signal can mislead. Two signals pointing the same direction is usually real. The Cisco TelePresence launch was a weak signal about the partnership. The team read the product. I read the relationship. Neither of us pushed it far enough. Ask "Why Now" Before "What's Next" Most people jump straight to the future: what will the other party do next? That's the wrong starting question. Ask why now first. Why is this happening now, when it could have happened a year ago? The timing tells you what changed in their world, and that change tells you what they're likely to do next, often more reliably than asking the question directly.   State the move that just happened. A competitor launched a product. A regulator opened an inquiry. A customer asked for a discount. Name it plainly. Ask what changed. What was true a year ago that isn't true now? What can they do today that they couldn't do then? Their capability, their pressure, their read of you, their read of the market. Identify the shift. Use the change to predict their next move. What's the natural follow-on from the thing that made this move possible? That's usually where the real consequence lives.   Cisco didn't enter telepresence in 2006 because telepresence was suddenly interesting. They entered because they'd decided the partnership with HP no longer constrained them. "Why now" would have surfaced that. "What's next" wouldn't have caught it in time. Watch the Response, Not the Result Your decision produces a result. The result triggers a response from everyone watching, your competitors, your customers, your team, your investors. Most analysis stops at the result. The response is where the actual consequence lives.   Toys R Us could have predicted that Amazon would sell more toys. That was the result. What they didn't predict was Amazon's response: opening the platform to third-party sellers, learning the toy business, and using the data to compete directly. By the time Toys R Us understood the response, Amazon had already replaced them. State the immediate result of your decision in one sentence. What will be visibly different in the world after you act? List who can see that result. Be specific. Name people if you can, not categories. For each one, ask: what does the result tell them about you? Your priorities, your weaknesses, your appetite. The result is information about you they didn't have before. Ask what they're now in a position to do that they weren't before. The result changes what's available to the other actors, not just the market. Identify the responses you can't undo. A customer who loses trust. A competitor that smells weakness. A regulator who opens a file. Those are the ones to model carefully. HP launching Halo was the result. Cisco entering TelePresence was the response. By the time anyone at HP said the word "over," the partnership had been over for three years. Practice Exercise: Run All Three on One Decision Pick one decision you're currently working through. Run the three skills against it in sequence. Weak signal. What have you noticed in the last 90 days connected to this decision that doesn't quite fit your current story? Don't explain it away. Name it. Why now. What changed in the world recently that's making this decision feel urgent now? Was that change visible six months ago? Watch the response. Who will see the result of this decision, and what does it tell them about you that they didn't know before? The first time you run this, you'll miss things. That's normal. The skills sharpen with repetition. The fifth time you sit down with a real decision and work through all three, you'll catch signals that other people in the room aren't even seeing yet. That's what improvement looks like. If any of the three turns up something the room hasn't discussed, you've found the work that needs to happen before the decision is made. Take what you found and run it through the two skills from the November 2025 episode. Map how people will respond. Ask "and then what?" two or three more times. All five skills work as one system. The link to the November episode is in the description below. Most second-order failures do not arrive as surprises. They arrive as something somebody noticed once, didn't have a way to act on, and explained away.

Every playbook, every case study, every innovation workshop is built on the same question: how do you succeed? You map the path forward. You model the upside. Nobody teaches you to ask the harder question. How would you guarantee this fails? That's inversion thinking. Charlie Munger called it one of the most useful tools he had, and he used it for sixty years. Most innovators know the quote. Almost none of them actually use it. By the end of this episode, you'll know why that gap exists, what it costs, and the exact steps to close it. If you want to try this on a real decision right away, I've built a free tool for it. Link below. I'll come back to it later in the episode. What Is Inversion Thinking? Inversion thinking is the practice of reasoning backward from failure. Instead of starting with "what does success look like and how do I get there," you start with "what would guarantee this fails" and design those conditions out of the plan. You'll also hear it called thinking backwards, and when it's aimed at a project before launch, a pre-mortem. Munger's rule was three words: invert, always invert. Or, in his blunter version, "All I want to know is where I'm going to die, so I'll never go there." People hear this and think pessimism. It isn't. A pessimist names the failure and stops there. Inversion names the failure and uses it to redirect the plan, while the fix is still cheap. HP Invented the Category. Then Gave It Away. In 2005, HP built Halo. It was the best telepresence system in the world. You walked into a Halo room and the people on the other end looked like they were sitting across the table from you. Life-sized. Perfect audio. Nobody had built anything close. The team that made it was brilliant, and they believed one thing without question: quality wins. They built rooms that cost $500,000 each. They required customers to run those rooms on HP's proprietary network at a monthly cost that would make your eyes water. Every decision traced back to the same conviction. Make the experience extraordinary, and the market will come to you. Nobody in that room asked the one question that mattered. What if quality isn't what the market is buying? Because it wasn't. The market was buying access. Cisco, and then Zoom, came at the same opportunity from the opposite end. Good-enough quality, on any device, on any network, available to everyone. They understood what the Halo team never tested. In communications, reach beats quality. Every new user makes the service more valuable to everyone already on it, so the product that spreads to the most people wins, even when it looks worse. That network effect beat Halo so completely that Zoom became a verb. HP defined the category and then gave it away. In 2011, under quarterly pressure, HP sold Halo to Polycom for $89 million. In 2022, HP bought the business back, folded into Poly, for $3.3 billion. Thirty-seven times the price, to reacquire a category it had invented. The failure was visible the entire time. It lived inside one assumption nobody questioned: that quality was what the customer cared about most. An inversion exercise would have dragged it into the open. Ask "how do we guarantee Halo fails," and one honest answer was already the plan. Bet everything on quality. Price it for the few. Lock it to our own network. Leave the rest of the market wide open for a cheaper rival. No crystal ball required. Read the plan from the other side and the failure was sitting right there in it. The Three Moves Inversion runs in three moves. The first two are mechanical. The third is where the discipline lives, and where most people quit. Move One: Invert the Question Take the goal and flip it. Write your goal as one sentence. The way you'd say it to the board. "We will win the telepresence market with the best experience available." Turn it into a failure question. Same goal, opposite direction. "How would we guarantee we lose the telepresence market?" List every path to that failure. Don't rank them. Don't defend anything. Write down every way it could happen, including the ones that feel unlikely or embarrassing to say out loud. Price. Distribution. A competitor's move. A wrong read on the customer. Sort each one: recoverable, or not. A slow first year is recoverable. Letting a competitor own the network effect while you keep only the high end is not. The ones you can't undo are what matter here. Set the rest aside. Move Two: Find the Load-Bearing Assumption Behind every failure you can't recover from sits a single assumption holding the whole plan up. Find it. Take your most serious irreversible failure mode. The one from Move One that would actually end the project. Ask what would have to be true for that failure to never happen. For Halo: "Enough customers will pay a large premium for superior quality, and they'll do it fast enough to matter." That sentence is the load-bearing assumption. Ask whether you tested that assumption or inherited it. Did you confirm it with evidence, or did it ride along with the idea because it felt obviously true? The Halo team inherited theirs. Quality felt like an objective good, so nobody checked whether the market agreed. If you can't point to the evidence, you've found your real risk. A plan resting on an untested load-bearing assumption is a bet wearing the costume of a strategy, however solid the rest of it looks. Move Three: Decide What to Do With It Once the assumption is exposed, you have three honest choices. Kill it. If the assumption is false and the failure is irreversible, stop now, while stopping is still cheap. Change the plan so the failure mode disappears. The Halo team had room to do this. A software tier on any network, at lower quality, to build the user base and the network effect, with the premium rooms kept for the customers who'd pay for them. They'd have owned both ends. The plan allowed it. The conviction didn't. Proceed, with the bet named out loud. Sometimes you take the risk on purpose, eyes open, because the upside justifies it. That's legitimate. Taking the same risk by accident, because nobody said the word "assumption" in the room, is not. The one move you cannot make is to see the failure mode and proceed as though you hadn't. That isn't confidence. It's the most expensive form of hope there is. Why You Can't Do This Alone You know the three moves now. The hard part is running them on your own work. You can't fully see your own assumptions. You built the plan. You believe in it. The assumption holding it up feels so obvious that questioning it never occurs to you. The Halo team wasn't careless. They were the best in the world at what they did, and that was the problem. The more expert you are, the more your assumptions feel like facts, and the less it occurs to you to test them. Then there's the room. Even when someone can see the failure coming, the dynamics of a team work against saying it out loud. You earn standing by backing the plan, not by listing the ways it dies. Raise the failure scenario and you look like you lack conviction, or like you're not on board. So the failure half the room quietly senses stays unspoken until it's expensive. Culture rewards the loudest voice on the upside, not the person who turns out to be right about the risk. Two walls. You can't see your own assumptions, and the people who might see them are discouraged from speaking. AI has none of those problems. No ego in the plan, no career to protect, no boss to impress, no reason to soften the bad news to keep the room comfortable. Point it at your work, tell it to find the failure, and it will, without flinching and without politics. It won't make the call for you. It surfaces the failure modes you're too close to see, and then you do the judging. That's how you practice this skill on your own. You sit down with a real decision and a partner that has no reason to spare your feelings. So I built the AI Prompts for Inversion Thinking for exactly that. One prompt makes the AI write the post-mortem of your project before you've even started. Another has it play a competitor designing your defeat. Then one walks you to the single assumption your whole plan is betting on.  You bring the decision and the judgment. The prompts make sure nothing gets skipped just because it's uncomfortable to look at. Here's your work this week. Take one real decision you're sitting on, something with actual stakes, and run it through the pack. It's free at innovation.tools, or use the link in the description. The Long Game The people who use inversion well aren't more negative than their peers. They're more honest about which risks they can walk back and which ones they can't. That single distinction, made early and acted on, is the difference between a project that fails fast and cheap and one that fails slowly, expensively, in year ten. The failure that ends your project is usually the one plenty of people saw coming and nobody was willing to name. Say it now, while it still costs you nothing.

Most product decisions get made by analogy. Someone says, "This is how we've always done it," or "This is what the market expects," or "This is what the competition is doing." The room nods. The decision gets made. And buried somewhere in the middle of all of it is an assumption nobody checked. First-principles thinking is the discipline of identifying assumptions before the market finds them for you. By the end of this episode, you'll have the tools to strip any problem down to what's actually true and build answers that hold, even when the boardroom is watching, and the clock is running. What Is First Principles Thinking? First principles thinking is the practice of breaking a problem down to its fundamental truths, then building your solution up from what actually holds. Not from industry convention. Not from what worked last time. From what's actually true about the problem in front of you. The alternative is reasoning by analogy: doing what worked before, doing what competitors do, doing what the category expects. Analogy is faster and usually right. It fails badly when the thing that used to be true stops being true and nobody notices. Why Assumptions Go Unchecked In 2005, HP's CEO, Mark Hurd, stopped me in the hallway at Building 20 in Palo Alto and drilled me on HP's R&D funding. The metric he focused on was R&D as a percentage of revenue. He wanted HP's ratio to look more like Acer's. I pushed back. I argued we should be comparing ourselves to Apple, not Acer. Mark didn't hesitate. "We are not Apple, and we never will be." What stopped me in that moment wasn't the disagreement. It was the certainty. Nobody in the room questioned whether R&D as a percentage of revenue actually measured what we thought it measured. That metric had been in use for decades. Every competitor used it. Every analyst tracked it. It felt like bedrock. It wasn't. It was an inherited constraint that had calcified into a rule. R&D as a percentage of revenue tells you about accounting categories. It tells you nothing about what that spending produces, whether the right problems are being attacked, or whether innovation output is growing or shrinking. The assumption underneath the metric had never been tested. Nobody had ever asked whether comparing R&D ratios across companies with entirely different business models actually tells you anything meaningful. The cost of that unchecked assumption didn't show up in the next quarter. It showed up over the following decade. HP's innovation pipeline quietly drained, and the Fast Company "Most Innovative" recognition we'd earned three years running disappeared with it. One inherited metric, accepted as fact by an entire room of experienced people, making a generational decision. That's what derivative thinking actually costs. Not a bad quarter. A decade. The people in that room weren't careless. They were experienced. Experience is exactly what makes inherited assumptions feel like facts. The metric felt like a fact. It was a choice nobody remembered making. That's exactly what a first principles question would have caught. Nobody asked it. The Three Core Skills The three skills run in sequence, and each one depends on the one before it. The first, Strip the Assumptions, finds the inherited assumptions baked into how the problem was framed. From there, Test What Remains and Build Up takes what survived and builds your solution from what's actually true. Finally, When to Use First Principles tells you when the process is worth running in the first place. Skip ahead, and the later skills don't hold. Run them in order, and they compound.  Strip the Assumptions Before you can reason from first principles, you have to know what you're actually working with. Most problems arrive already carrying assumptions in how they're framed. Your first job is to find them. Steps to strip assumptions: Write the problem exactly as it was given to you. Don't improve the framing yet. Use their words. Underline every word that implies a constraint. "Must," "can't," "always," "never," "the only way to." Each one is a candidate. Ask, for each constraint: is this physically true, or is it inherited? A physical truth holds regardless of what you decide. An inherited constraint is someone's prior decision that calcified into a rule. Set the inherited constraints aside and restate what remains. This is the real problem. It's usually smaller and easier to solve than what you started with. Treat what survives as your design constraints. These are your real boundaries. Take this list into your brainstorming, and test every idea against what's on it, not against the assumptions you crossed out. This step takes 20 minutes when you do it honestly. Most teams skip it entirely, then spend months optimizing a solution to the wrong problem. Test What Remains and Build Up Not every constraint is an assumption. Some things are actually true: physics, unit economics, human behavior at scale. The goal isn't to pretend those constraints don't exist. It's to be precise about which reality you're dealing with. Steps to test what remains and build up: Take each surviving constraint and push on it. Ask: Is this true because it's physically impossible to change, or because changing it would be expensive, unfamiliar, or uncomfortable? Expensive and unfamiliar are not the same as impossible. Separate the hard limits from the soft ones. Hard limits are what's actually true: things that hold regardless of how the problem is reframed. Soft limits are negotiable. Label them clearly. Most teams never make this distinction and treat every constraint as if it were granite. State your hard limits in plain language.  Write it down. One sentence per hard limit. These are the actual boundaries your solution has to honor. Reason forward from what remains. Don't start from where the industry is and work backward to justify it. Now ask: what solution do the hard limits support?  That last step is where unexpected solutions come from. When you reason backward from convention, you arrive at a modified version of the existing answer. The shape is familiar because you started with it. When you reason forward from hard limits, you land somewhere the category didn't expect, because you weren't anchored to the shape of the existing answer. Solutions built this way often feel strange at first. People will question them. That discomfort is usually a signal you've found something real rather than something inherited. That's what reasoning from what's actually true produces, rather than reasoning from what everyone assumed. When to Use First Principles Before running the process, ask these four questions. One yes is enough. Has the environment this decision was built for changed significantly? Does every solution on the table feel like a variation of the same thing? Is the current approach inherited rather than chosen? Would a bad assumption here cost you more than an afternoon to find and fix? If all four are no, past experience is the right tool. Use it.  The 20-minute assumption-strip is cheap. The cost of skipping it isn't. The Assumption Reversal Exercise For this exercise, you will need a partner. Have them watch this video first. They need to know what an inherited assumption looks like before they can spot yours. Once you're both ready, grab the free First Principles Thinking Checklist at innovation.tools or find the link in the description. It gives you both a shared reference point before you start.  Here is how it works: Each person brings one real problem. Something current, with actual stakes. Not a thought experiment. The problem should be one you've been turning over in your mind without arriving at a satisfying answer. Work on your partner's problem, not your own. You are trying to find the assumptions baked into how they've framed it. They are doing the same for yours. The reason this works is that you can see their inherited constraints more clearly than they can. You're not inside their problem the way they are. Each person lists every assumption they can find in the other's problem. Write them down. Don't argue yet. Don't evaluate. Just surface as many as possible. Quantity matters here. The obvious assumptions are easy. Push past them. Take each assumption and reverse it. If the assumption is "this requires a significant budget," the reversal is "what becomes possible if it requires no budget?" If the assumption is "the customer won't accept a different format," the reversal is "what would we build if they would?" Don't ask whether the reversal is realistic. Ask what it opens up. Discuss what the reversals revealed. Not every reversed assumption leads somewhere useful. But one of them usually exposes a constraint that was never as fixed as it felt. That's the one worth following. The point of the reversal is simple. Some assumptions hold when you push on them, and some don't. You can't tell which is which until you try. The Long Game Every time you run this process and find something that didn't hold, you get faster at spotting them. The judgment about when to use it gets sharper. That's what improvement looks like in practice: not a dramatic flash of insight, but a practiced ability to find the assumption in the room before it finds you. The assumption that costs you most isn't the one you haven't thought of yet. It's the one you stopped questioning years ago.  Find your partner. Run the Assumption Reversal this week. That's where this starts becoming a skill. Subscribe for the next episode. It builds on this.

Last June, I was on a business trip in Silicon Valley when a second cardiac device failed. Same problem with a second surgical team six months apart. The full story is on philmckinney.com. What changed everything was one doctor who stopped treating what everyone else had diagnosed and asked whether they even had the right problem. That one question uncovered what two surgical teams had missed. That's the expert trap. And it shows up in your business, your career, and your decisions far more than you'd expect. Before you act on the next expert recommendation you receive, there are three checks almost nobody makes. Stay with me, because one of them is going to feel uncomfortable. That's the one that matters most. THE TRAP A friend of mine ran a mid-sized manufacturing company, and a few years ago, he hired a well-regarded industry analyst to help him think through where his business was headed. The analyst had data, slide decks, and a client list that made you feel like you were in good company just being in the room. He pointed to three companies in adjacent categories that had shifted to direct-to-consumer sales and won. He was confident, he was credible, and he was paid well to be both. My friend followed the advice. He put together a team, built the infrastructure, and ran the channel for twenty-two months. He lost around four million dollars, and his best wholesale distributors felt abandoned. Some of them never came back. The analyst wasn't wrong. Direct-to-consumer had worked for those other companies. The data was real, and the success stories were real. But nobody in that room ever asked whether any of those success stories involved his specific customer, his specific product, or his specific buying cycle. The companies the analyst cited were consumer brands. My friend's company was in the industrial supplies industry. Completely different purchase decision. He'd actually noticed this early on, and something felt off, but he never said it out loud because the expert had already spoken. That's the feeling I'm talking about. You notice something doesn't quite fit, but you don't raise it, because who are you to question the expert? That's the expert trap, and it's one of the most reliable ways your thinking gets replaced without you realizing you handed it over. WHAT'S ACTUALLY HAPPENING When you perceive someone as having more relevant knowledge than you do, your brain measurably reduces the cognitive effort it puts into evaluating what they're saying. This has been studied, and it's not a weakness or a character flaw. It's a shortcut your brain developed because trusting domain expertise is usually the right call. The cardiologist probably does know more about your heart than you do, and the structural engineer probably does know more about load-bearing walls. The shortcut works often enough that it sticks. The problem is what it skips. It doesn't feel like you're surrendering your judgment. It feels like being informed. And so you follow advice that was right, just not for your situation, your timing, or your constraints. The advice was calibrated for circumstances that don't match yours, and the moment the credential appeared, the evaluation stopped. The wrong takeaway from everything I just said is to become reflexively skeptical, to walk into every expert conversation looking for the angle, ready to push back. That's just a different way to stop thinking. The goal isn't distrust. The goal is to stay in the evaluation while the expert is talking, instead of handing it over. Three checks help you do exactly that, and any serious expert should be able to answer them without hesitation. CHECK ONE: CONTEXT The first check is one question: where, specifically, has this worked before? Most people ask whether something works and most experts answer that question confidently. But that's the wrong question. What actually matters is where it worked, what kind of organization, what stage of growth, what kind of customer, what competitive environment, what specific circumstances. Expertise is built on pattern recognition developed inside a specific set of situations. The pattern is real, but whether your situation matches it closely enough to actually apply it is a completely different question, and it's the one nobody asks. Even in medicine, good surgeons will tell you that outcomes from major clinical trials don't always replicate cleanly when the patient profile differs from the trial population. The research is real and the expertise is real, but the fit question is what determines whether any of that expertise is actually useful to you right now. Most advisors don't volunteer this, not because they're hiding anything, but simply because nobody asks. So ask. Just simply and directly: where have you seen this work, and where does that situation differ from ours? A good expert has thought about this already. The answer comes quickly and it's specific. If they get vague or keep circling back to the general principle instead of the specific situation, slow down, because that vagueness is telling you something. CHECK TWO: INCENTIVE The second check is the one that's going to feel uncomfortable, but ask it anyway: what does the expert gain from this recommendation? Every expert operates inside incentive structures, and that's just how it works. A surgeon recommends surgery more often than a physical therapist does, not because surgeons are corrupt, but because surgery is the tool surgeons have. A financial advisor who earns commission on certain products is structurally more likely to recommend those products. A consultant whose business model depends on long engagements has different incentives than one whose model is based on outcomes. None of this makes the recommendation wrong. It just makes it something you need to understand before you weight it. The way to surface this without it feeling like an accusation is to ask about the logic rather than the incentive. Ask them to walk you through why this approach rather than the alternatives they considered. Think about it this way. If a mechanic quotes you a repair and you ask why that repair instead of the simpler one, you expect a real answer. You get that answer from a mechanic you trust. You should expect exactly the same from every expert in your life, regardless of how much more impressive their office is. Before we get to the third check, think about the last significant decision you made based on expert input. Could you answer the context question? Could you answer the incentive question? Most people can't. The checks never happened. The third check is the one I almost never see anyone use, and in my experience it's the most revealing of the three. CHECK THREE: FAILURE RATE The third check is this: when doesn't this work? Think about what every expert presentation looks like. Track record, success cases, confidence — the whole architecture is built around what worked. What failed almost never comes up unprompted. But any expert who has used a recommendation enough to believe in it has also seen it fail. They know where it falls apart and what the warning signs look like. That knowledge is exactly what you need, and it's almost never volunteered. So ask for it directly: when have you seen this approach not work, and what tends to produce a different outcome? The doctor I mentioned at the top, Dr. West, that's exactly the question he asked. Not how to treat the condition better, but whether they even had the right diagnosis. Every other expert had followed the standard protocol. He asked when the standard fails. He found one paper describing one edge case that had been sitting in the literature for six years. That question uncovered what two surgical teams had missed. That's what the failure rate check does. It doesn't surface doubt, it surfaces evidence. And an expert who can only tell you what worked hasn't really thought carefully about when it doesn't. That's someone selling a recommendation, not helping you make a decision. THE SYNTHESIS Three checks — context, incentive, and failure rate. What they do together is simple. They require the expert to give you something you can actually examine rather than something you're simply being asked to accept. That's the difference between making a decision and receiving one. CLOSE You already know which of the three checks you'd struggle to make. That's the one worth starting with. The friend I mentioned at the top, the one who spent twenty-two months and four million dollars on a channel that was never right for his business, I talked to him afterward. He knew something felt off from the beginning. He noticed the mismatch. But the confidence in the room, the slides, the client list, all of it washed that feeling away. He said: I knew enough to ask the question. I just didn't know I was allowed to. You're allowed to. Drop a comment and tell me which of the three checks is hardest for you to make. I want to know if it splits the way I think it does. See you next week.

Confirmation bias is shaping your decisions right now. Not occasionally. Every day. And the unsettling part is that the smarter you are, the harder it is to see it happening. By the end of this episode you'll know exactly what confirmation bias is. How to recognize when it has taken over a room. And three specific practices that actually work. Not borrowed frameworks, but what forty years of high-stakes decisions has taught me. Let's get into it. What Is Confirmation Bias? Confirmation bias is your brain's tendency to seek out, favor, and remember information that confirms what you already believe, filtering out everything that contradicts it. Most people think that just means seeking out information that agrees with them. That's part of it. But here's what makes it truly dangerous. Once you form a strong belief, three things happen automatically. Unequal Evaluation. Picture two studies landing on your desk. One says your strategy is working. One says it isn't. You read the first and nod. You read the second and start looking for the flaw: the methodology, the sample size, the funding source. Selective Memory. Your brain doesn't store evidence equally. What supports your belief stays accessible. What contradicts it becomes harder to recall the longer you hold the belief. The Backfire Effect. When someone directly challenges a belief you hold, your brain treats it as a threat. The response isn't reconsideration. It's defense. Studies show you actually leave the argument more convinced than when you entered it. Together, the longer you hold a belief and the more it matters to you, the harder it becomes to change, no matter how much evidence says you should. Confirmation Bias in Today's World Confirmation bias has always been part of human thinking. What's changed is the environment around it. Algorithms feed you content that matches what you already believe. Social media shows you opinions from people who think like you. Search engines rank results based on what you've clicked before. Every system you interact with daily is built to confirm your existing views. Not by accident, but because confirmation keeps you engaged. The result compounds. The more confirming information you consume, the stronger your existing beliefs become. The stronger your beliefs become, the more your brain filters out opposing information. The more that information gets filtered, the harder it becomes to update your thinking, even when updating is exactly what the situation demands. This is mindjacking in action. The systematic replacement of your thinking by systems built to do it for you. And confirmation bias is one of its most powerful tools. It's visible everywhere. In public discourse where people can no longer agree on basic facts. In organizations that keep funding failing strategies long after the evidence says stop. In leaders who build teams designed to tell them what they want to hear. You might assume that smarter, more experienced people are less susceptible to this. The research says otherwise. The Smartest Person in the Room Gets It Wrong Here's what surprises most people. Confirmation bias doesn't get weaker as you get smarter. It gets stronger. Dan Kahan at Yale ran a study. He gave people a math problem where the correct answer contradicted their political beliefs. The smarter the person, the more likely they were to get the answer wrong, in the direction that protected their belief. More intelligence, applied more effectively, in service of the conclusion they'd already reached. A smart person who has formed a wrong belief is better at defending it. They find flaws in the opposing data faster. They construct more sophisticated arguments. They're more convincing to others and to themselves. I watched this play out in a board meeting. A CEO had championed a major strategy. Three separate analyses came back contradicting it. Each time, he found a different flaw in the methodology. By the end of the meeting he'd convinced the room the data was unreliable. The strategy continued. The outcome was exactly what the data predicted. He wasn't dishonest. He was skilled. His intelligence was working against him. And everyone in that room let it happen. If you're intelligent, experienced, and confident in your judgment, you are not immune to confirmation bias. You are more vulnerable to it. If you know someone who is always the smartest person in the room, send them this episode. They need it more than most. How to Overcome Confirmation Bias: What Actually Works Knowing about confirmation bias doesn't stop it. I know this from experience, not from research. I've been in rooms where everyone understood exactly what was happening and it happened anyway. What works is different from what you've probably been taught. Catch It in Yourself: The Flip Debate The moment I've most reliably caught confirmation bias operating in myself hasn't come from a checklist or a framework. It's come from a specific kind of conversation. I keep a small group of trusted advisors, people I call my kitchen cabinet. These aren't peers. They're almost never inside the organization. They have no stake in the outcome and no incentive to tell me what I want to hear. When I'm about to make a significant decision and I feel the pull of certainty, I take it to one of them. The conversation has a specific structure. I argue my position, fully and genuinely, the strongest version I can make. Then I stop. And I argue the opposite. Not a token acknowledgment of the other side. A real debate. I take the side I'm most resistant to and make the best case I can for it. What happens in that second argument is where confirmation bias shows up. The gaps. The assumptions I'd been protecting. The evidence I'd felt the urge to dismiss. When you're forced to argue a case you don't believe, you find the things you didn't want to see when you were arguing the one you do. An outside advisor is essential. Someone who will push back, ask hard questions, and notice when the flip argument is being faked. You can't do this with someone who needs something from you. The absence of stakes is what makes the honesty possible. Catch It in a Room: Two Signals to Watch For I've learned to watch for two signals that tell me confirmation bias has taken over a room. Both are visible before the decision is made. Almost everyone misses them. The first signal is the unwillingness to debate the other side. When a room has really decided, before the discussion is officially over, nobody wants to argue the opposing position. Not even hypothetically. Raise the other side and watch what happens. Eyes go flat. The conversation moves on. Someone changes the subject. If a room can't genuinely engage with the strongest case against the preferred direction, confirmation bias is driving. The second signal is circular justification. Listen for reasoning that keeps returning to its own starting point. The evidence for the decision is the decision itself. When you can't find an external reason, just a restatement of the conclusion, confirmation bias is driving. When I hear circular justification in a room, I stop the conversation. Not to embarrass anyone. To name what's happening. "We're not evaluating anymore. We're confirming. Let's go back to the evidence." That single intervention has changed the outcome of more decisions than any framework I've ever been taught. Change How You Decide: Full Options, Real Challenge Here's the most consistent change I've made in my own decision-making, and it comes directly from watching what confirmation bias costs people: I force a full pros and cons analysis on every serious option. Not just the one I'm leaning toward. This sounds obvious. Almost nobody does it. The natural pull is to build the case for the option that already feels right and compare it against the weaknesses of the alternatives. That's confirmation bias disguised as analysis. What I do instead is give every option on the table the same treatment. The best case for it. The best case against it. Without knowing in advance which one I'm going to choose. For decisions that carry real weight, I take it further. I bring in my brain trust: direct reports who will tell me what I don't want to hear, kitchen cabinet advisors, trusted board members. I ask specifically for the challenges. Not validation. Not enthusiasm. The places where the thinking is weak, the assumptions that might not hold, the evidence I might have filtered out. One question has changed how I approach every major decision: what am I not seeing? The answers, from people who have no incentive to protect my view, are exactly where the confirmation bias lives. Confirmation Bias Exercise: Try This Today This week, before you finalize any decision you've already started leaning toward, do one thing. Find one person outside your organization, someone with no stake in the outcome, and run the flip debate. Argue your position fully. Then stop and argue the opposite, with the same effort and commitment. Don't summarize the other side. Argue it. Make the best case you can for the view you're most resistant to. Notice what comes up in that second argument. The gaps. The assumptions. The evidence you'd been setting aside. That's where your confirmation bias is living. Run that exercise this week. Not once. Every time you feel the pull of certainty on a decision that matters. The Benefits of Overcoming Confirmation Bias The payoff from these practices compounds over time. Examined beliefs are more reliable than accumulated ones. Decisions that accounted for opposing evidence hold up better than decisions that filtered it out. Judgment that evaluates rather than confirms earns a different kind of trust from the people around you. Beyond your own decisions, catching confirmation bias makes you harder to capture. Every algorithm, every platform, and every persuader around you is built to exploit it. S