エピソード

  • How To Build Innovation Teams (My Playbook From HP and CableLabs)

    How To Build Innovation Teams (My Playbook From HP and CableLabs)
    2026/09/23
    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. ...
    続きを読む 一部表示
    38 分
  • How to Improve Analytical Thinking Skills

    How to Improve Analytical Thinking Skills
    2026/09/16
    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 ...
    続きを読む 一部表示
    27 分
  • How to Recognize Failure Patterns: How HP Quit and Apple Won

    How to Recognize Failure Patterns: How HP Quit and Apple Won
    2026/08/26
    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 ...
    続きを読む 一部表示
    17 分
  • How to Improve Your Abductive Reasoning Skills

    How to Improve Your Abductive Reasoning Skills
    2026/08/19
    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....
    続きを読む 一部表示
    18 分
  • The Customers Who Walked Away

    The Customers Who Walked Away
    2026/08/12
    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 ...
    続きを読む 一部表示
    24 分
  • When One Word Steers Your Answer

    When One Word Steers Your Answer
    2026/08/05
    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 ...
    続きを読む 一部表示
    14 分
  • What Half of 13 Reveals About Your Thinking

    What Half of 13 Reveals About Your Thinking
    2026/07/29

    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.

    続きを読む 一部表示
    5 分
  • How to Tell a Good Decision From a Lucky One

    How to Tell a Good Decision From a Lucky One
    2026/07/08
    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...
    続きを読む 一部表示
    13 分