Lesson 2: Capture the signal

Feedback is one raw signal from one user: a request, a complaint, a bug, a confused question. Not your interpretation of it. The thing they actually said.

Discovery vs. delivery

Product work splits into two halves:

• Discovery: deciding what's worth building.
• Delivery: building it well.

Founders over-index on delivery (it feels like progress) and skip discovery (it feels like talking instead of working), then build the wrong thing fast. Capturing feedback is the cheapest discovery there is: the users already did the talking. Your only job is to not lose it.

The rules of capture

1. Verbatim beats summary. "The export button doesn't do the thing" carries more information than "export issue."
2. Capture at the moment it lands. A signal you'll "add later" is a signal you've already lost.
3. One signal per entry. A support email with three complaints is three feedback items.
4. Your own observations count: tagged as yours. The rule isn't "no opinions," it's "know whose data point each one is."

Do it now

Open Feedback and press C to create. Add three real signals from memory: a support email, a Slack message, that thing a user said on a call last week. Title each with what the user actually wants.

Three is the minimum for Lesson 3, patterns need at least a few points.