Lenny's PodcastTomer Cohen: How LinkedIn collapsed PM into full-stack pods
Through bespoke trust, growth, and research agents, small pods own ideas end-to-end; LinkedIn sunset its APM program and built a full-stack builder ladder.
CHAPTERS
- 0:00 – 7:05
Why product building must change: skills churn and pace of change
Tomer frames AI as an empowerment shift and argues that organizations are falling behind because the pace of change is now faster than their ability to respond. He shares LinkedIn labor-market data (e.g., major skill shifts by 2030) to explain why product development needs to be reimagined from first principles.
- •AI’s real promise is empowerment and meritocracy (enabling people to do more)
- •Change is happening faster than organizations can respond
- •By 2030, skills required for the same jobs are projected to change dramatically
- •Fast-growing roles are reshuffling quickly, forcing organizations to adapt
- •This context motivates a fundamental rethink of how products get built
- 7:05 – 11:52
How process bloat created organizational bloat (and why shipping got slow)
He breaks down how a simple build loop (research → spec → design → code → launch → iterate) became overloaded with sub-steps, reviews, and dependencies. That process complexity then drove organizational complexity and micro-specialization, making even small features take multiple teams and sprints.
- •Every lifecycle step expanded into many sub-steps (many info sources, many reviews)
- •Individually rational steps add up to a massively complex system
- •Complex processes require more people/functions to run them
- •Micro-specialization emerges across PM, design, and engineering sub-disciplines
- •Launch speed suffers, and iteration (where success happens) becomes harder
- 11:52 – 12:33
The Full-Stack Builder (FSB) model: collapse the stack around craftsmanship
Tomer introduces LinkedIn’s Full-Stack Builder model, aimed at empowering builders to take ideas to market regardless of their traditional role. The intent is not replacing teams, but forming smaller, mission-focused pods with fluid human+AI collaboration across the lifecycle.
- •FSB goal: enable builders to go end-to-end from idea to market
- •Cross-domain capability matters more than rigid functional boundaries
- •Human+AI interaction should be fluid, not a rigid sequence
- •Teams still matter—just smaller and more mission-oriented
- •Pods assemble for a quarter, then re-form based on priority missions
- 12:33 – 16:35
What humans must own: vision, empathy, creativity—and especially judgment
He clarifies which parts of building should remain distinctly human, emphasizing judgment as the most critical trait in ambiguous situations. Everything else becomes a target for automation, so builders can spend more time on high-leverage decision-making.
- •Core human traits: vision, empathy, communication, creativity, judgment
- •Judgment/test-making is the most valuable capability to preserve
- •AI is still limited in “next-level” creativity, reinforcing the human role
- •Communication remains crucial for alignment and rallying others
- •Strategy: automate everything outside these traits to refocus builders
- 16:35 – 17:05
The three pillars to make it real: platform, tools/agents, and culture
Tomer lays out the implementation framework: you need an AI-ready platform, purpose-built tools/agents, and cultural adoption mechanisms. He stresses that tools alone won’t deliver transformation without the platform and culture investments.
- •Three components: platform, tools/agents, culture
- •Platform is foundational—without it, external tools won’t work well at scale
- •Agents/tools automate sub-steps across the lifecycle
- •Culture determines whether people actually adopt and improve the tools
- •This is a new production function, especially for large/legacy orgs
- 17:05 – 19:16
Platform work: re-architecting systems so AI can reason over LinkedIn
He explains why “off-the-shelf” AI tooling fails in a complex, legacy environment. LinkedIn is rebuilding composable UI/server-side components and integrating deeply with vendors so AI can operate reliably over their codebase and design systems.
- •Re-architecting core platforms so AI can reason over them
- •Off-the-shelf agents don’t work immediately on LinkedIn’s stack
- •Requires back-and-forth customization with vendors (coding + design tools)
- •Design systems and code context must be made AI-friendly
- •Key learning: integration is not enough—stack adaptation is required
- 19:16 – 23:22
Building specialized agents: trust, growth, research, analyst—and an orchestrator later
Tomer walks through several internal agents and why they’re tailored to LinkedIn’s unique context. They start with discrete “job-to-be-done” agents (trust/growth/research/analysis) and plan to add orchestration so agents can collaborate behind a simpler user experience.
- •Trust agent flags vulnerabilities and harm vectors in specs/ideas
- •Growth agent embeds LinkedIn loops, funnels, and historical test learnings
- •Research agent models member personas using internal research + tickets
- •Analyst agent helps query LinkedIn’s graph without deep SQL reliance
- •Strategy: build blocks first; later, orchestrate agents into one workflow
- 23:22 – 26:43
Tooling stack and adoption reality: enterprise LLMs, heavy customization, and tool sprawl
They use tools like Copilot/ChatGPT Enterprise but see the biggest gains from internal customization and orchestration. A practical challenge emerges: different teams gravitate to different AI tools (e.g., multiple design agents), forcing deliberate convergence choices.
- •Using enterprise LLM tools, but customization drives most value
- •Internal orchestration enables agents to ‘hand off’ work to each other
- •Teams prefer different tools based on familiarity and use case
- •Risk: ending up with too many parallel agents/tools across the org
- •Expectation: no single winner-takes-all tool for every starting point
- 26:43 – 27:51
Idea-to-design vs. code-to-launch: where automation is already paying off
Tomer splits the lifecycle into idea→design and code→launch, noting code acceleration started earlier. He highlights strong results from coding, maintenance, and QA agents—like automated handling of failed builds—while ramping investment in the earlier, higher-leverage discovery/design phase.
- •Lifecycle staged into idea→design and code→launch
- •Coding agent plus maintenance agent helps fix failed builds automatically
- •Claimed progress: near half of failed builds handled by the maintenance agent
- •QA automation also contributes to speed and reliability
- •New focus: accelerate early-phase quality (specs, research, product jams)
- 27:51 – 31:35
From concept to MVPs: timelines, data cleaning, and ‘golden examples’ as the real work
He shares how the program ramped internally and how quickly early MVPs appeared, but emphasizes the hidden cost: curating and cleaning knowledge. Letting an agent loose on “all your drive” fails—success requires carefully selected context windows and golden examples.
- •Initial internal announcement and team/process setup preceded MVPs
- •First agents reached MVP status within a few months of focused effort
- •Largest effort: collecting/cleaning corpora and selecting training examples
- •Giving blanket access to all docs leads to poor weighting and hallucinations
- •Key lesson: curate context intentionally; don’t equate access with usefulness
- 31:35 – 38:24
Pilot rollout and early impact: time savings, better discussions, and rising demand for access
The pilot is in pockets across the org, with a feedback-for-access loop to improve tools. Early signals include hours saved per week, improved insight quality, and new behavior changes (e.g., PMs/designers picking up Jira work and pushing changes).
- •Pilot measures: (experimentation volume × quality) ÷ time-to-launch
- •Reported benefits: hours saved weekly across PM/design/engineering roles
- •Quality improves via better insights and higher-quality discussions
- •Early behavior shifts: non-engineers picking up tickets and contributing more directly
- •Demand constraint: access is highly sought, but they want to GA only when ready
- 38:24 – 48:00
Change management and culture: incentives, performance reviews, and visible success stories
Tomer argues adoption is the hardest part: most people won’t change just because tools exist. LinkedIn uses incentives, updated expectations (including performance evaluation), training programs, and highly visible examples to make AI-enabled building feel achievable and worthwhile.
- •Only a small cutting-edge group adopts immediately; most need change management
- •Set expectations via hiring, calibration, and performance evaluation criteria
- •Create internal FOMO and momentum through pilot wins and storytelling
- •Celebrate examples (e.g., BD leader building portals; UXR → growth PM transition)
- •Training programs (Associate Product Builder) reinforce the new operating model
- 48:00 – 52:46
Limits, trade-offs, and talent: not everyone should be FSB; specialization still matters
He acknowledges negative surprises: off-the-shelf tools didn’t work, naive knowledge access caused hallucinations, and tool convergence is hard. He also clarifies that full-stack building isn’t for everyone—there will still be system builders and specialists, just fewer than before.
- •Biggest surprises: off-the-shelf tooling never worked; required major investment
- •Naive “connect everything” approach led to hallucinations and poor results
- •Tool preference fragmentation complicates standardization
- •Some people prefer specialization; the goal isn’t 100% conversion to FSB
- •FSB as a formal title/career path exists, but mindset change matters more
- 52:46 – 56:49
How to implement this in your company: don’t wait, invest upfront, and over-communicate progress
Tomer’s advice focuses on acting early and treating the transformation like a product rollout. Build platform and customized tools, but prioritize culture, visibility, patience, and ongoing communication—because large-scale transformation can’t be achieved with “2x productivity in a week” expectations.
- •Start with platform + tools + culture; culture is the differentiator
- •Maintain broad visibility so the org isn’t left guessing what’s happening
- •Be ambitious about the goal, patient and deliberate in execution
- •Allocate real resources: platform readiness and tool customization are non-optional
- •Don’t wait for a reorg—prove the mindset by building/trying tools now
- 56:49 – 1:07:31
Lightning round and closing: books, AI-in-the-car wish, growth mindset, and leaving LinkedIn
In the lightning round, Tomer shares recommended books, a favorite podcast, and a product wish: a frictionless ‘AI companion’ button in the car. He closes reflecting on his growth mindset (“becoming is better than being”) and discusses leaving LinkedIn after 14 years and his excitement for what’s next.
- •Book recommendations: Why Nations Fail; Outlive; The Beginning of Infinity
- •Favorite media: a Hebrew podcast that deeply explains the origins of songs
- •Product wish: a steering-wheel button for instant conversational AI companion
- •Life motto: continuous growth—‘becoming is better than being’
- •Reflection on leaving LinkedIn, gratitude for the ride, and excitement to build next
