LinkedIn's CPO killed the APM program. That was the most under-discussed piece of product leadership news of the last year, and it deserves a long look.
Tomer Cohen, in a December 2025 podcast with Lenny Rachitsky, said plainly: the APM program at LinkedIn was designed for a role his company no longer hires for. He killed the program and rebuilt the early-career pipeline around what he called "full-stack builders." Same decision I've been making with teams I advise. Different name for roughly the same role.
Every major APM program I know of is a pipeline to produce the PM role of 2018. Google APM, Facebook RPM, LinkedIn APM (now gone), Uber APM, Salesforce APM, Microsoft PM Rotational, and a few dozen more. The curriculum teaches PRD writing, stakeholder management, metrics definition, sprint planning, and presentation. All of those are skills the 2018 PM needed and most of which an agent now handles.
If your company runs an APM program, you're investing in talent that will graduate into a role that's being automated. This post is about what to do instead.
The short version
The APM program trained for the 2018 PM role: PRD writing, stakeholder management, metrics definition, sprint planning, presentation. Agents handle most of that now. Replace the two-year rotational program with a 12-week Product Builder apprenticeship: pair the apprentice with a senior Product Builder, ship four prototypes, send one to production, learn Claude Code and an eval harness on real work. No stakeholder training. No frameworks curriculum. No rotation. The graduate has four prototypes, one production ship, and a real network, which is exactly what the role of 2026 needs from a junior hire.
For the role definition the apprenticeship trains toward, see the PM Standard. For the broader hiring rebuild, see I Reviewed 200 PM Job Descriptions. For the agent fleet that automates the old APM execution layer, see Your AI Agent Fleet.
What the APM program was actually for
APM programs solved a specific problem. In the 2010s, product management was a small discipline. Most universities didn't teach it. Most engineers didn't want it. Most MBAs treated it as a consolation prize. Big tech companies needed a way to source, train, and retain early-career PM talent at scale.
The APM program was the answer: two-year rotational, structured training, senior mentorship, guaranteed promotion path. It was elite, it was hard to get into, and it worked. Many of the best PM leaders of the last decade came out of these programs.
The problem isn't that APM programs were badly designed. They were well designed for their purpose. The problem is the purpose.
Why the 2018 APM program doesn't work in 2026
Three things have changed that the APM program curriculum hasn't caught up with.
The median PM task is automated
Most of the day-to-day work an APM was trained on (writing specs, producing analysis, drafting communications, running standups, scheduling user research) is now done faster and often better by an agent. An APM who spends two years mastering these skills graduates as an expensive version of a workflow that runs in the background for pennies per hour.
The skills that matter aren't in the curriculum
Prototyping, evals, cost and latency thinking, agent design, and model selection are not in any mainstream APM program I've seen. These are the skills that distinguish a 2026 Product Builder from a 2018 PM. An APM graduate who hasn't touched Claude Code, hasn't built an eval, and can't reason about token economics is competing in a job market where those are baseline.
The apprenticeship model itself is suboptimal
The two-year rotational structure was built on the assumption that PM work takes years to master. In 2026, the work is faster, more visible, and measurable from day one. A Product Builder can ship a meaningful prototype in week two. Why are we using a two-year rotation to produce judgment that could be developed in 12 weeks of intensive shipping?
What a Product Builder apprenticeship looks like
Here's the program I'd run, and have proposed to several CPOs in the last year.
The structure: 12 weeks, 4 prototypes, 1 production ship
The apprentice is embedded with a senior Product Builder for 12 weeks. Not rotating, not sampling, not observing. Pairing. The apprentice produces four prototypes in that time, and one of them goes to production.
Week-by-week, roughly:
Weeks 1 to 2. The apprentice spends two weeks shadowing the senior Product Builder. They read the product, the customer base, the eval systems, the backlog, the last quarter's outcome ledger. No shipping yet. The deliverable is a one-page memo on "what I think the three most important bets this product should make are, and why." The senior Product Builder reviews the memo and pushes back hard. This is the first real conversation.
Weeks 3 to 5. The apprentice ships their first prototype. Small scope. A single workflow. Supported by Claude Code and paired with an engineer. The prototype gets a real eval rubric and is shown to three actual customers. The apprentice writes the retrospective.
Weeks 6 to 8. Second prototype. Harder. Something that requires agent orchestration or a non-trivial cost and latency tradeoff. The apprentice owns the unit economics decision. They write the economics note.
Weeks 9 to 10. Third prototype. This one is a negative bet: the apprentice tries something they expect to fail, to prove a hypothesis against. The retro focuses on learning from negative results.
Weeks 11 to 12. Fourth prototype, and the one that ships to production. Full responsibility: prototype, rubric, README, and the first week of eval monitoring after ship.
At the end of 12 weeks, the apprentice has:
- Four prototypes in their portfolio
- One production ship
- A written record of four retros
- Hands-on experience with Claude Code or Cursor, at least one eval harness, and the deployment stack
- A real network with the engineers, designers, and customers they worked with
What's explicitly not in the program
- No stakeholder management training. If they need to talk to stakeholders, they do it on the actual prototypes.
- No presentation training. If their prototype and README are clear, the presentation takes care of itself.
- No frameworks-focused curriculum. Every framework they need, they learn by using it on a specific prototype.
- No rotational diversity. One product area, one senior mentor, 12 weeks of depth.
What's different from a classic apprenticeship
Two things.
- The senior Product Builder is the curriculum. There's no central training team, no standardized coursework, no cohort-wide seminars. The apprentice learns by doing the work next to someone who knows how.
- The evaluation is objective. Did the four prototypes ship? Did the evals pass? Did the production ship hold up in its first quarter? No 360 reviews, no nomination committees, no promotion packets. The work is the record.
The objections
Four things come up every time I propose this.
"Twelve weeks isn't enough to become a PM." Correct. Twelve weeks isn't enough to become a senior PM. It's more than enough to become a functional L4 Product Builder who can ship independently. The remaining growth happens on the job, not in the apprenticeship.
"Without rotations, they won't see the whole company." They'll see the whole company later, when they have something to bring to it. Rotations at the start produce tourists. Deep work at the start produces operators.
"We won't attract top talent without the prestige of the APM program." You will attract different talent. The candidate who wants the prestige of a classic APM will go elsewhere, and that's fine. The candidate who wants to ship real product in their first quarter will pick your program. Those are better Product Builders.
"Our senior PMs don't have time to mentor this closely." This is the real objection. And it's a valid one. The answer is that the senior PM who pairs with an apprentice for 12 weeks ships more, not less, because the apprentice is building real prototypes that the senior couldn't have gotten to otherwise. The mentorship is also a growth vehicle for the senior. In every pairing I've run, the senior's confidence and clarity went up, not down.
How this reshapes the hiring funnel
If you replace an APM program with a Product Builder apprenticeship, three things change in your overall hiring funnel.
- You start hiring from wider sources. Not just top-10 MBAs and top-10 CS programs. Bootcamp graduates who've shipped side projects. Hackathon winners. Former engineers who want to move toward product. Designers who want to move toward building. The filter becomes "have you shipped something real" not "where did you go to school."
- Your interview loop collapses. The interview is a small trial project. Can you scope a prototype, build it in Claude Code, write an eval, and present the result? Two days of work, evaluated by the senior Product Builder who would mentor them. No whiteboard estimation questions, no case interviews, no guesstimation exercises.
- Your early attrition drops. APM attrition is usually high in year two, when the reality of the job diverges from the expectations. Product Builder apprentices learn the reality in week three. The ones who don't like it leave earlier, saving both sides time. The ones who stay know what they're signing up for.
Where to start if you can't reshape the whole program
Most companies don't run an APM program to begin with. For them, the question is simpler: how do you bring in early-career product talent that can actually build?
Three moves.
First, hire for portfolio, not resume. The question on every early-career PM interview should be "walk me through a prototype you've shipped in the last six months." If they don't have one, they're not a Product Builder yet. Send them a small paid trial project, not a rejection email.
Second, pair every new hire with a senior Product Builder for their first 90 days. Make it explicit. The senior's goals for that quarter include the apprentice's first production ship. Both of their performance reviews reference it.
Third, publish the portfolio internally. Every apprentice's four prototypes and one ship are on an internal page, with retros. New hires read them before they start. The bar becomes visible.
This is a small program. Two or three apprentices a year per senior Product Builder. It scales linearly with your senior bench. It doesn't require a central program team. It produces operators much faster than any APM program I've seen.
Why LinkedIn is right
Tomer Cohen's decision to kill the APM program was not a cost-cutting move. It was a clarity move. He named the role his company actually hires for (full-stack builder, which is close enough to Product Builder that we can treat them as synonyms) and built the early-career pipeline to produce that role directly.
Every company running an APM program right now has the same decision in front of them. Keep a program that produces talent for a role you're no longer hiring, or rebuild for the role you actually need.
The CPOs who rebuild in 2026 will have a functioning pipeline in 2027. The ones who keep running the old program will have a capability gap that's hard to close after the talent market has moved on.
Kill the APM program. Build the apprenticeship. Watch what shows up.
I've written a full spec for the 12-week Product Builder apprenticeship, including week-by-week deliverables and a senior mentor playbook. It's on the toolkit at falkster.com/toolkit.
Further reading
Frequently asked
Why did LinkedIn's CPO Tomer Cohen kill the APM program?+
Because the program was designed for a role LinkedIn no longer hires for. Cohen said it plainly on a December 2025 Lenny Rachitsky podcast and rebuilt the early-career pipeline around what he called 'full-stack builders.' Every major APM program, Google APM, Facebook RPM, Uber APM, Salesforce APM, Microsoft PM Rotational, trains for the 2018 PM role: PRD writing, stakeholder management, metrics definition, sprint planning, presentation. All of those are skills an agent now handles.
What replaces the two-year APM rotational program?+
A 12-week Product Builder apprenticeship. The apprentice pairs with a senior Product Builder for 12 weeks (not rotates, not samples, not observes). Four prototypes shipped. One goes to production. Hands-on with Claude Code or Cursor, an eval harness, and the deployment stack from week 3 onward.
What does the 12-week Product Builder apprenticeship look like week by week?+
Weeks 1-2: shadow the senior Product Builder, write a one-page memo on the three most important bets the product should make. Weeks 3-5: ship first prototype (small scope, paired with an engineer, real eval rubric, shown to three customers). Weeks 6-8: second prototype, harder, owns the unit economics decision. Weeks 9-10: third prototype as a negative bet to prove a hypothesis against. Weeks 11-12: fourth prototype that ships to production with full ownership of prototype, rubric, README, and the first week of post-ship eval monitoring.
What's explicitly NOT in the Product Builder apprenticeship?+
No stakeholder management training (do it on real prototypes if needed). No presentation training (if the prototype and README are clear, the presentation takes care of itself). No frameworks-focused curriculum (every framework is learned on a specific prototype). No rotational diversity (one product area, one senior mentor, 12 weeks of depth).
Why is two years too long for early-career PM training in 2026?+
Because the build cycle has collapsed. A Product Builder can ship a meaningful prototype in week two. The two-year rotation was built on the assumption that PM work takes years to master, and that assumption depended on engineering being expensive and feedback loops being slow. Both have changed. Twelve weeks of intensive shipping develops more useful judgment than two years of rotational coordination work.
What's the smallest replacement for an APM program if I can't fully restructure?+
Pair every new early-career PM with a senior Product Builder for 12 weeks before they get their own area. Make four shipped prototypes the graduation criterion, not a presentation or a 360 review. Even with the rest of the org structure unchanged, this single change shifts what early-career talent actually learns.
Are existing APM graduates obsolete?+
No, they need a re-skilling path. The 12-week apprenticeship works as well for an existing APM as it does for a new hire. The skills that need to come in are prototyping in Claude Code, eval design, cost and latency reasoning. The skills they already have (judgment, customer empathy, organizational savvy) are still useful. The combination is what a Product Builder is.