Build a Lab Inside Your Product Team: Dan Shipper on Keeping Up With a Moving AI Frontier

Shipper opens by pointing at how fast the ground is shifting: two new frontier models, which he calls Fable 5.1 and Astra 6, had launched the week before. He shows what they can do, including a historically accurate 3D reproduction of the Battle of Waterloo built from a single prompt that ran for about four hours, and a simulation of a thousand interacting agents built from a scientific paper. Astra is even good enough to edit video in Premiere, he says, and it produced most of the animations in his own slide deck.

For a product leader this raises an uncomfortable question. Keeping your head down may work for a while, and asking customers may help, but most customers are unfamiliar with the technology and are looking to you for direction. Turning a B2B SaaS app into a 3D multiplayer strategy game is possible, he jokes, but hard. His half-serious rule number one: never make a major life decision within 30 days of a meditation retreat, a psychedelic experience, or your first encounter with a frontier model.

The core problem, in his telling, is that everyone on a product team is expected both to execute the roadmap and to stay at the frontier. Those are opposite motions. Exploring is divergent: you try many things, run demos and throw most of it out. Exploiting is convergent: you focus, say no, and deliver against a plan. His proposal is to add research-lab elements to the product organization.

Shipper says every product org already has people who explore far more than their colleagues, and they are worth identifying. They are the early adopters: they run the newest models on weekends for personal projects and already live in a version of the future. That gives them a good sense of what the product might become, even though many of the things that excite them turn out not to be useful, and they can be a massive distraction.

The key question, he says, is how to harness those early adopters, and perhaps some customers who share the trait, without distracting the rest of the team. Every's answer, which he thinks many strong AI companies are converging on, is to separate concerns. The product team improves and scales what already works, while the labs team explores what comes next. He adds that AI makes this affordable, since a labs team can be a single person whose job is to dig into each new model when it lands and report back.

The two teams are held to different expectations. The labs team should expect to dispose of roughly 90% of what it makes, while the product team should expect to adopt about 10% of it, because it must keep the product coherent for existing customers. Shipper cites Anthropic Labs as an example: he says Claude Code, MCP, skills and Claude Design all came out of a small group experimenting inside Anthropic, which then invested more in the winners.

On team size, Shipper updates Jeff Bezos's two-pizza rule of eight to ten people into what he calls a "two-slice team" of one or two people. Beyond that, he says, coordination overhead and clashing visions slow things down. The pairing that works for Every is a pirate and an architect: the pirate is a "slop cannon" obsessed with finding value, who builds lots of messy things and throws them away, and the architect takes a messy, vibe-coded system and shapes it into something valuable and extensible.

Dogfooding is the next practice, because the most important thing in a lab is the speed of the loop between making something and knowing whether it is good. Building for yourself is the tightest loop, and if that is not possible, a couple of early-adopter customers can fill in. Experiments should be used on real work so you can tell whether something is useful or merely new.

Unlike a product team, a lab should run many experiments in parallel, even ones that try to solve the same problem. It may look messy and incoherent, but when capabilities move and the frontier is unknown, different people attacking the same problem from different angles help map it. Finally, Shipper wants the discarded 90% to pay off too. At Every, experiments become external content that draws readers and customers, they feed an early-adopter program, and they give the product team ongoing updates on what is now possible.

To get lab work into the product, Shipper proposes a research pipeline with ideas starting on the left as lab-only experiments and moving right until there is a handoff to the product team. Most experiments fail, and the survivors get tested in real work. At Every the first test is whether other people on the team start using the thing. If they do, it is ready for early customers and for the product team to decide where it fits on the roadmap.

His example is Kate, Every's editor-in-chief, whom he says he has lovingly tried to automate for three years. She has excellent taste in copy edits, but with a team of about 30 she cannot do them all, and hiring someone with her taste is hard. Shipper downloaded three years of her edits, built a benchmark he calls Kate bench, and had Fable attempt a copy edit on a new piece. Capabilities have only recently become good enough for it to work.

The experiment then moved into Every's internal company-wide agent, where Kate can now ask it to do a "Kate pass" on a draft and it files suggested changes based on her historical edits. Once internal use started to spread, Shipper brought in an architect, Yanek, to turn the messy prototype into a proper system. It now has a dashboard of accepted suggestions and remaining work, and Kate did 12% less work on those edits than the month before. The team is now considering putting it in front of early customers.

To keep ideas moving, Shipper says Every reviews the pipeline weekly, tracked in Notion and discussed at the all-hands. That lets the rest of the product team see what is starting to move up and think through the implications for the product without having to run their own experiments. It keeps the lab and the product organization in sync.

He also advises defining explicit criteria for advancing an idea and treating each promotion as an event. Every's main question is whether people use it and come back, with internal use as a proxy for value. The second is whether it is 10x better than what exists, a useful filter because novelty feels exciting but the real test is whether it is still better a month later. The third is whether it is affordable to serve at scale.

The end goal is merging winners into the main product, and Shipper says this cycle of self-disruption now works in AI because teams can move so fast. His example is Codex: a small team built it outside the main app while other OpenAI teams explored different form factors, such as the IDE and the CLI. Its desktop app launched in February 2026, grew so quickly that it was merged into ChatGPT and became its foundation, with the Codex team effectively taking over an app with 800 million daily users. Shipper's sign that the approach is working is that you welcome new model releases instead of dreading them.