How Do Product Managers Survive in the AI Era? | A LinkedIn CPO Interview
By 2030, 70% will have changed.
By 2030, 70% of skills will have changed.
👦🏻 Compiled by: Bella
🥷 Edited by: Koji
🧑🎨 Designed by: NCon
Lenny's Podcast is one of Crossing's favorite Silicon Valley podcasts — we listen to nearly every episode (and at minimum skim the summaries when we're short on time). Its greatest value isn't in interviewing founders, but in deep conversations with product managers and engineers who have their "hands in the dirt."
In the latest episode of Lenny's Podcast, they invited LinkedIn CPO Tomer Cohen for another standout conversation.
Tomer opened with a disquieting yet impossible-to-ignore statistic:
By 2030, 70% of the skills required to do a job will have changed.
When we first saw this data, it stopped us in our tracks. It comes from LinkedIn's long-term observation of real jobs and skill shifts.
The question is no longer whether you plan to switch jobs — it's whether what you're doing right now will remain competitive in the future.
This number made us realize that the question is no longer "whether to learn AI," but how we fundamentally need to rethink work itself, and the way we build products, organizations, and individual capabilities.
And so, we've decided to fully compile and organize this conversation between Lenny Rachitsky and Tomer Cohen.
In an era where AI becomes the default capability, how should people build products? Tomer offered one answer:
The "Full Stack Builder Model."
Its goal is to empower truly great builders: regardless of which team they're on or which layer of the stack they use, they can push their ideas into reality quickly.
🚥🚥🚥
What follows is a complete translation and structural reworking of this podcast episode, faithful to the original meaning as much as possible. We hope this serves not merely as a "summary of ideas," but as a serious mirror and provocation for how work itself will change.
Part I: When Skills Change Faster Than Jobs Themselves
👦🏻 Lenny Rachitsky
My guest today is Tomer Cohen, LinkedIn's longtime Chief Product Officer. He is spearheading an entirely new way of building products at LinkedIn — one that I believe will become the template for how companies operate in the future.
The initiative is called the "Full Stack Builder" program. Its core idea is to give anyone the ability to take a product from idea to launch.
They've even eliminated the traditional Associate Product Manager program, replacing it with a "Junior Full Stack Builder" program. They've introduced a new career path where anyone in any function can become a Full Stack Builder.
They've built an entire suite of internal tools, agents, and workflows around this goal — essentially creating a "human + AI" collaborative product team. Such teams move faster, adapt more readily to change, and deliver higher-quality results with fewer resources.
If you're looking for inspiration on how to rethink team operations, or trying to understand how AI can truly unlock the potential of teams and organizations, this episode is well worth your time.
Tomer, thank you so much for coming on, and welcome back to the podcast.
🧙🏻 Tomer Cohen
Thanks, great to be back.
👦🏻 Lenny Rachitsky
You're trying a new way of building products at LinkedIn that fully embraces the possibilities AI has opened up. To me, this feels like a model for how many companies will operate and build products in the future.
I want to start with the most fundamental question: Why did LinkedIn need to do this? Why rethink the entire way products are built? Why is this worth taking seriously?
🧙🏻 Tomer Cohen
To me, technology has always been about empowerment. The point isn't what technology does for us, but what it enables us to do.
We now have an extraordinary opportunity to return everything to a meritocracy. We're entering a phase where the pace of change far outstrips our ability to react.
The data we're seeing at LinkedIn is staggering: By 2030 — just four years from now — 70% of the skills required for various jobs will have changed.
This means whether or not you plan to change jobs, your job itself is changing. The real question is: can you keep it?
The same holds at the organizational level. The fastest-growing, most in-demand roles today are accelerating far beyond what was hot even a year ago. All these changes point to the same conclusion: if we want to stay competitive, we must return to first principles and rethink how we build products.
The goal of a builder is actually quite simple: start with an idea and make it real.
But in large organizations, this process gets endlessly decomposed and layered until it becomes extraordinarily complex. Research, design, review, security, privacy...
Each step has its own rationale, but stacked together, even a small feature often requires multiple teams, multiple codebases, and multiple sprints to ship.
Process complexity ultimately becomes organizational complexity: one builder gets split into engineering, product, design, and other functions, each of which continues to subdivide internally.
Now, AI gives us a genuine opportunity to simplify this technology and process stack, returning to something closer to a craftsperson's approach to building, and rethinking the complete product lifecycle — this is the backdrop against which the Full Stack Builder model was born.
👦🏻 Lenny Rachitsky
Wow, about that statistic you shared: by 2030, 70% of the skills people need for their current jobs will change. What is that based on?
🧙🏻 Tomer Cohen
Objectively speaking, change has always existed, but we've never seen it this dramatic. Whether you're in marketing, sales, recruiting, or engineering, your job is going to change massively. Engineering especially — there's enormous investment in agents flowing into this space, and these work patterns will fundamentally transform.
Not all jobs will change equally. Nursing, for instance, will be less affected. But some jobs could see 90% or even 95% change.
👦🏻 Lenny Rachitsky
I also saw a data point: 70% of today's fastest-growing jobs didn't even exist on the rankings a year ago.
🧙🏻 Tomer Cohen
Exactly. Not only did they not exist a year ago, many didn't exist ten or twenty years ago.
Part II: What Is the Full Stack Builder Model? What Are a Builder's Core Capabilities?
👦🏻 Lenny Rachitsky
Alright, let's talk about the program you've created. Please introduce its name, core content, and future vision.
🧙🏻 Tomer Cohen
The program is called the Full Stack Builder Model.
Everything must always start from the goal. And there's only one goal: empower great builders. No matter what role they play, what stack they use, or what team they're on, they can push their ideas to market. The core idea is giving builders end-to-end capability to craft experiences, fusing together different skills and expertise.
I've always believed that a builder's most precious time should be spent on the things only they can truly do well.
First is vision — articulating a clear, compelling picture of the future that makes people believe this direction is worth pursuing.
Next is empathy — genuinely understanding unmet needs.
Then there's communication — the ability to connect people around an idea, so that more people want to invest their energy toward the same goal.
Then there's creativity. I believe AI is still limited in this regard — it's better at synthesizing existing information, while humans retain the edge when it comes to higher-level creative breakthroughs.
Finally, and I think most importantly for a Builder, is judgment. You could also call it decision-making — the ability to make high-quality decisions even in highly complex, uncertain environments.
Beyond these five, I'm also pushing hard on automation.
This isn't just about increasing the number of attempts (though iteration speed does improve). More importantly, it's about making a scaled organization more agile, adaptive, and resilient.
My analogy is the US Navy SEALs: they cross-train, they're mission-focused, they operate in small teams, they're highly agile and can rapidly assemble. I believe this is the organizational form that will win in the future.
👦🏻 Lenny Rachitsky
So to simplify, the idea is that a Builder basically handles the entire product development process alone: ideation, research, data, prototyping, shipping?
🧙🏻 Tomer Cohen
Yes, but it doesn't have to be solo. I still believe in the power of teams.
👦🏻 Lenny Rachitsky
Got it, so smaller teams.
🧙🏻 Tomer Cohen
Yes, small teams focused on a mission. For example, we've started adopting a Pod model. Instead of large teams, you assemble a small squad, ideally composed of Full Stack Builders. The focus shifts away from gathering the classic "iron triangle" of engineers, designers, and PMs — toward finding people who can operate across functions, have them solve a specific problem within one quarter, then reassemble. We've seen tremendous success with this model, both in speed and in team focus and flexibility.
👦🏻 Lenny Rachitsky
It feels like what you're trying to reclaim is the speed, adaptability, and flexibility that gets lost as teams bloat. Because going back to your original point, change is happening so fast that companies built the traditional way simply can't compete.
🧙🏻 Tomer Cohen
Exactly. It's not that you have to break the model. I think the model is already broken. It's just that the pace of change is helping us realize it.
Part III: AI Agents Aren't the Point — Change Management Is
👦🏻 Lenny Rachitsky
So on the automation front, where are you seeing success?
🧙🏻 Tomer Cohen
If you're a startup, you might naturally operate this way already. But for a company at our scale, this is almost an entirely new mode of production and thinking.
We're investing mainly across three areas: platform, tools and agents, and culture.
On platform: We're rearchitecting our core platform so AI can understand and reason over it. We've built server-side componentized UI, essentially getting it ready for AI integration. You can't just bring in third-party tools and expect them to run on LinkedIn's tech stack — that was one of our biggest lessons, that plug-and-play never works. You need to do a lot of customization.
👦🏻 Lenny Rachitsky
So this is essentially refactoring the codebase to make AI work more effectively?
🧙🏻 Tomer Cohen
Exactly. Whether it's Copilot, Cursor, or Windsurf, we need to build a layer that lets AI reason effectively over our code. Same with design systems — Figma and other tools need to know how to work with our design system.
👦🏻 Lenny Rachitsky
That's the platform investment. What about tools?
🧙🏻 Tomer Cohen
Tools is where we build agents. As I mentioned, our goal is to automate as much as possible outside those five core Builder capabilities. This also means it's almost impossible to use off-the-shelf tools here — every agent has to be highly customized.
Take our Trust Agent: when a product is still at the idea or spec stage, it can proactively identify potential risks based on historical experience and domain expertise. Using "Open to Work" as an example, when the Trust Agent reviewed that product plan retroactively, it not only surfaced issues we had already recognized at the time, but also uncovered vulnerabilities that only emerged later — significantly reducing post-launch risk costs.
Another is our Growth Agent. We've fed it all our past growth loops, funnels, and experimentation experience, so it can both execute growth ideas and evaluate their potential. Today, its use has expanded beyond the growth team — even our UXR team uses it to assess which proposals are most likely to drive meaningful impact.
Then there's our Research Agent. It draws on years of user research and support data to evaluate product plans from the perspective of specific user personas — say, small business owners — and often directly shifts team decision-making, filling the gap where information is hard to centralize in large organizations.
We also have an Analytics Agent that can query LinkedIn's entire complex graph directly, without relying on SQL or data science teams.
Most of these agents are still at the MVP stage. Our goal is to gradually roll them out across LinkedIn over the coming months.
👦🏻 Lenny Rachitsky
Lots of questions here. One is, how did you build it? What platform did you use? What does it take to build an agent at LinkedIn? Are these all internal tools, or are you using third parties?
🧙🏻 Tomer Cohen
We're experimenting with a lot of tools.
For knowledge-based agents like these, we've tried everything from Copilot Enterprise to ChatGPT Enterprise, but what drove the biggest gains was deep internal customization.
We even built an Orchestrator specifically to let the Trust Agent and Growth Agent collaborate back and forth, rather than simply executing in sequence. This layer is almost entirely internal — and precisely because of that, it requires serious investment.
On the agent design side, we're also working with multiple companies simultaneously to find what works best for LinkedIn. One very practical discovery is that different teams naturally prefer different tools.
And what we need to solve next is how to simplify processes amid this variation — including which tools to select and how to integrate them.
👦🏻 Lenny Rachitsky
So for example, you might have a great Figma agent, but some teams want to use a different design tool?
🧙🏻 Tomer Cohen
Exactly. We've experimented with Figma, Subframe, Magic Patterns, and others. We see people gravitating toward different tools based on function, familiarity, and so on.
Ultimately, I don't want eight design agents at the company, so we have to narrow it down to a few.
I think this pattern holds across many domains, because a lot of agents are attractive in that they're trying to solve similar end goals, but they go about it very differently.
In the end, I don't think there will be a winner-take-all dynamic, because the starting point of the customer or user will largely determine how easy these tools are for specific use cases.
👦🏻 Lenny Rachitsky
Another interesting finding is that you're designing very specific, single-task agents. Was this a very deliberate decision? Have you tried more general-purpose agents?
🧙🏻 Tomer Cohen
In the long run, we'll definitely have an orchestrator that unifies these agents. But early on, we wanted to first get each agent's capabilities right and clearly defined, with clear ways to evaluate and measure their individual performance.
There's actually a kind of "division of labor" at play here. At the same time, we're deliberately shielding this complexity in the architecture — end users don't need to know which specific agents are collaborating behind the scenes.
For example, you might not know you're using a Trust Agent. What you're actually interacting with might be what we internally call a Product Jam Agent, which runs our internal product jam process. To the user, you're just using a product jam engine, and this agent coordinates with other agents behind the scenes.
So right now, we're starting from these foundational building blocks, layering up step by step, until we eventually build out the full orchestrating layer.
👦🏻 Lenny Rachitsky
Listening to you, one thing that stands out: you're pouring enormous energy into the front half of product development — things like defining the right requirements, handling trust issues, and product jams and user research.
I suspect a big reason you're doing this is because the actual coding itself has already been significantly accelerated by AI tools.
Can you talk about why you think this is the most worthwhile place to invest?
🧙🏻 Tomer Cohen
Yes, absolutely. We actually started investing in programming quite early, and that work is now starting to come together. We have our own coding agent, and we've broken the work into two phases. One is more of an "idea to design" phase, and another that we call "code to ship."
The "code to ship" piece has already had a lot of energy put into it, and we've made very clear progress. From the coding agent to what we call our maintenance agent — which automatically handles things when builds break — that entire pipeline is continuously improving.
Right now, close to 50% of builds and related quality assurance work is being done by the maintenance agent and QA agent.
👦🏻 Lenny Rachitsky
That's so cool.
🧙🏻 Tomer Cohen
But before we launched this initiative, we hadn't invested much in the "idea to design" space. And that's actually a critical part of the work, at least before you get into coding.
Our thinking is to empower everyone. If you're an engineer, you can essentially use all these tools at the front end of the process and become a full-stack builder.
👦🏻 Lenny Rachitsky
From when you had this idea to when you actually assembled the first team, started building these initial agents, and redid the underlying code architecture — how long did that take?
🧙🏻 Tomer Cohen
I officially announced this to the company at the end of last year. After that, there was a period of building the team and setting up internal processes.
Our first batch of agent MVPs came together about four to five months after the model training was completed.
But if you're just counting build time, it was really a matter of months. A huge amount of work went into centralizing all the data corpus and cleaning it up. You can't just dump all your cloud documents into the model and let it reason freely. That works very poorly, because it can't judge the importance of historical content or know which information should be weighted more heavily.
You have to think through: in what context should it see what information, what knowledge areas should it focus on; and at the same time, curate a set of high-quality golden examples.
Simply having the model traverse the entire knowledge base and reason over it doesn't work.
👦🏻 Lenny Rachitsky
That makes sense. For example, maybe a researcher has a strong opinion about something that you disagree with, but the model doesn't know that. It just treats those opinions as data, as fact.
🧙🏻 Tomer Cohen
Exactly right. And models often can't understand: which content is relevant to the original spec, to the ultimate success metrics.
So when you bring these tools into a team, you can't just "plug them in." What's more critical is that you think through exactly what to feed them. Feeding data is never as simple as just granting access.
I see a lot of teams focusing on connecting and integrating tools, which reminds me of over ten years ago — when I was at LinkedIn helping rebuild the feed from scratch. I had to personally sit down and go through piece by piece to curate what good content looked like.
I spent several weeks putting together a full set of high-quality "golden examples." But the key wasn't stuffing all the data in — it was making sure the model got the right data. That takes investment.
So what I'd say to companies considering entering this stage: You have to put in this foundational work upfront, and then you reap the efficiency and quality gains.
I think there's a general lesson about AI here: whether it's your first time using AI or not, whether you're using Cursor, or Figma for design, or other tools — you have to be prepared to put in that upfront time, and then you'll truly see speed and quality grow. They will come, but the upfront investment can't be skipped.
👦🏻 Lenny Rachitsky
How big is the team now? How many teams are using it? What have you actually shipped? Can you help us understand where things stand?
🧙🏻 Tomer Cohen
Sure. We already have a meaningful portion of teams using these tools, continuously giving us feedback, and we've seen quite a few success stories.
I usually measure its value with a simple formula: experiment volume × experiment quality ÷ time from idea to launch.
On the time dimension, whether you're a PM, designer, or engineer, you're now saving several hours each week: analysis agents, rapid prototyping tools, and the product jamming experience have all contributed significantly.
On quality, we're seeing noticeably better depth in insights and discussions. And quality and time sometimes reinforce each other: the higher the quality, the less time you need to spend reworking or validating.
As for scale, I wouldn't say it's reached a majority of the organization, because we haven't done an internal "general availability" launch yet. That's expected to happen in the coming months, once all conditions are ready.
The signal right now is very clear: everyone wants access. Everyone wants in.
👦🏻 Lenny Rachitsky
So how are you piloting this currently? Is it that certain people get access to these agents first, and then continue working their normal way but with these additional tools?
Or did you assemble a dedicated team — with a mandate of "from now on you work this way" — and observe what happens?
🧙🏻 Tomer Cohen
Basically, we do have a core team responsible for building out the full-stack builder track and tools across the entire R&D system.
Then within each domain, we have small teams using it. That is, we select specific domains and give the tools to the teams there. The only condition is: they have to keep giving us feedback.
That way the tools keep getting better, rather than just giving you access and being done. We want these teams to be people who will actually use it and push it forward. So right now we're using a kind of pod model for piloting.
👦🏻 Lenny Rachitsky
So these pods are like small units within larger teams? Like a group of designers, PMs, engineers? Can you give an example? Which teams at LinkedIn are piloting this now?
🧙🏻 Tomer Cohen
We recently launched semantic people search and semantic job search. These projects used some of the new tools during their build process.
In this project, the PM could directly build dashboards themselves without waiting for design resources to free up.
Then there was a design team — it started with their manager pushing this. I often tell them: "Don't wait for internal GA, just start using it." And now, these designers are submitting PRs themselves, which almost never happened before.
This change is starting to spread to other teams pretty quickly, with more and more people actively wanting to join — it has a bit of a grassroots, bottom-up diffusion feel.
That said, the initial formal push did come from leadership.
We reorganized product leadership from the old functional structure (Design, PM, BD, etc.) to being organized by product domain, so they could truly own across the full product stack. They went through "360-degree capability assessments" to ensure they had full-stack building skills.
At the same time, on talent development, starting next year we'll replace the traditional APM program with an Associate Product Builder (APB) program. New hires joining LinkedIn will go through rigorous training, join these pods, and gradually become a core talent pipeline going forward.
👦🏻 Lenny Rachitsky
So the future APM program might essentially be this full-stack builder-oriented APM program?
🧙🏻 Tomer Cohen:
In a sense, yes. The training we've prepared for this cohort is really excellent — I honestly wish I could have joined it myself back in the day (laughs).
We've designed a very systematic, very advanced training framework for them, and this framework will also become the foundation for how we roll out training across the entire company going forward.
Here's how we think about these people:
You might have strong technical skills, but you're not yet an engineer at a company;
Or you might have great design taste, but you haven't designed in a large-scale product environment.
We'll teach you at LinkedIn how to actually apply those capabilities inside a company, on real products. And this training content will eventually extend across the entire organization.
👦🏻 Lenny Rachitsky:
Got it. It's still relatively early, but you mentioned earlier that teams are already saving several hours per week — is that right?
🧙🏻 Tomer Cohen:
Yes. And I think the most critical thing is actually the feedback. We're treating this as a product being refined internally at LinkedIn. Early adopters keep giving us feedback, and so far it's been overwhelmingly positive.
What's interesting is that the most active users are actually LinkedIn's top talent. The quality of their output has noticeably improved, and they're more willing to invest time in co-building and pushing this system to expand further.
That's why we're so confident about the future. I expect that in about the next six months, more teams will start adopting it, and at that point, the broader effects will gradually become visible.
👦🏻 Lenny Rachitsky:
That insight is really fascinating: top talent actually benefits the most from these tools. Because there's been this ongoing debate — does AI make average people stronger, or does it make people who are already excellent even stronger? Sounds like it's probably the latter.
🧙🏻 Tomer Cohen:
Yes. In a way it's both surprising and not surprising. Of course you want everyone to benefit, but the reality is that the people who adopt it first and use it best are usually that small top tier within the organization. They already have the drive to keep improving, and they're more willing to experiment with cutting-edge ways of building.
That's why I often ask my team one question: if we build all these tools, will they actually use them? And I'm very clear on the answer now: no. New tools alone aren't enough. The first movers are typically only about 5% of the organization — people who naturally prefer change and enjoy trying new things.
You have to build incentive mechanisms, demonstration cases, clear usage patterns. People need to see success stories before they'll change.
I went through the exact same challenge when I led LinkedIn's shift from desktop to mobile. Change management and cultural investment are what ultimately determine success or failure. The vast majority of people need to be brought along into change, and that, actually, is the most important work right now.
👦🏻 Lenny Rachitsky:
Right, and it's easy to understand why many people don't want to invest the time — they're already busy, and now they have to learn a new tool with no clear short-term payoff. You mentioned earlier that there are three key parts to success: platform, tools, and culture. So at the cultural level, what have you actually done that works? Like creating some FOMO — does that kind of thing actually work?
🧙🏻 Tomer Cohen:
Yes, I have to emphasize: platform and tools are necessary but far from sufficient. What really determines whether you succeed is whether you're willing to make sustained investment at the cultural level. And cultural change is always slow at first — I already verified this during the desktop-to-mobile transition. But once it gets going, its acceleration is very fast.
People's behavior is heavily driven by expectations. In other words, you have to clearly tell them what you expect them to have and achieve in a given role.
👦🏻 Lenny Rachitsky:
Like changing performance review criteria?
🧙🏻 Tomer Cohen:
Exactly. From hiring, to competency calibration, to performance reviews — everything needs to be redesigned. In the early days we focused on two things: the awareness of proactively incorporating AI into work, and AI literacy (AI Agency & AI Fluency). The key isn't the tools themselves, but whether employees are willing to use them and willing to help refine them together.
Another key is generating real success stories, which is what the pod model is for. Not proving "the tool works," but demonstrating "it actually produced results." We've even seen partnership teams and BD teams join in — work that previously required engineering support, people are now completing directly themselves, telling others through action: "I can do this, and so can you."
On talent development, the APB program itself is also a strong cultural signal. New hires being systematically trained as multi-stack builders creates a demonstration effect within the organization. Meanwhile, publicly showcasing and celebrating these successes at all-hands meetings is also very important.
There was a very typical example recently: a user researcher saw an opening for a growth PM, stepped up proactively, used AI tools to fill in capability gaps, and transitioned from UXR to growth PM. This wasn't the traditional path, but it actually happened. Leap stories like this have enormous cultural driving power.
At the root of it all, this can't be pushed through by command. Tools need to be good enough, feedback needs to be smooth enough, people need to see real success, feel that the investment is worth it, and ultimately see qualitative change in their own work — only then does culture truly transform.
👦🏻 Lenny Rachitsky:
Several points you just mentioned — like showcasing success stories, letting people see how colleagues actually use AI tools, creating a program with a bit of an "admissions barrier" that people apply to join, and adjusting performance criteria — these are all critical. Because once promotion and evaluation standards change, people's behavior naturally follows.
So I'm curious: have you already formally incorporated these capabilities into performance reviews for PMs, or more broadly across the job architecture? Or are you still in a gradual rollout phase?
🧙🏻 Tomer Cohen:
We're pushing forward on two levels simultaneously. First, within my own direct team, we did 360-degree assessments, and the results go directly back to individuals — this itself creates strong motivation.
After that we extended this mechanism to a broader scope. Now it's already explicit in hiring that we're looking for people with these capabilities, and it will soon be formally incorporated into performance reviews, with full transparency to everyone. The feedback has actually been quite positive, because the standards are clear and there are real cases to reference.
But this kind of mechanism isn't suitable for a one-size-fits-all rapid rollout. What I care about is whether you truly have end-to-end thinking, whether you proactively use tools to take things from start to finish.
So I've always emphasized: don't wait for the company's formal announcement to start building in new ways. Whether or not you have an "official toolkit" in hand, you can start building and using things yourself first, prove yourself with results. Become a full-stack builder in mindset first, rather than waiting for someone to give you a title.
As long as you do this, change will naturally happen. And some of our best talent has already done so, and has moved faster because of it.
👦🏻 Lenny Rachitsky:
So how do you encourage people to use these tools on their own? Are there methods that get people to experiment even without joining a formal program?
🧙🏻 Tomer Cohen:
We share a lot of the tools we build on a regular basis. I've presented on "how to use these tools" at several all-hands meetings. We consistently share tool usage at all-hands, while also encouraging people to actively showcase new tools they've discovered and found useful, whether in Slack, messaging groups, or elsewhere — the format doesn't really matter.
Honestly, people are already a bit overwhelmed by all the tools, tutorials, and prompt examples floating around. But what really matters is: find one point that you find particularly useful, particularly efficiency-boosting, then go deep with it, master it, and bring others along to experience it — that way the impact doesn't stay limited to a small number of people.
👦🏻 Lenny Rachitsky:
Have there been any unexpected negative results? Like PRDs becoming too AI-driven and actually slowing people down?
🧙🏻 Tomer Cohen:
Yes. One thing that surprised me is that many tools aren't truly plug-and-play. We initially tried giving AI open access to all historical documents and context, but the results were terrible — lots of hallucinations. This forced us to invest heavily in cleaning and structuring data. One reason is that we have enormous amounts of historical information, legacy code, old knowledge bases, old designs, and so on.
Another challenge is tool fragmentation. We want to converge on a unified toolset, but the reality is that people naturally choose tools they're familiar with, which makes unification very difficult.
On quality, we are seeing clear improvement so far, but this is largely because we're still in early stages, and the users themselves are more willing to experiment repeatedly and iterate quickly. Overall, the speed of tool adoption remains a challenge.
One more important point: not everyone needs to, nor should, become a full-stack builder. Specialization still has value. I don't expect everyone in the organization to shift to this model.
I believe two types of roles will coexist in the future: one is system builders, responsible for providing foundational capabilities for full-stack builders; the other is people who remain specialized. It's just that compared to the past, demand for purely specialized roles may decrease somewhat.
👦🏻 Lenny Rachitsky:
So is Full Stack Builder already an official job title? They don't call themselves product managers or engineers anymore?
🧙🏻 Tomer Cohen:
We have indeed established an official Full Stack Builder title internally, and we're gradually moving people who meet the criteria into this track.
👦🏻 Lenny Rachitsky
So this is essentially creating an entirely new career track. Where are you mainly finding these people right now? Product, engineering, design, or a mix?
🧙🏻 Tomer Cohen:
It's a mix. My advice is to look around your organization for people already working cross-functionally — whether in engineering, design, product, or even BD. You'll find there are already quite a few people with this boundary-crossing ability.
👦🏻 Lenny Rachitsky:
Is there any function that stands out as particularly strong in this regard?
🧙🏻 Tomer Cohen:
I think the key isn't the function, it's the mindset. If I had to name the hardest skill to learn, I'd say design — building a design agent to a high standard takes serious extra effort. So by comparison, it's actually easier for designers to pick up other skills.
But ultimately it comes down to mindset. I've seen designers write code, and I've seen PMs do design, and both have done it well. People who can truly work cross-functionally are distributed across every team: they're proactive, willing to experiment with new tools, already building new experiences, and have a strong growth mindset. At that point, their original background and title matter much less.
👦🏻 Lenny Rachitsky:
I really love what you guys are doing here: this is the easiest time in history to move between different product roles. Designers becoming PMs, or moving into this entirely new role, is easier than it's ever been.
🧙🏻 Tomer Cohen:
This is the point I emphasize most with my team, and the one that motivates them the most. Because at the end of the day, incentives for individuals and organizations are now aligned.
Organizations need to change, to become more agile and resilient; and individuals in their careers want to be on the frontier, mastering new ways of building. The things you want to do for your own professional growth happen to be exactly what the organization most needs you to do.
So the "permission" I can give them is really just going with the flow. It's not asking them to change, it's supporting them in doing what they already want to do.
👦🏻 Lenny Rachitsky:
Last question: if someone listening thinks their company should start doing this too, what advice would you give them? How do you successfully kick off this kind of transformation inside a company?
🧙🏻 Tomer Cohen:
I'd start by thinking through how the whole system should be built, which basically breaks down into three layers: platform, tools, and culture. Platform and tools are necessary conditions, but far from sufficient — what really determines success or failure is culture. You need to seriously think about how to bring people along on this journey.
If I could do it over, I'd show what we're building to the entire organization earlier, rather than going deep with the core team from the start. In hindsight, it would have been more effective to let everyone see the tools and understand the direction sooner.
Patience and investment matter too. You can build a product from scratch in a week now; but driving transformation at a large organization is completely different. You need urgency and ambition about the goal, while being careful and patient in execution, and clear about where you must keep investing.
If you're not willing to invest in the platform, not willing to customize tools for yourself, all you'll end up with are generic agents that don't actually fit you.
At the core, it's still that same principle: early investment is unavoidable. Don't expect to double efficiency in a week. At the individual level, results may come quickly, but what really matters is consistently producing success stories and driving this transformation at the organizational level.
👦🏻 Lenny Rachitsky:
That's so cool. I know there are already a lot of product leaders and executives coming to you for advice. I'm glad we got to systematically work through these topics today. One last question: is there anything we haven't covered that you think would be especially helpful for listeners?
🧙🏻 Tomer Cohen:
Whether you're in an organization waiting for leadership to push this forward, or you're the one who wants to drive it, my advice is the same: don't wait.
The first critical thing I did was clarify the direction to the whole company early on: we start with small pilots, move forward using pods, build tools, but this is a long journey we take together, not an end state. We won't "arrive" at some finished state; we'll just keep getting better.
In today's competitive environment, you only need to be better than others at building. And the way we build will keep being reshaped over the next few years, so definitely don't wait. What really matters is continuous progress, constant reflection, and transparent communication with your team — not just sharing the vision, but showing incremental results. If you're a leader, set public KPIs or OKRs for yourself and take ownership of this.
If you're an individual contributor, you really don't need to wait either. Regardless of whether your CPO or CEO has made any formal announcement, you can start taking action now; either push for change, or join an organization that's already doing it, and put yourself on the frontier of how products will be built in the future.
Part IV Lightning Round:
👦🏻 Lenny Rachitsky:
With that, we're moving into the exciting lightning round.
First question: what are the books you most often recommend to others? Two or three is fine.
🧙🏻 Tomer Cohen:
I usually like to recommend three as a set, and they're on very different topics.
The first is Why Nations Fail. It explains national success through institutions, distinguishing between "extractive" and "inclusive" institutions, and discussing whether a system truly allows more people to participate and share opportunity. This book has been very inspiring for my understanding of how to build fair opportunity systems through product, and for understanding product and institutional design.
The second is Outlive, which centers on "Medicine 3.0" — personalized medicine — and systematically discusses how long-term health should truly be optimized. In the AI era, this kind of thinking will become increasingly important.
The third is The Beginning of Infinity. This isn't the easiest read, but it profoundly shaped my understanding of "causality" and progress. Its core argument is that true breakthroughs only happen when we have clear, correct explanations of how the world works, and once they do, progress is essentially unlimited.
👦🏻 Lenny Rachitsky:
Any movies or TV shows you've particularly enjoyed recently?
🧙🏻 Tomer Cohen:
There's a Hebrew podcast I really love called "One Song." Each episode picks a relatively well-known song and goes deep into its origins and history. I love music, and the way they analyze a song is really brilliant — they're especially good at bringing out the story behind it.
👦🏻 Lenny Rachitsky:
Have you come across any new products you really like lately? Could be an app, clothing, or a gadget.
🧙🏻 Tomer Cohen:
There's actually a product I really want, and I don't think it would be hard to build at all.
My car has Alexa built in, and my kids can request songs the whole ride — it's like a mini concert. One of my favorite things is using voice mode to talk with ChatGPT, but there's still some friction. What I really want is a button on the steering wheel that summons my AI companion with one press, like having a copilot sitting next to me. I think that would completely transform the driving experience.
👦🏻 Lenny Rachitsky:
Do you have a personal motto that's been helpful in work or life?
🧙🏻 Tomer Cohen:
I mentioned earlier a line I really connect with: "I might be wrong, but I'm not confused."
But what truly influences me is the "growth mindset." I especially love this line:
"Becoming is better than being." I think it fits the full-stack builder philosophy really well.
The point was never about "arriving at some state" — it's that you're always in a process of evolving, iterating, moving forward. You should fall in love with the process, not the outcome — keep growing, keep evolving, no need for anxiety, no need for FOMO.
I often ask myself: if I look back at myself from a year ago — how much have I grown? What have I learned? What new skills have I acquired? Have I become a "newer version" of myself? That delta is the kind of thinking I love.
👦🏻 Lenny Rachitsky:
Following that to our last question. When this episode airs, people will already know that your 14-year journey at LinkedIn is coming to a close — it's been a truly legendary run. You joined very early and witnessed enormous change at the company. So I want to ask: how are you feeling? What's next?
🧙🏻 Tomer Cohen:
What I feel most is pride.
I first truly came to know LinkedIn when I had just moved to Silicon Valley. It was a 2008 lecture at Stanford on social networks, where Reid Hoffman spoke about the power of "online professional communities" — I remember thinking then that this was a very promising vision. Later, through a fortunate turn of events, I joined LinkedIn, and quickly discovered that the company's mission aligned deeply with my values.
Looking back, much of what I learned at LinkedIn came from the difficult moments. It's hardship that makes people grow, and I'm deeply grateful for that.
At the same time, I'm excited about the future. I've always loved change, loved putting myself in positions where I can learn and grow the most. This is a fantastic time for building, and I'm looking forward to exploring new problems and new domains.
👦🏻 Lenny Rachitsky
I think it might take you quite a while before you stop feeling like you're still at LinkedIn, and before you can gradually let go of all the things that have kept you up at night over the years.
🧙🏻 Tomer Cohen
When you spend so many years building something, one of the most important traits of a builder is that you develop intense passion for what you're creating. It's not about caring for the job itself — it's about genuinely caring for the product, from the heart.
When people complain, you feel it. That persistent sense of "not enough" is like raising a child. So it's hard, and it always will be. I'll always think of LinkedIn as one of the "children" I helped raise.
👦🏻 Lenny Rachitsky
I'm really looking forward to the day you come back and tell us what you want to do next, or what new project you've started. I'm glad to have had this chance to truly get to know you. Tomer, thank you so much for coming on the show.
🧙🏻 Tomer Cohen
Thanks, Lenny.