Product Managers used to direct. Now we edit.

Late last year, one of our engineers shipped a feature in a day that I was still in the process of scoping.

He didn't ask. He didn't wait for the PRD. He had been in a brainstorm session, understood the problem, opened Claude Code, and built it on our live data. By the time I sat down to write the spec, the thing was working in our staging environment.

I remember having a bit of an identity crisis. Part of me was excited — this is exactly the velocity I'd wanted when I started Floto. Part of me was uncomfortable. The flow I'd run for seventeen years as a PM at Google, YouTube, and Meta had just been bypassed entirely. But — gut punch — the product was better for it.

That was a forcing function. I started paying attention to where else our team was working in ways that didn't match the playbook I'd been trained on. The list got long fast.

This piece is about what I've learned in the months since building an AI product in an AI-native team. Not as a prediction about where PM work is heading, but as a report from a team that's already there. Floto is a product team of six people. Engineers using coding agents. Designers prototyping in code. Products built on non-deterministic models. And the shifts I've felt are sharp enough that I think they probably point at something real for anyone doing this job.

The loop reversed

For a few weeks after, I tried to keep running the old loop. PM writes the PRD. Designer turns it into mocks. Engineering builds. Iterate. I'd done it a thousand times.

It kept breaking. Not because the team was indisciplined. Because the loop assumed two things that were no longer true: that building was expensive enough to warrant heavy upfront alignment, and that I — the PM — had a clearer picture of what to build than the engineer with a coding agent and a model.

Neither held anymore.

So we flipped the order.

We now start with engineering. I bring our engineers a clear statement of the problem we're solving. Not a spec. Not mocks. Not a PRD. They build the first prototype directly on our live data, in our actual codebase, in a way that can be iterated into shippable code. No throwaway. No rebuild.

Then — and only then — my designer and I get involved. We play with what engineering built and shape the product experience around it. The starting point is what the model can actually do, not what we imagined it could do before anyone touched the code.

“The engineer pulling on the model holds more information about what’s possible than the PM staring at a Figma file.”

Rags Vadali, Co-founder & CEO @ Floto

This took me a few cycles to accept, because it felt like giving up the part of the job I was best at. I'd spent years building the muscle of designing experiences upfront. Holding the whole product in my head before we wrote a line of code. The reversed loop asked me to stop doing that.

But here's what I kept noticing: every time I tried to pre-design an experience for an LLM-driven feature, I was wrong about what was possible. Either the model could do more than I'd specified — and the design left value on the table — or it couldn't do what I'd assumed, and we had to throw the design away.

As a PM today, I don't know what I don't know about LLMs. After eighteen months of building AI products, I've realised it's foolish to pre-design an experience disconnected from what the model can actually do.

The engineer pulling on the model holds more information about what's possible than the PM staring at a Figma file. Once I accepted that, the order had to change.

From director to editor

The hardest part of the shift wasn't process. It was identity.

I used to think of my role as something like directing a film. Before anyone started shooting, I had the full scene in my head — who stands where, what they say, how the light falls. The PRD was the script. Design and engineering executed against it. The skill the job rewarded was conviction and detail upfront.

That's not what I do anymore. We shoot a lot of footage now — prototypes, half-built features, things engineering tried because the model surprised them. I don't have the scene mapped before we start. My job is to look at what we have and cut it into something coherent. Something that feels like a product, not a tech demo.

I'm an editor now, not a director.

It’s taken me the last few months to realise this is a genuinely different skill. Directing rewards conviction and a strong upfront vision. Editing rewards taste, ruthlessness about what to cut, and the ability to see the shape of something inside a pile of raw material. I was hired and promoted for the first one. I'm frantically learning the second.

My designer's role moved in a parallel way. She spends less time designing from scratch in Figma. More time upstream with users, figuring out what we should be solving. And then, when engineering hands us a prototype, she's the one shaping a raw working thing into a designed experience. The Figma file used to come first. Now it usually comes after.

The product is the experience layer

The deeper thing I've been wrestling with is what we're actually building.

When you ship a product built on an agent, the UI is no longer the product. The agent is. The real work is defining the experience on top of it.

That sounds like a small distinction. It isn't. It's the reason PRDs stopped working for me.

A PRD assumes a deterministic system. You can specify what the screen does because the screen does the same thing every time someone clicks the button. With an agent, you can't specify a single correct behaviour. You can only define what range of behaviour is acceptable. What hard stops must hold. What anti-patterns to avoid.

Requirements turn into ranges. Specifications turn into guardrails. The artefact has to change shape too.

So I started writing something else. I call it a Product Experience Document — a PXD.

The audience changed first. A PRD existed to align humans across a team. The PXD has a smaller, sharper audience: the engineers and designers shaping the experience, and the agents doing the coding. Then the contents changed:

• Why — the problem and why it matters now
• Success criteria — what makes the feature work, in user terms
• Experience principles — the qualities the feature must have
• Example interactions — the good, the bad, and the ugly. Concrete examples of what a great response looks like, what a mediocre one looks like, what counts as failure
• Critical moments — the specific points in the flow where the experience makes or breaks
• Success metrics — how we'll know in production

The good/bad/ugly section is the part I'd never have included two years ago. It's the most important section now. When part of your audience is an AI translating intent into code, showing the model what good looks like beats describing it.

The real job

Here's where I've landed.

A lot of what I did for seventeen years as a PM was compensating for tools that didn't quite work. Designers couldn't easily get user feedback, so I became the bridge. Engineering couldn't ship small changes quickly, so I became the gatekeeper. Research took weeks, so I became the synthesizer. I was good at it. I built a career on it. But it wasn't the real job. It was the job that had to exist because the rest of the toolchain was slow.

Most of that compensation work is gone in our team. It will be gone in most teams within a few years.

What's left is harder, smaller, and sharper. Taste. Judgement. The ability to look at a working prototype and decide what it should become. That's a more concentrated job than what most PMs do today, but it's not a smaller one. It might actually be the job PMs always thought they had.

If you're a PM and you're reading this, the question I'd leave you with isn't whether AI is coming for your role. It's which version of the role you've been doing. Because one version is thinning out fast, and the other one is about to get a lot more interesting.