Published in Inspiration

How Notion built a product management system to align every team

By Madhu Muthukumar

Former Chief Product Officer, Notion

10 min read

When hundreds of support tickets started flooding in one night, we knew we were reaching a breaking point. Engineering had launched a new feature without support knowing, and we scrambled to respond to customer questions the rest of the night.

But it wasn’t just that. For weeks leading into that launch, Product marketing was poking a dozen engineers to fill out the release notes every week. Different teams were running their own status meetings to keep track of the same launch. Collectively, we were wasting a lot of time trying to communicate.

Notion was growing — we had five engineering teams, and multiple projects were progressing in parallel. But few people could understand everything that was shipping, or why. If we couldn’t find a better way to coordinate across teams, we weren’t going to be able to scale our business.

Every startup has these growing pains. I’ve seen this same situation happen on product teams at Twitter, Oculus, Robinhood, and now Notion (we’re not immune either!). So I thought I’d share how we designed a solution for our own team.

In this piece, we’ll walk through the systems and processes we put in place to keep every team updated on our engineering and product work. We’ve included templates, too — so you can immediately apply the best parts to your own team.

Standardize the best ways you work

When I joined Notion, one of the first things I did was talk to engineers and designers about the ways that they typically built and shipped products. Some teams used formal task and sprint systems, while others kept updates in one big, collaborative doc.

I’d seen this before: As companies grow, different teams develop different habits, making it difficult to coordinate work. That’s ok! Teams should work however works best for them, especially in a remote work world. But we needed to standardize how we communicated about the work our teams were doing.

But how do you know what to standardize if everyone’s doing things their own way? Figure out what everyone is using mostly the same way, and standardize that.

At Notion, our engineering, product and design groups were mostly centered around three concepts: teams, projects and tasks (you can find our definitions for each below). We spent time defining each component, then codified them in a company-wide doc so that everyone was creating projects the same way.

Agreeing on what not to standardize is important, too. For example, we don’t dictate how teams have meetings, or what mockup tools to use. Pick a couple of ground rules, then allow people to work freely.

Build a product management system that speaks to every team

Identifying and standardizing these components helped us organize all our work across every product and engineering team. But then, we needed to consistently communicate to the rest of the company about this work and in a language they understood.

To do this efficiently, we built a communication system with four parts:

  • Teams — A set of people that contains projects.

  • Projects — A discrete, independently shippable set of work that can be broken into tasks.

  • Tasks — Work items assigned to an individual.

  • Updates — A quick, readable summary of each project, due every 2 weeks.

Some parts help the engineering teams coordinate with each other, and some parts, like the updates, speak to the rest of the company. Each of these is a Notion database, with all of them linked together to create the system. We think of this system as having four layers, with each one providing a different level of context for different teams.

Your system will probably look different — it might live in spreadsheets or a folder of docs. You might organize your work in sprints or milestones. But if you’d like a starting point, we’ve included our exact setup below as a template.

Let’s walk through each part of the system, how we structured it, and what audience it serves.


Clear owners make for organized projects. But making an accurate list of teams is harder than it looks. The way that you build software doesn’t look like an org chart. You’re looking for the virtual groups that people really work in to ship something. That might include a lot of functions you don’t typically think of on the same “team,” like an engineer, a designer, a product marketer, a lawyer, and likely a few others.

A good way to find these teams is to look at the Slack channels people make to coordinate on project work. Those channels can usually tell you the unofficial teams that are currently functioning.

After you’ve found these teams, you can build a roster that’s as simple or as complex as you want. On ours, we include the team name, who’s on the team, and a brief description of what they do, plus a couple other useful things like their Slack channel and team charters.


Once you have your teams, you can identify projects for each of them. For us, projects are the “thing” that can be shipped, and are most often the things that people in the company care most about.

This is also where teams like Sales, Legal, and other engineering sub-teams care — they may not be actively building the project but often want to understand progress to do their best work. And they all want the same level of context:

  • What the project is solving

  • What’s the status

  • When it’s shipping

  • Where to dive deeper into designs and decisions

Our Projects database is optimized to answer those questions: it includes project name, a “tl;dr” description, status, launch date, and pointers to the more detailed project docs. We display them in a table format so that anyone can scan the list of active projects and immediately get the answers they need.

Here’s the full list of properties we include in our project tracker


Once projects are properly identified, the engineers, designers, and product managers can break them down into manageable tasks. These should represent the project team’s day-to-day work, and should be specific and detailed enough for the people doing the work. If you try to make tasks understandable to everyone, they become vague and useless.

To make tasks understandable to the people executing them, we use specific properties to track priority, QA status, the assigned engineer, the related project, and anything else engineers need to get their work done.

Weekly updates

The final layer is for folks who don’t know what projects they’re interested in. If lots of tasks make up a project, then lots of projects make up an update. People aren’t going to scan a list of fifty projects. They want to be shown what to pay attention to.

Because weekly updates are for the entire organization, I write them myself in plain, readable English. I pull the content from the individual product updates that each engineering team writes, then write them in Notion pages so that it’s easy to find and search through older updates. But you could format them as emails or docs too.

Currently, I structure weekly updates into three buckets:

  • What’s shipping — Simply a list of everything that shipped to external customers that week.

  • Announcements — Things that are making progress, good or bad. Examples of what you might put in here are a new PRD or significant delays on a project.

  • FYIs — Learnings from recent projects or general changes across the product and engineering org.

But you should expect this structure to change as your company’s priorities change. Right now at Notion, we’re interested in what’s shipping and making sure all teams are aware of those plans. If your team is rallying around three big rocks, your update could focus on how those are progressing.

A self-reinforcing system is a successful one

Everything we just said? All of it goes out the window if no one uses your system. To make sure ours was successful, we needed to show people the value of it.

Our goal was to keep everyone on the same page, while asking for as little additional work as possible. It’s a tricky balance. To do this, we found as many ways as possible to connect parts of the system to each other. That way, adding information to one part makes the other parts more valuable, incentivizing folks to keep contributing to the overall system.

For example, I embed the project tracker at the bottom of every weekly update. Anyone who’s interested in learning more about a particular project knows exactly where to go to get more details. By doing this, I create incentive for the engineering team to keep the list of projects up to date.

Individual engineering teams also embed a filtered view of the tasks database inside each project doc with only the related tasks visible. Anyone who opens the project page can immediately see how the work’s been broken down and how far it’s progressed.

Linking to other departments’ systems reinforces the value too. Take Product Marketing — they look to the external launch dates in the Projects tracker to populate a launch calendar.

Building a product takes a village

By the end of this process, we built a system to track all of our product and engineering work in one place, and communicate it to the rest of the company with minimal overhead. We hope it’s a helpful framework to take back to your team.

But things change fast at startups! As we grow, the exact system we use will change. Yours will too.

So as your systems evolve, we’ve found that understanding what different teams need to know is what’s most important. It takes a whole company to build a product. And keeping everyone’s needs in mind is how we’ve maintained transparency as we scale.

Share this post

Try it now

Get going on web or desktop

We also have Mac & Windows apps to match.

We also have iOS & Android apps to match.

Web app

Desktop app