『The Innovators Studio with Phil McKinney』のカバーアート

The Innovators Studio with Phil McKinney

The Innovators Studio with Phil McKinney

著者： Phil McKinney
無料で聴く

【Amazonプライム会員限定】今ならプレミアムプランが4か月 月額99円。

10月19日まで。※適用条件あり
Forty years of billion-dollar innovation decisions. The real stories, the hard calls, and the patterns that repeat across every organization that's ever tried to build something new. Phil McKinney shares what those decisions actually look like. Phil was HP's CTO when Fast Company named it one of the most innovative companies in the world three years running. He co-founded a company and took it public. Now he runs CableLabs, the R&D engine behind the global broadband industry. This isn't theory. It's what happened. And what you can see coming if you know what to look for. Running since 2005, originally as The Killer Innovations Show, now The Innovators Studio. Tens of millions of downloads. Full archive at killerinnovations.com. New episodes at philmckinney.com.Copyright 2005-2026 Techtrend Group LLC. See philmckinney.com マネジメント・リーダーシップ リーダーシップ 個人的成功 経済学 自己啓発
エピソード
  • 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 分
adbl_web_anon_alc_button_suppression_t1
まだレビューはありません