In an era when AI model capabilities change rapidly, it's hard to give one team both the job of reliably executing the existing product roadmap and the job of exploring new possibilities. To solve this, Dan Shipper, co-founder and CEO of Every, proposes separating a product lab (Labs) that experiments quickly with a handful of people from a product team that refines the product for existing customers. The key is to make it okay for most experiments to fail, and to move only the few ideas that survive real work into the center of the product.

1. The Assumptions of Product Development That AI Has Changed

Dan Shipper opens the talk by saying that AI isn't just slightly improving features; it is shaking up the very way products are built. Every time a new model is released, results that were previously impossible are quickly becoming reality—to the point that it feels like "the world changed again."

Dan cites recent models like Fable 5.1 and Astra 6 as examples. Dan explains that after entering a single prompt and letting it run for about four hours, it produced a historically accurate 3D simulation of the Battle of Waterloo. Dan also says one teammate fed in a research paper on customer behavior and ran an experiment simulating thousands of customer agents on the computer and observing them visually.

"I put in one command and let it run for about four hours, and this is what came out. It's truly insane."

Dan says AI has already reached a practical level for video work too. Every makes a lot of video, and Dan judges that Astra has become good enough to perform real editing work inside editing tools like Adobe Premiere. Dan adds that most of the animations used in the talk were made by Astra, and that Dan barely touched the animations tab personally.

Faced with changes like these, product leaders can react in many ways. They can focus only on their existing work, ask customers what they want, or even feel tempted to turn their existing SaaS product into something entirely different, like a 3D multiplayer strategy game. But Dan doesn't think any of these is a simple right answer. Customers, too, often don't know the possibilities of these latest changes well, so they frequently expect the company to show them the direction instead.

So Dan offers a slightly tongue-in-cheek first principle: don't get so excited the first time you meet a new AI model that you make a decision that bets the fate of your company.

"Don't make life-changing decisions within 30 days of a meditation retreat, a psychedelic experience, or meeting a frontier model for the first time."

2. Execution and Exploration Are Different Jobs

The fundamental problem Dan describes is that a product organization has to do two opposing things at once. One is execution: reliably building and improving the product along the roadmap you've already set. The other is exploration: exploring new models, new interfaces, and new user behaviors.

Exploration spreads out in many directions. You try various models, build countless prototypes, show demos, and throw many of them away. Execution goes the opposite way. You narrow options, set priorities, focus on the plan, and complete a coherent product customers can understand.

"To explore new territory, you have to diverge. You try a lot of things, and you throw away a lot of them."

"Execution, on the other hand, is convergence. It's focusing, saying no to some things, and delivering the plan you've already set."

Dan points out that if you try to maximize both modes simultaneously within one team and the same process, everyone ends up distracted. In particular, every organization has early adopters who get their hands on new technology faster than anyone and build personal projects with new models even on weekends. Because they are the people who see future possibilities first, they are extremely valuable, but they can also constantly pull the whole product team in new directions.

"Because we already live in the future, we have a pretty good idea of where your product could go. But at the same time, we can be an enormous distraction."

So the question product leaders must answer is clear: how do you use the insights of the early adopters in your organization and some leading customers, while keeping the rest of the product team from getting caught up in the noise of exploration?

3. Separating Exploration into a Small Lab

Dan's answer is to create a Labs team within the product organization. The product team focuses on improving and scaling what currently works well, while the Labs team explores what will become possible next. Labs takes on the role of testing new models, building demos, and discovering unfamiliar ways of using things.

Dividing roles this way lets the organization secure two advantages at once. The product team can reliably own existing customers and the product experience, and Labs can explore future possibilities without fear of failure.

Dan says that in the AI era especially, this lab doesn't have to be a huge separate organization. Even one person is enough to start. That person experiments directly each time a new model comes out, investigates what has become possible, and brings the results back to the team. The logic is that because AI tools greatly boost individual productivity, even a small team can do far more exploration than before.

"The great thing about AI is that you can have a one-person Labs team."

Labs and the product team differ even in their criteria for success. For Labs, throwing away about 90% of what it builds is normal. The product team, meanwhile, adopts only about 10% of the many possibilities Labs throws out and folds them into the existing product. In this structure, even discarded experiments aren't failures; they are achievements that quickly tested possibilities and eliminated unnecessary paths.

Dan cites Anthropic as an example. Small independent groups like Anthropic Labs ran a variety of experiments, and in the process several successful features and products emerged—content-related features, Skills, and design elements of Claude, among others. There were also countless experiments people never saw, but the company gradually invested more only in the ideas that succeeded.

4. Four Principles for Running a Lab

Start With a Very Small Team

Dan says the old "two-pizza team"—a team of about 8–10 people—should become a "two-slice team" in the AI era. The ideal lab size is one or two people. As headcount grows, coordination costs rise, perspectives clash, and the speed of fast exploration can disappear.

"In the AI era, I'd like to call it a 'two-slice team.' One person, two at most."

The combination Dan recommends is a "pirate" and an "architect." The pirate may look somewhat chaotic and disorderly, but is someone who tries to find something valuable as fast as possible. They create and discard many ideas and catch interesting signals. The architect looks at the messy prototypes that come out of that and turns them into beautiful, reliable, scalable systems.

"The pirate finds the value no matter what. The architect turns that messy system into something valuable, beautiful, and scalable."

Use It Directly in Real Work

The most important thing in a lab is to quickly get an answer to the question "Is this good?" after building something. To do that, you should use the product yourself as much as possible. Put it into your real workflow and check whether it genuinely saves time and money, or whether it's just a novel toy.

