Which feature requests matter? A Caret filter for founders
Published August 10, 2026 · Hub: Feature prioritization hub
Your backlog is a graveyard of feature requests that each sounded reasonable on the day they arrived. Sales wants parity with a competitor. A champion customer wants a workflow built around their org chart. Support wants the ticket that would close the most tabs. Someone asks what ships next—and “customers asked for it” is doing too much work as a justification.
A request is not a requirement. Treating the inbox as a to-do list turns the product into a compromise bundle—especially when Cursor can scaffold the compromise by Friday.
Use this filter to decide which requests deserve engineering time. Run it in Caret so each ask stays tied to the job, the evidence, and a yes or no you can reopen later. Hub: feature prioritization. Companions: how to prioritize features, should I build what customers ask for?.
Why common feature-request fixes fail
First-in, first-out. Age is not importance. Old requests often survived because nobody wrote a clear no.
Revenue veto. A large deal asking for a feature is a signal, not a mandate. Ask whether building it helps the next ten ICP customers—or only this contract.
Competitor bingo. Parity lists feel strategic. Pay parity tax when win/loss evidence says you lose without it—not when a competitor got a press mention.
Scoring the request text. RICE on “Add Salesforce sync” without a job, ICP filter, or constraint produces confident nonsense. Score survivors, not the raw inbox. See RICE.
Paste into Cursor. Dropping the raw request into an agent skips the filter. Fast delivery of the wrong solution is still the wrong solution.
The Caret filter: request as hypothesis
Every request lands as a capture. The filter decides whether it becomes an opportunity with a decision brief—or a parked/no note next to the same capture.
Gate 1: Capture, then rewrite as job + evidence
Before anything enters a ranked list, record in the project:
- Proposed solution — what they asked for (keep it)
- Underlying job — what they were trying to accomplish
- Evidence — who, how often, which channels, what breaks if ignored
If you cannot name the job, the request is not ready to prioritize—it needs a clarifying conversation or discovery. Ask against project context can help: “Do we already have captures about this job from other accounts?”
Gate 2: ICP and revenue as evidence—not automatic yes
| Filter | Pass | Fail / park |
|---|---|---|
| ICP fit | Recurs for target segment | One off-ICP customization |
| Revenue link | Tied to expansion, churn risk, or repeated deal blockers and ICP | Single deal hostage feature |
| Pattern | Multiple accounts / channels (insights) | One loud champion |
| Strategy fit | Strengthens wedge or table stakes for ICP | Pulls product into a new category by accident |
Revenue matters as intensity of pain—not as a veto that overrides ICP.
Gate 3: Constraint check
Name the constraint this cycle: activation, retention, monetization, reliability, or differentiation. If the request does not reduce that constraint, label it later or no even when the account is friendly.
Gate 4: Smallest useful effort
Estimate the smallest change that tests whether the job matters—not the full vision in the request email. Many “must-have platforms” collapse into a single workflow fix or integration slice.
Gate 5: Promote survivors only
Promote passing requests to opportunities. Rank that shortlist—impact, evidence strength, effort, risk of inaction, or a light RICE pass. Write a product decision brief for Now: what, why, evidence links, non-goals, success check. Hand the brief to coding agents; leave the full inbox out of the sprint.
Broader feedback triage: how to prioritize customer feedback. Conceptual loop: how Caret works.
Worked example: five asks, one Now bet
Inbox (each item captured in Caret):
- Enterprise A: custom approval chains matching their org chart
- Three mid-market ICP accounts: “notify us in Slack when a job fails”
- Community: dark mode (often)
- Sales: Salesforce two-way sync for one stuck deal
- Churn interview: “we left because failures were silent until the customer emailed us”
Constraint: reliability / trust for ICP mid-market.
Insights: Slack-on-failure and silent-failure churn collapse into one theme. Approvals, dark mode, and Salesforce stay separate.
Filter pass:
| Request | Job | ICP | Constraint | Outcome in Caret |
|---|---|---|---|---|
| Custom approval chains | Match their org politics | Weak | No | No / parking with note on capture |
| Slack on job failure | Notice critical failures in time | Strong | Yes | Now opportunity + brief |
| Dark mode | Comfort / preference | Mixed | No | Parking |
| Salesforce two-way | CRM as system of record | One deal | Partial | Needs pattern; not Now |
| Silent failures (churn) | Same as Slack theme | Strong | Yes | Reinforces Now opportunity |
Brief for agents: Ship failure notifications (Slack or in-product)—not org-chart approvals, not full Salesforce sync. Evidence: three ICP captures + churn quote. Success: time-to-notice for failed jobs; support volume on “we didn’t know it failed.”
No note (approvals): “Custom approval chains optimize one enterprise’s structure. Constraint is reliability for ICP. Shipping failure alerts; revisiting workflow customization only if multiple ICP accounts show the same job.”
Mistakes that restart the inbox factory
- Promoting Salesforce sync because the deal is large while the reliability pattern is clearer and cheaper
- Filing “Slack alerts” and “silent failures” as unrelated tickets instead of one insight
- Using RICE before ICP and constraint gates
- Soft-parking everything as “roadmap” so sales keeps promising dates you never set
- Opening Cursor on the raw request text without a brief
Where the filter still fails
You can gate requests in a spreadsheet for a while. Then sales reopens the parked items, the written no is missing, and “customers asked for it” is doing the prioritization again.
Caret keeps each ask next to the job, the gates you ran, and the yes or no—so the next five requests get filtered against memory, not against whoever spoke last.
Start a free 7-day trial—no credit card—and run this week’s asks through a project. Or see what Caret is first.
FAQ
How do you prioritize feature requests?
Capture the request with context, rewrite it as a job, filter by ICP and constraint, then promote survivors into a decision brief—not the full inbox into the backlog.
Is a feature request a requirement?
No. A request is one proposed solution. Prioritize the underlying job; keep the suggested fix as a hypothesis until evidence in product memory confirms it.
When should you say no to a feature request?
When it fails ICP fit, does not reduce the active constraint, lacks pattern evidence, or would displace a clearer trajectory-changing bet. Record the no next to the capture.