Josh Woodward says he and Lenny Rachitsky finally met, discussing Google Labs in a podcast.

My biggest takeaways from @JoshWoodward (Head of @Google Labs, the Gemini App, and Google AI Studio) 1. The best ideas almost never come from a design sprint or brainstorm. At Google Labs, the ideas that became NotebookLM, Google Flow, Google Beam, and AI Studio all started with small groups of people who were obsessed with an insight and couldn’t stop themselves from building. These ideas surfaced in the shower, over a weekend, in a hallway. The implication for teams everywhere is that the environment matters more than the process. “You cannot microwave a good idea.” 2. Fall in love with the problem, not the product. Most ideas require three, four, or five significant pivots before they either find traction or get shut down. Teams that get hooked on a specific solution will struggle to make those pivots. Teams that are attached to the problem—the underlying pain point or the user behavior they are trying to shift—can keep adjusting until they get it right. 3. When looking for early PMF, data and retention are important, but the strongest signal of PMF is in people’s eyes. Do they light up? Do they lean in? When you show someone a prototype and they’re genuinely engaged, you feel it. When NotebookLM’s first AI podcast demo was played in a hallway, the reaction was immediate and unmistakable. 4. Keep a list of what is “almost possible,” and move fast when something crosses over. Google Labs keeps a live list of experiences that are almost possible. When something crosses the threshold, Josh describes it as “a phase shift,” like solid to gas, and the team moves immediately. Maintain a running list of things that are almost ready, and have a team positioned to sprint when one of them arrives. 5. Every company needs to think like a labs team now. The underlying technology is changing so fast that what’s possible is shifting from week to week. Which means that every company needs to be spending time playing with the latest models, running far-out experiments, and being first to discover what they unlock before the competition does—and then bringing those discoveries to the rest of the org. 6. When something is not working, the team almost always knows before the leader does. Josh’s instinct as a leader is not to be the one who decides to shut down a project. He watches instead for the passion running out, for the sense that the team has tried everything and nothing is working. His goal is to create an environment where people feel safe enough to say, “I don’t think this is working.” 7. Someone’s “unlearning rate” is one of the most valuable skills right now. Everyone talks about growth mindset and learning speed. Josh is watching for something different: How quickly can someone take an insight, validate or invalidate it through testing, and then let it go? The ability to walk away from a prior belief or approach when the evidence says you should is rare and becoming more valuable. 8. Roles are not blurring into one universal “builder” role. There is a tendency in the current moment to talk as though everyone is becoming a generalist builder. Josh thinks this would be a bad idea. The best people on his teams still have a primary specialty—a major—and also a “minor” they’ve developed. The advice he gives to early-career PMs who are excited about vibe coding and prototyping is clear: build adjacent skills in service of becoming an exceptional PM, not as a replacement for it. 9. A well-designed lab needs isolation, a clear mission, and the ability to create “good trouble.” Three things matter when setting up an internal labs team. First, it needs structural independence, reporting far enough from existing business units that weird ideas can survive long enough to prove themselves. Second, the lab’s mandate has to be explicit: are you graduating ideas to existing products, or inventing new categories? Clarity on that question changes almost every decision. Third, the lab should be a place to challenge how the company itself works, not just what it builds. At Google Labs, that included piloting new job ladders and builder roles before rolling them out more broadly. 10. Google Labs manages the marathon-sprint tension through seasons. At any given time, roughly 20 to 30 experiments are running in parallel, but individual teams experience a defined rhythm: sprints, post-launch recovery, and open exploration periods. After Google I/O each year, many labs teams enter a mode that looks unproductive from the outside: no shipping, just hacking, building, and discovering. Josh treats this as the seedbed for the next season.