Chapter 13 – Writing Good PRD & Managing Product Backlog


[PreviousChapter 12 – How to develop Product Roadmap]

[Back to content page —  Product Management 101]

Once your team moves to “Build” stage, it is necessary for the development team to understand the previous research, product vision as well as the roadmap.

PRD (Product Requirement Document) is the answer to keeping all the team members on the same page. It serves as a single point document where all the team members and stakeholders can understand the purpose of the product and requirements.

The PRD doesn’t need to be an exhaustive document, but it should provide a basic idea of what the product would be.

A good PRD should have the following sections –

  1. Intro, Vision & Goal
  2. Who’s it for
  3. Why build it
  4. Competition & Product Inspiration
  5. Architecture, Features, Mockups & UX Flows
  6. Release Criteria & Plan
  7. Go-to-Market Plan
  8. Future Ideas

Product Hunt PRD –

Post developing your product roadmap; once, you start digging into different problems areas, you’ll be overwhelmed with the numerous tasks, requests, and feedback from multiple sources.

Product Backlog is the answer to managing these requests.

What is Product Backlog

A product backlog is an ordered (in form of priority) list of everything that is needed for the product. The list might contain –

  • Features (in form of user-stories)
  • Bugs
  • Technical Tasks (e.g. Database Changes, Micro-services Upgrade)
  • Knowledge Tasks (e.g. Researching new Technology, Incorporating new Algorithm)
A Product Backlog is ever-evolving

You’ll be constantly getting new items from multiple sources — development team, prospects, management, marketing and, most importantly, your customers.

Hence, you’ll have to constantly take in all the requests, prioritize and manage those requests.

A good Product Backlog should be –
– Prioritized
– Detailed
– Estimated
– Updated

Building a Product Backlog

The following process can be used to build Product Backlog –

New Issues — All new issues (Feature Request, User Stories, Ideas, Feedbacks, etc) lands in this section.

Ice Box — If the task is important but you don’t have any current plan to work on that, it is moved into Ice-Box.

Backlog — If a task is intended to be completed, but it is not yet ready to be developed (need more details or team has no extra capacity), the task is moved into Backlog.

Sprint Backlog — Sprint Backlog is created by moving tasks (or issues) from Backlog in the sprint. By this time, each task in backlog (that is being moved into the sprint) should contain detailed user stories, acceptance criteria, and time estimate.

In Progress — All the tasks (issues) that the team is working in the current sprint.

Done — All the tasks that are completed.

Closed — If any task wouldn’t be attempted (as decided by the team), it is moved into Closed Section. However, it can be re-opened again.

Read in detail on managing backlog via this blog by folding burritos.

If you need to revisit how to write & estimate user stories, you could refer to Chapter 7 – How to write User Stories?

User Stories

User Story Estimation

[PreviousChapter 12 – How to develop Product Roadmap]

[Next: Chapter 14 – Product Prioritization]

[Back to content page —  Product Management 101]

LIKE & SHARE if you found this article useful.
It gives me 🔋 to write knowing people find value in it.   

Share & Help others find the resource