How Should AI Startup Founders Structure Research and Product?
For AI startup founders and CTOs · Based on Emit Jane Luma Foundation Lab Method
// TL;DR
AI startup founders face the existential question of how to structure the relationship between research and product. The Foundation Lab Method provides the answer: don't structure them as separate functions — make them one unified system. Product decisions must generate training data. Research improvements must ship as product capability. This framework teaches founders to identify scarce data, build thin product stacks, target professions instead of verticals, and apply logarithmic scaling tests before each major compute investment. Use it from day one to avoid the structural trap of competing research and product roadmaps.
Why do most AI startups fail at balancing research and product?
Most AI startups treat research and product as separate teams with separate roadmaps, separate incentives, and separate timelines. Research wants to train bigger models. Product wants to ship features. They compete for resources and attention.
The Foundation Lab Method eliminates this tension by design. In a foundation lab, there is no product team and no research team — there is only one thing. Research produces the product. The product feeds data back into research. Every product decision is evaluated against whether it improves the next training run, and every research milestone is defined by the product capability it unlocks.
This is not an organizational hack. It is an architectural decision that shapes hiring, roadmapping, resource allocation, and company culture from day one.
How do I apply the foundation lab method at the pre-product stage?
Before writing any code, answer two questions:
1. What is the scarce data problem for my modality? Is there a YouTube-scale dataset for what you're building? If not, your first product must generate that data. Release something people love to use for free that produces training data at scale. Expect uncertainty — you may not know whether you need 1 million or 1 trillion examples.
2. Which professions will I serve? Do not think in verticals (healthcare, entertainment). Think in professions (surgeons, filmmakers, financial analysts). Professions have specific end-to-end workflows. Design your product around the complete workflow of a specific profession, not a fragment of it.
With these answers, build the thinnest possible product stack on top of your current base model capability. Every gap between what the model can do and what the product promises is a data collection job for the next training run — not an engineering harness project.
What mistakes should AI founders avoid with this framework?
The costliest mistake is building complex engineering harnesses to paper over model capability gaps. These spaghetti systems take six to eight months to build and become irrelevant with the next model iteration. Instead, treat each gap as a two-to-three-week data collection job.
The second mistake is chasing consumer deployment before your model passes the intelligence threshold test. Consumer generative products that rely on novelty produce day-one spikes followed by retention collapse. Focus on enterprise and professional deployments where end-to-end workflow value sustains engagement.
The third mistake is collecting only artifact data (finished outputs) instead of process data (how outputs were made). End-to-end agents require process data. Design your product to log the full creation path, not just the result.
How do I evaluate scaling decisions as a founder?
Apply the 10x logarithmic scaling test before every major compute investment. Ask: if the next model were 10x larger, would it be categorically different or just incrementally better? If not categorically different, the bottleneck is architecture, data quality, or missing modality coverage — not scale. Fix the real constraint first. Scale amplifies what works; it cannot fix structural problems.
Deploy Forward Deployed Creatives (FDCs) to your most important enterprise customers. These are not sales engineers. They serve two functions simultaneously: helping customers deploy AI into their workflows, and piping intelligence back to your research team about what the model needs to learn next.
Next step: Map your current model's capability gaps against your end-to-end product promise. Categorize each gap as a fine-tuning job, a training run, or a pre-training investment. This becomes your unified product-research roadmap.
// FREQUENTLY ASKED QUESTIONS
How do I convince my investors that merging research and product is the right approach?
Frame it as a structural competitive advantage. Separate research and product teams create misaligned incentives and wasted cycles. A unified foundation lab means every dollar spent on product also improves the model, and every dollar spent on research also ships product value. The compounding effect is the moat — competitors with separate teams cannot iterate as fast because their feedback loops have organizational friction.
Should I hire researchers or product engineers for a foundation lab?
Hire people who can do both or who are willing to operate across the boundary. The foundation lab structure requires researchers who care about product impact and engineers who understand model training. Avoid hiring pure researchers who will resist product constraints or pure product engineers who treat the model as a black box. The best foundation lab hires are those who see product deployment and model training as one continuous optimization loop.
How early should I start capturing process data?
From your first deployed user. Process data — the actions, iterations, and decisions in the path to a final output — is your scarcest and most valuable training asset. Design your product telemetry to log the full creation path from day one. Even small amounts of high-quality process data from real professionals using your product are more valuable than massive amounts of artifact data scraped from the internet.