What changed?
- 07/2026: Published the five-decision triage model and weekly operating cadence.
- 07/2026: Added explicit accept, decline, defer, merge, and re-route criteria.
What is product request triage?
Product request triage is the decision process that turns an incoming signal into an explicit outcome. Product request triage determines whether a request is accepted, declined, deferred, merged with existing evidence, or routed to another owner.
A request can arrive from a customer conversation, support message, sales call, internal teammate, production incident, or API. The source matters because the same sentence can represent different impact, urgency, and confidence.
Triage is not prioritization alone. Prioritization orders work that remains under consideration. Triage first decides whether the signal belongs in the product system and what evidence or action comes next.
Which product request triage statuses should a team use?
A small product team can cover most triage outcomes with five statuses: accept, decline, defer, merge, and re-route. Each status needs a definition and a required next action, or the queue becomes a second backlog.
| Outcome | Use when | Required next action |
|---|---|---|
| Accept | The problem is understood and deserves active planning. | Create or connect delivery work, then assign ownership. |
| Decline | The request conflicts with product direction or lacks sufficient value. | Record the reason and close the request. |
| Defer | The request may matter, but evidence or timing is insufficient. | Set a review condition or review date. |
| Merge | The same problem or evidence already exists. | Link the source to the canonical request. |
| Re-route | Another team or process owns the problem. | Assign the destination and confirm receipt. |
How should a team evaluate product requests?
A product team should evaluate requests by problem evidence, affected users, expected value, urgency, strategic fit, delivery cost, and confidence. A score can support discussion, but the evidence behind each input matters more than the total.
Do not hide uncertainty inside a precise-looking number. Mark low-confidence inputs directly. A request with high possible impact and weak evidence may deserve discovery, not immediate delivery.
- Problem evidence: direct observation, repeated reports, or an unverified opinion.
- Reach: how many relevant users or workflows the problem affects.
- Impact: the cost of leaving the problem unresolved.
- Urgency: what changes if the team waits one cycle or one quarter.
- Strategic fit: whether the problem supports the current product direction.
- Effort and risk: delivery cost, dependencies, reversibility, and uncertainty.
What does a weekly product triage cadence look like?
A weekly product triage cadence needs one queue owner, a fixed review window, preparation before the meeting, and a decision recorded for every reviewed request. Ten well-prepared decisions are more useful than reviewing fifty titles without context.
- Before review: remove duplicates, request missing context, and identify the likely owner.
- During review: state the problem, evidence, affected users, urgency, and proposed disposition.
- After review: connect accepted work, record decline reasons, and set review conditions for deferred requests.
- Monthly: inspect queue age, decision mix, repeated sources, and requests that re-entered triage.
Which product request triage metrics are useful?
The most useful triage metrics measure decision speed and decision quality: median time to decision, queue age, percentage with a recorded disposition, deferred requests without a review condition, duplicate rate, and accepted requests that reach delivery.
A low time to decision is not automatically good. Fast declines without context can destroy trust, while fast acceptance can overload delivery. Review the metrics together and sample the underlying decisions.
Cadylo supports team triage queues, explicit issue properties, project and cycle planning, and delivery analytics so the original request can remain connected to later work.
Questions
Frequently asked questions about product operations.
Who should own product request triage?
One named product owner should be accountable for queue health, even when decisions involve engineering, design, support, or sales. Shared input is useful, but shared accountability often leaves old requests without a decision.
How often should a team triage product requests?
Most small product teams should review urgent requests continuously and hold a scheduled triage review once or twice per week. The right frequency depends on request volume and decision urgency, not on a universal meeting schedule.
Should every customer request become an issue?
No. A customer request is evidence, not automatic delivery scope. Keep the request and its source context, then create or connect an issue only after the team accepts work or needs a structured discovery action.
What is the biggest product triage mistake?
The biggest product triage mistake is using defer as a status with no review condition. Deferred requests need a date, evidence threshold, dependency, or product event that tells the team when to reconsider them.