Why every company now needs to think and operate like a lab team | Josh Woodward (Google Labs, Gemini, AI Studio)

We have entered a period of technology where the ground doesn't just shift under our feet; it liquefies every few weeks. If you are building a startup right now with a two-year roadmap locked in stone, you are effectively building a museum piece. The old way of shipping software—meticulous planning, long development cycles, and rigid feature sets—is dead.

Josh Woodward, who runs Google Labs and oversees projects like Gemini and AI Studio, recently shared a perspective that resonates with what I have been seeing on the ground: every company now needs to operate like a research lab. This is not about academic fluff. It is about the tactical necessity of surviving in a world where the underlying models change faster than your marketing team can write a blog post.

The End of the Feature Roadmap

For a long time, the founder's job was to be a visionary who knew exactly what the world needed. You drew a line from point A to point B and told your engineers to start digging. In the AI era, that approach is a liability. Woodward suggests that the most successful teams are no longer those with the best plan, but those with the best feedback loops.

When you are building on top of LLMs, you aren't just writing code; you are negotiating with a black box. The capabilities of GPT-4, Gemini, or Claude are not static. A feature that was impossible on Monday might be trivial by Friday. Conversely, a moat you built around a specific prompt might be evaporated by a model update. Operating like a lab means your primary output isn't just a product—it is data about what is actually possible right now.

Build for the Ceiling, Not the Floor

One of the hardest things for founders to grasp is that we are no longer limited by what software can do, but by our ability to imagine how to use it. Woodward points out that in the lab environment, you have to lean into the weirdness. If a model shows a spark of an emergent behavior, you don't ignore it because it wasn't in the PRD (Product Requirements Document). You pivot to see if that spark can be turned into a fire.

This requires a cultural shift. Most developers are trained to eliminate edge cases. In an AI-first lab culture, those edge cases are often the most valuable signals. They show you where the model is pushing against its current boundaries. If you only build for the safest, most predictable use cases, you are just building a wrapper that a big tech company will integrate into their OS by next quarter.

The Art of Killing Your Darlings

If you are going to operate like a lab, you have to get comfortable with the garbage disposal. Labs have a high failure rate by design. If everything you try works, you aren't experimenting; you are playing it safe. The problem is that most founders have too much ego wrapped up in their initial ideas.

Woodward highlights a critical point: knowing when to kill a project is just as important as knowing when to scale one. In the AI space, prototypes are cheap. You can spin up a functional demo in an afternoon. This ease of creation is a double-edged sword. It makes it easy to start, but it also makes it easy to accumulate a graveyard of mediocre ideas that suck up your time and focus.

• Speed of iteration beats polish: Don't spend a month on UI for a feature that might be obsolete when the next model version drops.
• Validate the core interaction: If the AI can't do the heavy lifting in a messy text interface, a pretty button won't save it.
• Cut ties early: If the model requires too much "prompt engineering" to behave, the tech isn't ready. Move on.

The New Stack is Human-in-the-Loop

There is a lot of hype about fully autonomous agents, but the lab-first approach suggests a more grounded reality. The most successful AI implementations right now are those that enhance human intuition rather than trying to replace it. Woodward’s work at Google Labs emphasizes the idea of a "creative partner."

For builders, this means your UI shouldn't just be a "Submit" button. It should be an interface for steering. We are moving from a world of command-and-control software to a world of collaborative steering. If your product doesn't allow the user to course-correct the AI, you aren't building a tool; you're building a lottery ticket. Sometimes the user wins, sometimes they get hallucinations. That isn't a business model.

What This Means for Founders

If you are a founder today, your job title is effectively Head of Experiments. You need to be looking at your product every morning and asking: "If a model with 10x the reasoning power dropped today, would my product be more valuable or totally irrelevant?"

If the answer is irrelevance, you are building a bridge to nowhere. You need to move up the value chain. Don't solve problems that are just about moving data from point A to point B. Solve problems that require judgment, context, and iterative refinement. Those are the areas where the lab-first mentality pays off.

The goal is not to build a perfect machine, but to build a learning organism that evolves as fast as the models do.

We are seeing the rise of the "polymath builder"—someone who understands the technical constraints of the models but also has the product intuition to know which experiments are worth running. You cannot delegate this to a project manager. The founder must be in the lab, looking at the raw outputs, feeling the friction, and deciding where to pivot.

The Skeptic's Takeaway

It is easy to get caught up in the "everything is changing" narrative and use it as an excuse for lack of discipline. Operating like a lab is not an excuse for a lack of focus. In fact, it requires more discipline. You have to be rigorous about your metrics, honest about your failures, and ruthless with your time.

Google can afford to run a thousand experiments because they have the balance sheet to support it. You probably don't. Your "lab" needs to be leaner, faster, and more focused on finding a specific vein of value. The takeaway here isn't to wander aimlessly, but to stop pretending you have all the answers. Build, test, fail, and pivot. Do it in days, not months. The winners in the next three years won't be the ones who predicted the future correctly in 2024; they will be the ones who were flexible enough to react to the future as it arrived every Tuesday morning.

Read the original at Lenny's Newsletter →