Diverge-Then-Converge Roadmap Reset
On a platform shift: drop the roadmap, keep the objective, let teams go crazy, then pick 4-5 bets.
- Difficulty
- Advanced
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 90%
Cohen's protocol for reorienting an entire product organization around a new technology without shipping the usual pile of pointless AI features. The trick is to preserve the problem statements while destroying the solutions: teams let go of their roadmaps but go back to the same objectives, then get several weeks of deliberately unmanaged exploration (duplicates allowed) before leadership converges resourcing onto a handful of bets and reviews only those, every week.
Origin
Run by Tomer Cohen at LinkedIn in Fall 2022 — months before the world learned about ChatGPT in March 2023. He called his product leaders into a room and told them to let go of their roadmaps and come back in a couple of weeks with how they thought differently about the problem they were already trying to solve.
Core principles
- 01Never start from 'we have this cool technology, what can we do with it' — that is how the useless-AI-feature pile gets built.
- 02The objective survives the platform shift; the roadmap does not.
- 03Divergence is a learning strategy, not a morale strategy — though it delivers both.
- 04Duplicate work during divergence is acceptable because the leader is learning from the variance.
- 05There is no playbook for a new technology; you have to write it (LinkedIn wrote its own prompt-engineering playbook).
- 06Capacity and cost are hard constraints, so divergence must be time-boxed and followed by top-down convergence.
- 07What the leader repeatedly reviews is what the org believes is important.
How to run it
- 1
Call the room and revoke the roadmaps
Get the product leaders together. Explicitly tell them to let go of what they have built and let go of their roadmaps — while being clear that the work was great. This is a reset, not a rebuke.
Watch out Skipping the 'what we've done was great' framing turns the reset into a demotion and kills the exploration energy.
- 2
Send them back to the objective, not to the technology
The assignment: go back to what you were trying to solve for, and come back in a couple of weeks with how you think differently about that problem knowing this technology now exists. The question is always 'how can you do that objective better,' never 'what can we do with this.'
Pro tip This is the same clarity-of-problem discipline from 'we might be wrong but not confused' — the nuanced problem statement is the only thing you carry across the platform shift.
Watch out The moment the framing becomes technology-led, you get the meme: a somewhat-dumb artificial person integrated into everything.
- 3
Set ground principles, then deliberately do not contain them
Establish the ground rules and then let teams run to inspire creativity. Allow duplicates and overlapping ideas explored differently. The leader's job in this phase is to be excited and to watch what people come up with.
Pro tip Cohen's real motive was learning: going in a straight line teaches you almost nothing, while people pushing the boundaries teaches you enormously. The morale benefit — people no longer frustrated that there's a thing they wish they could try — is a bonus.
Watch out Expect failure. Cohen: 'we failed a lot but we learned so much along the way.'
- 4
Write the playbook as you go
Capture what the org learns about the new technology as an internal playbook (LinkedIn's became a prompt-engineering playbook). Treat the absence of an external playbook as the opportunity.
Pro tip LinkedIn learned so far ahead of the market that it shared findings with OpenAI and Microsoft.
- 5
Converge top-down onto four or five bets
Several weeks in, close the divergence with a top-down pick. Go back to the objectives, select the handful of biggest bets from everything you have seen, and converge resourcing onto them. No more everybody building whatever they want — capacity and cost are constraints.
Pro tip Do this as an explicit, announced top-down call. Trying to converge by consensus after a divergence phase re-opens the divergence.
- 6
Review only the bets, weekly, forever
Replace the usual rotating multi-topic product jams with a weekly review of only the four or five bets, and nothing else — precisely so the organization understands what the leader cares about and stays focused.
Pro tip The signal is in the exclusion. Reviewing 'nothing else' is the message.
In the wild
In Fall 2022, before ChatGPT was public, Cohen asked every team to completely revisit their entire roadmap: let go of it, return to the problem statement, and come back in two weeks with a new solution framed AI-first. Teams then explored freely, including building duplicates, and the organization wrote its own prompt-engineering playbook. Several weeks later leadership picked the four or five biggest bets and converged all resourcing on them, with weekly reviews of only those bets.
→ LinkedIn moved AI from the back of its marketplaces (the invisible matchmaker) to the front of the product, restructured its entire product operations and portfolio, and had a head start on the market that only learned about GPT-class models in March 2023. Shipped output includes the LinkedIn job-seeker Coach experience.
Lenny connects Cohen's divergence phase to Brian Chesky's habit of introducing chaos when roadmaps feel too calm and on schedule — asking how the team could do something in one day instead of two weeks. Cohen agrees: people settle into lanes, get comfortable, and stop knowing that other ways exist.
→ Cohen's conclusion: the disruption has to be externally invoked or triggered by the leader, because inertia is human behavior and will not break itself.
Common mistakes
Starting from the technology
'We have this cool technology, what can we do with it' produces AI shoved into everything and shipped features nobody wants. Cohen inverts it: go back to the objective you were already trying to solve, and ask how the technology does it better.
Skipping the divergence and mandating the bets on day one
Without a real exploration phase the leader has no variance to learn from, no internal playbook, and a workforce quietly frustrated that they never got to try the thing they were excited about.
Never closing the divergence
Capacity and cost are constraints. Duplicated exploratory builds are only defensible for weeks; if leadership does not make a top-down pick and converge resourcing, the excitement becomes permanent sprawl.
Is it for you?
Best for
A product leader at a company facing a genuine platform shift (LLMs, mobile, etc.) whose existing roadmaps were written under the old technology's assumptions.
Not ideal for
Incremental periods with no platform shift, or teams with no slack capacity at all — the divergence phase requires tolerating duplicate, throwaway work.
From the transcript
“it wasn't like oh we have this School Technology what can we do with it it was like go back to the objectives you were…”
“we actually allowed teams to run to really Inspire creativity I didn't want to contain them”
“even some we're building duplicates for uh for a while of like you know similar ideas but un differently”
“no more everybody's building whatever they want we also you know capacity is also constraint cost is a constraint”
“I just reviewed the five kind of bets we had on a repeated basis nothing else”
“prompt engineering became a Playbook internally for us”
From the episode
How LinkedIn became interesting: The inside story
Tomer Cohen (CPO at LinkedIn)