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:

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

(Video) Creating a Lean Mean Marketing Machine

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.

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)

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

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

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.

(Video) Transforming Your AR Process into a Lean, Mean Revenue-Collecting Machine

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.

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.

(Video) Building a Lean, Mean, Lead Generating Machine with Outbound Prospecting

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)

Try Jira Product Discovery for free

Get it free

Share this article

Creating a lean, mean product requirements machine (9)

Dan Radigan

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.

(Video) How to create a lean, mean product roadmap by Prof. Rajeev Kumra

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.

Are prds agile? ›

A PRD helps you gather requirements in an Agile world

Lastly, and most obviously, a PRD helps Agile teams bridge the gap between high-level product requirements and the implementation details of the development-team. Gathering requirements is tricky in Agile and can even seem counter-productive.

What is the difference between MRD and PRD? ›

An MRD is often confused with a 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.

What are the key components of a PRD? ›

PRD is an overview of the key important details that needed for the potential project development. The document includes key goals, objectives, principles of implementation, expected results, required time and any additional technical requirements.

What are the 5 steps in product design? ›

Product Design Process: 5 Steps
  • Step 1: Target Market Research. ...
  • Step 2: Initial Concept Design. ...
  • Step 3: Sketches, Drawings, and more Sketches! ...
  • Step 4: Prototyping. ...
  • Step 5: Consumer Feedback.
13 May 2022

What are the 5 product design elements? ›

The Five Elements of Product Design
  • Product must be authentic. Identify a clear purpose and make that purpose apparent in its design.
  • Product must provide unique experiences. ...
  • Effective product design goes unnoticed. ...
  • Do one thing extremely well. ...
  • Solve pain points elegantly.
29 May 2018

How do you write a good MRD? ›

That said, here are the steps necessary to write an effective marketing requirements document:
  1. Step 1: Understand The Customers Pain. ...
  2. Step 2: Understand Your Competitors. ...
  3. Step 3: Identify The Essence of The Product. ...
  4. Step 4: Craft Core Requirements. ...
  5. Step 5: Define Nice To Haves. ...
  6. Step 6: Layout The Business Case.
5 Aug 2019

What is MRD process? ›

What is MRD? An MRD or Market Requirements Document, is a document outlining the needs of customers and helps you create a plan to meet those needs. Developing a Market Requirements Document involves collecting information that gives the context of a problem, who experiences that problem, and when that problem occurs.

What does PRD stand for product? ›

A product requirements document (PRD) is an artifact used in the product development process to communicate what capabilities must be included in a product release to the development and testing teams.

Is kanban agile or lean? ›

Kanban is a visual-based agile framework with a focus on optimizing the flow of work in a continuous delivery manner.

Is agile like Lean Six Sigma? ›

Agile methodology focuses on better management of projects. Lean Six Sigma methodology focuses on improving processes. Combining the two may be the key to maximizing process efficiency.

Is Lean Six Sigma considered agile? ›

When we look closely, Six Sigma and Agile methodologies can be deemed as conflicting approaches. This is primarily because they have different objectives. Six Sigma focuses on process control and standardization through reduction of defects and variation. Agile focuses on flexibility to change and incremental delivery.

Who writes PRD document? ›

A PRD 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 is the difference between MRD and BRD? ›

The Business Requirement Document (BRD) describes the high-level business needs whereas the Functional Requirement Document (FRD) outlines the functions required to fulfill the business need. BRD answers the question what the business wants to do whereas the FRD gives an answer to how should it be done.

Who is responsible for PRD? ›

The primary responsibility for a PRD falls on the Product Manager, but well-developed PRDs require the attention of multiple parties. Depending on what your product is, what it does, and who's responsible for making those things happen, a PRD may have a fair number of contributors.

What is the PRD model? ›

A PRD is a guide that defines a particular product's requirements, including its purpose, features, functionality, and behavior. This document is generally written by the Product Manager to communicate what they are building, who it is for, and how it benefits the end-user.

What is the difference between BRD and PRD? ›

A PRD is not the same as a BRD (business requirements document). The BRD describes the business needs of a specific project, not the purpose of product development. However, you'll likely need a BRD to support project execution after you have an approved PRD in hand and the development cycle begins.

