Key Takeaways

  • Dan Shipper argues that forcing engineers to explore new AI models while executing sprints ruins both workflows.
  • Exploration is divergent while execution is convergent: mixing them leads to distracted builders or outdated software.
  • AI tooling makes a labs team of one viable for small startups without bloated overhead.
  • Labs teams should expect to throw away 90% of their prototypes, while core product teams should aim to absorb only 10%.

The Divergent vs. Convergent Trap

When a new frontier model drops, product organizations feel an urge to test its capabilities immediately. Leaders tell their sprint teams to look into the new release while keeping core delivery on schedule. The result is predictable: velocity drops, roadmap items slip, and the experiments stay shallow.

Dan Shipper, co-founder and CEO of Every, sees this conflict as a mismatch in mental modes. Exploration requires open-ended, divergent thinking where dead ends are normal. Execution requires disciplined, convergent thinking where shipping stable code is the only goal. Shipper puts it plainly: “The problem is as we said before right now everyone in your product or is doing both exploration and execution.”

When one person tries to hold both mandates, the urgent always crowds out the experimental. If an engineer is on call for bug fixes or committed to a biweekly sprint, they cannot dive deep into an erratic new model. Conversely, if they wander off chasing demos, core product quality degrades.

Run a Labs Team of One

The solution is a clean structural split. Shipper advocates separating concerns by creating a dedicated labs function that operates entirely outside the standard product cadence.

“On a labs team what you've started to do is separate concerns. Some people are in charge of improving and scaling what already works. They're on the product team. And some people are in charge of exploring what comes next, exploring the frontier, doing all these demos, trying these new models, all that kind of stuff,” Shipper explains.

Historically, maintaining an internal research lab required a massive balance sheet like Xerox PARC or Bell Labs. Startups could never justify pulling three engineers off revenue-generating work just to build speculative demos. Modern AI tools flip that equation. “What is amazing about AI is it allows you to have a labs team of one,” says Shipper. A single engineer using AI code assistants can churn out working prototypes in days that previously took a full engineering squad weeks to assemble.

The 90/10 Throwaway Rule

To make a labs team work, founders must redefine failure. A standard product squad aims for a high hit rate: nearly every pull request should merge into production. A labs unit operates on inverted economics.

“On a labs team, you're going to expect to dispose of like 90% of what you make. You try it and you throw it away,” Shipper notes. The lab's job is not to build maintainable architecture; it is to explore edge cases, stress-test new APIs, and see what breaks.

The transfer mechanism into production must be just as strict. “So for a product team, you want to expect to adopt about 10% of what the labs team makes or tries,” Shipper says. If your main product squad starts adopting half of what comes out of the lab, your experiments are too cautious. The lab should push far enough past the frontier that most prototypes fail. Only the genuine breakthroughs earn a spot on the production roadmap.

What to Do With This

Pull one strong engineer off your core product sprint next Monday and assign them as a dedicated labs team of one. Give them two weeks to build three quick throwaway prototypes on the newest frontier model APIs, with strict instructions to delete at least two of them without merging code.