Who this is for
PMs and founders fielding feature requests who want the underlying problem captured, not just the literal feature a user happened to ask for.
The moment this saves you
A user asks for a button, I log 'add a button,' and three months later we build the literal button instead of solving the actual problem they had, because the why never made it into the ticket.
See it work
Messy spoken thought in. A clean, structured artifact out.
Feature request from a customer call. The account manager at Brightline asked if we could add a way to bulk-edit tags. But digging in, the real problem is they have like 5000 contacts mistagged from a bad import, and they're editing them one by one which is brutal. So the request is bulk tag editing but the problem is really cleanup after a messy import. This is the third customer to hit this. Probably medium-large effort. The workaround they're using now is a spreadsheet export and reimport which is awful.
Feature request: Bulk-edit tags
- Requested by: Account manager at Brightline (3rd customer to ask)
- Literal ask: A way to bulk-edit tags
- Real problem: ~5,000 contacts mistagged from a bad import, currently fixed one by one
- Current workaround: Spreadsheet export and reimport (painful)
- Rough effort: Medium-large
- Note: The deeper need is cleanup after a messy import, not just bulk editing
The workflow
Record a voice note
Hit the hotkey and talk, no formatting, no typing.
Tag it with this context
Contextli shapes your words into the structured output above.
Find it later
Everything's searchable and organised by context.
Pull it into Claude or ChatGPT
Bring your contexts straight into your AI tools with the Contextli MCP.
Your raw recording and transcription stay on your device, so you can always go back to the original.
The prompt behind this context
I'm going to describe a feature request from a user or customer. Turn it into a structured feature brief: a bold Title (the requested feature), then labeled lines: Requested by (who, and how many have asked if I say), Literal ask (what they literally requested), Real problem (the underlying need, which is the point of the brief), Current workaround (only if mentioned), Rough effort (only if I estimate), and Note (any deeper insight I add). Separate the literal ask from the real problem clearly. Don't invent customers, counts, or effort. If I describe more than one request, make one brief each. Output only the brief(s).
Make it your own. This is a starting point. Once it's in Contextli, tweak the instructions so the output comes out exactly how you like it.
Use this context
One tap adds it to your clipboard. Open Contextli and paste to add it.
Next, open Contextli, Contexts, Import, paste.
Make it your own. This is a starting point. Once it's in Contextli, tweak the instructions so the output comes out exactly how you like it.
Your raw recording and transcription stay on your device, so you can always go back to the original.
Related contexts
Product Demo Feedback
You watch a user try your product and see exactly where it breaks down, then the meeting moves on and the insight gets diluted. Speak what you observed right after. You keep the raw signal, the confusion, the workaround, the delight, so the team fixes the real thing.
User Research Observation
Right after a user interview, your memory starts smoothing the awkward truths into what you hoped to hear. Speak it now, what they actually said and did, where they got stuck. You get a clean observation note that keeps the real signal, not your wishful version of it.
Product Bug Report
You just watched something break mid-demo. Don't lose the repro hunting for the tracker. Mutter what happened, what you clicked, what you expected, and walk away with a report engineering can actually act on.