How to write a development request that moves fast
A development request is a need expressed with enough context for a team to scope it without calling you back: who has the problem, what they are trying to do, what it changes, and how to check it is done. For clients of a subscription team: four elements, three examples, and how to split.
“We should be able to export the data.” Nine words, and already three questions: which data, for whom, in what format? By the time those questions go back and forth, the request has lost two days without a line of code being written. In a model where a team delivers your requests one at a time, speed is not decided in the code. It is decided in the request.
A development request is a need expressed with enough context for a team to scope it without calling you back, and enough freedom for them to choose the best way to build it. Neither a specification document nor a one-line message. Here is how to write it, how to split it, and how to keep it moving once dropped. The examples come from Figue Unlimited; the principles hold for any team.
No mandatory template: at Figue, a forty-second voice note can be better than a three-page document. What matters is that four pieces of information are there, in any order.
01
Who has the problem
A customer, a member of your team, you. “The sales team” is not a user; “Léa, who prepares quotes every morning” is. That detail changes screen choices, shortcuts and priorities.
02
What they are trying to do, and what stops them
The action, not the feature. “Finding a customer's orders to answer a complaint, and today she opens three tabs” says more than “add a filter”.
03
What changes if it is done
Time saved, an error that disappears, a customer who stops chasing, a sale that closes. It is what lets the team sometimes propose a simpler solution than the one imagined, and lets you decide whether it deserves its place in the queue.
04
How you will know it is done
One sentence you can check on the preview. “Léa finds a customer's orders by typing their name, from the home page, without leaving it.” If you cannot write it, the request is not ready yet.
03
Three examples: before, after
The same needs, written twice. On the left, what we often receive; on the right, what goes into production without a single back-and-forth.
The same request, before and after
Situation
Before
After
An export
We should be able to export the data.
Marc, our accountant, re-enters invoices into his software every month. He needs an export of the month's invoices, as CSV, with number, customer, amount and VAT, from the Invoices page. He will know it is done when the file opens in his tool without edits.
A notification
Add notifications.
Customers do not see their order has shipped and write to support. Send the customer an email when the order moves to Shipped, with the tracking number. It is done when a test customer receives the email within a minute.
An AI agent
Put AI in support.
Support receives 40 emails a day, half of them order-tracking questions. An agent reads each email, answers tracking questions on its own using the order data, and forwards the rest to a human with a summary. It is done when a week of test emails is sorted with no forwarding error.
Notice what the “after” versions do not say: neither how, nor with what. They say who, what, why, and the final test. Everything else is scoping, and scoping is the team's job.
04
How do you split a request so it moves fast?
In a queue handled one request at a time, a three-week request blocks everything else for three weeks. The same request split into five three-day steps delivers something verifiable every week, and lets you reorder what comes next between two steps. Splitting is not a constraint of the model; it is its main lever.
The rule we apply at Figue: a step must be deliverable on its own, testable on its own, and useful on its own, even if the rest never comes. A client portal splits into “log in and see my orders”, then “download my invoices”, then “change my address”. Not into “database”, “API”, “screens”.
A dropped request goes through three states. It waits in the queue, it is in progress, or it waits for something from you. That third state is the one that costs the most time without anyone noticing.
At Figue, a request waiting on your answer is marked “waiting on you” and does not take a slot: the team moves to the next one. But it is also the moment your request is not moving. A question left for three days is three more days, whatever the team's speed.
“A request's turnaround is the build time plus the time you take to answer. The first depends on us. The second, on you.”
Three habits that make the difference: answer scoping questions the same day, approve previews within forty-eight hours, and provide access (accounts, APIs, test data) when you drop the request rather than when the team asks for it.
06
Dropping from your AI assistant: the request without a form
Since 2026, Figue Studio connects to AI assistants through MCP. In practice: you tell Claude or ChatGPT the need the way you would tell a colleague, the assistant shapes it with the four elements above, and drops it in your queue. You reread, adjust, done.
It does not replace scoping by the team; it prepares it. The assistant asks the missing questions before the request leaves, and saves you the next day's back-and-forth. It can also read the state of your queue, reorder it, and tell you what is waiting on you.
No. A spec describes a solution; a request describes a need and a verifiable outcome. Scoping, which turns one into the other, is the team's job. If you already have mockups or constraints, attach them, they help; but do not hold a request because they are missing.
How many requests can I drop?
As many as you want. The queue has no limit. What is limited is the number of requests in progress at the same time: one per slot. Drop everything that comes to mind, then order it.
What happens if my request is too big?
The team proposes a split into deliverable steps during scoping, and you choose the order. A big request is split first. If it amounts to a whole product, we tell you so and propose a quote.
Can I drop a bug as a request?
Yes, and it is the same format: who, what they were trying to do, what happened instead, and how to reproduce. A screenshot or a video is worth ten lines. A blocking bug goes to the top of the queue if you decide so.
What if I do not know what I want?
Drop the problem without the solution: “customers abandon checkout, I do not know why”. The first step will be to instrument and look; the second will follow from what we see. It is a request like any other.
