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.
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.
That fear of shipping slop is what keeps me careful. 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 now I brainstorm first, usually with a skill that forces me to articulate what I’m trying to do, then 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 now have two audiences, the team building the product and the agent helping them, and that changes the writing. Ambiguity gets expensive, and rhetorical flourishes don’t survive the first load into context. A good spec has to load cleanly as context and work as a plan an agent can follow step by step. 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 defines the product. A PRD says what you want, and an eval tells you whether you got it, so for anything with an agent in the loop it’s now the artifact I 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. Most runs get from ticket ID to a working hypothesis in about 20 minutes.
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 bring engineering a classified issue and a working hypothesis they can check. I also didn’t expect to learn more about our products in the past couple of months than I did in the 1.5 years before that.
What didn’t change
I use AI to lay out the tradeoffs, and then I still have to pick which user or business opportunities we 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 works the way it always did, and if anything it got more delicate. Prototyping makes it harder to tell when I’m helping and when I’m stepping on toes, and I end up renegotiating that line with the team most weeks.
And when an incident happens, you still write the postmortem, make the call to the customer, and carry the fix into the next planning cycle.
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. Eventually I noticed that output quality tracked my CLAUDE.md and my skills library more closely than my phrasing.
I also thought adoption would follow a normal curve, with some PMs fast, some slow, and most in the middle. Across the PMs I talk to, I’m seeing a widening gap between those willing to change how they work and those who aren’t. It shows up in how fast they can investigate a problem and in whether other teams pull them into things.
I was talking to my wife the other day about what I’m doing, and she asked, “Why are you automating your job away?” I told her I’d automated the digging, like the cross-referencing and the first pass at an analysis, and that I now spend more of my time deciding which problems deserve that work. 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 anyone who says they do. What I can do is keep track of what’s getting harder, and write about it again when I know more.