As a general rule, as a general principle, I certainly try to make sure that we're always reserving some capacity for bold, audacious experimental research projects. You can think of those really uncertain bets as being five to 10% of the team's capacity. About 25, maybe 30% of the team's capacity should generally be on just operations... and then the remainder of it, what is that, about 60% or so, is really on incremental progress.
The role of AI in new product development
September 04, 2022
Featuring: Ryan J. Salva (VP of Product, GitHub)
4 quotes · 4 insights
Watch Full EpisodePortfolio your bets: 70% core, 20% adjacent, 10% moonshots
Empowered teams own outcomes, feature teams just ship
You can't really delegate roadmap to an R&D team. 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 who really need to own and feel like they control the roadmap.
Platform teams need different validation cycles
Engineering fundamentals in a lot of ways are the contracts that differentiate an R&D team from an operational product team. Bringing that fundamentals process into it is going to feel candidly a little bit unnatural to the researchers.
Separate innovation from execution structurally
"That methodology" refers to the three-horizon innovation framework where horizon two/three are longer-term projects (3-5 years out), and EPD stands for Engineering, Product, and Design teams.
Not to say that there aren't teams at Microsoft who might also use that methodology, but where we've been really maybe explicit or intentional about it is at GitHub where we've actually ring-fenced a team to think about that horizon two and horizon three work and kept them separate from EPD.