What is the difference between PRD and SRS? ›

The PRD lists WHAT the system should do. (you know, it lists the business processes (requirements), and then details the functional and non-functional requirements resulting out of the business requirements. The SRS details / specifies HOW the system will do what's required. Nobody's perfect.

What are the 4 steps of requirements development? ›

In my experience, business, user and system/technical requirements development involves these 4 key steps:
  • Requirements Elicitation.
  • Analyzing Requirements.
  • Validating Requirements.
  • Documenting Requirements.
1 Sept 2010

What are the 5 D's in product development? ›

Discover, Design, Develop, Deploy, Deliver TM

This is what we call the “5D vision of Product Management”. Product managers need to consider, plan, and execute in all 5 Dimensions to create great products.

What are the 7 steps of product planning? ›

The 7 Strategic Phases of the Product Planning Process
  • Product Concept Development. This initial phase might be the most fun and creative stage in the product lifecycle, and it's the most critical. ...
  • Competitive analysis. ...
  • Market Research. ...
  • Minimum Viable Product development. ...
  • Introduction and launch. ...
  • Product lifecycle. ...
  • Sunset.

What are the 7 components of a product? ›

Initially 4, these elements were Product, Price, Place and Promotion, which were later expanded by including People, Packaging and Process. These are now considered to be the “7 P's” mix elements.

What are the 4 P's of design? ›

The 4 Ps of Service Design

People. Products. Partners. Processes.

What are your top 4 tools for product design? ›

Prototyping & Design
  • Adobe XD: Fast & Powerful UI/UX Design Tool.
  • Figma: An Interface Design Tool.
  • Sketch: The Digital Design Toolkit.
  • InVision: Digital Product Design & Workflow.
  • Flowmapp: Visual Sitemaps.
  • Adobe After Effects: Stunning Animations of All Sorts.
  • Adobe Illustrator: To Illustrate.
21 Dec 2021

What are the essentials of a good requirement document? ›

Any good requirement should have these 6 characteristics:
  • Complete.
  • Consistent.
  • Feasible.
  • Modifiable.
  • Unambiguous.
  • Testable.
21 Mar 2016

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

What is SRS template? ›

What Is a Software Requirements Specification (SRS) Document? A software requirements specification (SRS) is a document that describes what the software will do and how it will be expected to perform. It also describes the functionality the product needs to fulfill all stakeholders (business, users) needs.

How is MRD testing done? ›

Minimal residual disease testing uses highly sensitive methods. The most widely used tests are flow cytometry, polymerase chain reaction (PCR) and next-generation sequencing (NGS). These tests use samples of bone marrow cells (taken by aspiration) and/or peripheral blood cells (taken through a vein).

What is an MRD assay? ›

Measurable or minimal residual disease (MRD) testing is used to see if the cancer treatment is working and to guide further treatment plans. MRD testing is mainly used in blood cancers (leukemia, lymphoma and myeloma), but is being studied in other cancers.

How many cells are needed for reliable MRD? ›

RQ-PCR–based MRD studies require, for each follow-up time point, ≥2 × 106 cells, which is sufficient to extract ≥6 μg of DNA, needed for analysis of ≥2 MRD-PCR targets in triplicate and the control gene in duplicate.

What is MVP in PRD? ›

To take a step back, a software engineering MVP is defined as the Minimum Viable Product. Meaning, the first point in the product's lifecycle at which your product has the minimal feature set and performance specifications such that it has some usefulness to a customer.

Who writes requirements in Agile? ›

The Agile project manager works with the product owner to translate the BRD into a series of epics that define the product. These two then translate features to user stories. Here, developers meet the functional requirements to fulfill the business requirements.

Why is PRD important? ›

A PRD 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 are the 7 Lean principles? ›

The seven Lean principles are:
  • Eliminate waste.
  • Build quality in.
  • Create knowledge.
  • Defer commitment.
  • Deliver fast.
  • Respect people.
  • Optimize the whole.

Is Kaizen a Kanban? ›

In general, Kaizen can be thought of more as a model or philosophy of management, while Kanban takes on a more tactically-oriented approach. One of the key similarities in the two approaches is their attempt to identify and remove waste or inefficiency that's in a system.

Is Kaizen same as Kanban? ›

Kaizen boards specifically manage Kaizen efforts, whereas Kanban boards generally represent workflow. However – many teams choose to manage their Kaizen efforts as a workflow – some version of To Do, Doing, and Done – making a Kanban board a natural fit for their Kaizen practice.

What replaced Lean Six Sigma? ›

Total Quality Management (TQM)

Total Quality Management predates Six Sigma and Lean methodologies, gaining a lot of attention in the late 1980s when the US Federal Government began using it. Success results from customer satisfaction within this system.

Which is better Six Sigma or Kaizen? ›

Six Sigma vs Kaizen: Differences

The main difference between Six Sigma and Kaizen is that Six Sigma uses technical data that are oriented to solve product deviations. In contrast, Kaizen focuses on making work environments better, which has a positive impact on overall performance.

Why is Six Sigma better than Lean? ›

Lean strives to maximize value to the customer while using a few resources as possible. Six Sigma strives for near perfect results that will reduce costs and achieve higher levels of customer satisfaction.

What is the difference between Lean and Lean Six Sigma? ›

The Lean Method

The primary difference between Lean and Six Sigma is that Lean is less focused entirely on manufacturing, but often shapes every facet of a business. Lean Six Sigma combines these two approaches, which creates a powerful toolkit for addressing waste reduction.

Is Kaizen a part of Six Sigma? ›

When it comes to the Lean process, Kaizen and Six Sigma are both offshoots. Kaizen is rooted in the idea that making small, continuous positive changes can lead to significant improvements.

Why Agile is better than Lean? ›

The difference is that in Lean thinking, teams increase speed by managing flow (usually by limiting work-in-process), whereas in Agile, teams emphasize small batch sizes to deliver quickly (often in sprints).

What is a PRD form? ›

PRD overview: A product requirements document (PRD) contains all the requirements for a product so that the product development team can understand what that product should do. PRDs are typically written by a product manager before the team begins work.

What is a project PRD? ›

A product requirements document (PRD) is an artifact used in the product development process to communicate what capabilities must be included in a product release to the development and testing teams.

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.

Who writes product requirements? ›

A PRD 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 is ERD and PRD? ›

By Fast Radius July 12, 2021. An engineering requirements document (ERD) is a statement describing the goal and purpose of a new component. Unlike a product requirements document (PRD), which tells engineers what they need to build, an ERD specifies why a part is being built and how its design fuels its purpose.

What are the 4 types of documentation? ›

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

What are the five 5 Principles of document design? ›

This publica- tion, created for anyone with an interest in designing effective documents, covers the principles of document design: balance, proportion, order, contrast, similarity, and unity.

Videos

1. Make your facility a Lean, Mean Profit Machine
(Chase Jackson Energy Easy Founder)
2. 6 Ways to Create Generational Wealth And How To Pass It Down To Your Kids
(Valuetainment)
3. How to create a lean mean lead generating machine - Robert Li @ WordCamp Brisbane 2019
(WordCamp Brisbane)
4. Lean. Mean. Hauling Machines. | John Deere L-Series Production-Class Wheel Loaders
(John Deere)
5. Lean, Mean, Testing Machine
(Apptimize)
6. DUDE Wiper1000 - A lean, mean poop destroying machine
(DudeProductsTV)

Top Articles

Latest Posts

Article information

Author: Maia Crooks Jr

Last Updated: 01/18/2023

Views: 6442

Rating: 4.2 / 5 (63 voted)

Reviews: 86% of readers found this page helpful

Author information

Name: Maia Crooks Jr

Birthday: 1997-09-21

Address: 93119 Joseph Street, Peggyfurt, NC 11582

Phone: +2983088926881

Job: Principal Design Liaison

Hobby: Web surfing, Skiing, role-playing games, Sketching, Polo, Sewing, Genealogy

Introduction: My name is Maia Crooks Jr, I am a homely, joyous, shiny, successful, hilarious, thoughtful, joyous person who loves writing and wants to share my knowledge and understanding with you.