Research-to-Product Graduation
Move an incubated moonshot from the research lab to a product team without killing it or trapping the researchers
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 7
- Confidence
- 94%
Salva's account of taking Copilot from GitHub Next (the ring-fenced research team) to EPD (engineering, product, design) is a repeatable transfer protocol. It defines a graduation trigger, a seed-team mechanism (send researchers over as the founding squad, don't just take a handoff), a scaling signal, and a return criterion that is deliberately not calendar-based: a researcher only goes back to research when there is a replacement in seat actually doing the job. It also fixes ownership — the product team, not the research team, owns the roadmap.
Origin
Ryan Salva's own experience running the GitHub Next → EPD transition for GitHub Copilot over roughly 18 months, from technical preview to general availability. The three-horizon vocabulary it sits inside is broader industry language (commonly credited to McKinsey), but the transfer protocol is Salva's.
Core principles
- 01Give the research team no obligation to security, privacy, uptime, or accessibility up front — they need space to create
- 02Graduation is triggered by evidence, not by calendar or executive enthusiasm
- 03Transfer people, not just artifacts — knowledge transfer requires the researchers to sit inside the new squad
- 04The team with the closest feedback loop to the customer owns the roadmap; you cannot delegate roadmap to a research shop
- 05Engineering fundamentals are the contract that separates a research project from an operational product
- 06The researcher's exit is gated on a qualified replacement in seat, never on a date
How to run it
- 1
Fund and protect the research team first
Hire smart people, ring-fence them from the product org, and explicitly release them from up-front obligations to monetization, security, privacy, uptime, and accessibility. Their measure is ambiguity and confidence level, not calendar dates.
Pro tip Define horizons by confidence, not years: 'a measure of ambiguity and confidence level more than calendar dates.'
Watch out Imposing productization fundamentals on day one is the standard way large companies neuter their own R&D groups.
- 2
Wait for the graduation signal
Graduate only when the idea is clearly connected to a representative set of customers with a genuine problem, and there is signal at at least medium confidence that the solution solves it in a novel way.
Watch out Executive excitement is not the signal. A representative customer set with a genuine problem is.
- 3
Run informal market testing with prototypes
Put prototypes in front of progressively more customers and ask two questions: is this actually solving a problem for you, and is this something you would use? Nothing as formal as market research — just increasing exposure.
Pro tip Listen for the specific reaction that means you have something real: customers saying it does something extraordinary they could not do on their own.
- 4
Seed a new product squad with the researchers themselves
Make an intentional decision to move some researchers, for a finite period, into a newly formed product squad. They are the seed and the knowledge-transfer mechanism — not consultants on call.
Pro tip Pair them deliberately with engineers who are comfortable maintaining a service; the researchers won't have those skills and shouldn't be expected to.
Watch out Expect the fundamentals process (uptime, reliability, review) to feel unnatural to the researchers. Budget cultural change management for it.
- 5
Scale on the public-enthusiasm signal
Run a technical preview, expanding from tens of thousands to hundreds of thousands of users. Treat unprompted public excitement — mind-blown tweets, Hacker News threads — as the trigger to start hiring and building the insulation layer around the researchers.
- 6
Return researchers only against a replacement in seat
The criterion for a researcher going back to the research team cannot be a date. It must be a replacement in seat who is actually doing the job and has picked up the necessary skills, guaranteeing continuity of expertise and domain familiarity.
Pro tip Stagger the returns — GitHub moved researchers back gradually, one at a time, over months.
Watch out A calendar-based rotation guarantees a knowledge cliff exactly when the product hits its scaling load.
- 7
Hand over the roadmap, not just the code
The product team maintaining the product and holding the closest customer feedback loop must own and feel it controls the roadmap. Innovation continues inside the product team; it is not outsourced back to the research shop.
Watch out If the research team keeps dictating direction, the product team never takes real ownership of the customer or the use case.
In the wild
Copilot originated in GitHub Next as a second/third-horizon project. Once developers in early testing called it magical and said it did something extraordinary they couldn't do on their own, GitHub moved researchers into a new EPD squad, ran a technical preview scaling from tens to hundreds of thousands of users, watched Hacker News and Twitter light up, then hired a permanent team around the researchers.
→ Copilot reached general availability; researchers began gradually returning to GitHub Next only once replacements were in seat, and multiple EPD squads now own the roadmap.
The researchers seeding the Copilot product squad had to absorb engineering fundamentals — reliability, security, service maintenance — that had been deliberately withheld from them during the research phase.
→ GitHub mixed in engineers comfortable maintaining a service alongside the researchers, treating the shift as explicit cultural change management rather than a skills failure.
Common mistakes
Taking a clean handoff instead of transferring people
Saying 'cool, we'll take it from here' loses the tacit knowledge that made the prototype work. The researchers have to sit inside the new squad for a finite period as the seed.
Rotating researchers back on a schedule
A calendar-based return leaves the product team without domain expertise at the exact moment scaling pressure arrives. Gate the return on a qualified replacement actually doing the job.
Leaving roadmap authority with the research team
Roadmap cannot be delegated to R&D. The team closest to the customer feedback loop must own it, or it never truly owns the product.
Outsourcing innovation entirely to the research team
Once the product squad takes over, innovation has to keep happening inside it. Otherwise the product stagnates between moonshots.
Is it for you?
Best for
Product and engineering leaders at large companies who have an R&D or incubation group and need to convert a promising prototype into an operational, revenue-bearing product
Not ideal for
Organizations with no dedicated research function, or startups where the founding team is already the product team
From the transcript
“I mean I think like the first step is to invest in it. Like the first step is really like hire really smart people, attract…”
“They need space to create and experiment.”
“mind-blown emoji tweets and like threads on Hacker News about people getting really, really excited about it. That's how we knew it was time to…”
“needs to be based on a replacement in seat who's actually doing the job and has picked up all of the skills necessary. And only…”
“The team who's responsible for maintaining the product, for building the product, who has the closest feedback loop with the end customer, they're the ones…”
“we generally think of it more as like a measure of ambiguity and confidence level more than calendar dates.”
From the episode
The role of AI in product development
Ryan J. Salva (VP of Product at GitHub, Copilot)