Why Companies Need to Operate Like Labs: Josh Woodward on AI Product Discovery, Team Rhythm, and Frontier Judgment

1. Guest Background

This episode of Lenny's Podcast is hosted by Lenny Rachitsky and is framed by the title question of why every company now needs to think and operate like a lab team. The subject is not AI in the abstract. It is an operating question: when model capabilities, user experiences, and product-building methods keep shifting, how should a company discover what has become possible, test it, decide whether to double down or quit, and connect exploratory work back to real users?

The guest, Josh Woodward, is positioned in the evidence as VP Google Labs and head of Google Labs, the Gemini app, and AI Studio at Google. The guest context says he has worked at Google for more than 16 years and leads Google Labs and related AI product efforts. His work includes experimenting with and scaling new AI products, including Google Labs, the Gemini app, AI Studio, Notebook, Flow, and Google Beam. That makes the episode unusually useful because Woodward is speaking from both sides of the product lifecycle: small zero-to-one experiments and very large AI products such as Gemini.

Lenny's opening premise is that underlying technology and model capability are changing so quickly that companies need people whose job is to stay at the frontier, try the latest models, run many experiments, and identify what is now possible before competitors or startups do. Woodward agrees, but immediately shifts the discussion from slogan to execution. In his view, the difficult part is bringing startup-like methodology, ideas, energy, and excitement into medium or large teams while cultivating the people and ideas that can actually thrive in that environment.

2. What the Episode Covers

The interview follows the full loop of AI product exploration: where ideas come from, how Labs decides what is worth pursuing, how early product-market fit feels, when a project should be killed, what talent signals matter, and how a frontier team should relate to the rest of a company. Woodward begins with idea generation. He says strong ideas rarely come from design sprints or calendar-scheduled brainstorms. More often, they come from hallway moments, weekends, breaks, side projects, and small groups of people who are so curious that they cannot stop building. Labs, in this account, is not a meeting format; it is an environment that notices and advances these small prototypes.

A major part of the episode is Woodward's explanation of how Google Labs makes frontier sensing more systematic. The team keeps a list of things that are “almost possible” and watches for shifts in models, experiences, and user behavior. When a capability crosses a threshold, he compares it to a phase shift, and the team can move quickly around it. Labs also thinks through futures such as software design and development, creativity, work, knowledge, and entertainment, including technical conditions such as latency, language coverage, and modality. Woodward says the team has 82 future-oriented predictions, while openly acknowledging that most may be wrong. The predictions matter because they force a point of view.

Woodward gives concrete product examples rather than staying at the level of organizational theory. He describes early excitement around NotebookLM's AI-hosted handling of British Parliament debates, where dry source material became interesting in a new format. He also points to Flow and Whisk as examples of controllable creative experiences that had not been possible in the same way before. He says Labs is currently all AI-driven, including adjacent work such as Google Beam, which he describes as creating a 3D version of someone for hologram-like conversation. In consumer AI, he sees opportunity in entertainment, reopened messaging and chat spaces, and products around scarce resources such as time, money, memories, and shared offline experiences.

The second half of the conversation turns toward organization. Woodward names talent signals such as unlearning rate, explosive endurance, and the ability to collaborate with both people and agents while building trust quickly. He describes Labs seasons: intense periods around events such as model launches or Google I/O, followed by time for hacking, rediscovery, and building for fun. Planning is short-horizon but not chaotic: Labs works with a rolling six-month view, and strong teams should move from an idea to a meaningful milestone in roughly 50 to 100 days. He closes the organizational loop with advice on setting up Labs teams, warnings about premature consolidation and over-hiring, and cultural symbols such as TPU harvester, golden bandaid, and LLM whisperer awards.

3. Core Views: Reasoning, Examples, and Limits

The episode's central argument is that AI-era product organizations need a durable frontier capability, not just a faster version of their existing roadmap process. Lenny frames the pressure clearly: model and infrastructure changes are happening so quickly that what was impossible yesterday can become plausible today. Woodward agrees, but his answer is more demanding than “create an innovation team.” A useful Labs function has to do three things at once: notice when technical or experiential thresholds move, connect those changes to real user problems, and create a path for experimental work to be advanced, killed, or graduated inside a larger company. Without all three, a lab can become exciting but strategically irrelevant.

