Creating a lean, mean product requirements machine (2022)

Summary: A product requirements document (PRD) defines the requirements of a particular product, including the product’s purpose, features, functionality, and behavior. It serves as a guide for business and technical teams to help build, launch, or market the product.

Building a great product requires tons of research and comprehensive planning. But where do you start? Product managers often start with aproduct requirements document(PRD).

A product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.

Creating a lean, mean product requirements machine (1)

Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.

Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

Gathering requirements in an agile world

What does the requirements gathering process look like in an agile world? It sounds tricky - and it is. But don't worry. At Atlassian, we know all about creating PRDs in an agile environment. Here are a few things to keep in mind:

Agile requirements are a product owner's best friend. Product owners who don't use agile requirements get caught up with spec'ing out every detail to deliver the right software (then cross their fingers hoping they've spec'ed out the right things). Agile requirements, on the other hand, depend on a shared understanding of the customer that issharedbetween the product owner, designer, and the development team. That shared understanding and empathy for the target customer unlocks hidden bandwidth for product owners. They can focus on higher-level requirements and leave implementation details to the development team, who is fully equipped to do so – again, because of that shared understanding. (Boom.)

Creating a shared understanding among teams

If you're excited by the idea of a shared understanding, but haven't a clue how to create it, try some of these tips:

  • When conducting customer interviews, include a member of the design and development teams so they can hear from a customer directly instead of relying on the product owner's notes. It will also give them the chance to probe deeper while the topic is fresh in the customer's mind.
  • Make developing and using customer personas a team effort. Each team member has unique perspectives and insights, and needs to understand how the personas influences product development.
  • Make issue triage and backlog grooming a team sport as well. These are great opportunities to make sure everyone is on the same page, and understand why the product owner has prioritized work the way they have.

Want to give it a try?Sign up or log into Confluence>>

Create a customer interview template to document your customer insights. Follow our tutorial to get started on conducting valuable customer interviews:

(Video) How to create a lean mean lead generating machine - Robert Li @ WordCamp Brisbane 2019

  • Create insighful customer interview pages
  • Turn info into insights with the Customer Interview Pyramid

When the team and product owner share the same mindset, you don't need ultra-detailed requirements.

Anti-patterns to watch for

  • The entire project is already spec'd out in great detail before any engineering work begins
  • Thorough review and iron-clad sign-off from all teams are required before work even starts
  • Designers and developers don't know when requirements have been updated
  • Requirements are never updated in the first place (because everyone signed off on them, remember?)
  • The product owner writes requirements without the participation of the team

Ok: you’ve discussed a set of user stories with your engineer and designer. Gone back and forth, had a few whiteboard sessions, and concluded there are a few more dimensions you need to consider for this feature that you are working on. You need to flesh out some assumptions you’re making, think deeper about how this fits in the overall scheme of things and keep track of all the open questions you need to answer. What next?

Keeping requirements lean with a one-page dashboard

When writing a requirementsdocument, it's helpful to use a consistent template across the team so everyone can follow along and give feedback. At Atlassian, we useConfluenceto create product requirements with the product requirements document template. We've found that the section below provides "just enough" context to understand a project's requirements and its impact on users:

1. Define project specifics
We recommend including high-level direction at the top of the page as follows:

  • Participants: Who is involved? Include the product owner, team, stakeholders
  • Status: What's the current state of the program? On target, at risk, delayed, deferred, etc.
  • Target release: When is it projected to ship?

Creating a lean, mean product requirements machine (2)

2. Team goals and business objectives
Get straight to the point. Inform, but don't bore.

3. Background and strategic fit
Why are we doing this? How does this fit into the overall company objectives?

Creating a lean, mean product requirements machine (3)

4. Assumptions
List the technical, business, or user assumptions you might be making.

(Video) Ep. 76 - Making a Lean, Mean, $5 Mil Machine and How to Tame It with Tyler 'Sully' Sullivan

5. User Stories
List or link to the user stories involved. Also link to customer interviews, and inclused screenshots of what you've seen. Provide enough detail to make a complete story, and include success metrics.

Creating a lean, mean product requirements machine (4)

