1. What problem are we solving?

Describe the current situation before proposing a solution. Where does work slow down? What is repeatedly copied, checked, or corrected? Which decisions are difficult because the right information is missing?

For example, ‘we need a dashboard’ describes a possible interface. ‘Our operations team spends each morning combining three reports before it can assign work’ describes a business problem. The second statement leaves room to consider reporting changes, an integration, an existing tool, or custom software.

2. Who will use it, and what do they do today?

Identify the people who will use the system, the tasks they perform, and the conditions they work in. An administrator reviewing exceptions needs a different experience from a field worker entering a quick update on a phone.

Map one real workflow from start to finish. Include handoffs, approvals, spreadsheets, and the workarounds people rely on. Talk with the people doing the work so the brief reflects actual needs rather than assumptions.

3. What would a successful first release change?

Choose a small set of observable outcomes. A team might want to reduce duplicate entry, make request status visible, or complete one workflow without moving between several tools. Record a baseline where possible, then agree how the change will be assessed.

Separate essentials from useful later additions. A feature earns its place in the first release when it is necessary for the chosen outcome, not simply because it could be included. This makes trade-offs easier when scope, time, or budget needs to change.

4. What must the software work with?

List the systems, data sources, and people the new tool depends on. Confirm whether integrations are available, who can authorize access, and which system is the source of truth. Unclear dependencies can change a project’s scope substantially.

  • Data: what will be collected, imported, retained, or deleted?
  • Access: who can view, change, approve, or export information?
  • Integrations: which systems must exchange information, and how often?
  • Constraints: what security, contractual, accessibility, or operational needs must be reviewed?

5. Who will own it after launch?

A useful brief covers the operating life of the tool, not just delivery. Agree who will manage accounts, review feedback, maintain integrations, and decide which improvements come next. Clarify hosting, support, documentation, and handover expectations before work begins.

At XORA Technology, these are the kinds of questions we use to connect a business challenge with a practical technology direction. Bring the problem, the people involved, and the constraints you already know. A clearer brief can grow from there.