Salesforce Hires PMs to Say What Good Looks Like. The PM Is the Product Builder Now.

On November 3, Aakash Gupta published his conversation with Jayesh Govindarajan, who runs Salesforce's roughly 700-person Agentforce org. Gupta asked what Salesforce looks for when it hires PMs. Two core skills: AI prototyping and AI evals. Then five traits, and the one Govindarajan calls the most important is a single question.

"Can you say what good looks like?"

That's the PM job for the next five years in seven words. Not writing the document. Not running the meeting. Defining good, building to it, and holding the checkpoint while agents do the rest.

This is part 1 of The PM Transition. The thesis is simple. The PM becomes the Product Builder. And the Product Builder works inside one loop with design, product marketing, and forward deployed engineering, under the CPO, because when building is cheap the outcome is decided by the loop, not by any one seat.

The short version

The PM who writes specs and waits is being replaced by the Product Builder: one person who takes a customer outcome to a working product in a day, runs a fleet of agents, writes the eval instead of the PRD, and owns a number instead of a backlog. This week made it concrete. Salesforce's Jayesh Govindarajan hires AI PMs for prototyping and evals, and his top trait is whether you can say what good looks like. Figma's Ezra Mechaber showed a shared repo of 31 skills every Figma PM uses and an agent that runs growth experiments with one human checkpoint. Paweł Huryn published 43 free skills that take a product from idea to paying users in Claude Code, Codex, or Cursor. The job is defining good and holding the checkpoint. And because the outcome is decided by the loop of customer, spec, build, story, and adoption, the Product Builder belongs in one function with design, product marketing, and FDE, under the CPO.

Three signals, one job description

Govindarajan's list is worth reading in full, as Gupta reports it. Agency, which he says is in short supply. An agent-native mindset: do a task by hand a few times, then teach an agent to do it. Skepticism, meaning you check every output before it ships. Craftsmanship, where the red flags he names are generic prototypes and long docs sent as a checkbox. And setting the bar.

Notice what's missing. Nothing about writing requirements. Nothing about managing a backlog. Every trait is about the gap between what an agent produced and what the customer needed, and whether you can see it.

He also wants PMs to bring domain expertise to evals, because generic evals aren't enough. That's the part engineering can't do alone. The engineer can build the harness. Only the person who knows the customer can write the rows that say this answer is right and that one is wrong.

Figma is further along the same path. On How I AI, Claire Vo's guest Ezra Mechaber walked through PM OS, which the show notes describe as a shared repo of 31 skills that every PM at Figma now uses, and AutoXP, an agent that runs growth experiments with one human checkpoint. One checkpoint. The PM is the checkpoint.

And Paweł Huryn put the whole lifecycle on GitHub. His 43 product engineering skills, MIT-licensed, run from discovery through build, release checks, and the first analytics after launch, for PMs, founders, and designers working in Claude Code, Codex, or Cursor. His line is the one I'd put on the wall. You don't need to be technical. "You need to know what the product was supposed to do."

Three sources, a week apart, from a $190B incumbent, a design tools company, and a solo practitioner. Same job.

What the Product Builder actually does

I've written about the six skills behind the Product Builder and about why a Product Builder is not a PM who uses AI. I won't restate either. This series is about the shape of the work over the next two to five years, and four shifts define it. Each gets its own part.

The day changes first. When an agent can build a working version by lunch, the PM's day stops being meetings about the thing and becomes running the loop on the thing. Customer signal in the morning, a build by noon, the eval run by three, a decision by five.

The spec becomes an eval. Govindarajan's line, "every AI feature you ship is one you'll keep rebuilding," is the reason. A PRD is written once and read once. An eval runs on every build, forever. The PM's durable artifact is the set of examples that define good, and it gets better every time a customer surprises you.

