How to run a research loop and a product loop at your company

Share on:

Most startups that try to do both research and product end up doing neither well. The research group drifts into science projects, the product group starves for breakthroughs, and everyone is frustrated. This is a classic failure mode.

Here’s a mental model I find useful:

You Need Two Loops—And a Tight Coupling Between Them

There are really two feedback loops you have to run in parallel:

• The outer loop is exploration: asking new questions, trying things that might not work, pushing into unknown unknowns.
• The inner loop is exploitation: rapid product iterations, A/B tests, reliability work, prompt tweaks.

you need both. The failure mode is when these loops get disconnected. The research loop becomes a playground with no impact; the product loop becomes incremental and starved for breakthroughs. The key is to force a connection: tie every exploration to a metric or user pain the inner loop cares about. When the outer loop finds something, harvest it deliberately. Don’t hope for accidental transfer—make it a process.

Define “Good” Up Front

for every research bet, write down what success looks like before you start. Even if your first version is rough, forcing yourself to define an evaluation spec is much better than wandering indefinitely. These specs become your north star. They will change as you learn more—that’s expected. Don’t wait for perfect; iterate in public.

Set a Clear Kill Bar

most companies let sunk cost and optimism keep bad research projects alive for far too long. Decide up front what will cause you to stop. If a line is consistently under the “scaling laws” or baseline, kill it. If you run out of reasonable hypotheses, kill it. Conversely, when you see real signs of life—multiple people are excited, the numbers are bending—double down hard. Being decisive about killing and doubling down is most of the job.

Make Research Ship

great researchers want to accelerate science + ship and see real-world impact of their work. Make that explicit. encourage them to produce artifacts on a tight cadence: prototypes that demo progress, tools that help the team, better ways to measure progress and seek truth, docs that clearly explain what was learned. This keeps research honest and motivating, and it feeds the product loop directly. It sounds obvious, but very few teams do it well.

Organize Around Bets, Not Functions

avoid building a big “research team” in a corner. make very small, vertical pods—two or three researchers with a PM or engineer—focused on a specific bet. Pair those pods with whoever talks to customers every day so ideas get validated quickly. Small teams with clear missions compound much faster than big silos.

Appoint an Interface Owner

you need someone with an ops/product/special projects brain to own the boundary between research and product. In the places i’ve seen this work, a great TPM or equivalent is invaluable. This person tracks research vs. product priorities, makes sure experiment results get communicated and integrated and prevents drift into science projects with no outcome.

Embrace the Tension

research is about truth-seeking and longer horizons; product is about delivery and iteration. You will never perfectly balance them. Instead of pretending the tension isn’t there, build rituals that make it productive. Have a regular cadence of reviews, update your evals, enforce your kill bars. Talk about the tradeoffs openly. Most companies let this fester; the ones that embrace it build very valuable things.

it’s uncomfortable to marry exploratory research with a fast-moving product loop. It feels like chaos on one side and grind on the other. but if you can get a high-velocity product loop and a real research loop reinforcing each other, you will build something very hard to compete with. Most people won’t do this. That’s why it’s such a big opportunity.

Related posts

• August 15, 2025 Experience × Evals: the build loop for self‑improving agents
• June 25, 2025 Age of Taste: where the cost of trying is ~zero, but knowing what to do is everything
• June 01, 2025 Age of the Agent Spec
• May 17, 2025 Age of the Agent Orchestrator
• May 08, 2025 Reinforcement fine-tuning and reward engineering