--- title: "How to write a development request that ships in days" description: "A simple template for feature requests and bug reports your team can ship fast: the problem, who has it, and what done looks like." url: https://www.fluff.software/guides/how-to-write-a-good-request/ updated: 2026-10-23 publisher: Fluff Software --- # How to write a request that ships quickly. A simple template for writing feature requests and bug reports your development team can ship fast: the problem, who it’s for, what done looks like, and what to leave out. By **Scott Gulliver**, founder of Fluff Software Published 23 October 2026 _Image: A workflow diagram, product brief and user goals sketched out_ ## Short answer Say what the problem is, who has it, and what done looks like. Add one example and anything that’s out of scope. A request a developer can start without asking a question ships days faster than one that needs a conversation first. ## Why does request quality matter so much? Every unclear request starts with a round of questions. Each round trip costs a day if people are busy. Clear requests skip that, so the same queue ships noticeably more. ## The template **Problem:** what’s going wrong or missing, in one or two sentences. **Who:** which users hit it, and how often. **Done looks like:** how you’ll know it works, written as things you’ll check. **Example:** a screenshot, a link, a real record or a sketch. **Not this time:** anything tempting that should wait. ## A worked example **Weak:** “Reports need exporting.” **Strong:** “Problem: account managers copy the monthly usage report into Excel by hand every month, which takes about an hour each. Who: the four account managers. Done looks like: a Download CSV button on the usage report, exporting exactly the columns on screen, respecting the current filters, with dates in DD/MM/YYYY. Example: screenshot attached. Not this time: scheduled email exports.” The second takes two minutes longer to write and saves a day of back-and-forth. ## Describe the problem, not the solution “Add a dropdown here” might be the right answer. It might also be that a dropdown is the third-best option and a default value would solve it outright. Describing the problem lets the team bring judgment to it. That’s a large part of what you’re paying for. ## Keep requests small enough to ship If a request has “and” in it three times, it’s probably three requests. Smaller requests ship sooner, get reviewed faster and are easier to roll back if something’s wrong. ## Bug reports: the four things that matter - What you did, step by step. - What you expected. - What happened instead, with a screenshot or error message. - Where: which browser or device, which account, roughly when. If it’s breaking production for users right now, say so in the title. Urgent production bugs jump the queue. ## Questions Do requests have to be technical? No. Plain English is best. The team turns it into the technical plan; your job is to describe the problem and what done looks like. What if I’m not sure what I want? Say so, and describe the problem. Working out the right solution is part of the job, and on Embedded Plus the monthly planning session is a good place for the bigger questions. ## Keep reading [How unlimited requests work Why development subscriptions work one task at a time per track, how that keeps ‘unlimited’ fair, what counts as one request, and how to get more done faster.](https://www.fluff.software/guides/how-unlimited-requests-work/) [UAT without the bottleneck How to review and sign off development work quickly: a daily slot, clear acceptance checks, one decision-maker and feedback that can be acted on first time.](https://www.fluff.software/guides/uat-without-the-bottleneck/) [How to clear a software backlog A practical method for getting a software backlog under control: delete ruthlessly, sort by value and risk, break big items down, and protect a steady release rhythm.](https://www.fluff.software/guides/how-to-clear-a-software-backlog/) --- Fluff Software, a senior product team embedded in your business. Book a call: https://www.fluff.software/contact/ or email contact@fluff.software. Agents: see https://www.fluff.software/llms.txt and https://www.fluff.software/AGENTS.md.