How we use Notion to manage our product backlog / bets

At Climate Policy Radar, bets are things we might do that might improve our product. We frame these as problems we need to solve or solution ideas that we think might add value. This post explains how we keep track of bets from initial idea to completion. Most other organisations would probably call this a product backlog, but internally we like to talk about these as bets.

Why bets instead of features, improvements or product backlog items?

There is lots of uncertainty in product development. When you start out with a problem to solve, you don’t know what the solution will be. And there’s always a good chance that new features won’t have the desired impact. Everyone has a mental model of bets which captures this uncertainty. So to help us keep this uncertainty front of mind, we decided to think of a new feature or product backlog item as a ‘bet’.

The bets database

All bets go into a Notion database which we have imaginatively named the Bets Database (you might call this a product backlog in your organisation). Notion databases are great because they allow you to filter, sort and view information in an infinite variety of ways.

Metadata for each bet

Each bet has four metadata fields

Status

Reflects the stage the bet is in. Most bets evolved from idea > discovery > delivery > done. Possible values include:

• idea
• blocked
• queue for discovery,
• discovery
• queue for delivery
• delivery
• done this week
• done for previous quarters

Tag

A dumping ground for all the structured metadata we might want to add. At the moment this includes:

• what product it is for
• milestone/project associated with it
• disciplines involved
• roadmap category
• labels we use during standups to flag things as needing discussion

Assigned

The team member(s) assigned to the bet

Linked Actions, Notes or Questions

We have a separate database called Actions, Notes & Questions where we keep track of all the tasks that need doing. Discovery/design activities and stakeholder coordination tasks go here. Developers like to use Linear for tech tasks so we keep those separate. Each action, note or question can link to one or more bets.

Template for a bet

Once prioritised, bets use the following template:

Title

A brief statement describing the thing we are doing in the smallest number of words that the team will understand. Titles are sometimes prefixed with a code to make them easier to find

Hypothesis statement:

All bets start with the statement “IF we solve this problem / deliver this solution THEN we will achieve these positive outcomes”. This keeps us focused on the value we want to achieve

Linear / Figma / Whimsical links

Once developers start working on a bet, we create a Linear project and link it to the bet. This enables us to quickly switch between engineering tasks in Linear and bet information in Notion. Any associated Figma designs or whimsical storyboards/maps we’ve created are also linked to at the top

Notes

Notes is a filtered list view of all entries tagged with #Note for this bet in the Actions, Notes & Questions database. We keep notes in this database because often actions & questions lead to useful product documentation. We want to minimise the number of different notion databases we have so that information is easier to find. By the end of discovery, most bets have at least 3 notes in them:

• problem discovery: includes everything we’ve learnt about the problem we are trying to solve
• solution options: the different options we explored, and why we made the choice we did
• solution requirements: only includes information about what we have agreed to build

Linked databases

Actions, Notes & Questions visualise the work that’s needed on each bet. Meeting notes associated with this bet are also displayed here.

Why we prefer a minimalist approach to Notion metadata and templates

We used to have a much more complicated template with lots of different metadata fields and lots of pre-written headings for us to fill in. However, we found that our main use of the bet page was as a container for information. From the bets page, we wanted to quickly access all relevant designs & documentation, and see a view of all work planned vs in progress vs done. We did not want to have to scroll through pages of metadata and information to find what we were looking for.

Different views of the bets database

Notion allows you to view databases as tables or lists, but I tend to use the board view for bets (which looks kind of like Trello). The three main views I like to use are ideas, priorities and done.

View 1. Ideas

This is a dumping ground for ideas which are not currently a priority.

The bet template is not used for ideas. Most ideas just include a title and maybe a sentence from the ideator explaining their thinking.

The ideas view also includes discovery work. Bets move toward the top as they move from idea > queue for discovery > discovery. I find it useful to view ideas alongside discovery work as I often need to move bets back and forward between these states.

Most people don’t look at the ideas board. That’s not a bad thing though. I prefer for people to focus on their priorities!

Why I don’t just delete all the ideas

A lot of product managers argue for deleting items from the product backlog when they are not an immediate priority. This is because of the overhead involved in triaging all those extra priorities, and the distraction it causes to the team. These are good points that are worth considering. But I prefer to solve this problem by filtering them out of the priorities view rather than deleting them entirely because:

• when people have ideas, most people like to write them down somewhere to share them with others. Better to have them all in one place where everyone knows where to find them rather than scattered around in emails, slack messages or random pages on Notion.
• sometimes bets get deprioritised after some discovery thinking has already happened. I don’t want to see that bet on my priority board, but I also don’t want to lose that information. Tagging it as an idea gets it out of everyone’s way without data loss.
• as a product manager, I find it useful to browse all the ideas every few months when we do strategic planning. I make sure they are all tagged by roadmap category (data in, data quality, UX/UI, platform) so that similar ideas are together. The effort required from me to do this is negligible
• as a team member, it is useful to have a look through the ideas list to get a sense of the types of directions the product might go in the future. This is particularly true of new joiners

View 2. Priorities

This is for bets prioritised for the current planning cycle.

When a bet moves into the discovery queue, I start using the full bet template.

The priorities view shows all work on a board view with bets flowing from left to right.

Blocked is for work that people can’t start yet even if they have the capacity. This is usually because there is another bet that needs to progress before this one can start.

Discovery is where we understand the problem we are trying to solve, ideate solutions and decide on the best one. Discovery is multidisciplinary and involves product, UX design and engineering. At the end of discovery, we know what we are going to build. During discovery, we use the linked Actions, Notes & Questions database to keep track of actions/questions we need to answer. We keep problem/solution documentation in the same database with a label of “Note”. This means it automatically appears in the notes list at the top.

Delivery is where our engineers actually build the thing. We keep track of engineering tasks in Linear. But artefacts like architectural decisions, requirements documents and user story maps live in Notion or Whimsical.

Queues exist for discovery and delivery. These are for things that are not yet in progress but are a priority. Queues are an excellent thing to visualise, as having too much work in queues is a form of waste.

Done this week shows all work done in the last week.

In our weekly team standup meetings, we walk the bets board from right to left, starting with “Done this week”. Not much getting done in a week is a warning sign for us that we are not delivering fast enough. When we walk through the other cards, if it seems like they need a bigger conversation, we add the label “Discuss after standup” and move on to the next card.

View 3. Done

This is for bets that are complete. I have broken up “done” into multiple statuses. These include:

• done this week (see above explanation)
• done for all previous quarters. This enables us to keep track of what work we did and when we did it.

Other views I like to use

We have lots of other views too including:

• priorities filtered by project/milestone or discipline involved. This helps us have more focussed conversations with specific team members
• a table view of all bets. I mainly use this to search the whole database with no filters applied when I want to do a full database search
• a filtered view of all bets showing only those assigned to me

Breaking bets down into smaller chunks

As bets go through discovery, we often decide to break them out into smaller chunks. When this happens, discovery documentation can become fragmented and hard to find. At the moment, we are handling this by

• moving the initial discovery bet into done
• breaking it up into smaller chunks
• prominently linking all the smaller chunks back to the original discovery bet

Duplication with Linear

The line between engineering work and bet actions can get blurred. It also sometimes feels like overkill to set up a linear project/task for a small bet which might only involve a small amount of engineering work. However, there are lots of things that the bets database is doing for us that it does much better than Linear. And the duplicated effort here is just a few extra clicks. Debatably this is an ok trade-off given the different strengths of both these tools. This is one area I am not entirely happy with in our approach, and we might try to consolidate tools in the future.