It usually goes like this: you spend long hours with your team on creating a perfect brief for your product. You send it out to a few software companies and receive a set of additional questions from every one of them.
And even though you thought you would be able to get your estimation in a few days or so, it takes anywhere from a week to one month to receive it. Now imagine a perfect world where one and only document is sufficient to get your estimates from a few companies. In this world it takes weeks, not months, to start building your product with a company you trust and like.
And I hope that I can help you achieve that. So instead of groping in the dark and creating a spec that is too vague or too detailed and complex (what happens just as often), you can read this article and use the template of the Product Spec that I’ve prepared with our team based on hundreds of specs we’ve analyzed over the past years.
That’s right, I’m talking about the main product artefact at the initial stage of any collaboration with a software house—the “brief”, “spec” or just specification.
Just so you know, the template I’m discussing here is not just Monterail-specific. You can tweak it, fill it out, and send to any other agency. You’ll find out what a good software development company needs before starting the work in general.
Good? Good.
Here, at Monterail, we are getting a lot of briefs for new projects: some of them are simply rough ideas and the others are complex and developed technical specifications.
Obvious as it may sound, the key is—make it as clear as possible. The purpose of the whole thing is seeking advice, and the more information and honesty, the better the advice. On the other hand, you want to hire people who know what they are doing, so you might want to leave some space for them to show their expertise.
In other words your brief should be specific enough to define goals, but vague enough to allow flexibility in technical decisions.
Most of the documents are quite long, but you should remember that you will have an opportunity to dive into more details in the next stages of the sales process. Usually, it happens during discovery workshops (or whatever your future vendor calls it).
The table of contents may look like this:
List of content in the Product Spec template from Monterail
1. Glossary
Every industry has its own language. Whenever you use any industry-specific concepts and terms, include them at the beginning of your brief. There are also some terms whose meaning can vary depending on the context—it’s important to clear those up. What do *you* mean by using a specific term?
This way you’ll avoid additional questions, speeding up the whole process.
2. Purpose of The Document
Explain your expectations and what you want to achieve by reaching out to this software company. It will help the team put the emphasis on those parts and aspects of the product that you care the most. It may look like this:
We'd like to gather the requirements for <product name>, get an initial feedback from potential contractors regarding the choice of the best technology and assess the potential risks and costs associated with its development.
Short and sweet, but it clears up your expectations which may facilitate your future communication with the software company.
3. Deadline
Your process will be more efficient if you state the deadline within which you want to make a decision on a vendor (or, effectively, when you want to start a project) — not only will it help you get the feedback on time, but you will also be able to see your potential partner’s approach to deadlines, a feature that will be very important in the future cooperation.
Just make sure to leave around a week for processing to make sure you get a quality analysis, not a rushed response.
4. General Context
Ok, now it’s time to dive into more details. This is where you describe your business and the app.
Introduction
Tell a bit about yourself and your company — how well do you know the market for the product? What is your experience with software development? What are you looking for in the cooperation? Who would be working on the app on your side?
Main goal of the app
Briefly describe the market you operate on and maybe provide some links to simplify the research. This section should clearly state the problem that exists on the market and how the product should help solving it.
Strategy
Do you have plans for launching the app? Who would be your first users? How do you plan to reach them? Do you already see potential ways of expanding it? Do you need any external 3rd party cooperation for the launch (e.g. bank's API to be ready)? Do you have any specific timeline (e.g. you want to launch it before a certain event takes place)? Do you have to keep within a specific budget? Do you plan to enter a round of investments at some stage? All of this will help your contractors suggest a roadmap that will fit your needs.
5. Functional Requirements and Scope
User roles
Who will be the actors in your system? The most common ones are:
- Visitor — a person who is not logged in to the application
- User — a person who is logged into the application and is essentially the end user of the service
- Admin — a back office employee who facilitates application processes and moderates users activity (think of user management, adding new categories, publishing content, etc.)
Try to state all possible roles that you plan to have in your system and describe them in a general way, e.g. what is the main goal of having such a role in the app? Who will be behind those roles (e.g. are they specialists in their field or do they need a more friendly design to be onboarded?). How often will they be using the application? What is the most common operation they will be performing?
Features
Most of the software houses choose to work in the Agile methodology which allows for more flexibility in terms of scope and provides solutions better suited to the ever-changing environment of the modern world. It’s most important to make sure your development team understands the goals you need to achieve so that they can propose the best solution for you.
If you go into too much detail, such as data structure for example, without explaining the underlying business needs, a good team will try to reverse engineer the original business goals and ask a lot of questions.
It’s not necessarily bad, but if you are short on time, I’d suggest presenting features like this: think of what should the app have to achieve the main goal you stated in the beginning given the limitations. That would translate into number of features in the future technical spec of the app quite clearly, while still allowing for different design solutions.
For example,
- Visitors should see the landing page and an invitation to log in/sign up
- Visitors should be able to sign up providing their email, password and a full name
- Users should be able to log in with their email and password
- Users should be able to see the dashboard summarizing their recent activity
- Users should be able to write a post
- visible for everyone
- visible for specific users (private post)
- attach a picture
- set the visibility options
- Admins should be able to see the list of users
- Admins should be able to block user
And so on.
This is essentially a cut version of something which is called user stories, the artefact used widely in the product design. User stories are very powerful, but preparing those could prove very difficult and generally unnecessary at the very early stage of the product design (as they are likely going to change), and such a shortcut as in the example above proves to be a good starting point for the design discussions.
Integrations
Will your application need to have any external integrations? For example, Google Analytics, HotJar, or other analytics tools? Payment gateway? Map display? External database or an API? What are the scenarios for their usage?
6. Non-Functional Requirements
Usage
State any specifics if you'd like them to be taken into account: what devices should the app be available on? What languages should be available? Are there any legal limitations developers should be aware of? Should any part of the app be available without an Internet connection? (especially important for the mobile apps)
Design
Are you also looking for a partner to help you design your new app? Do you already have any drafts/ideas or maybe designs are in progress? Do you have any guidelines it has to comply with? Do you need branding?
Benchmarks
Are there any applications that you really like and would like to use as benchmarks? Or maybe you've seen some specific element out there and think your app could use something similar? Are there any examples of design you really like? What are the main competitors for your product and what do you like/dislike about them?
7. Additional Materials
Add everything that doesn't exactly answer any of the questions above, but is still relevant to the product you are building: marketing presentations, user feedback reports, future ideas, illustrations and even relevant news.
8. FAQ
Let me just share a protip at the end — when you start getting responses from the agencies/consultants/freelancers — and most probably there will be questions (there should be either way!), don't just use emails for this (it will be repetitive and most likely lost in the future) — start to add questions and answers into your brief and update the rest of your candidates with the information. It will save you tons of effort and megabytes of traffic.
If you include all the elements I’ve mentioned above in your product spec, you can be sure you’ll receive your product estimation faster and with greater details. Not sure how it should look in a ready-to-go version? See our example of a filled out Product Spec.
Usually, the spec itself is not enough and it cannot replace contact with your future vendor. As a business analyst, I usually ask our potential clients many questions in order to understand their business and the product before we deliver our final estimation.
:quality(90))