BUILDSIDE — PRODUCT FEEDBACK DECISION WORKSHEET
Turn requests into a considered next step
https://www.buildside.app/solutions/prioritize-product-feedback

Copy this worksheet into any notes app.
Complete it yourself; this is an editorial planning resource, not automated scoring.

1. THE PRODUCT'S CURRENT FOCUS
Product:
Intended audience:
Core task:
Current product scope:
Decision owner:
Review date:

2. UNDERSTAND THE REQUEST
What did the person ask for, in their own words?
What were they trying to accomplish?
What happened instead?
What workaround do they use?
What would a useful outcome look like?
Is this a bug, a confusing workflow, a missing capability, or a preference?
What remains unclear?

Keep unnecessary personal details out of public notes.

3. COMPARE THE EVIDENCE
Audience fit:
Does this person match the intended audience? If not, what would serving them change?

Impact:
Is the core task blocked, harder to complete, or still usable?
What concrete example supports that assessment?

Recurrence:
Who else has experienced the same problem?
Separate repeated requests from one account from independent observations.

Confidence:
What did we observe directly?
What was reported?
What are we assuming?
What evidence is still missing?

Effort and dependencies:
What must be understood before estimating the work?
Could a smaller change address the underlying problem?
What would we delay by taking this on?

Votes and scores can inform a review. They do not replace task context.

4. DECISION BRIEF
Request or problem:
Known:
Unknown:
Next check:
Current decision: INVESTIGATE / PLAN / DEFER / LOWER PRIORITY / OTHER
Reason:
Owner:
What new evidence would change the decision?
When should we revisit it?

WORKED EXAMPLE — FICTIONAL SESSIONPATCH
Audience: Independent consultants.
Request: SMS reminders because clients miss appointments.
Known: A user reports missed appointments.
Unknown: What caused the most recent miss?
Next check: Review the reminder workflow and ask what the client saw.
Current decision: Investigate before choosing SMS.
This example is not evidence that SMS is always the right or wrong priority.

5. PUBLIC DECISION-NOTE TEMPLATE
We heard:
[Describe the problem without exposing private information.]

Our current focus:
[Name the audience and task this release serves.]

We decided:
[Explain what you will investigate, plan, defer, or change.]

Why:
[Give the evidence and tradeoff behind the decision.]

What remains open:
[State uncertainty and what would make you reconsider.]

What happens next:
[Give a useful next step and owner. Only promise timing you can support.]

6. CLOSE THE LOOP
[ ] Reply to the relevant conversation.
[ ] Keep the product's roadmap status accurate.
[ ] Distinguish an intention from an available feature.
[ ] Explain what changed when work ships.
[ ] Check whether the original task became easier to complete.
[ ] Revisit old decisions when the evidence or product scope changes.

Buildside: product context, feedback, roadmap, and public updates.
The founder remains responsible for the decision.