Product document naming

J. Kelly Brito

I recently found myself looking for an alternative to the term PRD (product requirements document), for product people who don’t like abbreviations, and who think product discovery identifies opportunities, not requirements.

Depending on your point of view, getting naming Just Right either wastes time, or provides valuable framing that you will benefit from daily for a long time to come. My personal interest in naming things dates back nine years, so it shouldn’t surprise you to find me overthinking this particular question.

The PRD mistake

Software product management generally deals with making choices, not defining requirements. Each industry and product category does have genuine requirements, though, often legal requirements. You can recognise genuine requirements because they apply equally to your competitors. Instead of calling it a PRD, at least pick a more honest name, like product choice rationalisation.

Meanwhile, I also don’t like the term PRD because I don’t like lazy abbreviations. In product management especially, you communicate with people in many groups, who have different daily jargon and potentially conflicting abbreviations. In writing, even for internal stakeholders, avoid abbreviations.

One-pagers

John Cutler calls these documents one-pagers, to emphasise conciseness that he calls ‘crisp communication’. This name works in the context of writing extensively for product managers, about product management techniques and frameworks.

As a product manager working with other teams, you might not get away with the arrogance of claiming such a generic term. Something like product docs avoids that ambiguity, provided that you don’t use the term documentation for user guides and manuals.

Similarly, developers and support teams often refer to tickets that describe every kind of work they get via an incident ticket system. Personally, though, I prefer not to name documents according to their length or database.

Opportunities

When product managers talk about product discovery, we talk about the problem space. But then problems have to include problems the customer didn’t know they had, which feels awkward (and patronising). The term opportunity benefits from including more than just problems. In Continuous Discovery Habits, Teresa Torres writes:

I’ll refer to customer needs, pain points, and desires collectively as “opportunities”—they represent opportunities to intervene in our customers’ lives in a positive way.

We can therefore refer to opportunity descriptions. But this term’s accuracy makes it boring, and ithas too many syllables, so it won’t catch on.

In practice, you can just call the document an opportunity, and ignore the difference between the document and the opportunity itself. This is the same kind of category error we got used to from people asking each other to create issues (in Jira). I can live with that, and like opportunity, but would prefer a shorter word.

Bets

Annie Duke popularised talking about bets in her book, Thinking in Bets. In this context, bet abbreviates the idea of my bet… were I to actually place it, rather than a bet you’ve already made, so you can also use it for bets you decline to prioritise.

John Cutler also actually defines one-pagers as:

short, space-constrained, descriptions of a proposed product bet

I like short names, but not everyone will enjoy the gambling reference. Furthermore, talking about placing bets requires enough trust and safety to acknowledge product decision uncertainty.

So write down bets, opportunities, problems or even product docs. But please give up PRD.