When I start talking about product specs, most people roll their eyes. A product spec is perceived as a large document that no one reads which takes forever to write. After all, we all want to be genuinely agile and start building the thing as soon as possible. I used to think about specs the same way when I was a developer, but my perspective changed after I began to manage product development.
On a typical app, you have at least a hundred user stories sitting in the backlog. Of course, you can combine them into epics and features, but this structure still doesn’t give you the full picture of the product and is hard to grasp. User stories are great for tactical planning and prioritizing, but they are doing a poor job when you need to see the product requirements as a whole.
Why you need a spec document
There are several reasons why you need a product spec document and one of the biggest ones is communication.
First of all, it is invaluable when hiring someone to build an app for you. You can’t ask the developer you are going to hire if he has built an app similar to yours without describing what you want to build comprehensively. So how are you going to do that without a spec? Would you invite everyone you’re going to interview the project management tool you are using? Are you going to send them a bunch of screens in a zip archive? It is too unprofessional. A good product spec includes functional and non-functional requirements illustrated by the flow diagrams and communicates what you what to build clearly.
Without the spec, it’s impossible to estimate the amount of time needed for the project. No matter whom you are going to hire to build the app for you, you’ll have to give them something to base an estimate on. While an agency might offer to do the spec work for you, a freelance developer usually expects you to know what you want. Remember that spec won’t guarantee reliable estimate as there will still be a high level of unpredictability, but it will reduce the number of errors in estimation.
Finally, the spec allows you to do some critical thinking upfront, especially on the technical side. It allows you to think about the architecture as a whole before the real work starts, reducing the cost of the error. While working on the spec, you can think about HOW you build everything, because user stories and UI describes only WHATto build.
What to include in your spec
A spec should include as much information about requirements as possible. There are two main types of requirements that you would typically include in the spec — business requirements and solution requirements. While business requirements might sound to you like something from the world of enterprise software, they are still worth thinking about and including in the spec. After all, you need to convey your goals, objectives and needs to developers and other team members working with a spec, and by including it, you won’t have to repeat them each time.
Business requirements are typically described at the beginning of the spec, while the majority of it consists of solution requirements that come in two forms — functional and non-functional.
Functional requirements
Functional requirements describe how the product must behave, what features and functions it should have and how it should react to user’s input. If you already have user stories, then you already have your functional requirements ready. You need to organize them properly and place related UI flow charts alongside the written description of functionality to illustrate the concepts.
Non-functional requirements
You might think that the non-functional requirements are the ones that don’t have a function and thus are not important. In reality, it’s quite the opposite — they describe the product from a perspective that is not visible for the user and therefore don’t have a direct function — e.g., there’s no button to click, and there’s no result to see.
A typical set of non-functional requirements capture crucial information that is hard to convey in users stories. For example, if you are building the mobile app, you can describe what devices you want to support. Non-functional requirements can make or break the whole project for Android app development, for example, because there’s a wide variety of devices and you need to balance the number of supported ones with your budget and other business attributes.
How many users do you expect within the scope of the current project? What are the security requirements? What tech stack, programming languages, and frameworks you need to use? What will be your deploy process and how you will monitor your servers? While it might feel like unnecessary detail at the beginning of product development, you have to plan for these things and have time and budget to address them.
Hire a consultant
If you are a non-technical founder, you might have trouble creating the product spec yourself. I would highly recommend hiring a consultant to spec the product for you and rely on him make technical choices. If you are an early-stage startup, typically this is why you want to have a technical co-founder, but since this kind of work is mostly technical, you can hire someone skilled to do it (contrary to hiring someone for customer development and user research).
Whom should you look for? I’d recommend choosing the main direction you want to move in (e.g., a programming language you want to use) based on what you’ve learned online and posting a job on one of the freelancer sites. Even on Upwork, you can find excellent professionals who will happily scope the project for you.
Of course scoping won’t be cheap, but you won’t have to dilute your equity. Another benefit is that you won’t have to risk your product by hiring inexperienced developers accidentally — you will have the spec to hold them accountable because it will contain all technical details.
Is scoping a must in today’s world of agile software development? Definitely not. However, it allows you to have a better understanding of what you want to build at the beginning of the project and allows you to capture non-functional requirements. The scope document is invaluable when you are kickstarting the project. Of course, requirements will change over time as you learn more about the product and get feedback from users, but at that point, you will be in a different mode, and you will have a team that is ready for the change — something you don’t have in the beginning unless you have co-founders.