Verified against ChatGPT · 2026-08-10
Triage a raw feature request into a decision-ready writeup instead of a wishlist entry nobody follows up on
Turns a customer's raw feature request into a structured triage note that separates the customer's actual underlying need from their proposed solution, checks it against similar past requests, and states what decision is actually needed next.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are triaging a customer feature request so it becomes something the product team can actually act on, not another line in a spreadsheet nobody revisits. RAW REQUEST "Can you add a way to export our reports directly to Google Sheets? Right now I download a CSV and re-upload it every week." REQUESTING CUSTOMER CONTEXT Mid-tier customer, 8 months tenure, has mentioned this twice in support tickets but hasn't escalated it as a blocker. SIMILAR PAST REQUESTS Three other requests in the past quarter for 'easier export' or 'automatic sync to spreadsheets', worded differently each time. ROADMAP CONSTRAINTS Engineering has one open slot next quarter and it's currently earmarked for a compliance-driven audit-log feature. DECISION NEEDED Whether this goes on the next roadmap review agenda as a real proposal or gets logged and revisited only if volume increases. Step one: separate what the customer asked for from what they actually need. Customers propose solutions, not requirements, and the literal request is often a workaround for a more specific underlying problem — state both explicitly, and note if the underlying need could be met by something simpler or already-existing that the customer doesn't know about, since a request that only needs an existing feature surfaced or explained is a very different triage outcome from a genuine gap. Step two: check this against the similar past requests you were given. State whether this is the same underlying need recurring (in which case volume and pattern matter more than any one customer's framing) or a genuinely different need that happens to sound similar on the surface — conflating the two leads to either under-counting real demand or bundling unrelated asks into one feature that satisfies neither. Step three: weigh this against the stated roadmap constraints honestly. Do not recommend building the feature just because a customer wants it — state what this customer or segment is worth, what the cost of not building it might be (churn risk, expansion blocker, competitive gap), and what it would cost to build relative to what's already committed, then make an actual recommendation rather than listing pros and cons and stopping. OUTPUT FORMAT 1. Stated request vs. underlying need. 2. Relationship to past requests (same need recurring / different need). 3. Recommendation: build, defer, or redirect to an existing feature — with the one-sentence reason. 4. The specific decision this triage note hands to whoever reads it next.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Separating the stated request from the underlying need is the single highest-leverage move in feature triage because customers reliably propose implementations, not requirements — a request for a Google Sheets export button is really a request for less manual re-entry work, and those are not the same design problem; GPT-5.1, if simply asked to triage a feature request, will tend to restate the literal ask rather than interrogate it, because the literal request is already a complete, well-formed sentence that looks done. Explicitly asking whether this matches past requests, rather than evaluating it in isolation, corrects a real weakness of one-off triage: any single request looks like low-priority noise, but the same underlying need phrased three different ways by three different customers is a real pattern, and a model not told to check for this will evaluate each one independently and understate the aggregate signal. The instruction to weigh cost against the stated roadmap constraint and produce an actual recommendation, rather than a balanced list of considerations, matters because a model asked for a triage note will often hedge into "there are trade-offs on both sides" as a safe default, which is not decision-ready output — a real triage note has to commit to a recommendation precisely so the person reading it doesn't have to redo the analysis themselves before acting on it.
What you get back
Stated request: a direct Google Sheets export button. Underlying need: eliminating a weekly manual CSV download-and-reupload workflow — the specific destination (Sheets) is incidental to that need. Relationship to past requests: same underlying need as three prior tickets this quarter, just worded around different destinations (Sheets, Airtable, 'automatic sync') — this is a pattern, not an isolated ask. Recommendation: defer building a native Sheets integration, but propose a scheduled-export-to-email or webhook feature instead, which would satisfy all four requests with one build rather than one-off integrations. Decision handed off: whether a generic scheduled-export feature should compete for the one open engineering slot against the planned audit-log feature.
Verified against
ChatGPT GPT-5.1 · 2026-08-10
Changelog
- 2026-08-10 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