6. User interaction and design
After the team fleshes out the solution for each user story, link design explorations and wireframes to the page.

Creating a lean, mean product requirements machine (5)

7. Questions
As the team understands the problems to solve, they often have questions. Create a table of "things we need to decide or research" to track these items.

8. What we'renotdoing
Keep the team focused on the work at hand by clearly calling out what you're not doing. Flag things that are out of scope at the moment, but might be considered at a later time.

Pro Tip:

The Agile Manifestoreminds us that we can be flexible with how we create requirements. Some teams douser story mapping exercisesto identify problems and solutions. Sometimes the full product triad (product owner, developer, and designer) visits a customer and then brainstorms solutions to a particular problem that the customer mentioned.

No matter how requirements are born, it's important that the team considers them to be one ofmanyways they can define and communicate customer problems. See our section onagile designto learn how product owners can use Keynote and Powerpoint to mock-up real experiences as requirements.

Example of a one-page PRD

Here's a look at a fully fleshed out product requirements document that we created using Confluence. Remember, no two product requirements will be exactly the same. Use this example to understand the different elements that should be included in your PRD, but not asthedefinitive way to do it.

Creating a lean, mean product requirements machine (6)

Creating a lean, mean product requirements machine (7)

Want to give it a try?Sign up or log into Confluence>>

Once you're in, choose the product requirements blueprint and then follow the tutorial below to help you get started setting up your requirements:

  • How to create a product requirements document
(Video) Lean Canvas Intro - Uber example 🚘

Key takeaways from the one-page approach:

If you are to take away anything from this blog, understand the “why” – the not “what” – because the “why” will help you explore what is best for your team. Here are the benefits and challenges we’ve observed with the one-page dashboard approach:

1. One page, one source
Keeping it simple. The product requirements documentbecomes the “landing page” for everything related to the set of problems within a particular epic. Having something that is the central go-to location saves your team members time in accessing this information and gives them a concise view.

2. Extra agility
One of the awesome things about using a simple page to collaborate (verses a dedicated requirements management tool) is that you can be agile about yourdocumentation! You don’t have to follow the same format every time – do what you need, when you need it, and be agile about it. Chop and change as needed.

3. Just enough context and detail
We often forget how powerful a simple link can be. We embed a lot of links within our product requirements documents. It helps abstract out the complexity and progressively disclose the information to the reader as needed. Linking detailed resources may include such things as:

  • Customer interviews for background, validation or further context for the feature
  • Pages or blogs where similar ideas were proposed
  • Previous discussion or technical documentation and diagrams
  • Videos of product demos or other related content from external sources

4. Living stories
I see a lot of customers do this as well. Once the stories have been roughly thought out and entered as issues inJira Software, we link to them in our page (which, conveniently, creates a link from the issues back to the page as well). The two-way syncing between Confluence and Jira Software means we automatically get to see each issue's current status right from the requirements page.

5. Collective wisdom
Capturing product requirements in Confluence makes it easy for other people in different teams to contribute and make suggestions. I’ve been amazed at the number of times someone from another team jumped into the conversation with a comment providing great feedback, suggestions, or lessons learned from similar projects. It helps a large organization feel like a small team.

6. Engaging "extras"
Diagrams made with tools like Visio, Gliffy, or Balsamiq better communicate the problems to your team. You can also embed external images, videos, and dynamic content.

7. Collaboration!
The most important aspect of all this is getting everyone involved. Never write a product requirements document by yourself – you should always have a developer with you and write it together. Share the page with your team and get feedback. Comment, ask questions, encourage others to contribute with thoughts and ideas. This is especially important for distributed teams who don't often get a chance to discuss projects in person.

Challenges

With every approach there are down-sides. Here there are two main challenges we’ve experienced and observed from customers as well:

1. Documentation can go stale
What happens when you implement a story and get feedback and then modify the solution? Does someone go back and update the requirements page with the final implementation? This is a challenge with any type of documentation, and it’s always worth questioning whether such trade-offs are worthwhile. Talk to your team about what you would do in a scenario like this.

