Backlog size is inversely proportional to how often we talk to customers
A claim that “the size of your backlog is inversely proportional to how often you talk to customers” prompts wide-ranging debate about product management practice. Many argue that oversized backlogs are usually a sign of weak prioritization, fear of saying no, and dumping every idea into tickets, while others note that frequent customer conversations can actually grow the backlog but make priorities sharper. Participants explore strategies such as separating raw feedback from actionable work, aggressively pruning or time-limiting tickets, and relying on sales and support insights to focus on real customer problems rather than a grab bag of requested features.
Backlog size vs. talking to customers
- Many disagree that backlog size is inversely proportional to customer contact.
- Some say: frequent customer conversations generate more requests and backlog items; the benefit is smarter prioritization, not a smaller list.
- Others argue: big backlogs tend to be stale “graveyards” of assumptions; talking to customers frequently exposes more valuable work and makes old tickets obviously obsolete.
- Consensus: the relationship depends heavily on context (early startup vs. mature product, type of product, team discipline).
What should go in a backlog?
- One camp: backlog should only contain reasonably short‑term, actionable work; long‑range ideas belong in lighter-weight docs or separate tools.
- Another camp: keep a single searchable system; use tags, issue types, statuses (e.g., “parked”) and auto‑closing to manage scale.
- Some explicitly treat the backlog as a diplomatic “yes, we wrote it down” tool; others call this cultural dysfunction and emphasize the PM’s job is to say “no” clearly.
- Several recommend separate flows:
- Raw feedback / customer problems.
- Product discovery / opportunity trees.
- Delivery tickets for work that’s actually going to happen.
Customer input vs. feature requests
- Strong theme: customers should inform you about problems, not dictate UI or solutions.
- Risks called out: reactive building of every request leads to incoherent, option-heavy products.
- Recommended: synthesize multiple requests into root problems and design minimal, general solutions aligned with product vision and business goals.
Tools and processes
- Mentioned approaches: Jira + Product Discovery, Productboard, specialized feedback aggregators, public GitHub issue trackers, personal notes.
- Backlog hygiene techniques: regular grooming, aging out old issues, WIP limits, “short-iteration-only” team backlogs, t‑shirt or value/cost sizing, prioritization frameworks (e.g., RICE, opportunity‑solution trees).
Organizational and cultural factors
- Large, unhealthy backlogs often linked to: weak product orgs, PM turnover, fear of saying no, and unmanaged input from sales/support.
- Multiple comments stress mining sales, support, and CS as rich sources of structured customer insight.
- Observing real users (and sometimes impersonating accounts) is seen as invaluable for UX, but impersonation raises serious security, privacy, and compliance concerns in some domains, requiring strong auditing and controls.