Woodward's view of idea generation is one of the episode's most important claims. He says good ideas rarely come from design sprints or formal brainstorm meetings. Instead, they often emerge from small groups, side projects, hallway moments, weekends, and breaks, when people are so interested in a possibility that they build anyway. That does not mean the process is passive or mystical. Google Labs maintains a list of things that are “almost possible,” and the team tracks model capabilities, user behavior, experience patterns, latency, language coverage, and modality. The list gives curiosity a structure. It lets the team notice when a capability crosses a threshold and quickly organize around it.

The limitation is that Woodward does not claim these predictions are reliable. In fact, he says Labs has 82 future-oriented predictions and that nine out of ten, or even 9.9 out of ten, may be wrong. The value is not forecast accuracy in a narrow sense. The value is having a temporary point of view that makes learning faster. A company with no point of view about the future will mostly react to whatever is currently loud. A company that treats its predictions as certainty will overcommit to fantasy. The useful middle ground is to hold hypotheses strongly enough to test them and lightly enough to abandon them.

A second major view is that early product-market fit should not be judged with the same tools used for mature products. Woodward says that when showing early prototypes, the metric is not DAU, DAU/MAU, or D7. The signal is whether users' eyes light up, whether they lean in, and whether the prototype hits a nerve around a pain point. The NotebookLM example makes the point concrete: British Parliament debates are not obviously compelling raw material, but AI hosts made the material interesting in a way that suggested a new experience. Flow and Whisk show a similar pattern: the important signal was not just generation, but a new level of control in creative work.

This qualitative approach also has boundaries. Woodward acknowledges that teams sometimes get excited, build a product, and discover it is not good. Early product-market fit is more art than science, and sometimes depends on a few people having conviction about the future. That makes it powerful but also risky. A dazzling demo can be mistaken for demand; a small number of enthusiastic users can be overread; an internal team can fall in love with its own taste. Woodward's corrective is to fall in love with the problem rather than the first solution. A direction may need three, four, or five pivots before the team knows whether there is something real there.

The same logic governs killing ideas. Woodward says the team usually knows before the leader when something should stop. The signs are not only numerical; they include fading passion, trying everything without progress, and the team's ability to say that a feature is not good enough to launch. This puts responsibility on leadership in a specific way. The leader is not merely the person who makes the final call. The leader must create an environment where uncomfortable truths can surface before the organization spends more time defending a weak idea. In the episode, Woodward describes being proud of a PM who recommended not launching a Gemini feature after early signals were not there.

A third view is that AI changes team shape without eliminating expertise. Woodward expects lower execution costs to allow more products and smaller teams, shifting some Labs work from five to seven people toward two to three or four. Roles blur: PMs may code and design, and builders may come from strategy, operations, business development, or marketing. Yet Woodward rejects the overextended version of “everyone is a builder.” People still need a major or specialty. For a PM, vibe coding should serve the work of becoming an excellent PM; for other functions, AI-enabled building should expand the craft rather than erase it.

That is why Woodward's talent signals are not just technical. He looks for unlearning rate: how fast someone can learn something and then walk away from it when tests or new evidence say it is wrong. He values explosive endurance: the ability to sprint hard without exhausting the team so badly that the work cannot continue. He also says collaboration matters more, not less, in the AI era, because people must work with agents or swarms of agents while still building trust with humans. The reasoning is subtle: if AI makes execution cheaper, the scarce organizational resources become judgment, trust, taste, pacing, and the ability to reconfigure small teams around new problems.

A fourth view is that Labs must be independent enough to protect strange ideas and connected enough to matter. Woodward says every company needs a frontier team plugged into model releases, new building methods, and the latest things gaining attention on X. But he also warns from history that large-company labs often fizzle after three to four years or fail to commercialize what they discover. His practical answer is to define the game: is the lab graduating work into existing products, inventing new product lines, or challenging company operating methods? That answer determines the right distance from business units, the right metrics, and the right graduation path.

Finally, Woodward's critique of AI benchmarks provides an important value constraint. He says principles and values are underdiscussed because products encode them, while model benchmarks, Elo ratings, speeds, and feeds are overemphasized. This is not an argument that capabilities do not matter. It is an argument that capability metrics are proxies, and users mostly care whether a product helps them. The best reading of the episode is therefore not “copy Google Labs.” It is: build a system that can sense frontier change, test it against human need, use stage-appropriate evidence, preserve professional depth, and stay honest about when an idea is only a toy.

