Corporate labs fizzle in 3-4 years unless kept independent

1. Ideas don't come on schedule — ▶ 6:09

   There is no answer in the back of the book. Good ideas rarely come from design sprints or calendar slots set aside for ideation. They surface in hallways, on weekends and over breaks, when people can't stop hacking and send a video. "You can't microwave good ideas." Notebook, Flow, AI Studio and Beam each started with a very small group of obsessed people. The leader's job is to create space for that chemistry, stay on alert to catch it and funnel it forward, and to pay attention to people's side projects.

2. The almost-possible list — ▶ 8:06

   The team tracks experiences that are almost possible. When one crosses over, it is a phase shift, like solid to gas, and they build a team around it. Entertainment is one area: if a model hits a given latency across enough languages and modalities, new things become buildable. The doc holds 82 predictions, each starting "we believe the future is." Woodward expects 9 out of 10, maybe 9.9, to be wrong, but argues you need a point of view. He also wants teams mining behavior outside the Bay Area, in other cities and classrooms.

3. Eyes are the metric — ▶ 14:57

   Product-market fit is "way more art than science," and sometimes it is two people with conviction they can't explain. His best early test is showing prototypes outside the building and watching faces. It is not DAU over MAU or D7 retention. It is whether eyes light up and people lean in. Teams should fall in love with the problem, not the solution, because it takes 3-5 pivots to find out. When fit arrives, as with Nano Banana or the NotebookLM podcasts, you are "swarming it and holding on for dear life."

4. The team knows first — ▶ 18:06

   The team usually knows before the leader does. Passion runs out, and everything has been tried without movement. The leader's job is to make it safe to ask uncomfortable questions. Woodward's example is from the day before: early data on a Gemini feature showed people's eyes weren't lighting up. The PM argued against launching, saying it was not good. He replied to all to thank her. He trusts the team because they are the ones trying to make the thing go every day.

5. Assistant question, partial answer — ▶ 25:19

   Rachitsky asked why Google hasn't built the obvious assistant on Gmail, Calendar and Docs. Woodward points to what is in Gemini Spark today. He says the direction is to forget modes and toggles and give users one prompt box that just does things. Users ping him wanting it to work with their Google data and resist connecting competitors. The vision is a Gemini that is "personal, proactive, powerful," with more coming soon. He gave no date and no reason for the delay, only "watch this space."

6. Benchmarks overhyped, principles underhyped — ▶ 28:17

   Model benchmarks are the overhyped item. Most people will never care about an ELO rating and may not know how to pronounce it. The industry over-rotates to speeds and feeds and loses sight of why something is useful to someone. The underhyped item is discussion of principles and values, since products encode them. He wrote an internal Labs principles doc over the summer and wants more industry debate on what to build and what future people want.

7. Unlearning rate and trust — ▶ 32:07

   He screens for mispriced signals. Unlearning rate is how fast someone learns something and walks away from it. Explosive endurance, a phrase from a Roger Federer book, is going very hard over a long stretch. And trust: even as one person can direct swarms of agents, he expects collaboration to matter more. Labs project teams have shrunk from 5-7 people to 2-3, maybe 4. They team up like musicians playing different songs. People who can build and scale trust fast are the ones he looks for.

8. Not everyone is a builder — ▶ 37:16

   PMs adapt to other functions fastest because they are used to simulating a lawyer, BD person or salesperson. Strategy, ops, BD and marketing people are also becoming good builders in Labs. But Woodward calls "everybody's a builder" overhyped. People keep a specialty, like a major and minor in college. If everyone becomes a generic builder, you lose respect for expertise. His advice to new PMs is to vibe-code in service of becoming an exceptional PM and not lose that major.

9. Name the sprint — ▶ 39:06

   Labs runs 20-30 experiments at once, organized in seasons. The best lesson he has learned is to name when a team is in full-on mode, let people opt in or out, and be just as clear when it isn't. After Google I/O, June is for hacking, because that is where next season's seeds come from. Too little pressure bores people into leaving. Planning is a rolling six months, matching the almost-possible window. The best teams go from idea to meaningful milestone in 50-100 days.

10. Why labs fail — ▶ 44:11

    Woodward agrees with Dan Shipper's frontier-team model: people whose job is to know what went viral on X in the last 24 hours, with eight $200-a-month subscriptions. But the history is bleak. A large company's lab is usually ineffective and fizzles after 3-4 years, or the company can never commercialize its output and someone else builds it as a startup. The fix is a bridge, people who can say a toy today is essential in five years. Labs also uses zero-to-one, one-to-10 and 10-to-100 stages so scaled products don't crowd out early work.

11. Three tips for a lab — ▶ 48:01

    First, independence: don't nestle it under a business unit, and in some companies it should report to the CEO. Second, define the game: graduate ideas to existing products, or invent new product lines. Labs started as the first and widened. The mantra is users first, Google second, lab third. Third, use the lab to challenge how the company works. Labs creates "good trouble," such as piloting a builder job ladder before it rolled out across Google. He hires people who can't stop building and are energized by unstructured problems.

