In this short article, I share my thoughts on how to write a great digital product brief.
Let’s make something clear for all of you reading this - a good brief can help you get what you want regardless of the side you are on.
From the sender's perspective, a good brief will save time on explanations, lower the possibility of misunderstandings and speed up the time from initial contact to decision making. Time is money, isn’t it?
From the addressee’s perspective, a good brief can help understand the foundations of a project and it is the best starting point for continuing a discussion about delivering something valuable in the foreseeable future.
No one wants to discuss the points I’ll mention in this article in the middle of an ongoing project. If it happens, then the chances your product will be delivered on time, within budget and you won’t hate your partner on the way, are (the) small(est).
I am not able to count the amount of project briefs I have gone through, and I can tell you that there is nothing better than a spot on information about the project for a person responsible for the first contact.
Some briefs are good, some are ok and some are “I want an app, how much will it cost?” [sic!]. But, what is a good brief? What should it consist of? There is a thin line between a 60-page documentation and the “I want an app” brief. The first one is something business people like because it looks professional and comprehensive (at least from their bosses’ perspective). The problem is that these are usually prepared by business people with no or little help from someone with a technical background. Those type of documentations can give you a good sense of the product, but they usually end up being vastly different from the final look of an actual product. This is due to the fact that it’s very difficult to predict the technical challenges some of the business ideas will impose. I always wish that someone who prepared this type of documentation could put in the same amount of effort into project discovery with the development team.
The latter one usually means that someone, for some reason, did not have enough time or, what’s even worse, desire to write down a couple of lines of text. That’s a red light for someone like me, but the reasons for writing such a “brief” are not limited to the ones I mention here. Sometimes, it’s simply a fear of disclosing too much before getting to know the other side. I get that. Therefore, it’s worth verifying such a brief as it might turn out completely opposite to what the cover of a book shows.
Fortunately, most of the briefs I receive are somehow in-between. There are some mutual traits that make a good brief and I’ll try to narrow them to the 4 ones I believe are crucial. In this article, I’ll try to share my experience with what works best in my opinion. Here we go.
Why?
You probably know Simon Sinek’s famous “Why/How/What circle” (if not click here. You're welcome). It’s difficult not to agree with “Why” being one of the most important things you’d want to know. You may ask why ;) (hope you will) - because knowing the context in which you will operate can give you a lot of information. For me, the answer to “Why” makes it easier to jump into the clients’ and potential users’ shoes, anticipate questions and quickly suggest appropriate solutions. There is nothing better than a good brainstorm in which you can compare different fields of specialization against an idea.
From the client’s perspective, there is nothing better than making sure your intent is well understood and explaining “Why” to people, who will make your idea real, seems like a good thing to do.
From a team perspective “Why” can help them in motivation as they will know the reason for doing something. No one likes to be treated like a “tool”.
How?
The second step in “Why/How/What circle”. This one does not have to be complete, but it’s good to know which platforms you’re aiming at. Are you planning to have a mobile app, web app, or maybe both? Do you have a design or are you looking for this as well? Basically, this should give an idea of how you are planning to approach the problem you identified. This will help in defining a team composition and gathering information about availability. Without this, you may be walking into a grocery store, looking for a pair of shoes - a waste of time.
What is the preferred release date and why?
Even though it may be difficult to prepare an estimate of the development during first contact, the preferred release date will set expectations and help to verify the plans vs actual amount of time a team will have to meet them. It may turn out that the plan is too ambitious and, in order to keep the release date, you will need to narrow the scope even further. The MVP approach is always preferred in this scenario, so narrowing the scope to the required minimum and testing the idea against the target audience.
What is the budget?
You may not want to share this with the company your contacting, thinking “I don’t want to reveal my cards just yet” - it’s not a poker game. It does not necessarily have to be put upfront while contacting a software development company for the first time, but if your budget is limited, then it's good to discuss it because it will affect the time a company can spend on your product. Software development is unpredictable to some extent, so it’s difficult to say precisely how much the development of a certain application will take. If your plan is ambitious but your budget limited, it might be good to refine it and stay realistic - “Rome wasn't built in a day”. Limited budget is nothing bad, but unrealistic expectations on top of a limited budget are. We don’t want the scenario from the picture below as much as you don’t.
Example brief
Why: We’ve found out that due to an increase in number of cars per household in X city, people have problems with traffic while commuting and it takes them too much of their private time.
What: Create a mobile application that will gather data of its users’ commuting habits, and based on an average traffic congestion, the app would suggest time to leave the house/office in order to spend the least time commuting from A to B.”
Release date: We would like to have an MVP ready for testing by the end of summer time because Autumn marks the beginning of an increase in car traffic.
Budget: We can afford to spend around X of our current budget on MVP. (The amount here would indicate that Sender has enough to build a backend service and a cross-platform mobile application with a small buffer).
Wrapping up
Ok, so we have a reason, we have the means, we have the time and the budget. What’s left? Many things, because a good brief should be created with project characteristics in mind. I could dive into things like business models, preferred tech-stack, stakeholders, type of projects and so on, but that’s not what this article is about. I believe that the above examples (with a small exception for an unlimited budget) make a good brief. This information will set the expectations on both sides and create a great foreground for an upcoming successful partnership.
Let me know in the comments what you think works best.
Get in touch at andrzej@appunite.com if you’d like to discuss your current or upcoming digital product!
