The Horizon-3 Research Team That Ships
Fund a 3-5 year research team, then bolt it to product so ideas actually reach production.
- Difficulty
- Expert
- Time to result
- ~ongoing to results
- Steps
- 6
- Confidence
- 90%
Most 'future' teams fail in one of two directions: they become an ivory tower producing papers nobody productizes, or they get raided for near-term work and turn into another delivery team. GitHub Next avoids both by pairing genuine 3-5 year horizon research with a permanent, two-way synergy loop into product and engineering — the path to production is designed in from idea zero. Copilot came out of this team.
Origin
GitHub Next, GitHub's applied-science research team, as described by Shani. She contrasts it explicitly with Facebook's New Product Experience team and Google's equivalent, which she says have not produced comparable outcomes.
Core principles
- 01The team's day job is to invent the future, on a three-to-five-year horizon, not the current roadmap
- 02Ideas must have a designed path to production from day zero, or they never clear the hump
- 03Two failure modes to guard against: ivory tower (papers, no shipping) and tactical raiding (six-month deliverables)
- 04Innovation comes from everywhere — the research team is a concentration of it, not a monopoly on it
- 05If you try to structure innovation you kill the organic spark; encourage it instead
How to run it
- 1
Staff for mindset, not just credentials
Hire applied scientists and research scientists who genuinely want to invent, and give them explicit bandwidth and freedom to do it. Shani names 'the right people with the right mindset' as the first of two success conditions.
- 2
Fix the horizon at three to five years and defend it
The team thinks about what software development looks like in three to five years — not what ships next quarter. Their output is papers, experiments, and POCs.
Watch out The moment leadership says 'we need something in six months, go invent it right now', you have created a second engineering team and lost the horizon.
- 3
Wire in a permanent two-way loop with product and engineering
Keep the research team in constant discussion with product and engineering: research shares POCs and future vision, product shares customer feedback and ideas. Ideas flow both ways, continuously.
Pro tip Shani's second success condition is 'focusing on making things real' — never let the team sit disconnected from product and engineering.
Watch out Disconnection is what turns a research team into an ivory tower: 'they write but nothing is coming out of that.'
- 4
Ask 'how does this reach production?' at idea zero
Build the productionization question into the very first conversation about a new idea, not at handoff. Ideas that were never asked this rarely survive the hump between prototype and product.
- 5
Keep a flexible funding mechanism for ideas from anywhere
When anyone brings a researched idea (a paper plus a proposal), decide case-by-case: can we fund it, can we allocate bandwidth, do we run a POC in the owning team or spin up a v-team. Keep the routing flexible rather than fixed.
Pro tip Sources GitHub actually harvests: the field team implementing for customers, product, design, engineering, and the open source community hosted on the platform.
Watch out Do not replace this with a scheduled creativity slot. 'You have 15 minutes a day to be creative' is not how it works.
- 6
Broadcast the vision six to twelve months before it exists
Put the next vision on stage well ahead of availability — GitHub shared Copilot Workspace at Universe long before shipping — which both recruits feedback and forces the org to keep thinking ahead of its own roadmap.
In the wild
A researcher inside GitHub Next experimented with what could be done with a large corpus of code. The experiment worked, and because the team was tied into product and engineering rather than isolated, the org could rapidly scale and launch it.
→ Copilot went from research experiment to a product used by 1.5M+ developers and 37,000+ organizations, and reset the entire category.
Shani points to well-known corporate future-teams (Facebook's New Product Experience, Google's equivalent) that never produced comparable outcomes. Her diagnosis: they either became academic and shipped nothing, or were pulled into tactical six-month deliverables.
→ GitHub's counter-move is the deliberate synergy loop between GitHub Next and the product org, which she credits as the difference.
Common mistakes
Letting the research team become an in-house university
The team produces papers and prototypes but nothing finds its way to production, because no one designed the path from idea to product at the start.
Raiding the team for near-term deliverables
Handing them a six-month mandate converts a horizon-3 team into an ordinary horizon-1 engineering team, and the company loses the only group thinking past the roadmap.
Trying to schedule innovation
Structuring creativity into allotted slots kills the organic spark. Encouragement, bandwidth, and customer exposure produce ideas; calendar blocks do not.
Is it for you?
Best for
Product or engineering leaders at scaled companies who have (or want) a research/future team and keep watching its output die before production
Not ideal for
Early-stage startups where the whole company is already the horizon-3 bet and a separate research function would just fragment focus
From the transcript
“they're basically applied scientist research scientist that are working together and they're really thinking about three five years Horizon”
“one that the team is becoming basically an our University they right but nothing is coming out of that so nothing find its WS to…”
“the second thing that companies tend to use these teams is too much tactical and here is that we need something in six month go…”
“if you try to structure innovation you're losing that organic spk”
From the episode
The future of AI in software development
Inbal Shani (CPO of GitHub)