A corporate lab usually dies within 3-4 years. Josh Woodward says that is the base rate, and he has read the books to check. Either the lab turns ineffective and fizzles, or it lasts but the parent never commercializes what comes out. Then someone else sees the future and builds it as a separate company. Everything else he describes is a defence against that outcome.

The defence has three parts. First, people whose whole job is the frontier. These are the ones with eight $200-a-month subscriptions, who have heard about whatever went viral on X in the last 24 hours. Second, an environment where they can build. A lab cannot be nestled under an existing business unit. It needs independence, which in some companies means reporting to the CEO or sitting far enough away to be safe. Third, and the part most often missed, a bridge. Someone has to tell the core business that the thing that looks like a toy today will be essential in five years. A lab can get the first two right, fail on the third, and then nothing else matters.

Independence is not isolation. Woodward's teams run on an ordering: users first, Google second, the lab third. The lab's job is to make users and Google successful, not itself. He also says to decide the game up front. Is the lab there to graduate ideas into existing products, or to invent new product lines? Google Labs began as the first and widened as AI blurred categories. A lab can also be pointed at the company itself. "Good trouble" is the phrase. Labs piloted a builder job ladder, because roles were blurring, before it rolled out across Google. Success brings its own hazard. Products that grow out of the lab, like Notebook, Flow and AI Studio, can crowd out the zero-to-one work. So the team uses stages: zero to one, one to 10, 10 to 100. Early on you watch eyeballs. Later you watch waterfalls and CPAs.

Inside the lab, ideas do not come from process. They rarely come from design sprints or time blocked out for ideation. They come from people swimming in the hallway, or hacking over a weekend or a break, who can't help sending a video. "You can't microwave good ideas." Notebook, Flow, AI Studio and Beam each began as a very small group of obsessed people. The manager's job is to make room for that and catch the signal.

The preparation is not passive. The team keeps a list of what is almost possible. When an item crosses over, it behaves like a phase change, solid to gas, and a team forms around it. Entertainment is one area. If a model reaches a given latency across enough languages and modalities, new things become buildable. A doc behind this holds 82 predictions, each starting "we believe the future is." Woodward expects 9 out of 10, maybe 9.9, to be wrong. He argues you need a point of view anyway, and that you have to try to live in it. He also wants teams mining behavior well outside the Bay Area, in other cities and classrooms.

Judgment is rougher than planning. Product-market fit is "way more art than science." No OKR tells you. Sometimes two people simply have a conviction they can't explain. His best early test is to show a prototype outside the building and watch faces. It is not DAU over MAU and not D7 retention. Do the eyes light up, does the person lean in? Teams should fall in love with the problem, not the solution, because it takes 3-5 pivots to learn whether you have anything. When it hits, as with Nano Banana or the NotebookLM podcasts, you swarm it and hold on.

The same logic governs killing a project. The team usually knows before the leader does. Passion drains, and everything has been tried without movement. The leader's job is to make it safe to say so. The day before the conversation, a PM looked at early data on a Gemini feature, concluded it was not good and argued against launching. Woodward replied to all to thank her. He applies the same scepticism to benchmarks. Most people will never care about an ELO rating, he says. The industry over-rotates to speeds and feeds and loses sight of why something is useful.

Speed shapes the people he wants. Planning is a rolling six months, matched to the almost-possible window, since model labs release new pre-training models a couple of times a year. Within that, the best Labs teams go from idea to a meaningful milestone in 50-100 days. Project teams have shrunk from 5-7 people to 2-3, maybe 4. The skills he screens for follow from this. Unlearning rate is how fast someone can learn something and walk away from it. Explosive endurance is going very hard over a long stretch. The third is building trust, which he expects to matter more as one person can direct many agents.

He rejects the idea that everyone is now simply a builder. PMs adapt fastest, since they are used to simulating a lawyer or a salesperson. Strategy, ops and marketing people are building well too. But people keep a specialty, like a major and minor in college. Lose that, he warns, and you lose respect for expertise.

Now the objections. Rachitsky pressed that excitement is a low bar when every demo is magic. Woodward conceded the demos dazzle, then moved to universal user behavior and whether people will pay. That is a filter, but not one he quantifies. Rachitsky also asked why Google, sitting on Gmail, Calendar and Docs, has not shipped the obvious personal assistant. The answer was direction, not date: one prompt box, no modes or toggles, "personal, proactive, powerful," watch this space. Users want it to work with their Google data, he says, and resist connecting competitors. That explains demand, not delay. His own structure also complicates his advice. He runs both Labs and the billion-user Gemini app, so the bridge he prescribes is partly one person.

The deepest open question is about the product itself. Asked whether Google will have 10,000 products or five in five years, Woodward said he keeps switching sides. Maybe neither. Models might generate bespoke experiences, with labs teams building the agents behind them, in a world that may not assume humans are the ones tapping the screen. Labs is running experiments to prove both sides. If the answer is neither, the thing a labs team exists to build may stop being a product at all.