I’ve decided I’m practicing FDD now. Fear-Driven Development, in the tradition of TDD but less rigorous and more sweaty. Every time I send a pull request, which happens a lot now, I’m terrified of an engineer sending it back to me and asking me to please stay in my lane and stop sending them slop. So I plan, write specs and implementation plans, test thoroughly, and distrust the agent’s inevitable confidence.
I’ll come back to that. The loudest take on PM work right now is that AI is collapsing the role — that we’re one product cycle away from redundancy, or being reduced to prompt jockeys. That hasn’t been my experience at all. Over the last five months at Cloudflare the job got more hands-on, harder (brain fry is real), but also a lot more fun.
What changed
We all ship now. The biggest shift in my day-to-day is that my team and I write code. There is no universe in which I’m touching our data pipeline code. But prototypes, internal tools, small features, and the live bugs and UX improvements that are safe for us to touch now go out as PRs instead of going into the backlog. One of our engineering managers put it well:
I like these dashboard revamps. Far better if PMs can express their visions for the product directly to Opencode, avoids a lot of back and forth.
This is where FDD comes in. The terror of shipping slop is the thing that keeps me responsible. Telling Claude “hey, build me X” is a fast road to code that doesn’t work the way it should, or worse, works but breaks things you won’t find until later. So the pattern I run now is: brainstorm first, usually with a skill that forces me to articulate what I’m trying to do; write a spec; turn the spec into an implementation plan; and only then start generating code.
The planning is what makes the whole thing faster, and the output better, which took me a while to believe. Skip the brainstorm and you’ll spend the next week untangling code the model wrote confidently and incorrectly. Plan properly and the build itself is usually the fast part.
Context is the product. The second change matters more, and it took me longer to see: I spend real time maintaining a context layer. A CLAUDE.md file that tells the agent how we work, a library of skills, stakeholder memory, agent routing, a second brain that feeds all of it. None of this was part of my job a year ago. My own PM rubrics live inside this layer too. My /okr and /prd commands load the problem-first frameworks and antipattern checklists I’d apply myself, so the first pass on any draft or review is already done before I open the doc.
Evals are the new PRD. Specs and product requirements documents are changing the same way. When a document has two audiences (the team building the product and the agent helping them), the writing changes. Ambiguity gets expensive, and rhetorical flourishes don’t survive the first load into context. A good spec loads cleanly as context and runs as a plan, which is a different job than writing a memo for stakeholders. Ameya Bhatawdekar at Braintrust has a good post on how evals are the new PRDs:
An eval is a structured, repeatable test that answers one question. Does my AI system do the right thing? Think of it as a unit test for AI behavior.
The argument is that in AI-native products the eval suite is what defines the product. A PRD says what you want; an eval tells you whether you got it, which is why it’s the artifact I now ask for first.
We take more load off engineering. CUSTESCs (our customer escalations) used to take hours and hours of PM and engineering capacity. Someone would dig through Jira, read code across a dozen repos, chase down the relevant ClickHouse tables, check the docs against what the customer expected, and go back and forth for days before anyone had a useful working hypothesis.
Our team now has a /custesc command that does most of that in parallel. It pulls the ticket, runs three agents at once across code, Jira, and the wiki, generates and runs ClickHouse queries to check the leading hypothesis, and passes the draft through a blind validator and challenger before it lands as a classified analysis. Ticket ID to root cause in about 20 minutes, most of the time.
This moves where the investigation work sits. A CUSTESC used to be a tax on engineering. Now I can run the full investigation myself and come to engineering with a classified issue and a working hypothesis, instead of a vague “can someone take a look at this?” The side benefit I didn’t expect: I’ve learned more about our products in the past couple of months than I have in the 1.5 years before that.
What didn’t change
Figuring out what to bet on. AI can lay out the tradeoffs; it can’t tell you which user or business opportunities to prioritize this quarter. Deciding what to say yes and no to is still the hardest part of the job, and the roadmap is a set of bets you own. (We’ve moved fully to Now/Next/Later, which is a longer conversation than this post can hold.)
Trust with engineers. Being useful to your team is earned slowly, by showing up and owning the ambiguous stuff. The calls no one wants to make are yours. If anything, PMs being able to prototype makes the line between helping and stepping on toes harder to hold. It’s a human line, and it gets redrawn every week.
Owning outcomes when things go wrong. When an incident happens, you write the postmortem, you make the call to the customer, and you carry the fix into the next planning cycle. Those are the moments that define whether people trust you, and they land on a person.
What I got wrong
I underestimated the context layer. For the first year I treated AI as a chat tool: ask good questions, get good answers. So I got good at prompts. It took me embarrassingly long to notice that output quality was tracking my CLAUDE.md and my skills library more closely than my phrasing ever did.
I thought adoption would be gradual. I assumed PMs would pick this up on a normal curve: some fast, some slow, most in the middle. What I’m seeing across the PMs I talk to is a widening gap between PMs who are willing to change how they work and PMs who aren’t. It shows up in how fast they can investigate a problem, in the specificity of their design arguments, and in whether other teams pull them into things.
Getting started is easy and the early wins are obvious. The hard part is being open to changing your job. I was talking to my wife the other day about what I’m doing, and she asked the obvious question: “Why are you automating your job away?” My answer: what I automated is the digging — the cross-referencing, the first pass at an analysis. What’s left is deciding which problems are worth digging into, and that part got more valuable.
Where this leaves us
I don’t know what this job looks like in another year, and I’ve stopped trusting the takes that say they do. The ground shifts faster than the opinions written about it, and most of the stable-sounding ones age badly within a quarter. What I can do is keep noticing what’s getting harder, and stay honest about the parts of this I’m still bad at.