The team becomes a fleet. Figma's 31 skills and Huryn's 43 are early versions of the same thing: the PM's work, packaged so agents can run it. The hard question isn't how to start. It's how many agents one person can actually check, which is the skepticism trait with a ceiling on it.

And the backlog becomes a number. When a feature costs a day, a ranked list of features stops being the thing you manage. The outcome is. The Product Builder owns one number for their area and answers for it weekly.

The loop decides, not the seat

Here's the piece most PM career advice misses. You can be the best Product Builder in the company and still lose, because the outcome isn't decided by any one seat anymore.

Look at the loop. Customer, spec, build, story, adoption. When the build took a quarter, each step could live in a different org and hand off on a calendar. Now the build takes a day, and the handoffs are the slow part.

The sibling series have been mapping those seams one at a time. Design owns the behavior and the repair rate. Product marketing owns the claim, and the PM and PMM now write one file(coming Nov 6). The forward deployed engineer owns the field and hands back what the customer taught them. And Salesforce's own answer to that last seam, as Gupta reports it, is a Slack channel where FDEs tag field feedback and PMs match it to the roadmap. I argued this week in kill the paper-cut channel that a channel is an inbox, not a loop.

Every one of those seams has the PM on one side. The PM defines good. Design, PMM, and FDE each hold a piece of what good means to the customer. If those four answer to four executives with four scorecards, the definition of good gets negotiated in meetings while the agent waits.

So the Product Builder needs the other three in the same function, on the same number, under the same leader. That's the CPO. Not because the CPO is a better manager than the CMO or the CTO. Because the CPO is the one executive who answers for whether what shipped got bought and used, and that's the only number all four seats serve. It's the case The CPO Transition has been making from the top, starting with why the CPO owns the operating model. This series makes it from the PM's chair.

The decision this quarter

If you lead product, there are two calls to make before planning season, and both are cheaper now than later.

First, how PMs on AI features are measured. If the scorecard still counts specs shipped and roadmap items delivered, you're paying people to produce the artifact agents just made free. Move them to an eval pass rate and one outcome number per area.

Second, who the PM's three neighbors answer to. Pick one product area where prototypes now ship weekly. Name the PM, designer, PMM, and FDE who own it, and check whether they share a boss and a number. If they don't, that's the seam where your loop is losing days.

If you're a PM, the decision is smaller and more urgent. Start writing the eval before the spec, on the next thing you own.

What I expect

These are my predictions, not facts, and I'll check them in later parts.

By the end of 2027, most PM job posts at AI-native software companies list writing evals as a core requirement, and fewer than half still ask for writing PRDs.

By 2028, the artifact a product review reads first is the eval suite and its pass rate, not a document. The demo comes second, because demos are free.

And by 2028, at most AI-native software companies, product, design, product marketing, and forward deployed engineering report to the CPO, with one outcome number per product area. The companies that get there first will ship slower demos and faster outcomes.

One thing to try this week

Take the feature you're about to spec. Before you write a word of the PRD, write ten examples of output you'd ship and five you'd reject, each with one line on why. That's your first eval.

If you can't write them, the PRD wasn't ready either. If you can, hand the fifteen to whoever builds, person or agent, and see how much of the PRD you still need.

Sources: Aakash Gupta with Jayesh Govindarajan, "What an AI-Native Product Team Actually Looks Like at Salesforce," Product Growth, November 3, 2026, for the hiring skills, the five traits, the six steps, and the Salesforce and org-size figures as Gupta reports them. Claire Vo with Ezra Mechaber, "How Figma's PMs actually use AI every day," How I AI, Lenny's Newsletter, November 2, 2026, show notes only. Paweł Huryn, "Product Engineering: 43 Free Skills From the First Idea to Paying Users," The Product Compass, October 29, 2026.

Part of the running argument on AI Product Management: the job did not get harder, the parts we trained people for got cheap, and what's left is defining good, building to it, and owning the number, inside one loop under the CPO.

Related answer: What does Salesforce look for when it hires AI PMs?