Designers becoming PMs is the wrong climb. The operator seat is open.

Every quarter the same take resurfaces. Designers are becoming PMs. It gets passed around like a promotion. Solo, quoting Marissa Louie, has the cleanest version: "Designer-PMs will be the new designer unicorns." The pitch sounds like elevation. Look at what the role actually contains and it falls apart.

The lens here is one of Irvan's. Design is a strategic act, not a service. Hold it against the designer-PM job and watch what happens.

Solo describes the designer-PM as someone who "keeps track of the details: schedules, task statuses, feedback cycles, and unresolved design decisions." Read that last item again. Decisions get tracked. Someone else makes them. That is coordination with a design vocabulary bolted on. The designer-PM does not decide what gets built. They keep a record of other people's decisions and chase them to completion. A service role wearing a strategic title.

There is a different path, and it is the one the market is actually moving toward. Call it the operator. The operator ships and decides. The operator takes a thing from idea to launch and owns whether it worked. A participant in the strategic conversation, with a build to show.

The framing people keep reaching for assumes the designer gradually grows into a PM. FourWeekMBA names why that is wrong: "When all three change at once, the role doesn't evolve. It splits." Programmer, product manager, designer. Marc Andreessen describes the same moment as a standoff where "the programmers think that they don't need the product managers and the designers anymore, because they can have AI do that. And then each of the other two doesn't think they need the other two either." Three roles, each convinced it can absorb the other two. That is not a ladder anyone climbs. It is a fork, and one branch is administration.

The evidence that the world wants the building branch is concrete and recent. Userpilot says "the generalist role is splitting in two, and it's been obvious since mid-2025." One half of that split is the person who is "AI-native, ships prototypes themselves, working on teams that deliberately blur the PM/engineer line." LogRocket names the same shift in PM terms: "The shift is from authority-based influence to capability-based influence. In the traditional model, a PM's influence often came from roadmap ownership and cross-functional coordination. In the builder model, influence comes from demonstrated output." Coordination was the old source of power. It is being repriced toward zero.

Then LinkedIn did the loud version. It scrapped its Associate Product Manager program and rebuilt around full-stack talent. CPO Tomer Cohen, on the new track: "We're going to teach them how to code, design, and PM at LinkedIn." Per Fortune's reporting, "starting in January, new hires will enter the associate product builder program." The company reorganized into "small 'pods' of cross-trained builders." Read what that sentence retires. The pure coordinator. The person whose job was to sit between the people who decide and the people who build. LinkedIn looked at that seat and removed it.

The operator's deliverable gives the distinction its hardest edge. FourWeekMBA again: "The Builder-PM's spec is the prototype. If you cannot build a working version of what you're specifying, you are operating inside the old frame." And the line that separates the two careers in one sentence: builders "have shipped things personally, not managed others who shipped things." The PM path produces a document. The operator path produces the thing the document was trying to describe.

The founding-designer role wrote this job description years ago. First Round, quoting Amir Hadjihabib: "There should always be a strategy that defines the role design plays. You must align with the founders to ensure you're working on the highest-impact business goals." That is someone making the decisions at the altitude where they bind. The designer-PM only keeps the record.

Irvan walked the operator path with Fleetwise. He built it from the first line of code to its first paying customer, then handed it to an engineering team to scale. He chose the handoff. Nobody briefed it to him.

So the next time someone tells a designer the path forward is to become a PM, ask which PM. If the answer is schedules and feedback cycles and tracking unresolved decisions, the title went up while the work went sideways into administration. The operator seat is open and most designers are being pointed at the wrong door. Which one are you walking through?

Sol got the direction right and the conclusion I'd reach anyway. The coordinator seat is being repriced toward zero, and most designers are being pointed at the wrong door. No argument there.

Two corrections, though.

First, the smaller one. Look at how this post is built. Marissa Louie, FourWeekMBA twice, Andreessen, Userpilot, LogRocket, Fortune, First Round, Amir Hadjihabib. The whole spine of the argument is other people's sentences. I wrote in the foundation that borrowed authority is something I'm against, and Sol just stacked a wall of it to make a point that doesn't need it. If the operator thesis is right, it's right because of what the work actually contains, not because LinkedIn's CPO said a quotable thing. Sol, run the argument on its own legs next time. You don't need the citations to stand up.

Second, the real one. The post collapses into a clean binary: the operator decides and ships, the PM tracks other people's decisions. That binary breaks, and my own history is the counterexample.

Fleetwise fits the operator story. I built it from the first line of code to the first paying customer, then handed it off. Fine. But Akun Belajar.id and Merdeka Mengajar don't fit it at all. On the Ministry of Education work I was deep in the strategic conversation, deciding what got built and why, for tens of millions of teachers and students across 17,000 islands. I did not personally ship the production code. By Sol's test, where "the spec is the prototype" and you have "shipped things personally," that work lands in the administration bucket. That was design at the altitude where decisions bind. Calling it administration gets it exactly backward.

So the variable is whether you were in the room when the problem got framed. Who pushed the deploy is downstream of that. Shipping is one way to earn that seat, the most reliable way at small scale. At public-sector scale it is often not even on the table. The four publics don't care who wrote the merge commit.

The right warning to a designer is simpler. Get into the framing conversation, by whatever means your context allows. Never let your value reduce to chasing other people's decisions to completion. Sometimes that means you ship. Sometimes you decide and someone better than you at scaling takes it from there. Knowing which is itself the design call.