How we have setup Notion to help our startup stay organised

I am working at a startup of 13 people with big plans for the future. Notion is one of the main tools everybody in the team uses. This post describes how we have set up Notion to make information easy to find across multiple growing teams.

What is Notion

Notion is a note-taking and productivity tool. We use Notion for

• organising our ideas and documentation
• keeping track of work

We don’t use Notion for:

• tracking technical work. For that we use Linear
• file storage. For that, we use Google Drive

As you can see from the table below, in most places I have worked before the jobs that I am using Notion to do would have to be done by two separate tools.

Job to be done	Most places I’ve worked before	Climate Policy Radar
Tracking work	Trello	Notion
Organising ideas & taking notes	Wiki software (eg. confluence) or lots of linked Google Drive or Microsoft docs	Notion
Tracking developer tasks	Jira, Pivotal Tracker	Linear
File storage	Google Drive or Microsoft	Google Drive

How we have set up Notion

Notion allows you to create two types of pages:

1. Normal pages. These
2. Pages in databases

Normal pages include a page title and a flexible drag-and-drop content area. You can insert different types of headings, text, media etc into this content area. You can also embed content from third-party tools, such as a view from Linear.

Databases are normal pages with one crucial addition: customisable metadata. For all pages that belong to a database, you can add an unlimited amount of extra metadata fields. These enable users to visualise, filter and sort the database content in a multitude of ways.

How we use databases

Meetings and Communications is one of our main databases. Each page in this database has the following fields:

• Date (date field): so we know when the meeting happened / or comms got sent

• Type (select): eg. planning meeting, decision, premortem, weekly sync, 121

• Tags (multi-select): optional field used for anything else we might want to tag this by

• Participants (person): tags all the people who involved in this

• Links to pages from other databases: eg. any partnerships, bets or actions/questions this meeting or comms relates to

Having this content in a database means we can do things like

• Allow a team member to see notes from all meetings they have attended

• View all relevant meetings or comms related to a specific product bet or partner

• Find all content from a specific time period (which will come in handy in the future when we need to archive old content)

From the start, we have created common databases designed for reuse across the organisation. This means that data science & operations meeting notes get stored in the same place. If people want to view them separately they can create a view of the database and filter using tags.

Some of the main databases we use are

• Product bets: things we might do that might improve the product (aka product backlog)

• Actions, notes & questions: things we need to do, questions we need to answer or documentation of work we have done

• Meetings & comms: minutes for meetings, written communications or notes about work

• Partnerships: third party organisations we are working with, or planning to work with

• User research: interview summaries, analysis, scripts and planning

• User research PII database: a restricted database to keep track of sensitive data related to user research

• Papers: academic and research papers that relate to our work

• Tools we use: describes what they are, why we use them and how

• Glossary: words & acronyms we use along with definitions

• Team members: a place for everyone to introduce themselves to the team. Also includes a personalised view of all the databases

Databases are powerful, but less is more. Having more databases means

• Viewing/filtering/sorting becomes less powerful, as this can only happen on one database at a time

• People get confused about which database to find things in

• The information architecture of the organisation becomes more complex and hard to manage

We try to avoid creating new databases unless the benefits of doing so outweigh the cons.

How we use templates

For each database, I have at least one template. Templates enable me to prefill the page with any useful page elements or prompts at the click of a button. This means:

• Pages of the same type get structured and formatted consistently with minimum effort

• Complex links between database pages are mostly handled automatically. Though there is still a need to manually set up some of the links when you create a new page

Below is an example template for one of our bets.

Ownership & structure

Below is our top-level Notion structure (with the person responsible for maintaining that section in brackets).

• Home (operations lead)

• Comms & engagement (comms lead)

• Collaborations & partnerships (comms lead)

• Data science (data science lead)

• People (operations lead)

• Policy (policy lead)

• Product (product lead)

• Technical (CTO)

The whole team gets consulted before we make any major changes. We’ve found it useful to have one person responsible for each area so that someone can champion continuous improvement.

Public notion pages

Notion isn’t just for the team. We can choose to make some pages available to partners or to the public too. For example, Notion powers our public roadmap. We also have a notion database that we use to track all of the work we are doing with LSE which everyone from both organisations has access to.

Problems with Notion

Overall, I think Notion is a great tool, but not perfect. Here are some of the main problems I’ve found so far:

When copying and pasting data between different pages, tables are not copied. They need to be manually duplicated and manually inserted into the correct position on the page. It would be nice if I could select all and copy in the same way as I can on Google Docs or Word.

It can be slow to load at times. This may be a downside of having a database-heavy Notion setup.

Labels on cards don’t appear in a consistent order on the board view. They appear in the order in which they got added. This can make boards with lots of labels difficult to read.

Metadata on databases is super powerful. But every time you open a page in a database, the first thing you see is lots of separate metadata rows. This means you have to scroll a lot before you get to the content of the card. It would be great if Notion found a way to minimise the space this takes up in the UI. Similarly, when you view the metadata on cards in board view, the labels all appear on separate lines. Wrapping separate metadata fields instead of all the content being on a new line could fix this. Our workaround for both of these problems is to minimise the number of metadata fields we have in each database.

Thanks for reading

I hope you found this useful. Get in touch if you have any feedback. I’m particularly keen to hear from anyone who knows solutions to any of the above problems!