Modeling feedback as a signal that ages
Feature requests rarely stay “equally true” over time. Some demands surge as a market shifts, others sit steady for months, and many quietly fade as customers find workarounds or move on. Treating every request as a timeless vote creates two predictable failures: you over-build for yesterday’s pain, and you under-react to what’s accelerating right now.
A practical fix is to treat feedback like a signal with recency decay. New signals matter more than old ones, but older signals don’t instantly become irrelevant—they just contribute less unless they keep getting reinforced. This is the core idea behind a Feedback Recency-Decay Model: a lightweight way to translate “how many people asked” into “how strongly is this still demanded today.”
The Feedback Recency-Decay Model in plain terms
The model combines two ingredients:
- Demand volume: how many distinct accounts (or users) requested the same outcome.
- Recency weighting: newer requests count more; older requests count less, based on a decay curve.
Conceptually, each request contributes a weight that decreases with time. If requests continue to arrive, the total score stays high or climbs. If requests stop, the score naturally drifts downward—without you having to manually “archive” anything.
Choose a decay curve you can explain
You don’t need academic precision; you need consistency and interpretability. Two common options:
- Exponential decay: the weight drops by a fixed proportion each period. It’s great when you want the model to react quickly to change.
- Stepwise decay: e.g., full weight for 30 days, half weight for 31–90 days, quarter weight after 90 days. It’s simpler to communicate to stakeholders.
The “right” curve depends on release cadence and how quickly your market moves. Weekly shipping teams can afford faster decay; quarterly release cycles often prefer slower decay to avoid thrashing.
Rising, flat, and fading demand: how the model changes prioritization
1) Rising demand: prioritize acceleration, not just totals
A rising request stream is a leading indicator. Even if the total number of votes is modest, rapid recent growth suggests urgency: a new competitor is setting expectations, a platform change broke workflows, or a segment is expanding.
Operationally, the Recency-Decay score helps you spot this earlier than a lifetime vote count. A request with fewer total votes can outrank an older “classic” request if it’s getting consistently reinforced in the last few weeks.
What to do when the signal is rising:
- Validate the driver: is this tied to a new customer segment, pricing tier, or integration?
- Assess blast radius: does it unblock onboarding, reduce churn risk, or unlock revenue expansion?
- Decide the response type: sometimes the right move is a quick mitigation (docs, workaround, minor UX fix) while you plan the deeper feature.
2) Flat demand: prioritize by strategic fit and effort
Flat demand means the request keeps showing up, but at a steady rate. These are often foundational usability gaps or “table-stakes” expectations. Recency decay won’t artificially inflate them, but it will keep them visible as long as the stream continues.
This is where you should lean harder on second-order factors:
- Segment value: which customer cohorts ask for it, and what is their revenue or expansion potential?
- Opportunity cost: what else could the team ship in the same timeframe?
- Maintenance footprint: how much long-term complexity does the feature add?
A flat signal is a good candidate for a clear service-level expectation around feedback handling—what gets acknowledged, when it gets triaged, and how updates are communicated. If you already run a structured system, align this model to your process rather than replacing it. For example, you can map score thresholds to stages in a feedback SLA. (If you want a companion framework for the operational side, see The Feedback SLA Playbook for Feature Requests.)
3) Fading demand: downgrade gently and capture why
Fading demand is the most emotionally tricky category because the request might have once been a top complaint. But if no one is asking anymore, the most common explanations are:
- Customers found a workaround or changed behavior.
- Your product improvements indirectly solved the problem.
- The segment that cared most churned or deprioritized that workflow.
- The market moved on.
The Recency-Decay score lets you deprioritize without deleting history. That history is still valuable: it tells you what used to hurt and can re-emerge if conditions change.
What to do when demand fades:
- Add a “reason note” during triage (workaround exists, replaced by new workflow, etc.).
- Keep watching for re-acceleration after launches, pricing changes, or new integrations.
- Be cautious with “zombie requests”: long-lived items with many lifetime votes but no recent reinforcement.
How to implement the model without over-engineering
Step 1: normalize feedback into deduplicated “ideas”
Recency weighting only works if you’re not counting duplicates as separate signals. Centralize requests, merge similar ones, and keep the original context attached. Platforms built for feedback management (including Canny) make this easier by keeping a single canonical idea with many linked requests and comments. For teams that want a robust hub for capture, dedupe, analysis, and communication, canny.io is a practical reference point because it keeps the feedback stream connected to segments, accounts, and updates.
Step 2: decide the unit of demand
Counting “users” can overweight loud accounts with many seats; counting “accounts” can underweight broad user pain. Many teams track both:
- Account-weighted demand for prioritization (each customer counts once).
- User-weighted demand for UX and adoption impact.
Step 3: pick a decay window aligned to your roadmap rhythm
If your typical discovery-to-ship time is 6–10 weeks, a half-life in that range keeps the model responsive. If shipping takes 6–12 months, decay must be slower or you’ll constantly chase new spikes and miss strategic platform work.
Step 4: layer in “value multipliers” after the recency score
Recency decay answers “how alive is this request.” It does not answer “is it worth building.” Add multipliers such as:
- Revenue or tier impact (e.g., enterprise vs self-serve).
- Churn risk (support tickets, renewal notes, escalation tags).
- Strategic alignment (platform direction, differentiation).
This keeps the model from turning into a pure popularity contest.
Using the model to communicate priorities with less friction
The best outcome of a Recency-Decay approach is not a perfect ranking—it’s calmer decision-making. You can explain why something moved up (“recent demand accelerated”) or down (“requests stopped arriving, and existing customers have workarounds”), without implying anyone was “ignored.”
Two practical communication patterns help:
- Public-facing transparency: show status changes and summaries so customers understand what you’re learning, not just what you’re shipping.
- Internal traceability: link each prioritized item to the latest customer examples so engineering and leadership see current evidence, not outdated anecdotes.
When you treat feedback as a time-sensitive signal—rising, flat, or fading—you get a roadmap that reflects the present while still respecting the past.