If a product is hard to use internally, you need to build a tight feedback loop with a small number of early-adopter customers. What matters isn't getting positive reactions in interviews, but seeing whether people actually use it again and again.

"Use every experiment in real work. That's how you find out whether it's useful, or just interesting because it's new."

Run Parallel Experiments on the Same Problem in Different Ways

A product team usually makes an aligned plan to solve one problem, but a lab should try solving the same problem in several ways at once. It may look redundant and messy on the surface, but when a new capability emerges, you can't yet know what is valuable.

When different people approach the same problem from their own perspectives, you can quickly map a wide unknown territory. You learn faster which approaches actually work and which are useless.

Get Returns Even From Discarded Experiments

If 90% of a lab's experiments don't lead to products, you shouldn't just scrap them; you should recover their value in other ways. Every explains that it turned experiment results into external content. Publishing what you tried, what worked, and what failed makes the content itself help the brand and bring in customers.

"People want to see what we tried—what worked and what didn't."

Experiments can also be used in a leading-customer program. Showing not-yet-finished attempts first to customers who want to work more closely with the company, and having them validate the attempts together, can give those customers special value as well. At the same time, the changes and possibilities Labs discovers should be continually shared with the product team. The product team doesn't need to run every experiment itself, but it does need to know the signals that will affect product strategy going forward.

5. A Research Pipeline That Moves Experiments Into the Product

After creating a lab, the key challenge is "how do we move good experiments into the product?" Dan describes this as a research pipeline that moves from left to right.

At first, Labs produces a large volume of very small experiments. Most are stopped, but some promising experiments get validated in real work environments. Next, other teammates try them, and if internal usage grows, they can be offered to early-adopter customers. After that, the product team examines them closely to determine their place in the product strategy and roadmap, and they are scaled to all customers only when truly ready.

"Once other teammates start using it, it's usually ready to show to early-adopter customers."

As an example from inside Every, Dan introduces editor-in-chief Kate. Kate has an excellent editorial sense, but there were limits to her personally editing every piece of writing from a team that had grown to about 30 people. Dan says the reason it's hard to simply hire more Kates isn't just a shortage of people, but that her particular editorial sense is hard to replace.

So Dan has been experimenting with having AI edit the latest pieces using years of Kate's past editing records. Kate reportedly often received messages like this:

"It's no big deal, but I uploaded every edit you've made over the past three years and asked Fable to edit the latest piece."

At first it was a somewhat crude experiment built on personal time, but as performance gradually improved, the whole organization started using it internally. An AI agent reviews drafts and suggests edits based on how Kate has revised in the past, and it also learns again from what changes Kate actually makes afterward.

Once this system was adopted internally, an engineer in the "architect" role entered the picture. Dan says an engineer named Yannick is turning this messy tool into a systematic product. A dashboard shows the acceptance rate of suggestions per document, the amount of work still left for Kate after the AI has processed a piece, and what Kate revised again after the AI's suggestions. This makes it possible to measure whether the system is steadily improving.

As a result, the additional editing work Kate has to do has reportedly dropped 12% compared with a month earlier. It's not simply "AI managed to edit," but a metric showing the actual workload decreased. At this stage, the team begins considering whether the capability can be applied to work beyond editing, and whether it can be offered to early-adopter customers.

6. Criteria for Product Inclusion and the Long-Term Goal

Dan emphasizes that the research pipeline should be reviewed regularly. Every tracks experiments in Notion and, in a weekly meeting, discusses together which experiments are in progress, what looks promising, and what will move to the next stage. This is a mechanism that keeps Labs and the product team separate yet not disconnected.

The product team doesn't need to dive into every experiment, but it should be able to think ahead about how a given possibility would affect the product if it became real.

"Without getting distracted by running every experiment itself, the product team should be able to think, 'If this is really right, what does it mean for our product?'"

Clear criteria are needed when moving an idea to the next stage. Dan presents the following questions as especially important:

• Do people actually use it, and do they come back and use it again?
• Is it truly 10x better than the existing way?
• Over time, does it show lasting value rather than mere novelty?
• Is the cost structure viable enough to offer it to many customers?

"New things look very exciting. But is it really still better a month later?"

"Whether it works now and whether it can be delivered to customers at scale are different questions."

The ultimate goal isn't to pile up cool experiments in the lab, but to integrate proven successes into the core product. Dan sees OpenAI's Codex as a good example of this approach. Codex was developed by a small team outside the main application, and meanwhile various teams inside OpenAI experimented with different directions, such as whether future programming would happen inside the IDE or in the CLI.

Dan explains that as a result of those experiments, the Codex desktop app launched in February 2026, grew rapidly, and was eventually integrated into ChatGPT to become one of its core foundations. It's an example of a small experimental team influencing the core product experience of a massive user base.

"You can scale the current version while building the next generation of the product at the same time."

7. When Change Becomes an Opportunity Instead of a Fear

Dan Shipper's message is simple. In an environment that changes as fast as AI, you need both a team that protects the existing product and a team that experiments with the future. If you make everyone chase every new technology, the organization gets distracted; but if you have a small, fast lab dedicated to exploration, you can prepare for the future without shaking the existing business. 🚀

Labs has to fail a lot, and the product team has to be protected from the noise of that failure. In return, only ideas that are used repeatedly in real work, are overwhelmingly better than the existing way, and are scalable in terms of cost should be moved to the center of the product.

The clearest sign of success Dan offers is how the organization reacts when a new AI model comes out.

"If, when a new model comes out, you welcome it and get excited instead of worrying, that means this approach is working."

In the end, a good product organization isn't one that blindly follows changing technology, but one that, whenever change happens, quickly experiments and learns, then turns it into real value for customers.