How to manage your Product backlog in Notion.

Cover image: How to manage your Product Backlog in Notion.

Nowadays we have so many different tools that make our life easy, there’s no excuse in using Excel anymore 🙃 just kidding, you can use anything you want as long as it makes sense to you, but if you’re working with others, your colleagues also need to be comfortable using it since teamwork is crucial to the success of a project. In my case, the tool that I’m most comfortable with is Notion, it’s been 3 years since I first discovered it and to be honest it became one of my most used tools.

I use Notion for personal purposes and work purposes, such as documentation repo of almost everything, task management, taking minutes, even as main deliverable, and also to manage a product backlog.

To manage a project/product, you definitely need a list of broken down pieces of work, call them tasks, issues, user stories, or to-dos, that will need to be refined, defined and designed (not all of them) and then passed down to the dev team. I input all these tasks in a table as presented in Figure A that has 7 columns: tasks/issues, status, priority, effort, epic, type, and version.

Figure A. Screenshot of a Product backlog in Notion

This is the information required in each of these properties also called fields:

• Tasks: the piece of work, to-do, issue, or user story.
• Status: where in the development process are we in each task.
• Priority: the importance of each task.
• Effort: how much work we need to put in to complete this task.
• Epic: body of work this task belongs to.
• Type: type of request that led to the creation of this task (explained further in this article).
• Version: version of the product in which this task will be included (ie. MVP, V1, V2).

One of the things I like about Notion is that it’s very customisable to each team, project, product, or company. You have total freedom of designing how anything will be represented, in this case, the product backlog in Table A is what worked for ourselves. It is important to mention that you have the ability of also modifying tools such as Jira or ClickUp to the needs of your project; you can create custom fields or your own workflow, I just find it’s easier to do it in Notion.

Process

Now that we’ve created our layout, we need to start populating this backlog to get the project going. This process usually goes like this:

1. New task created

I normally receive a new task from client/stakeholders, or from within the team. The first thing that I do is to describe what this task is about and anything else that gives context to the task to reduce uncertainty and ambiguity. Then, I set the status to ‘To start”, this is how I use all status:

• To start: when all I have is a brief description of the task that will be groomed later.
• Requirements: I change to this status when I start collecting all the functional requirements and acceptance criteria. Sometimes when I first log the task I ask the appropriate questions to collect requirements at the moment and save time.
• Design: if this tasks needs design, it’s then moved to this status for the designer to start working on it.
• Under review: if you need approval from client (in this case we did) this is the moment in the process where we show the solution proposed to the relevant stakeholders to provide feedback and approval.
• Tech specs: when a task is in this status, it’s now time for the tech lead to take on and document the technical specifications and logic.
• Sprint: when task changes status to Sprint, it means that it’s already in the dev backlog and has been added to the current sprint to get built. The dev backlog lives in Jira, why? that’s another story.
• Completed: we change to this status when the task is already built and has been QAd.

You can see how the status look in Notion in Figure B.

This is where the whole process ends, but we have a couple more status.

• 🔴 Blocked: blockers exist, and even though we all hate them, we need to embrace them. I’ve found that including a status with a big red dot calling for attention really makes the client worry and pushes them to work faster and unblock.
• Descoped: we use this status for tasks that will no longer be built, but we leave them in case they enter the backlog in the future.

Figure B. Status property set to Select.

2. Categorise the item

All items are categorised in the column called Type (Figure C), depending on their function and their reason of existing in the Product backlog. The categories are:

• Design Changes: these are changes in the interface of the platform. I add here Design debt.
• Product Features: new features or epics that will soon be developed.
• Data & Analytics: any task related to tracking user behaviour in the platform, gathering insights, and KPIs.
• Bug 🐞: Any dev bug or design bug found that needs to be fixed.
• Client request: any new request made by the client.
• User feedback: improvement (and sometimes requests) based on analytics or feedback from the user.
• Technical debt: functionality or piece of code that needs to be refactored.

Make sure to include in this step the version of the product this new task will be developed into, this should be mapped against the Roadmap and the version rollout planned at the beginning of the project.

Figure C. Type of request

3. Set the priority and calculate the effort size

It’s very important to handle priority carefully. Some people consider this to be a hard thing to do, in my opinion it’s pretty easy to understand the importance a task has. If the task impacts directly the user positively, if it improves the usability, ease of use, and overall UX, consider it as high priority.

I normally use four different priorities, P1 🔥 being high priority, and P4 a nice-to-have. You can adapt the MoSCoW prioritisation framework to your Product backlog as well.

Finally, make a quick calculation about the effort size of the task. If you are a more Senior Product Manager you can make the calculation based on past experiences/projects. If you are unsure, make sure to include a more Senior PM or ask your Tech Lead for her/his input. Use easy to understand units of measure, like high, medium, and low effort, and consider the effort when prioritising.

4. Close your items

When the items in the Product backlog are ready to enter the Dev backlog, the Product Owner starts creating the user stories in Jira and then we do a refinement session between the Product Owner, Product Manager, and Tech leads, facilitated by the Sprint Master to discuss the item and the expected functionality.

In Jira we usually include the description, user story, scenarios using the Given / When / Then format, acceptance criteria, designs, and diagrams.

After the tasks have been added to a Sprint in Jira is when the status is set to In Sprint; and once they are reviewed, QAd, and put into production, I change the status to Completed and continue with the rest of the backlog.

Conclusion

There are several tools that can help you manage your Product Backlog, make sure to select the most appropriate for you, your team, and your project; and establish the ways of working with the whole team since the very beginning to avoid future problems.

The tool that I find the most useful is Notion, given that it can be adapted very easily and you can design how to structure your backlog. What has worked perfectly for me is to create a table with columns for tasks/issues, status, priority, effort, epic, type, and version.

I hope that this reading helps you in creating and managing all the pieces of work that your product/project needs. Feel free to contact me with any questions and have a wonderful day.