Ultimate Startup Requirement Document

5 min readDec 10, 2020

Table of content:

Hi, startupper!

This article appears based on our experience while receiving different documents from other startups. One of the startup key reasons to launch is to solve a problem, we are trying to solve startup problems. Some of you who has IT experience already faced with such cases:

Once you are reaching an advisor, technical partner, outsourcing business, or any other contact who needs to dig into your idea they are asking for a Requirement Document for X. Each of them is operating based on the way they used to.

A list of outsourcing companies would ask you for a Software Requirement Documentation, and if you don’t have it they will sell you a Business Analyst to write it. Marketing Agencies would ask for a Marketing Requirement Document or would sell the research to you. The reality is that we are living in an unstable world. We are living in a world where markets are changing, competitors are rising, and users are changing the apps every day. Based on this, while you will be working on such tons of papers, all mentioned above variables would be changed greatly and there is a huge chance that you will be out of the board. It is true, that each of the mentioned docs is a nice background for a product. But can you invest months into each of them? — Probably not. A lot of you would create one of them and sacrifice others. Or would outsource other. Still, both of these choices are a pain in the ***. So, what can work the best for a startup? Before we will dig into this let’s sort out the difference between these docs.

Market Requirements Document or Marketing Requirements Document

The reason for such a document is market demand. We need to determine the context of the problem when such an experience occurs, and with who. Mainly MRD consist of the next points:

Executive Summary;
Competitor Analysis;
Persona;
Vision;
Target Market;
High-level capabilities;
Metrics Strategy.

Note! The oldest wiki reference — 2009 (but we are sure it is much older).

Marketing Requirement Document Sample

MRD pros:

Product Managers, Marketers, and Designers know who are targeting the audience;
Tech lead understand the whole picture, and can split the launch versions without great architect changes;
Works as a single source on pre-revenue stage for Investors;
Individual customers can be involved in feature development that increases their loyalty;
General product strategy shows the path that inspires the team;
The team knows the weak points of competitors, which allows them to generate valuable ideas.

MRD cons:

It requires a lot of management to make stories moving forward;
Because of a different mindset, it is useless for a tech team. The Product Manager should rewrite stories for the rest of the team (esp. for developers);
Investors are not able to use it as a single document;
It takes a lot of time to create.

PRD or Product Requirements Document

Originally, PRD combines a general part of marketing direction and technical. Sometimes, it even looks similar to MRD, with a single exception. PRD is related to the product, needs, and opportunities, while MRD is related more to market needs. It consists of:

User Flow;
Competitors;
Analytics & Metrics;
Stakeholders;
Features for V1, V2, etc;
Objectives, key components;
Details of User Flow.

Note! The oldest wiki reference — 1989.

Product Requirement Document Sample.

PRD pros:

Describes the whole picture of the product with some risks;
Shows approximate time that is needed for a product to be launched;
Describes the budget that is needed;
The tech team knows what is needed.

PRD cons:

Requires some extra time to sort out small tasks for a tech team;
Built mainly on assumptions and not deep research.

SRD or Software Requirement Document (also known as Technical Specification)

It describes all aspects related to development. Starting from language & architecture requirements, and ending behavior of every button. As a rule, consist of:

Intro — about the project;
Solution — with design, architecture scheme, features, test plan, and release, rollout guidelines;
Further Consideration — support costs, maintenance costs, and risks;
Success Evaluation — impact and metrics;
Work — estimates, timelines, milestones, and future work.

Note! The oldest wiki reference — 1984

Software Requirement Document Sample

SRD pros:

There is no chance for the tech team misunderstand the project vision;
Saves money by clearly visualizing the whole picture for a tech team, so it works for outsourcing;
Single source/reference for any feature behavior.

SRD cons:

Requires around 2–10 weeks to write it down before the development starts;
In case of changes, requires additional time to maintain the document;
Useless for a marketing team.

As a rule, a major part of all outsourcing companies requires Specification. It takes some extra time and money. Both points are very important for startups and if there is a chance to save some and do faster they would do that. Unfortunately, it depends on the tech partner a lot. As a rule, no one will dig over and beyond your idea, market, vision, features before you pay the first invoice. Nevertheless, if you are looking for a low-cost development, make sure you have a high-quality spec, as otherwise, you would hear “we didn’t discuss such feature”, “this’s extra work that should be additionally billed”, etc. The worst scenario you can face is a different app architecture at the very end that does not allow you big changes or even a single feature change without a massive code change.

What document Startup needs?

A major part of blogs is writing something like “It’s up to you what to choose”. And each of them works if you have available resources and time for this. But as a rule, you don’t have them. Probably there will be a lot of haters, but we would suggest picking separate points from each Requirement Document. All of them were “designed” 15 years ago or more. The market changed greatly, and you just need to be “So Fast, So Furious” to handle all of the aspects. And here is what works the best from our perspective…

Here is the full article:
https://www.urlaunched.com/blog/evolution-of-requirement-docs