5/ The dominant feeling if you're doing this for the first time is that you will feel extremely uncomfortable — like this shiny new idea in your head is great and all but the PR/FAQ is making it look stupid. It makes you feel stupid.
This is GOOD.
Conversation
6/ It means you can't lie to yourself.
The work necessary to write a good PR/FAQ is never wasted — after all, if you don't figure it out while writing it, you're going to need to figure it out AFTER you've built a ton of crap.
1
6
7/ "Well, what about ideas that have a more gnarly idea maze?" you might ask. For instance, say you were building something that requires actual usage in order to uncover the right thing to build. Like Notion.
In this case, the PR/FAQ becomes a way to track iterations.
1
4
8/ "Can't you do this with simple hypothesis —> conditions for success written statements?"
For quick iteration cycles I think it makes sense to write hypothesis statements down. So you know exactly WHY you're doing this particular product iteration.
Quote Tweet
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?
Show this thread
1
4
9/ But the primary benefit of the PR/FAQ is that it forces you to think from the customer's perspective. It's particularly unforgiving in this way.
Customers don't give a shit about your features. They care about how it solves THEIR problems.
1
5
15
10/ Implication: use the PR/FAQ as a check-in test. I currently pause to write/update one between multiple iterations, in order to help check if I'm rigorously uncovering what matters.
Which is a fancy way of saying "am I asking the right questions?"
1
1
6
11/ The general principle behind the PR/FAQ is that you must answer:
1. Who's the customer
2. What's the problem you're trying to solve.
3. What's the solution (and you need to explain to the customer, not to investors, not to yourself)
1
1
19
12/ 4. Would they reasonably adopt this solution? (Because you're asking for a behaviour change.)
5. What's the TAM, is it big enough to be worth doing.
As a forcing function for good thinking, the PR section MUST be 1 page.
1
1
7
13/ Bryar told me that at Amazon, most product ideas died at Question 5.
In practice, as a builder outside Amazon, Q5 might not matter as much. Amazon is a multi-billion dollar company, so bets must have a shot of moving the bottom line.
Their bar is naturally quite high.
1
7
14/ Your bar can be significantly lower.
But low doesn't mean no rigour. The failure mode I've often most seen wrt the PR/FAQ are builders feeling uncomfortable, and then calling the PR/FAQ a waste of time.
Only to hit "who are the customers?" problems further down the road.
1
2
9
15/ Further proof that the PR method works more broadly:
- Tony Fadell wrote one before he started writing Build. (It's in the book.)
- Steven Sinofsky explains that the Windows marketing team wrote a mock PR ahead of the Windows 7 building cycle.
Replying to
16/ Ok, that's all I have for now. If you'd like more updates, follow me on Twitter. Or subscribe to my newsletter here: commoncog.com/blog/subscribe
I write from practice, so I plan to write a longer retrospective on the PR/FAQ process once I've got more reps in.
4
12
1
2
13
Updated this essay with a clarification from Colin Bryar (screenshot below).
It turns out that experienced PR/FAQ writers tend to be a bit more loose with the process.
And I guess that’s the point I’d like to get to.
1
6