(Video) Four Principles Lean Management - Get Lean in 90 Seconds

2. Lack of participation
“What can I do to encourage people to comment?”, “How can I encourage people to write more specs and stories on our intranet?”. This is a tough nut to crack, and it comes down to various wiki adoption techniques in your organization. There are plenty of resources to help you here. There may be deeper cultural issues at play here, too.

Now get to work!

When requirements are nimble, the product owner has more time to understand and keep pace with the market. And keeping them informative-but-brief empowers the development team to use whatever implementation fits their architecture and technology stack best.

Once a project's requirements are reasonably well-baked, we recommend linking the user stories in section 5 above to their corresponding stories in the development team's issue tracker. This makes the development process more transparent: it's easy to see the status of each piece of work, which makes for more informed decisions from theproduct owner, as well as downstream teams like marketing and support.

ProTip:

Don't track the user stories that come from project requirements in one system and defects in another. Managing work across two systems is needlessly challenging and just wastes time.

Remember, be agile in your evolution of requirements for a project. It's okay to change user stories as the team builds, ships, and gets feedback. Always maintain a high quality bar and a healthyengineering cultureeven if it means shipping fewer features.

Creating a lean, mean product requirements machine (8)

Dan Radigan

(Video) Becoming a Lean, Mean, Auto Body Repair Machine! with Michael Giarrizzo

Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling.

FAQs

What is MRD product management? ›

A market requirements document, or an MRD, is a strategic document written by a product manager or product marketing manager to help define the market's requirements or demand for a specific product.

What is the difference between BRD and PRD? ›

PRD management is a task of high value, and it must be done properly. Often, PRD is confused with BRD. BRD stands for a Business requirements document. The purpose of the business document is to prevent wasted efforts on the factors that do not affect business objectives.

What is the difference between MRD and PRD? ›

An MRD is often confused with a product requirements document

product requirements document
A product requirements document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.
https://en.wikipedia.org › Product_requirements_document
(PRD), but they have distinct purposes. While an MRD defines what customers need and how the product will provide this, a PRD describes how the product should actually be built.

Who writes product requirements? ›

A PRD

PRD
A product requirements document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.
https://en.wikipedia.org › Product_requirements_document
is usually written by the product manager as one of the first steps in the product development process. It serves as a living document for any designer and developer involved in the project to understand the purpose of the product and its current status.

What are examples of product requirements? ›

Typical quality requirements include: reliability of the product, consistency, durability, availability, customer experience, look and feel, performance, maintainability, materials / ingredients etc.

Who writes requirements in Agile? ›

In Agile, requirements are shared among customer and business analyst, product owner, scrum master, designer, development team. Usually, the team is responsible for choosing a technical approach based on high-level requirements and implementing more detailed statements or acceptance criteria in user stories.

How do you create a product documentation? ›

How to create product documentation
  1. Know your audience. It is important to understand your user when creating documentation (much as you would when creating the product). ...
  2. Keep your documentation simple. ...
  3. Use diagrams. ...
  4. Accept the truth: People do not read product documentation. ...
  5. References.

How do you write a good MRD? ›

Writing an Effective Marketing Requirements Document
  1. What is a Marketing Requirements Document or MRD?
  2. Step 1: Understand The Customers Pain.
  3. Step 2: Understand Your Competitors.
  4. Step 3: Identify The Essence of The Product.
  5. Step 4: Craft Core Requirements.
  6. Step 5: Define Nice To Haves.
  7. Step 6: Layout The Business Case.
5 Aug 2019

What are the four requirements for a market? ›

The four Ps are the four essential factors involved in marketing a product or service to the public. The four Ps are product, price, place, and promotion.

What is BRD business requirements document? ›

What is a business requirement document (BRD)? It is a document to record the functional, quality, and usability requirements into formats that are easily consumable for future analysis, architectural, and design activities, and most importantly in a format that is understandable by all business stakeholders.

Who prepares BRD document? ›

Who creates a BRD? The BRD is one of the first few documents created in a project's lifecycle. While the document is typically prepared by a business analyst , several individuals should be involved in creating it, including the project's team, business partners and key stakeholders.

