← Back to Work

05 / PRODUCT OPERATING MODEL

Fixing product intake before fixing the backlog

The backlog wasn't the problem. It was where the problem became visible. I redesigned how work entered Product so we could make better decisions before anything ever reached the backlog.

Jira
Slack
Docs
Conversations
Tribal knowledge
One Front Door
Structured Slack intake
Linear
Decision + status
Role
Lead Product Manager
Company
Cardata
Focus
Product Operations · Prioritization
Outcome
Structured intake · Cleaner backlog
Hundreds
of stale tickets triaged from the backlog
1 front door
replacing five scattered intake channels
SLAs
introduced by severity, with visible status

THE PROBLEM

Requests, bugs, sales asks, operational issues and internal ideas were coming into Product through Jira, Slack channels, documents, conversations and informal shoulder-taps. Priorities could change quickly without enough context, and there wasn't one reliable place to understand what had been submitted, what mattered, or what was happening next.

That created predictable problems: things got lost, duplicates accumulated, bugs competed with feature ideas, and the loudest stakeholder could suddenly become the highest priority. Often the missing piece was simple: why did this need to move ahead of everything else, who was affected, how serious was it, was there a workaround?

Jira
Slack
Docs
Conversations
Tribal knowledge
Backlog noise
shows up here

THE QUESTION WE NEEDED TO ANSWER

What information do we need at the moment someone reports a problem or idea?

THE EVIDENCE

Duplicate requests
Conflicting priorities
Lost context
CS / Support escalations
Stale backlog tickets
Tribal-knowledge dependency

We could have cleaned up Jira and called it an improvement. It wouldn't have lasted. If bad information kept entering Product, we'd eventually recreate the same backlog. The real question was upstream of the backlog entirely.

Key Decision

Cleaning a backlog treats the symptom. Improving intake changes the system that creates it.

Downstream

Clean up the backlog

  • Immediate relief, but the same noise returns
VS
Chosen

Upstream

Fix intake

  • Slower to feel, but changes what enters the system

WHAT I DID

1
Diagnose upstream
Traced where backlog noise actually came from.
2
Design one front door
Replaced five channels with a structured path.
3
Co-design with heavy users
Built with the people submitting most often.
4
Add transparency
Made status visible after submission.
5
Triage the backlog
Cleared stale tickets once intake was fixed.

HOW IT WORKS

1 Front Door
Slack command
Structured Context
What / Who / Severity / Context
Linear
One record
Decision
Priority with context
Status
SLA + updates

One front door

Rather than asking people across the company to learn how Product wanted tickets written, we created a central Slack intake experience. A simple command triggered a structured template that captured what happened, who was affected, severity and relevant context, then routed the submission into Linear. The person reporting a problem never needed to know how we organized it on our side.

Making Product less of a black box

Better intake solved only half the problem. People also needed to know what happened after they submitted something. A dedicated Product Slack channel communicated updates, releases and bug status, paired with clearer SLA expectations by severity. When someone knows an issue has been seen and understands its status, they're far less likely to escalate the same problem through another channel.

Submit
Seen
Status
SLA / update

THE TRADE-OFF

ChoseGave upWhy
One central Slack intake front door instead of team-specific processes Flexibility for teams already used to their own channels and lists The goal was to make reporting easy enough that people would actually use it instead of working around it
Aggressive backlog triage, removing stale tickets rather than preserving them Completeness: a full historical record of every request ever filed A clear view of what still mattered beat an exhaustive but noisy backlog
Transparency infrastructure: an updates channel and SLAs alongside the intake fix A narrower, faster-to-ship scope focused on intake alone Better intake only solves half the problem if people don't know what happens after they submit

What Changed

Hundreds
of stale items triaged from a backlog that had accumulated for years
Context, not just urgency
requests arrived with the information priority conversations actually needed
Structured intake
created the model the organization had been missing

WHAT I LEARNED

Cleaning a backlog treats the symptom. Improving intake changes the system that creates it.

My Role: Lead Product Manager

Owned

Product operations, intake design, prioritization, workflow design, customer discovery, stakeholder communication, cross-functional process improvement.

Partnered with

Heavy users of the intake process, customer-facing teams, and internal requesters and stakeholders.

Some product, customer and implementation details have been generalized to protect confidential information.

Next Case Rebuilding healthcare software without rebuilding everything
→