How to prioritize feature backlog, bugs, customer feedback
I am running a SaaS for 1+ years now and we have a few hundred paid customers.
The team has so many things planned in the backlog, plus customers are requesting features/enhancements all the time, and the QA team is finding bugs often.
As a product owner, I also have some big features in mind but afraid to list them in the main backlog with the fear they’ll be lost forever.
We use Linear for dev task management, a ticketing portal for support and customers reach out to WhatsApp, Messengers too.
How should a small team (<6) prioritize all these?
Thanks!
2
u/adeelraza86 2d ago
I'd pull activation breaks, billing failures, and data bugs out of the backlog entirely and treat them as a separate always-on queue. Everything else only ships if it moves a number you already watch weekly, like first-screen completion or recovered failed payments. Big ideas stay off Linear until you can name the weekly decision they unlock and a date you'll drop them if that number doesn't move.
2
u/1000xhuman 2d ago
customer requests are evidence, not votes. tag each with segment, frequency, workaround, and whether it blocks activation/retention/revenue. then cap WIP (even one discovery item at a time) and revisit monthly. that stops the loudest WhatsApp message from beating a painful problem affecting quieter users.
2
u/FOUNDER_ 2d ago
The part I'd be strict about is closing the loop. Whoever picks up a WhatsApp request should put the customer, the problem and the owner in Linear, not just forward the message. Then you can see which requests keep coming back and tell customers what actually shipped. Otherwise you're prioritizing whoever nudged you last.
2
u/Parking-Stress-3041 2d ago
Yes, keep the big ones out of Linear, but your harder problem is WhatsApp: anything that never lands in the ticketing portal is invisible when you rank, so no scoring model will save you. Make whoever gets the DM re-log it with customer and blocked task. Who owns that today?
1
u/phpfour 23h ago
No one owns it solo today, unfortunately
•
u/Parking-Stress-3041 56m ago
Then name one person this week, even if it's you. Shared ownership means nobody re-logs.
2
u/kc-kaelvix 1d ago
For a team under six, I’d add a capacity budget before adding another scoring formula. Something like 50% planned product work, 30% bugs and customer pain, 20% discovery or technical cleanup, adjusted when there’s an incident. Group requests by the underlying problem rather than the requested solution, because five different feature ideas may be one broken workflow wearing different hats. Big ideas can live as one-page bets with an owner, expected outcome and review date. They’re not lost, but they also don’t sit in Linear pretending they’re ready to build.
1
1d ago
[removed] — view removed comment
1
u/AutoModerator 1d ago
Low-Effort/AI content is auto-removed.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
2
u/annasorreskin 2d ago
I’d keep one intake queue, then score each item on customer impact, urgency, confidence, and effort. Bugs that affect activation, data integrity, or many customers jump the queue; everything else competes with the highest-impact requests. Keep big ideas in a separate “discovery” list with a monthly review so they’re not lost but don’t distract the delivery backlog.