Notion is among the fastest-growing productivity apps in the world — fourth on Okta's 2023 Business at Work rankings — with over 20 million users. Michael Manapat, who serves as Chief Product and Technology Officer, sat down with Lenny Rachitsky to walk through the operating model behind how Notion builds product: a tiny PM team, a four-point review process, twice-yearly planning cycles, and an engineering culture where everyone is expected to have opinions about the product.
Notion has under 15 product managers out of 550 employees. That is a very small PM organisation for the engineering size. How does that work?
Both Notion and my former employer Stripe are both very engineering-driven to start, and both companies have a very product-minded engineering core, which I think is a great thing. That said, there is a difference between engineers who think about product, and product managers who are out there talking to users and bringing in user feedback constantly, coordinating closely with go-to-market teams, and thinking deeply about product strategy. And I think that was missing at Notion early on. We didn't have PMs until two years ago, at around 50 or 60 engineers. I'm not sure this was actually ideal. So I'm glad we have PMs now and that we're growing the product management team.
How do you handle planning? What does the cycle look like at Notion?
I make the joke that we change how we plan every planning cycle and that we need to plan for planning. Historically, we didn't really look beyond what we wanted to do in a given half. And that's actually something we have recognized is a bit of a problem, in that we're always solving for what we can do in a few months and not thinking as holistically as we could be about the long term.
We roughly plan for each half, with differing resolutions for the two quarters. As an example, at the beginning of this year, we said for Q1, list out all of your projects in detail with a prioritization of the roadmap, and for Q2, just give some high-level bullet points of what you think you'll be working on. We then did planning for Q2 as the quarter started, taking those bullet points and making them concrete, with some added guidance for things that changed in the company strategy between Q1 and Q2. These days all product teams operate on two-week sprint cycles, and those cycles are all aligned across the organization.
Do you use OKRs?
Yes, we use OKRs at the company level as part of planning. The output of each of these twice-yearly planning cycles is a set of company objectives and a set of key results. There's more variation below the company-level OKRs. Some teams or groups do have OKRs; for example, teams working on product-led growth. In other areas, things are sufficiently nascent that a lot of our key results end up being like "ship this thing." I would say we're certainly far from Google, where they have OKRs at the company, the group, the team, and the individual level.
“We change how we plan every planning cycle. We need to plan for planning.”
Tell me about the four-point product review process. Where did it come from?
We used to have something that we called "working sessions." They would be between 30 and 45 minutes and relatively unstructured. What we found was we needed a bit more structure to make sure things were moving along. We also wanted to make sure that feedback from our co-founders Simon Last and Ivan Zhao and me was coming at known moments, and not just two days before launch, seemingly out of nowhere.
So now we have a process where at four points in the product development process, we have a "check-in." The four points are: (1) the statement of the user problem; (2) a discussion of possible directions — what are the three or so high-level possible approaches to solve the user problem, and what does the team recommend?; (3) the full solution, with high-fidelity designs and everything scoped out; and (4) the ship candidate, ready for a final quality check. All of these are predominantly asynchronous. At each of these steps, an engineer, designer, PM, or EM will send an email describing where they are, and then we'll review and give feedback asynchronously.
Is the four-point review fully async?
We've discovered that async check-ins don't work for some types of discussions. What are all the options you explored, and how do you think about each of them? Why did you choose them? Putting that in a doc and explaining that in writing takes a lot of time. People were spending way too much time documenting this stuff, and then when you take into account the email exchanges and then the responses and all of that, the process would drag out for quite a while.
So we're tweaking our approach. For the exploration-of-the-directions step, we're going to start focusing on in-person discussions with the team. Come in and let's stare at Figma together, discuss the pros and cons of each variant, ask questions, and align on reasoning. We normally schedule those types of synchronous check-ins for half an hour.
“We only ask for projects with meaningful product impact to go through the four-point check-in. Not every single change — but anything that matters.”
How is your organisation structured? Engineering, product, design all reporting to you?
We have a unified product and technology organization — engineering, product management, design, data, user research, and security all roll up to me. Our data lead, design lead, research lead, engineering and product management group leads, user research lead, plus the person working on our overall technical approach and our CISO — they're all peers and my directs, and we frequently meet and plan together.
I personally really like this, because you get a lot of crosstalk and exposure to what's going on with all of those people in the same room. Everyone has visibility into what the organization overall is working on, and you find that more gets surfaced proactively when you have a mixed leadership group like this.
How do you think about team structure? What are the layers?
Right now there are essentially four layers of teams. There are teams working on user-facing use cases or stories or workflows — for example, the project management team, or the docs and wiki team. Below that, figuratively speaking, there are teams that own what you might call underlying primitives, things like databases in Notion. Databases actually power both the wiki and also project management, so the team thinking about wikis and the team thinking about project management are both "clients" of this databases team, which we call "Collections" internally.
And then below that there are Notion-wide systems, like search, notifications, the sidebar, and so forth. And then below that is Infrastructure. One thing that's interesting about Notion is that no part of the product can really be isolated. You can't decompose Notion into individual products — if you change how databases work, or how pages work, that has implications for the use of Notion as a docs tool or a wiki tool. So there is a central planning and product coordination problem here to make sure things are considered holistically.
What tools does Notion use internally?
We use Notion for almost everything — writing, project management, presentations, etc. And we hope at least for product teams that it really can be almost everything for them. The "almost" here is a reference to the fact that some important things you do in product — for example, design (we use Figma), experiment setup and analysis (we use Statsig), or data analysis (we use Hex) — you can't do in Notion, and these aren't use cases that would make sense in Notion, at least for a while. You can embed your work from many of these tools in Notion, of course, which helps keep Notion the "hub" for all our work.
“There is a central planning and product coordination problem at Notion. You can't change how databases work without affecting every product surface.”
What is launching with Notion Projects?
Traditionally you needed to do a fair amount of setup to get the sort of project management framework — with projects, tasks, subtasks, etc. — in Notion that you might in another, project management-specific tool. It was possible given the generality of Notion's primitives but not always easy. Starting on the 31st, you'll be able to add our new project management tools to any teamspace, and it'll be much easier to use Notion for project management, whether for general use or for issue-tracking for engineering and product teams, and there'll be direct support for things like sprints.
Notion AI is also getting extended so that it'll automatically infer and complete information for you — by keeping project properties updated as other information changes automatically. We think this will be a big advance for how people use Notion for project management.