Chapter 13 /17— Writing Good PRD & Managing Product Backlog
[Prev: Chapter 12 — How to develop Product Roadmap ]
[Next: Chapter 14 — Product Prioritization ]
[Back to — Product Management 101 ]
Once your team moves to the “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 –
- Intro, Vision & Goal
- Who’s it for
- Why build it
- Competition & Product Inspiration
- Architecture, Features, Mockups & UX Flows
- Release Criteria & Plan
- Go-to-Market Plan
- Future Ideas
Product Hunt PRD –
https://docs.google.com/document/d/1yrU5F6Gxhkfma91wf_IbZfexw8_fahbGQLW3EvwdfQI/edit
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?
[Prev: Chapter 12 — How to develop Product Roadmap ]
[Next: Chapter 14 — Product Prioritization ]
[Back to content page — Product Management 101 ]
Want to learn more?
Enroll into Product Management:A-Z — The complete product management online course with 25+ chapters, 40+ live assignments and product interview tips . Built with inputs from experienced Product Managers working @ Top Tech firms like Google, Adobe, Amazon; the course has 500+ enrollments from 40+ countries.
Book Mock Interviews with product experts to practice your interview skills & get detailed feedback.
Check out PM Interview Questions — An exhaustive list of unique Product Management interview questions answered by product experts.
Click 👏 if you found this useful. SHARE to help others find this article.
It gives me 🔋 to write knowing people find value in it.
Originally published at zapupp.com