4. Learning and Application

The first practical use of the episode is to turn frontier sensing into a habit. A company should not start by naming a group “AI Lab” and hoping ideas appear. It should maintain an “almost possible” ledger organized by user problem, model capability, experience pattern, and behavioral shift. Each item should include a trigger condition: what latency, modality, language coverage, cost, distribution channel, or user behavior would make the idea worth testing now? This preserves Woodward's useful tension. Teams need a view of the future, but because most predictions may be wrong, the view should function as a learning scaffold rather than a commitment plan.

The second application is to separate early validation from scaling validation. For a zero-to-one prototype, the first goal is not to optimize DAU or retention dashboards. It is to find strong demand signals: users leaning in, asking to use it again, connecting it to a painful workflow, or showing willingness to pay because the value is obvious to them. Teams can run small sessions, observe reactions, and capture the exact pain point the prototype touches. Once the product enters later stages, the evidence should change. Woodward's zero-to-one, one-to-ten, and ten-to-a-hundred distinction suggests that funnels, CPAs, and conversion to magic moments belong later, after the team has evidence that people actually care.

The tradeoff is that qualitative signals are fast but fragile. A striking demo can create novelty rather than lasting demand. A founder or PM can confuse personal excitement with user need. A small group of early fans may not represent a market. The antidote is Woodward's advice to love the problem, not the solution. Teams should define the problem in stable language, then allow the product form to pivot three, four, or five times. At each pivot, they should ask whether the user pain became sharper, whether the experience became more valuable, and whether the team learned enough to continue. If all plausible attempts fail, stopping is progress, not failure.

The third application is to manage rhythm deliberately. Woodward's rolling six-month horizon and 50-to-100-day milestone expectation can become an operating cadence for AI product teams. A team can hold a multi-year vision, plan only six months in detail, and require each bet to reach a meaningful milestone within one or two development cycles. Milestones should not all be launch metrics. They can include crossing a technical threshold, proving a user reaction, clarifying a business model, or discovering that a premise is false. The point is to reduce the time an uncertain idea can drift without evidence.

This cadence needs seasons, not permanent sprint mode. Woodward's examples around model launches and Google I/O show when intense execution can be useful: a deadline creates focus and a shared language for urgency. But the recovery season is equally important. Time for hacking, rediscovery, and building for fun is not idle if it produces the next set of seeds. The boundary is that leaders must name the mode clearly. If everything is always urgent, explosive endurance becomes exhaustion. If nothing is urgent, frontier teams lose momentum. The discipline is matching the work mode to the moment.

The fourth application is to update talent selection without flattening craft. In hiring or internal staffing, teams can look for unlearning rate by asking candidates to describe when evidence changed their mind and what they abandoned. They can look for explosive endurance by examining how someone handles intense pushes and how they protect long-term team energy. They can test trust-building by placing people in ambiguous cross-functional work where they must collaborate with both humans and AI tools. But the boundary is important: AI fluency should not replace professional depth. A PM who codes should become a better PM, a designer using AI should become a stronger designer, and a marketer building prototypes should still bring marketing judgment.

The fifth application is organizational. A Labs or frontier team needs independence from existing business units so strange things can grow, but it also needs a route back into the company. Before creating the team, leaders should define whether success means graduating prototypes into existing products, creating new product lines, or changing internal ways of working. They should also define stage transitions: what evidence moves a project from zero-to-one to one-to-ten, when staffing increases, and when the main business should absorb the work. Woodward's warning about over-hiring is especially practical. Expanding to a large team before product-market fit can turn uncertainty into expensive inertia.

The sixth application is cultural. Woodward's TPU harvester, golden bandaid, and LLM whisperer awards show how values can be encoded in visible rituals. A company can design its own symbols for the behaviors it wants repeated: efficiency work that unlocks capacity, small product fixes that improve delight, or experiments that reveal new model capabilities. The rule is to reward real behavior, not performance theater. The deeper boundary from the episode still applies: a Labs team exists to create user value and organizational learning, not to look futuristic. When the rituals, metrics, and roadmap all point back to that standard, experimentation becomes a capability rather than a side show.

Source

• Original episode: Why every company now needs to think and operate like a lab team | Josh Woodward (VP Google Labs)