A useful project brief explains who needs help, what they need to do and what a successful result looks like. A few clear paragraphs, a rough sketch and a concrete example give us a place to start.
I use that context to ask questions and define the work with you before proposing a scope and timeline. This guide shows what to include, using a fictional booking product as an example. The same questions apply to a new app, a bot or a feature in an existing product.
Start with the problem and the person
Tell me who will use the product, what they are trying to do, and how they do it today. For our booking example: “Customers message our team to request a time. Staff check a shared calendar, send a payment link and confirm each booking manually.” That explains the work the software needs to support.
Include the result you want to see. That might be fewer manual steps, a working booking flow, or giving customers a way to track an order. If you have a measurement today, share it. If you do not, describe what a successful outcome would look like.
Walk through one important task
Choose a task that matters and describe it from beginning to end. For example: a customer chooses a service, selects an available time, pays, and receives a confirmation. Then an administrator can view or cancel the booking.
Mention the exceptions too. What happens if payment fails, the customer changes their mind, or two people choose the same time? You do not need to solve every case yourself. Flagging the question helps us discover the work before committing to a timeline.
Decide what the first release needs
Separate what is required for the first useful release from what can follow later. A booking product might need one payment provider at launch, while subscriptions and referral rewards can wait. Your priorities help me propose a release that is useful on its own.
A feature name can hide several decisions. For “customer accounts”, tell me who can register, what they can see, whether staff have different permissions and what happens when someone loses access. It is fine to leave these as questions for us to resolve.
Write down how you will check that a feature is complete. “Send booking emails” leaves room for different expectations. A clearer check is: “After a successful payment, the customer receives an email containing the booking reference, date and cancellation instructions.”
These checks are often called acceptance criteria. The GOV.UK guide to user stories explains the same idea: describe the user need, then list the outcomes that confirm it has been met.
Share what already exists
Your current website or app, and whether people are using it already.
Designs, brand assets, content and examples of interfaces you like. Explain what you like about each example.
Services that must connect to the product, such as payments, email, a CRM or a Telegram bot.
Any existing data that needs to move, and who owns the relevant accounts.
Constraints such as required languages, devices, accessibility needs or an existing technology choice.
If you are improving an existing product, say that upfront. A feature can involve changes to current data, permissions and workflows. Reviewing the existing system is part of understanding its scope.
Explain the deadline and the decisions
If there is a launch date, tell me what makes it important and what needs to be ready by then. A date tied to an event creates different choices from a preferred target. A budget range, if you have one, also helps us discuss priorities before putting a proposal together.
Name the person who can confirm priorities and approve the work. Tell me about dependencies too: pending content, access from a previous developer, or another team responsible for an integration. Those can affect the delivery plan as much as the code.
What a useful starting brief looks like
We run appointment-based services. Customers currently book through messages, and staff check availability manually.
For the first release, customers should choose a service and an available time, pay through our existing provider, and receive a booking confirmation. Staff need to view bookings and handle cancellations.
We already have a website, branding and a payment account. Subscription packages and referral rewards can follow later.
We need help deciding how cancellations and failed payments should work. We have a preferred launch date, but want to agree on what is realistic once those questions are answered.
This example still leaves work to define: availability rules, refunds, staff permissions and the information in each confirmation. That is expected. A starting brief gives us enough context to identify those decisions.
A brief you can copy
We want to build or improve: …
The people using it are: …
The problem with the current process is: …
The most important task a user should complete is: …
For the first release, we need: …
These features can wait: …
What already exists, including designs and integrations: …
Our deadline, constraints and budget range, if known: …
We will consider this successful when: …
The person making decisions is: …
Leave a line blank if you do not know the answer yet. Make open questions visible. Once we agree on a scope, a new request should come with a discussion of its effect on the work and timeline before it is added.
You can send your brief here. I work in writing, so there is no presentation or call to prepare. I will reply with questions and next steps before we agree on the work.