How to Build Products on a Moving Frontier: A Lab-Based Approach

Key Insights

• Separate exploration from execution by creating dedicated labs teams instead of asking everyone to do both
• Use small teams (one to two people) to explore new capabilities without introducing coordination overhead
• Pair "pirates" with "architects" — explorers who find value and builders who shape it into scalable systems
• Make experiments net-positive through dogfooding, customer collaboration, and external content sharing
• Build a research pipeline that gradually transitions promising lab experiments into core products

The Core Problem: Conflicting Modes of Work

When new AI models launch, product leaders face an impossible tension. Everyone on your team is expected to execute the current roadmap while simultaneously staying at the technological frontier. These are fundamentally opposed ways of working.

Exploration is divergent—you try many approaches, discard most experiments, and run demos. Execution is convergent—you focus, say no to distractions, and deliver against a planned roadmap. Doing both pulls your organization in opposite directions, creating paralysis and decision fatigue.

Why You Need a Labs Team

The solution is to separate concerns explicitly. Create a labs team whose sole job is exploration—trying new models, running parallel experiments, and mapping what's newly possible. Keep your product team focused on improving and scaling what already works.

This structure harnesses your organization's early adopters—those people already running new models on weekends—without distracting the rest of your team. Early adopters naturally live in the future and sense where your product might go, but they can become a major distraction if their enthusiasm isn't channeled correctly.

The investment required is minimal. A labs team can start as small as one person. Because AI gives individuals so many superpowers, a single explorer can move remarkably fast.

How to Run a Labs Team Effectively

Team Size: Stick to one or two people maximum—what Dan Shipper calls a "two-slice team." Anything larger introduces coordination overhead and conflicting visions that slow exploration.

Team Composition: Pair a "pirate" (someone obsessed with finding value through experimentation, willing to make messy prototypes) with an "architect" (someone who shapes messy systems into valuable, beautiful, and extensible solutions). This combination is especially powerful in the AI context.

Tight Feedback Loops: The most critical practice is dogfooding—building experiments for yourself. If you can't, bring in early-adopter customers to test with a tight feedback loop so you can iterate rapidly. Use all experiments for actual work, so you can distinguish between "useful" and merely "new."

Parallel Experiments: Even when tackling the same problem, run multiple competing approaches in parallel. Different perspectives help map an unknown frontier and reveal what's truly valuable versus what's just novel.

Net-Positive ROI: Make the 90% of experiments you discard work for you. Every turned experiments into external content that attracted customers. Others use labs work to fuel early adopter programs, offering customers early access as a perk.

The Research Pipeline: From Lab to Product

Successful labs teams need a clear path for promising ideas to reach customers. At Every, ideas flow left to right: many lab-only experiments begin on the left; survivors progress to internal testing, then early customers, then full product integration.

Example: KateBench

Dan's three-year effort to automate copyediting decisions from Kate, the editor-in-chief, illustrates this pipeline. He trained an AI model on her historical edits, creating a system where she could accept or reject suggestions to improve the model further. When the tool matured internally, an architect (Yanik) refined it into a scalable system with dashboards tracking acceptance rates and post-AI work remaining. Internal usage showed a 12% reduction in Kate's editing workload—clear evidence of value.

Once proven internally, KateBench moved toward early customer release, demonstrating how labs experiments graduate into core products.

Moving Ideas Through the Pipeline

Regular Review Process: At Every's weekly all-hands, teams discuss pipeline progress. This transparency keeps the product team informed about promising developments without requiring them to explore every frontier themselves.

Clear Decision Criteria:

• Are people actually using it and coming back?
• Is it ten times better than existing alternatives?
• Can we scale it for customers?

Internal Usage as a Proxy: When people voluntarily adopt a tool for real work, that's the strongest signal of genuine value.

The Speed Advantage: Why Labs Teams Work Now

This structure isn't new in concept, but AI makes it uniquely effective due to iteration speed. OpenAI's Codex exemplifies this: a small autonomous team built various coding assistance formats outside the main application, then launched a desktop app that grew so rapidly it was eventually merged into ChatGPT as a core feature. That small lab team's work now reaches 800 million daily active users.

The promise of this approach is clear: you can build the next iteration of your product while growing your current one, without becoming overwhelmed.

Conclusion

The unreasonable ineffectiveness of traditional product management during technology revolutions stems from asking everyone to execute and explore simultaneously. By creating labs teams, you harness early adopters' energy, identify winning experiments through clear criteria, and pipeline them into products at the right moment. The true measure of success is when your team welcomes new model releases with excitement rather than dread—because you have a systematic way to turn frontier possibilities into customer value.

---

Original source: How to build products on a moving frontier | Dan Shipper (Every)

powered by osmu.app