The Innovators Studio with Phil McKinney

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.