What changed?
- 07/2026: Published a three-stage model for product intake, backlog, and planned work.
- 07/2026: Added five realistic routing examples and explicit backlog entry criteria.
What is the difference between product intake and a backlog?
Product intake is a decision queue for new signals, while a product backlog is a set of accepted delivery candidates. Intake protects source context while the team verifies a problem; the backlog preserves work that passed that first decision but has not necessarily earned a place in a plan.
The distinction prevents every customer request, internal idea, integration event, or bug report from becoming delivery scope. A request can be valuable evidence without becoming a separate backlog item.
Planned work is a third category. An item becomes planned only after the team commits it to a cycle, milestone, project, or other delivery window. Acceptance into the backlog is not the same decision as scheduling.
What belongs in product intake?
Product intake should contain new requests, ideas, reports, and development signals whose product meaning is not yet settled. Each intake item should retain its source, problem statement, affected user or workflow, supporting evidence, urgency, and the person or system that submitted it.
- A customer request that describes a desired feature but not the underlying workflow.
- A sales or support pattern that may represent several related customer problems.
- An internal idea that needs evidence before the team considers delivery.
- An API, GitHub, or GitLab signal that needs routing to the responsible team.
- A possible duplicate that should strengthen an existing request instead of creating new work.
- A non-urgent report that still needs reproduction or impact assessment.
What belongs in a product backlog?
A product backlog should contain work the team has deliberately accepted for future consideration. Every backlog item needs a clear problem, enough evidence to justify retaining it, a responsible team, a usable next step, and a reason it belongs in the product direction.
A backlog item does not need a delivery date. It does need a decision boundary: the team should know why the item was accepted, what would increase or reduce its priority, and when it will be reviewed again.
Keep raw evidence connected to the accepted item. Creating five backlog issues for five reports of the same problem inflates demand without improving the decision.
How should a team route common product requests?
Route each request according to the decision it needs next. Unverified signals stay in intake, accepted problems move to the backlog, committed work moves into a plan, and incidents or support tasks go to the operational workflow that can respond without waiting for product prioritization.
| Example | Destination | Reason and next move |
|---|---|---|
| One customer asks for bulk editing without describing the affected workflow. | Product intake | Clarify the problem, frequency, current workaround, and impact. |
| Four interviews describe the same approval delay and a product owner accepts the problem. | Product backlog | Link the evidence to one canonical item and define the next discovery or delivery step. |
| A validated compliance change has an approved deadline, owner, and delivery scope. | Planned work | Connect the issue to the responsible project, cycle, or milestone. |
| A production outage affects active customers. | Incident workflow | Restore service first; capture product follow-up separately when needed. |
| A new request describes a problem already represented by an accepted item. | Existing item | Attach the source as additional evidence instead of creating another backlog issue. |
When should an intake request become a backlog item?
Move an intake request into the backlog when the team can state the problem, identify credible evidence, name the responsible team, explain the product relevance, and record a useful next step. If any of those facts are missing, the request needs clarification, routing, or a deliberate decline rather than silent acceptance.
- Problem: describe the user or business constraint without assuming a solution.
- Evidence: link the request sources, frequency, impact, and confidence.
- Ownership: name the team responsible for the next decision.
- Fit: explain why the problem belongs in the current product direction.
- Next step: define discovery, estimation, comparison, review, or planning work.
- Review condition: record a date or evidence threshold when timing is uncertain.
How can a team prevent backlog bloat?
Prevent backlog bloat by enforcing entry criteria, merging duplicate evidence, recording decline reasons, and reviewing old items against current product direction. A small team can start with two intake reviews per week and one monthly backlog review, then adjust the cadence to request volume.
Track median time to an intake decision, the age of pending requests, accepted items without owners, and backlog items without recent evidence or a next review condition. These measures reveal neglected decisions without rewarding acceptance volume.
Archive or decline items when the problem no longer fits, the evidence remains weak, or the product direction changed. Keeping the decision history is more useful than leaving obsolete items open forever.
How does Cadylo connect product intake to the backlog?
Cadylo keeps product requests in a team intake queue until an authorized teammate accepts or declines them. Accepting a request creates an issue for the selected team with its context intact; declining retains the request and resolution note in intake history without creating backlog work.
Cadylo can route intake requests by team, assignee, and priority. Teammates and Slack can submit triage requests, while API clients create issues directly and GitHub or GitLab development activity stays linked to accepted issues.
This boundary makes the conversion from request to issue an explicit product decision. It also gives the team one history for requests that moved forward and requests that did not.
Questions
Frequently asked questions about product operations.
Can an accepted request skip the backlog?
Yes. An urgent, validated request can move directly into planned or active work when the team has made both the acceptance and scheduling decisions. The important rule is to record those decisions separately rather than treating every accepted request as automatically committed.
Should bugs go through product intake?
An unverified bug report can enter intake when the team still needs to reproduce, route, or assess it. A confirmed incident or active customer-impacting defect should enter the operational workflow that can respond immediately, with a linked product follow-up when broader work is needed.
How long should a request stay in product intake?
A small product team can start with a five-business-day target for routine intake decisions while handling urgent requests immediately. The target should measure time to an explicit decision, not force the team to accept unclear requests to make the queue look fast.
Is a product backlog the same as a roadmap?
No. A product backlog holds accepted work candidates, while a roadmap communicates intended outcomes, priorities, and sequencing. Only a selected part of the backlog should support the current roadmap or near-term delivery plan.