Requirement Documents ( MRD vs PRD vs SRD ) for Startups. What to choose?

Or Evolution of Requirement Document

Hi, startupper!

Previously, we wrote about popular marketplace tactics that are used by big startups. This time, we would like to describe what requirement documents some “Experts” will ask you to provide, what you can do with them, and how to write requirements for a new software startup.

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

1. Market Reality;
2. MRD vs PRD vs SRD;
3. What is a Marketing Requirement Document?
4. Sorting out Product Requirement Documents.
5. What is a Software Requirement Document?
6. What document Startup needs?
7. Conclusion

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 Doc for X. Each of them is operating based on the way they used to.

Market Reality

A list of outsourcing companies would ask you for Software Requirement Documentation (SRD), 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 (MRD) 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 their apps every day.

Based on this, while you will be working on tons of papers, all mentioned above variables would be changed greatly. Also, 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 others. Still, both of these choices are a pain in the ***.

MRD vs PRD vs SRD

So, MRD (Market Requirements Document) is frequently confused with PRD (Product Requirements Document), but they have a similar aim. To be short, MRD describes a product of how the product will deliver a demand to the customers, while PRD defines how the product should be built. 😅 But don’t be confused with SRD (Software Requirements Document).

So, what can work best for a startup? Let’s sort out all the pros and cons.

What is MRD or Market Requirements Document (Marketing Requirements Document)

Compering MRD with PRD we would like to concentrate on the reason for such a document. So, the reason is market demand. We need to determine the context of the problem when such an experience occurs, and with who. Mainly MRD consists of the next points:

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

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

Marketing Requirement Document Sample

MRD pros:

• Product Managers, Marketers, and Designers know who is targeting the audience;
• Tech leads understand the whole picture, and can split the launch versions without great architectural changes;
• Works as a single source in the pre-revenue stage for Investors;
• You can involve individual customers 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.

What is PRD or Product Requirements Document

Originally, PRD combines a general part of marketing direction and technical. Sometimes, PRD 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 – is from 1989.

Product Requirement Document Sample.

PRD pros:

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

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 with the behavior of every button. As a rule, consists 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 (iOS development, Android development, Web development).

Note! The oldest wiki reference – is 1984

Software Requirement Document Sample

SRD pros:

• There is no chance for the tech team to 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; if there is a chance to save some and do it 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, or 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. Otherwise, you would hear “we didn’t discuss such a 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.

How to write requirements for a new software startup? What document Startup needs?

So, how to write requirements for a new software startup? 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:

1. Marketing Part (based on MRD and not PRD)

• Executive Summary;
• Competitor Analysis;
• Persona (or targeting Audience)

You can cut off:

• Vision;

Can be kept. But better to add it to the Executive summary in 1-3 sentences.

• Target Market;

This can be covered in the Executive Summary within a single sentence.

• High-level capabilities;

No need for this, as we would have User Flow based on the vision, competitor analysis, and persona. This paragraph could be just useless extra work.

• Metrics Strategy;

Can be kept. But we would suggest having it mentioned in analytics which is a part of PRD. What is more, we are not sure at this stage will our idea will work or not, it goes mainly as an assumption.

2. Product Part (based on PRD)

• User Flow
• Analytics & Metrics
• Stakeholders
• Features for V1, V2, etc

Can be cut off:

• Objectives, key components;

It is covered mainly in our Marketing part.

• Details of User Flow;

We would have a Software Requirement part, so no need to work on it for now.

3. Development Details (based on SRD high-level documents)

• Design;
• User Stories;

Can be cut off:

• Introduction;

This is just extra work that can be covered with MRD and PRD parts.

• Test Plan;

Once you have a QA. The work can be done with feature scope and UI/UX design.

• Work. Estimates and Timelines;

It can work for a Waterfall type of project but not for a startup. Sure, we need to have rough estimates with approximate timelines. But not a detailed one as it takes a lot of valuable time to sort out every small task. It is better to add an extra buffer to the price.

• Work. Milestones;

The agile world already has a principal 1-3 weeks Sprints. Also, we have a list of features for V1. That’s our Milestone.

• Work. Priorities;

We’ve mentioned this in PRD with Features for V1. What is more, as everything changes in the Startup world, the priorities would be put before each Sprint.

Conclusion

With such points, you would be able to cover all the aspects of your startup needs. You would need to invest 4-6 weeks in such a document creation. What is more, any team member can change it easily after getting on the market. But any change won’t play a big difference for your startup, as all team members would be already in the project fully. Especially, if you are driven by analytics after the first launch.

The weak point of such doc is that it can not be created by a single person. And it needs to be going in stages, as:

• Idea;
• Market Research;
• Product vision;
• Features to cover the demand;
• Design;
• User Stories.

Let’s sum up

So, your new document type would consist of:

• Executive Summary;
• Competitor Analysis;
• Persona (or targeting Audience);
• Stakeholders;
• Analytics & Metrics;
• User Flow;
• Future Features;
• Design;
• User Stories.

So, if you would need to select which document to work on, pick the points above and call it a Startup Requirement Document or if you want to – an Alternative Product Requirement Document (PRD). Here, we compared MRD vs PRD vs SRD. Do you have anything to add here?

Wish you all reasonable investing and valuable results. We would like to hear your feedback about the article. Drop us a line on Linkedin, Twitter, or Facebook. If you are looking for your startup support, simply book a call below.