Back to main page
How to write a brief for software development
So you’re building a product and you’ve decided to outsource part of your software development to a partner. You’ve done your research and you’ve found an agency who’s got what it takes to make your idea a reality. What’s next? It’s time to outline your vision for the partnership in a brief.
Knowing how to write a brief is essential. It’ll help ensure you and your partner see eye to eye every step of the way, from carving out a budget to developing your product’s features and taking it to market. It’ll build trust and streamline communication across teams. And it’ll make sure the final product meets all of your expectations come launch time.
Still, writing one can be challenging. You may have a clear idea of what you’d like in your head, but translating your thoughts into terms that make sense for people in another company with different backgrounds and skills is a whole different story. So I thought I’d share a detailed guide to walk you through the process, no matter what market you may be in. Let’s jump right into it.
What’s a brief?
The point of a brief is to give your partner context and instructions for developing your product. It should outline the current state of your business and your goals for the product’s life cycle. It needs to address both the technical and business sides of the problem you’d like to solve.
It also needs to be concise. A good brief will convey the minimum necessary information that gives your partner a maximum to work with. I sometimes hear about clients sending development agencies 30-page briefs. The reality is that no one will ever read something that long. Things change a lot over the course of a software development project and getting into too much detail early on is an unnecessary investment of any developer’s time. My advice: stick to a 10-page maximum.
Why do they matter?
Reading over your brief, partners should understand where you are, what you’ve done so far, what your current resources are, and who you want your customers to be. This information will directly affect how your product is built and help determine its success. For example, your market might require you to support five different languages. Knowing this early on will allow your partner to develop something whose scale, features, and cost best correspond to your business case.
Briefs are also important because they build trust. In a classic study of eighteen projects across seven different companies, researchers found that trust was an essential part of success in IT outsourcing. Two types of trust observed include knowledge-based trust, which depends on both parties knowing each other well, and identification-based trust, which depends on both parties understanding each other’s goals.
Think of your brief as a kind of onboarding tool: it’ll give your partner’s team the information they need to succeed on your terms. Without one, they can easily make decisions that aren’t in keeping with your goals. With one, they’ll be more knowledgeable about your project, more invested in it, and more comfortable communicating with you should any issues arise.
What should you put in a brief?
Describe your company
The first thing your brief should do is describe your company, including your team, market, customers, and the impact you’d like your project to have on the world. Software developers need this kind of information because they build products around the market constraints and customer personas you provide them with. Familiarity with your larger vision will also help ensure your values are aligned and the project echoes the bigger picture you want to paint.
Give an overview of your product
Next, give an overview of your product. Tell your partner what you’d like to build, which problem your product will be solving, and which platforms you’d like it to work on. If you’re developing a platform for car maintenance services, for example, it makes more sense to build an app than a web-based platform, as your customers will be using it on the go. Stating this in the brief will help confirm your partner is specialized in the kind of software development you need and ensure a successful collaboration moving forward.
Explain your business plan
Now it’s time to go through your business plan. How will your product make money? When will it be launched? What’s your go-to market? What about the long run?
It’s essential to include this kind of information in a brief because it provides a blueprint for the entire development process. Say your long-term vision involves expanding your product in a big way. You’ll have to use technologies that are easy to find developers for when hiring later on. Or, say you’re targeting a specific regional market. You’ll want to keep in mind which platforms are most used in that particular location and build accordingly (like iOS for the United States).
You might think that your partner doesn’t need to know your sales and marketing strategy to build a great piece of software. But they often do. For example, if you need your product to support add-on sales or if your main marketing channel will be push notifications and not email, this will affect what they develop and how it evolves over time.
Building a scalable technical solution from the start is always better than having to rebuild your product when expanding at a later date. That’s exactly what a business plan will help your development partner do: make sure your product is adaptable and well-suited to the growth you envision.
Share what’s been done so far
Don’t forget to share any analysis, market research, user testing, design, prototyping, and development you’ve worked on beforehand. This will give your partner a better idea of what’s been accomplished so far and what needs attention moving forward.
Plus, it’s always good to get advice from a pair of fresh eyes. Here at Mooncascade, we often do design reviews where design and UX team members look over each other’s work. Bringing together people who don’t have the same skill sets or ways of thinking will likely bring up questions you hadn’t thought of and provide stimulating feedback on your work.
Provide technical documentation
Even if you aren’t a technical person yourself, it’s essential to have a minimum understanding of the features and functionalities you’d like to build. Ideally, your brief will include a wireframe, an overview of integration, and a list of non-functional requirements like performance or security. This is crucial for planning out a budget with your partner. The more detailed your technical documentation is, the more accurate the estimate they give you can be.
Discuss roles and success factors
Be clear about who will own the product. Tell your partner which parts of development you want them to take on and which ones you want to keep in-house. Outline on-boarding expectations and figure out which team members will go where, as well as which roles your partner expects to play. This will avoid conflict and confusion as development continues.
Once roles have been established, list the success factors you’d like to see at the project’s outcome. This will allow you to assess your partner’s capabilities and help your partner assess your project’s do-ability. If possible, try to get specific business metrics down, like how many users you’d like to have by a certain time or revenue point. Again, the more precise you are here, the less unexpected cost (and failure) you’ll face later on.
Clarify time and budget constraints
This point goes hand-in-hand with the last one. Letting your partner know what your timeframe and budget are will allow them to give you invaluable feedback about the feasibility of your goals.
Often, clients don’t say how much money they’ve allocated to the project they’d like to work on. While this is understandable, it’s much easier to be upfront knowing what kind of resources the person across the table has available. If you’re afraid of getting cheated by a costly offer, let your partner know you’re taking multiple bids. Competition will help dampen the price.
Successful partnerships start with knowing how to write a brief
Once you’ve sent your brief off, don’t expect a quote back right away. For a software development company, analyzing something like this takes time. Expect plenty of questions from them as they look through it. If a developer gives you an immediate quote and doesn’t ask to meet with you, take it as a red flag.
And remember, you don’t have to write any numbers down or set anything in stone. You can use this article as a guide and keep things more open with a meeting, for example. Either way, these steps should give you a strong foundation for building a happy partnership and a successful product the next time you’re outsourcing. So what are you waiting for? It’s time to get started on that brief!
WANT TO KNOW MORE?
If you’re struggling to get your ideas into the language of software development, our team of software development experts would be happy to help you. Get in touch and let’s bring you some results!
