ThumbsumFeature request management, end to end: from intake to shipped and told
Every feature request lives a life: it is born somewhere inconvenient, gets counted or lost, gets weighed or ignored, becomes a promise or a ghost, ships or dies, and is either announced or forgotten. Most teams manage two or three stages of that life and improvise the rest — and each unmanaged stage has a characteristic failure that looks, from the outside, like "we're bad at prioritization."
Here is the whole lifecycle, stage by stage, with the failure mode and the fix for each. Tool-agnostic first; where Thumbsum automates a stage, it says so at the end of the section.
Stage 1: Intake — get everything into one pipe
Requests are born in emails, support chats, sales calls, tweets, and occasionally on the feedback board you built for them. The failure mode is fragmentation: each channel becomes its own partial truth, and the request that arrived by email never gets counted with its board twins.
The fix is a rule, not a tool: every request, regardless of door, lands in the same place within a day. Forward the email, paste the call note, log the tweet. A public board helps here twice over — it gives customers a self-serve door, and a search-first board deflects duplicates at entry: a customer who types their problem and sees "planned, shipping in February" votes instead of filing post #14.
(Thumbsum: board, email intake address, and CSV import all feed one pipeline; every item is analyzed identically on arrival.)
Stage 2: Understanding — extract the ask
A request title is an envelope; the ask inside is the unit that matters. "Jira integration" pushing your data into Jira and "Jira integration" pulling Jira data in are different products sharing an envelope. The failure mode is topic-level thinking: requests get grouped by keyword, decisions get made about a blur, and the shipped thing satisfies half its requesters.
The fix: for every request, write the concrete ask in ten words or fewer, in terms of what the user could do afterward. If you cannot, you do not understand the request yet — which is itself useful to know, and a fine reason to reply with a question.
(Thumbsum: the ask is extracted automatically on arrival and shown everywhere the request appears.)
Stage 3: Deduplication — group by intent
"Add SSO", "sso when??", and "SAML support please" are one demand wearing three outfits. Ungrouped, they undercount your most-wanted work by exactly the amount it is wanted. The failure mode compounds quietly: the more popular a request, the more scattered its duplicates, the more undercounted it is — your board systematically hides your best opportunities.
Group by the ask from stage 2, not by words. And count people, not posts: one customer filing three duplicates is one voice.
Stage 4: Weighing — put money next to every group
The stage most teams skip, and the one that changes everything. For each group: total monthly revenue of the people asking, the largest single account among them, the count of distinct paying accounts, and the age of the oldest unanswered voice. Dollars, not points.
The failure mode of skipping it is governance by loudness — votes and recency deciding what a business builds. You do not have to obey the money; you do have to know it. The full method, thresholds included, is in the prioritization system.
Stage 5: Deciding — four buckets, four moves
A weighted group is a decision waiting to be typed. Every group is in exactly one state: an unhappy payer awaiting a reply (answer today, before building anything), demand past your threshold (plan it, with a date), shipped-but-untold (email the askers), or a slipping promise (move the date or start, never silence). Keep the active set tiny — five items — and review twice a week. The failure mode here is the fifty-row "prioritized backlog": a ranking nobody rereads is a mood diary.
Stage 6: Promising — dates in public
When a group gets planned with a date, that date belongs on the public roadmap and the requesters deserve to hear it. Promises retain the customers that silence loses. The failure mode is the stale roadmap — dates that quietly slipped without anyone being told, which documents your unreliability in public. Rule: a promise may move, but it may never just rot; rescheduling with a note beats an untouched lie.
Stage 7: Shipping and telling — close the loop
The stage with the best return-per-minute in all of product work, and the most skipped: personal emails to everyone who asked, then a changelog entry that credits them. The mechanics, scripts, and why it compounds are the subject of their own guide — the short version is that "shipped but nobody told" should count as unfinished, and that requesters who hear back file better requests forever after.
The meta-failure: systems that need your best week
Read back through the failure modes: fragmentation, topic-blur, undercounting, loudness-governance, backlog-rot, stale promises, open loops. None of them come from bad judgment. All of them come from the same source — every stage above is a small recurring manual task, and manual systems fail during crunch weeks, which is precisely when feedback surges.
That is the honest case for automating the mechanical stages (1–4, 6's bookkeeping, 7's remembering) and keeping only stage 5 — the actual deciding — for yourself. It is the design thesis behind Thumbsum, and it is equally the design thesis behind a well-maintained spreadsheet. Pick either. The lifecycle does not care what runs it, only that something does — because every request is living its life right now, with or without your management.