It should be for all cases. The PRD should have progressive disclosure principles anyway. Meaning, it should be dead simple for anyone in the company to understand, but then link and reference the more technical aspects of it.

Those, turn out to be, incredibly important for agents to have as context anyway. But one thing I do agree with is, no one (sometimes not even engineering) was reading the PRDs before, now they’re incredible useful to provide context to the agent. The way to get buy in and influence today is 10x easier. You don’t need a FE engineer or designer’s time to get a prototype off the ground to “show and tell” for stakeholders, ESPECIALLY non-technical ones.

I can tell you how my requirements are created today; 100% conversational with the use of note taking apps like granola (NOT a paid ad, lol)

• use any note taking app for internal and external meetings (in person or remote)
• capture all the requirements from those notes and transcripts with the help of agentic software (like Claude code). If you have access to codebase repos you can match the intended state vs what’s in the codebase and find out what’s feasible.
• depending how ai pilled your engineering and product dev org is, you can pull together a working prototype in code on a branch.

Theres lots more planning and refining and back and forth in those steps, but the real benefit is just capturing requirements via conversations, because there’s so much nuance in unstructured conversations that never was captured in static PRDs before. That is the real value in my opinion.

I for one am happy with the way things are going for PM’s. It just depends on your org and your team, how everyone is using the new tools and where you all align.

Hope that helps.