What is difference between SRS and BRD? ›

SRS is the short used for Software Requirement Specification. BRD is commonly known as Business Requirement Specification Document. SRS is also called a Product Requirement Specification and System Requirement Specification. It is maintained by Business Analyst.

Who prepares FSD document? ›

The Functional Specification Document (FSD) is written by the project's Business Analyst and provides detailed information on how the system solution will function based on what the requested behavior is.

How do you write a medium PRD? ›

OK, how can I write a good PRD?
  1. Be clear about what template you will use.
  2. Elaborate on the details but be concise.
  3. Order your user stories by the most basic functionality first.
  4. Be ready to keep updating it and communicating the updates.
3 Jul 2019

Why is PRD important? ›

A PRD

PRD
A product requirements document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.
https://en.wikipedia.org › Product_requirements_document
keeps everyone on the same page: No one should have any questions about what the product is or what it's supposed to achieve after reading the PRD. It sets very clear goals and guidelines for a product and shows how the features of a product meet the user's needs.

What is a MRD test? ›

y Minimal residual disease (MRD) is a term used to describe the small number of cancer cells in the body after cancer treatment. An MRD positive test result means that disease was still detected after treatment. An MRD negative result means that no disease was detected after treatment.

Does a product owner write requirements? ›

Requirements are written by the product manager, product owner, or business analyst. Technical leads are often involved as well as the engineers who will be responsible for working on the features or improvements.

What is a product requirement specification? ›

A product requirements document

product requirements document
A product requirements document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.
https://en.wikipedia.org › Product_requirements_document
(PRD) is a detailed description of the requirements of a product, including the value and purpose of a product or feature. PRDs are written by the product manager to communicate what you are building, who it is for, and how it benefits the end user.

What is the difference between a requirement and a feature? ›

A requirement is a capability that a product must possess to ultimately satisfy a customer need or objective. A requirement tends to be more granular, and is written with the implementation in mind. Feature: A feature is a set of logically related requirements that allows the user to satisfy an objective.

What are product requirements VS project requirements? ›

Product requirements

Product requirements
A product requirements document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.
https://en.wikipedia.org › Product_requirements_document
consist of technical requirements, performance requirements and security requirements while Project requirements consist of delivery requirements, business requirements and project management requirements. Product and Project requirements consist of the same steps.

What are product functional requirements? ›

Functional requirements are features that are built to serve the products' users. They are pieces of functionality that solve particular problems for users. An example of a functional requirement would be: “User should be able to import contacts into their mail application.”

How do you gather requirements in agile? ›

7 ways to improve Agile requirements gathering
  1. Supplement user stories. User stories don't always include enough information for development decisions. ...
  2. Involve stakeholders regularly. ...
  3. Prioritize requirements. ...
  4. Focus on executable requirements. ...
  5. Use the INVEST principle. ...
  6. Think layers, not slices. ...
  7. Prototype and update.
30 Jul 2020

Do user stories replace requirements? ›

User stories doesn't replace the full set of requirements of RUP, but this is not necessary and you are not limited to user stories.

Do we create Brd in agile? ›

Before any IT organization builds an application for customers or business stakeholders, it should understand how to create a detailed BRD, particularly for Agile teams to use.

What is requirement documentation? ›

A requirements document

requirements document
A product requirements document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.
https://en.wikipedia.org › Product_requirements_document
defines what is needed from the product. It states the product's purpose and what it must achieve. It does not define how to deliver or build what is needed.

What are the types of documentation? ›

The four kinds of documentation are:
  • learning-oriented tutorials.
  • goal-oriented how-to guides.
  • understanding-oriented discussions.
  • information-oriented reference material.

How do you create a product documentation? ›

How to create product documentation
  1. Know your audience. It is important to understand your user when creating documentation (much as you would when creating the product). ...
  2. Keep your documentation simple. ...
  3. Use diagrams. ...
  4. Accept the truth: People do not read product documentation. ...
  5. References.

How do you write PRD medium? ›

