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

Share on:

Most startups that try to do both actual research and ship product quickly end up doing neither well. The research group drifts off into science projects, the product group starves for breakthroughs, everyone is frustrated.

Here is my version of a mental model that i like.

Run Two Loops, and Connect Them

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

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

You need both. The way this goes wrong is that the loops get disconnected. Tie every exploration to a metric or user pain the inner loop cares about. When the outer loop finds something, harvest it on purpose. Don’t hope for accidental transfer.

Write Down What “Good” Looks Like Early

For each research bet, write an “evaluation” spec before you start. Even if the first version is bad, forcing yourself to define success is much better than wandering indefinitely.

Those evals or measures become what you converge toward. They will change as you learn more; that’s fine. Don’t wait for perfect.

Have 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 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 Researchers Ship

Great researchers will want to ship. Make that explicit.

Ask them to produce artifacts on a tight cadence—prototypes that demo progress, tooling that helps the team, documents that clearly explain what was learned. This keeps research honest and motivating, and it feeds the product loop directly. It sounds obvious; very few do it really well.

Organize Around Bets, Not Functions

Don’t build a big “research team” in a corner. Make very small, vertical pods—two or three researchers with a PM/engineer—focused on a specific bet. Pair those pods with whoever talks to customers or users every day so ideas get validated quickly. Small teams with clear missions work much better than big silos.

Have Someone Run the Interface

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.

Accept the Tension

Research is about truth-seeking and longer horizon work; product is about delivery. 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 try to marry exploratory research with a fast-moving product. 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