Requirement Document (MRD, PRD, SRD) vs Startups. What is the solution?

Or Evolution of Requirement Document

Table of content:

  1. What is a Marketing Requirement Document?
  2. Sorting out Product Requirement Document
  3. What is a Software Requirement Document?
  4. What document Startup needs?
  5. Conclusion

Previously, we wrote about popular marketplace tactics that are user by big startups. This time, we would like to describe the what requirement documents some “Experts” will ask you to provide, and what you can do with this.

Intro

Hi, startupper!

Software Requirement Document vs Marketing Requirement Document vs Product Requirement Document

This article appears based on our experience while 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 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 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 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 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 the best for a startup? Let’s sort out all the pros and cons.

mrd vs prd vs srd

Market Requirements Document or Marketing Requirements Document (MRD)

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;
  • 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.

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;
  • 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 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?

Requirement Documents for startups

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)

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

You can cut off:

  • Vision;

Can be kept. But better to add it into 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 that is a part of PRD. What is more, we are not sure at this stage will our idea 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)

  • Design
  • User Stories
Can be cut off:
  • Introduction;

This is just extra work that can be covered with MRD & PRD part.

  • 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 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. Such a document creation would take approximately 4-6 weeks to work on and it can be changed easily by any team member 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 in such doc is that it can not be created by a single person. And it needs to be going by 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 Startup Requirement Document or if you want to – Alternative Product Requirement Document.


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

Scroll to Top