Product Managers are ultimately responsible for figuring out what to build and ensuring it is impactful.
Simple in theory, but not easy.
PMs have to source and process ideas from every direction, rationalize and advocate for which investments make sense, and hold steady in conviction about their roadmap while staying flexible for things to change as they learn.
For decades, the Product Requirement Doc (PRD) has been the instrument of the trade, the single source of truth for what to build and why.
In the 90s, PRDs spanned 20-30 pages and were meant to be the definitive record of every detailed change. With the evolution of agile development and the acceleration of software-centric businesses, product teams realized that static documents aren’t the best tool to represent dynamic creative work.
PRDs have miraculously prevailed, but Product Managers are still relying on the outdated concept of a single static document, which lands them in one of two ineffective camps.
At one extreme, the anxious Product Manager will spend too much time trying to create a perfect document that resembles a doctorate dissertation awaiting approval. This common failure mode shows up in teams that lack internal trust or have unclear ownership. The PRD becomes a process tool to solve a people problem.
At the other extreme, the overzealous Product Manager will spend too little time articulating their thinking, bypassing writing as a superfluous process that slows everything down. This common failure mode happens on teams that see a process as a barrier to progress, only to be met with a bunch of unresolved questions and problems to navigate downstream.
Neither view is ideal for modern product teams, whose work resembles any other creative pursuit: requiring enough constraints to get started, but also enough flexibility to enable new approaches or solutions as exploration gets underway.