Turning a Slack request into a decision-ready initiative

Here's a real shape of request, lightly disguised:

can we add a report that shows treasury exposure by entity? finance keeps asking

That's the whole thing. It feels actionable — there's a noun ("report"), a subject ("exposure by entity"), a hint of urgency ("keeps asking"). So a team picks it up and starts building a report. Six weeks later it's the wrong report.

The problem isn't the request. It's that a one-liner has to be shaped before it can be committed to, and most teams skip straight to building.

Five fields make an ask decision-ready

You don't need thirty fields. You need five — and you need to actually fill them:

1. Problem — what's broken today? "Treasury rebuilds exposure by hand in Excel every month-end and it's error-prone." Not "we need a report."
2. Outcome — what's true when this is done? "Treasury sees exposure by entity without touching a spreadsheet." Now you can tell when you've succeeded.
3. Owner — whose outcome is this? One name. If it's "finance," it's no one.
4. Scope — what's explicitly in, and just as importantly, out. "By entity, yes. By counterparty, later. Real-time, no."
5. Open questions — the things you don't know yet. This field is the point. A request with no open questions usually means you haven't looked hard enough.

Fill them with the person who asked

The leverage isn't in the fields — it's in filling them out loud, with the requester, before committing. Half the time the exercise changes the request: "oh, they don't need a report, they need the month-end exposure number to stop being wrong." The other half it surfaces an open question big enough to change the plan — the kind that's cheap to answer now and expensive to discover in UAT.

Then decide, on purpose

Once the five fields exist, the decision is easy and honest: commit it, shape it further, park it, or say no. What you never do again is commit to a sentence and find out what it meant in production.