Start with one job your staff need to finish. Describe what sets it off, who handles it, what a good result looks like and where things get awkward. That gives a developer something useful to discuss, even before you know what to build.
“We need a better booking system” is a perfectly reasonable place to start. The next useful question is what happens when somebody tries to book.
Before your first conversation with a developer, describe one piece of work from the first request to the finished result. Bring the awkward bit too. You can explain that in ordinary language, even when you have no idea how the software should be built.
Imagine a fictional training company. A customer emails asking for two places on a course. A coordinator checks availability, answers the customer and records the booking. If the course is full, somebody has to decide what to offer instead.
That is enough to start a useful brief. “Build a portal with a dashboard” leaves much more for the developer to guess: who uses it, what they are trying to finish and what counts as a booking.
The UK Government's guide to understanding a problem before building a service recommends examining users, their wider journey and constraints. Its government delivery process is specific to that setting. The useful starting question for our training company is simply: what does it take to get this customer onto a course?
Ask the person doing the job to walk through a recent example. Write down what you observed. Then describe what you want to work differently. In our fictional company, the notes might look like this:
The coordinator checks the course spreadsheet, replies by email and types an accepted booking into the calendar. We have seen a place offered while another reply was still waiting.
The coordinator should see which requests still need an answer and decide whether to offer a place. We still need to agree when a place counts as taken.
The first part describes current work. The second proposes a change and leaves a decision visible. This distinction matters when staff have different habits: one colleague may reserve places while waiting for a reply, while another may leave them available. Record both versions before asking the developer to turn either into a rule.
For the course enquiry, a practical outline could contain these notes:
These are proposed notes for the example, not settled rules for every training business. Ask what “agreed booking” means in yours. Does a place count as taken after the offer, the customer's acceptance or payment? A question written down is something you can resolve together.
Add a small worked example using invented records: Course A on 12 May has one available place; Enquiry B asks for two. Show the outcome you would expect, including who makes the decision. The developer can then ask about something concrete.
Use invented names and records where they explain the work. For real samples, share only what you are authorised to share, remove unnecessary personal or confidential details, and agree a suitable way to provide them.
Must have: a coordinator must be able to see requests still waiting for an answer. Explain the reason: otherwise somebody has to search through the shared inbox to find unfinished work.
Idea to discuss: customers could choose another course date themselves. Keep that as a possibility until you have considered the work and who it would help.
Open question: when should a place be reserved, and who can release it? Name the training manager as the person who can decide, rather than quietly letting the developer choose a business rule.
Include genuine limits too. Perhaps the existing calendar must stay, only certain staff may see customer details, or a particular course must be supported before a known date. Say which limits are firm and why. If a date or budget is still a preference, label it that way.
“Easier to use” needs an example. For this company, the coordinator should be able to follow an enquiry through to its answer and find every request still waiting. Use the normal booking and the one-place-left case to discuss what the finished work must demonstrate.
You can also record a current problem you want to measure, such as how often staff search several tools for an unanswered enquiry. State what you have observed and what still needs checking. Agree any target after establishing what you are comparing.
Give the brief to the people who do the work before sending it on. They can point out a missing step or explain why an apparent shortcut would cause trouble. Leave the unresolved points in the document, with someone responsible for answering each one.
We build custom business software. If you want to discuss a project with us, bring a job like this: what happens now, what you want to change, an example and the questions you still have. Scope and commercial terms can then be discussed around the work. The brief starts that conversation; the technical investigation and design still need doing.
You can start by describing the job, the people doing it, the tools they use and the result you need. Technical design can follow investigation. Record a genuine technical constraint if you know it, and explain why it matters.
Describe the versions you have actually seen and ask the people involved why they differ. Mark which differences are necessary and which still need a decision. Name someone who can settle that decision.
Write the question, what you already know and who can help answer it. For example: “When should a course place count as taken: when offered, accepted or paid for?” Keep that separate from agreed requirements.
Last newsletter: making more money from a subscription site or app you already own.
The one before: how to spot AI nonsense from real success stories.
Interested?
Weekly Or just let us know and we'll adjust it for you. Sounds good?
