So you have decided to develop a digital product. You or your organisation have the key concepts in place, and just need to find a partner to build it for you. But how best do you communicate your ideas and needs?
Writing a good brief is the key to both speeding up the process of finding a development partner, and helping you establish more accurate costs and timelines from the outset.
Developers will do their best to provide estimates for your platform based on the information you provide, and if you can nail putting together a concise brief, this can go a long way to establishing a great working relationship.
Your brief doesn’t have to prescribe to a particular format, but the important thing is that it contains an easy to read overview of the key facts.
You could decide to use a word document, a powerpoint presentation, diagrams, sketches, or even a mixture of formats. Just so long as the brief contains the following contents.
A brief should be, well, “brief”, but also concise. That is, easy to digest but not lacking in information.
There is certain key information that a development team need in order to establish estimates for a project, that can often be neglected. We would advise you to make sure each of the following areas are covered in your brief.
The background info:
Help bring your developers up to speed with the key background information. Who are you and what do you do? What are your USP’s and values? How large or established is your organisation?
Overview of the project:
Why are you here? What are you looking to achieve from this project? What problems are you trying to solve?
In this section list enough information to give us an overview of your goals and requirements. It’s also useful to include information about your target users and their needs
The business goals:
In order for us to fully deliver, it’s important that we understand the business case for your platform. This includes monetisation, how you plan to get exposure, how you will stand out vs. your competitors, and the long term plan for your product.
If you haven’t already, we would recommend completing a business model canvas. (You can use a free online tool like https://canvanizer.com/ )
Project Scope and Exclusions:
This is arguably the most important part of your brief. In this section clearly list your expectations as to what should be included in the platform
Try to prioritise your features based on “Must have”, “Nice to have” and “Future scope”, and be clear about what features you need in your first launch, and what features can wait. When talking about your project scope, you should try to talk in terms of goals, and what your users should be able to achieve from the platform, rather than a specific function. For example, instead of a function like this:
Use wording like this:
“Users are able to pay for their item, either via a subscription service or a one-off card payment”
This gives us more context as to what you are looking to achieve and why.
Challenges, constraints or assumptions:
Are there any unknowns for the project? Is there anything you are unsure of, reliant upon or constrained by? Do you need to integrate with any of your own platforms? Are you working with a 3rd party service? You may have assumed that your supplier can provide a certain service or content, or work with certain services. Make sure you spell this out to prevent any crossed-wires.
Measuring success and impact:
How would you evaluate this project as a success once launched? Will this help you save time, increase revenues, onboard more users? It’s important that we understand these goals so that we can work with these in mind.
It may seem counterintuitive to provide a potential development partner with your budget expectations, however you will save yourself and your potential partner a lot of time by disclosing this information. This may have huge implications for the development route and feature prioritisation. It helps to indicate an expected price range at the very least to give your developers an idea of how much investment you would like to input.
Do you have a deadline or high level timeline in mind? If you do indicate this here. Bear in mind, many developers have a lead time before they can schedule work. As a general guide, we advise our clients to expect the minimum project duration of around 3 to 4 months for most digital projects.
What happens next
When you email your brief to your potential partner, be sure to include any sketches or supporting documents that could help them understand your requirements in more detail. Make sure to let them know if you would like to gather proposals by a certain date.
Most developers will arrange a time to chat your brief through, either over the phone or face to face, so that they can ask any questions or have you run through the important aspects with them. Make sure you use this opportunity to gather as much information as you can about the company, to make sure you are a good fit.
It’s normal to expect a wait of around 1 week for a proposal, and if your developer has more questions it could take a little longer. However, don’t be disheartened. This usually means they are taking their time to get the estimates right.
Overall, if you understand your proposition, business case and desired outcomes, writing your project brief should be straightforward. Try to keep language simple, write in your own words and avoid spending days creating 10-page documents, which is likely to overwhelm your developers.
At the end of the day, communication is the cornerstone of a successful partnership. If you follow the structure and content provided in this article, you should be well on your way to writing a brief that will form a solid foundation for your relationship with your development partner.