Build a feedback loop

Feedback is not a vote

The purpose of feedback is to reveal information you could not see alone. It does not transfer the product decision to the audience.

People are usually more reliable when describing their situation, behavior, and difficulty than when predicting which feature they will use. Listen closely to the problem. Test the proposed solution.

Ask narrower questions

“What do you think?” makes the reader invent the evaluation criteria. The answers tend to be polite, broad, and difficult to act on.

Ask questions tied to a decision:

• Which sentence made the project unclear?
• What would you expect this button to do?
• When did you last experience this problem?
• Which step would stop you from trying this workflow?
• If this export failed, what would you lose?

One update should usually ask one primary question.

Find the right people

Ten reactions from other builders may be less useful than one observation from a person who repeatedly experiences the problem.

Publish where the relevant context already exists. A developer tool may belong in a focused open-source community. A local service may require direct conversations rather than a global social feed. Build in Public expands the surface for discovery, but it does not remove the need to find actual users.

Keep a feedback ledger

Record feedback without immediately turning it into a task:

Observation:
Who experienced it:
Context:
Evidence or exact behavior:
Current interpretation:
Decision: test / change / defer / reject
Reason:

Look for repeated situations, not repeated wording. Five people can request different features because they share the same underlying difficulty.

Close the loop publicly

When feedback changes the work, say so:

Last week I asked how people find old decisions. Most respondents remembered the feature, not the date. I added feature labels to search results but kept the writing form category-free. Here is the before-and-after screen.

This shows that participation mattered without claiming every suggestion was accepted.

When you reject a popular request, explain the constraint respectfully. A clear “not now, because...” creates more trust than silence or an impossible promise.

Beware of loud signals

Likes measure distribution and resonance, not product value. Comments measure willingness to comment. Waiting-list signups measure curiosity. Payment, repeated use, contribution, and changed behavior are stronger signals, but each answers a different question.

Choose the evidence that matches the current decision.

Feedback checklist

• [ ] I know which decision the question will inform.
• [ ] The question is specific and easy to answer.
• [ ] I am asking people who experience the relevant situation.
• [ ] Feedback is recorded before becoming a task.
• [ ] I distinguish stated preference from observed behavior.
• [ ] I will report what changed or explain why it did not.

The loop is complete only when learning returns to the work.