As I shift back into build mode, I'm reminded that much of the value of writing product docs is really so that you can't lie to yourself.
You're building this feature/making this change — but what's the hypothesis? What's the information you hope to generate?
Conversation
Of course, by 'product docs' I don't necessarily mean long PRDs. Even short outliner-style docs work as well (e.g. handful of points, briefly stated, but written so you can check in future).
Otherwise you might think you're making progress, while rapidly iterating to nowhere.
1
6
Something surprising: I used to assume that product docs are only worth it for larger teams.
(Which they are!)
Now I think: useful if you’re one person, less useful in a small team, useful again in a large team.
1
1
7
Reason: large team needs product docs for obvious reasons. It scales communication.
Small team: not necessary, because the mind meld can catch you — team members can call you out when your hypotheses don’t play out/when it’s a wasteful iteration.
Replying to
But if you’re one person, the only way you can catch yourself is by writing things down. There’s nothing quite like being called a liar in your own words. (To quote a wonderful line).
5
Replying to
That works if the small team has a shared consensus of exactly what the product will be, but all too often different team members have different conceptions of what that thing is, sometimes startlingly so.
1