As a project manager, you may need to deliver technical requirements to developers—even if you lack coding experience. Without a proper brief, your developers can't do anything. Or they will, but it won't be what the client asked for.
You are the developers' eyes and ears. You meet clients, hear them out, package their rambling into meaningful words, and pass them to the dev team. Based on your documents, they estimate costs, formalize requirements into tasks, and start working.
The quality of communication between you and the developers directly influences the project during its entire course. You can't just tell devs "You do this!" and slack off.
What to Include in Your Brief
We discussed this with Daniel Brady, a Senior Software Engineer at Tapjot, Inc., and he opened our eyes to a bunch of things. Here's what your brief should contain:
1. Project Overview
Even though developers work on technical things, some non-technical info is still required.
Project Goals & Outcomes
Explain what the project is intended for. Database? Learning resource? Landing page? eCommerce? Cover not just what the client wants, but what they want to achieve.
"Will meeting these goals provide short-term value, or are they steps towards longer-term success? How will achieving these goals impact the business? And for each goal, what is the impact of missing it?" — Daniel Brady
Project Budget
Because some development solutions are more costly than others. Devs need to know budget constraints to recommend appropriate approaches.
Deadlines (With a Caveat)
The client has their vision, but it's the dev team who does the work. They know better how long things take.
"There should be no timeline or deadline given unless agreed to by an engineering lead. Even urgent requests need to be vetted by an engineer before committing. If an engineer says it takes 4 weeks and the client needs it sooner, you need to reduce scope or find a way to give the team the time they need. We're not deliberately inflating estimates to make your life harder!"
Definition of Done (DoD)
What should the end result look like? At what stage is the project ready to show? Fully operational website or MVP? Discuss with the client and mention it in the brief.
2. Functionality Requirements
It's great when clients come prepared with a written list of desired website functions. Unfortunately, clients mostly come with vague requests like "You tell me what I want" or "I want a beautiful fast website with many visitors."
Example Functionality List:
If the client is vague, you and your team will have to work out the project from scratch using the info you squeezed out. This is when detailed project goals come in handy.
3. Features
Specify additional features the client wants. This is often what clients think about first. The exact list depends on project outcomes, objectives, functions, and navigation.
Image Galleries
Interactive Maps
Website Search
Background Animations
Feedback Forms
Star Ratings
4. References
Provide your dev team with references. Ask the client to point out competitors whose websites have the desired functionality. References can even include websites not related to the client's industry—as long as they illustrate what's needed.
What Your Devs Don't Need
Here's the info you might think developers need, but they probably don't. If you hire experienced developers, they'll tell you themselves, but it's good to know upfront.
Detailed Company Vision
"Green fuel is our passion, and we dream the whole world will one day realize..." Nope. Developers don't need to know your client's calling. They want to know what the client is trying to do with the website.
USP & Target Audiences
This is info web designers value. Developers turn web design into code and a working website—they don't design the website itself.
Mockups (Usually)
Unlike references that serve as starting points, mockups imply specifics. Unless you know from the beginning what the final product looks like (rarely the case), avoid mockups at briefing stage.
Branding Guidelines
For the engineering team, this is junk. Don't bother developers with marketing materials and brand books—that's for designers.
How to Facilitate Your Devs' Work
"How can I actually help the engineering team instead of being a pain in the neck?" Great question. Whether you work with dedicated development teams or individual contractors, these principles apply.
Communication Best Practices
- Be available: Make time for frequent discussions and demos
- Be explicit: Leave as little as possible open for interpretation
- Be patient: Be willing to repeat answers to questions
- Be timely: Communicate changes immediately and be ready to re-evaluate timelines with every change—sometimes things are easier said than done!
Tip Talk Before Estimating
Discuss the brief with the engineering lead before providing the client with final estimates. Send the document to the dev team in advance! Discuss it with developers, talk to the client, correct the brief, then hand the final version to devs.
Tip Use Messengers Properly
Don't call meetings all the time. This distracts developers from work and expands the time needed. Instead, create a Slack channel for all project communication. You'll have everything in one place—great for retrospectives.
Warning Don't Use Technical Jargon
Showing off is never a thing, especially on important projects.
"If we hear you use a technical term, we might think you understand more than you do about something, which can lead to big communication issues!"
Brief Template Summary
| Section | What to Include |
|---|---|
| Project Overview | Goals, outcomes, budget, deadlines (vetted by devs), Definition of Done |
| Functionality | What users need to be able to do on the website |
| Features | Galleries, maps, search, animations, widgets, etc. |
| References | Competitor sites or any sites with desired functionality |
| Skip | Company vision, USP, target audience, mockups, branding |
Frequently Asked Questions
What's the most important part of a developer brief?
Project goals and outcomes. Developers need to understand not just what the client wants, but why they want it and what they're trying to achieve. This context helps developers make better technical decisions and propose alternatives when the original request isn't feasible.
Should I include deadlines in the brief or let developers estimate?
Always let developers provide estimates first. You can share client expectations, but no timeline should be committed to without engineering lead approval. If there's a mismatch between client needs and engineering estimates, work with the client to reduce scope or adjust timelines—don't force estimates on developers.
How detailed should functionality requirements be?
As detailed as possible while staying flexible. List everything users should be able to do—subscribe, register, purchase, comment, etc. Include page structure and navigation. But avoid prescribing technical solutions unless you have engineering input. Let developers propose how to implement what you need.
The Bottom Line
Let developers do technical stuff. Focus on communication. Don't try to control the engineering team—instead, ease their job by providing all necessary info upon request.
A good brief includes goals, functionality, features, and references. It skips company vision, branding, and mockups. And it never forces deadlines without engineering input.
Need Developers Who Communicate?
Boundev developers are vetted for communication skills, not just code. Brief them once, get results.
Hire Developers Now