← Writing

Manual Feedback Sources That Actually Move Roadmaps (Not Just Create Noise)

Manual Feedback Sources That Actually Move Roadmaps (Not Just Create Noise)

TL;DR: Not all manual feedback is equal. Prioritize sources that capture real friction and real stakes—support pain, sales losses, research verbatims, and metric investigations.

Manual feedback is powerful—and dangerous

It’s powerful because it includes context and emotion.
It’s dangerous because it’s easy to cherry-pick.

So you need to be intentional about which manual sources feed your decisions.

Four manual sources worth protecting

1) Support themes (not ticket dumps)

Ask for:

  • weekly top 5 themes
  • 2 verbatims per theme
  • volume + severity

2) Sales losses (with honesty)

You want “why we lost,” not “pricing was high.”

  • what they bought instead
  • what capability they needed at that moment
  • whether it was a must-have vs nice-to-have

3) Research snippets (verbatims + observed behavior)

The fastest way to keep VOC alive is to share:

  • direct quotes
  • observed struggles (“clicked X three times, then gave up”)

4) Metric investigations (a.k.a. “why did conversion drop?”)

Every investigation creates feedback:

  • where users fall off
  • which workflows fail
  • what error states spike

A simple quality rubric

When a manual input arrives, score it quickly:

  • Stakes: does it impact retention/revenue/time?
  • Specificity: is it tied to a moment and workflow?
  • Repeatability: have we seen it elsewhere?
  • Segment clarity: who is this true for?

If it fails 2+ items, it still goes in the river—just don’t let it steer the roadmap alone.

Turn manual feedback into roadmap inputs

Use a two-step approach:

  1. River entry (raw + context)
  2. Theme candidate (weekly review) with:
    • frequency signals
    • affected segment
    • impacted KPI
    • suggested experiment/bet

Takeaways

  • The best manual sources are close to friction and close to stakes.
  • Use a rubric to avoid “whoever tells the best story wins.”
  • Store raw inputs first; synthesize second.