OK, how can I write a good PRD?
  1. Objective of the feature.
  2. Goals of the feature.
  3. (optional) Important notes.
  4. Assumptions.
  5. User Requirements ie. features/user stories.
  6. User workflow using draw.io.
  7. Use Cases.
  8. User actions — system requirements and wireframes for each Use Case.
3 Jul 2019

How do you document requirements gathering? ›

A 6-Step Requirements Gathering Process
  1. Identify the relevant stakeholders.
  2. Establish project goals and objectives.
  3. Elicit requirements from stakeholders.
  4. Document the requirements.
  5. Confirm the requirements.
  6. Prioritize the requirements.

Why do we need product documentation? ›

The purpose of product documentation is to communicate relevant information about the product to the people who need that information, when they need that information.

What is requirement documentation? ›

A requirements document

requirements document
A product requirements document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.
https://en.wikipedia.org › Product_requirements_document
defines what is needed from the product. It states the product's purpose and what it must achieve. It does not define how to deliver or build what is needed.

How many pages should a PRD be? ›

First of all, it is worth mentioning that you can have your PRD in any size. Meaning that most of the samples online will start from one-page-fit-it-all PRD and end up with documents of 3-5 and up to 10 pages or more.

What are product requirements examples? ›

15 Examples of Product Requirements
  • User Stories. Requirements that capture expectations for the product. ...
  • Customer Requirements. Requirements contributed by a customer such as a lead user. ...
  • Business Rules. Business rules that define the operation of the product. ...
  • Usability. ...
  • Customer Experience. ...
  • Brand. ...
  • Functions. ...
  • Features.
14 Aug 2017

What are the six most common challenges when gathering requirements? ›

Requirements gathering challenges and solutions
  • Undocumented processes. ...
  • Conflicting requirements. ...
  • Lack of access to end users. ...
  • Focusing on visual aspects rather than on functional. ...
  • Stakeholder design. ...
  • Communication problems. ...
  • In summary.
27 Oct 2020

What does a good requirement look like? ›

A good requirement states something that is necessary, verifiable, and attainable. Even if it is verifiable and attainable, and eloquently written, if it is not necessary, it is not a good requirement.

What are 2 key attributes to well written requirements? ›

Feasible: The requirement can be implemented within the constraints of the project including the agreed upon system architecture or other physical design or implementation decisions. Unambiguous: The requirement is written objectively such that there is only a single interpretation of the meaning of the requirement.

What are examples of requirements? ›

The following are common examples of requirements:
  • Accessibility. Requirements designed to ensure that products, services, interfaces and environments are accessible to people with disabilities.
  • Architectural Requirements. ...
  • Audit Trail. ...
  • Availability. ...
  • Backup And Restore. ...
  • Behavioral Requirements. ...
  • Capacity. ...
  • Customer Experience.
22 Mar 2021

Videos

1. Lean mean Protein machine
(KeepinitSimple)
2. How to create a lean, mean product roadmap by Prof. Rajeev Kumra
(WileyNXT Online)
3. Robert Li: How to create a lean mean lead generating machine using marketing automation and WordP...
(WordPress)
4. DUDE Wiper1000 - A lean, mean poop destroying machine
(DudeProductsTV)
5. How To Sterilize Nail Bits - Enbio Autoclave
(Erica's Dry Manicure + Pedicure)
6. Make your facility a Lean, Mean Profit Machine
(Chase Jackson Energy Easy Founder)

Top Articles

You might also like

Latest Posts

Article information

Author: Laurine Ryan

Last Updated: 11/11/2022

Views: 6010

Rating: 4.7 / 5 (77 voted)

Reviews: 92% of readers found this page helpful

Author information

Name: Laurine Ryan

Birthday: 1994-12-23

Address: Suite 751 871 Lissette Throughway, West Kittie, NH 41603

Phone: +2366831109631

Job: Sales Producer

Hobby: Creative writing, Motor sports, Do it yourself, Skateboarding, Coffee roasting, Calligraphy, Stand-up comedy

Introduction: My name is Laurine Ryan, I am a adorable, fair, graceful, spotless, gorgeous, homely, cooperative person who loves writing and wants to share my knowledge and understanding with you.