Distributed Product Ops with Notion
How I built a high-velocity product on a distributed, remote team using cascading objectives and a regular release calendar.
Businesses are driven by the cumulative impact of many small actions made by independently-functioning teams. While each team can celebrate their small wins without higher-level organization, the best outcomes happen when teams come together to build something greater than the sum of their parts. Good product operations create the right amount of trust, planning, and communication to make these teams more effective at building a successful product together.
In this blog post, I will share how I developed a strong product operations process at Rill. Rill is a globally distributed seed-stage startup with a team of about 30 people. When I created this process I did a lot of research on best practices and it struck me that most of the advice available on product operations speaks to small colocated teams or big distributed companies. My product ops framework is the result of many experiments in product development to focus our small distributed team on shared goals to ship focused, impactful features. Jump right into the template I created for a fictitious video streaming company in Notion to see a demo. Then read on to understand what applies to your organization.
Taking product ops from 0 to 1
When I joined Rill there were less than 20 employees. As we hired, I needed to shift Rill from a culture of founder-led product development to one that delegated trust and tactical decisions to the global talent being brought in. I started with a few truths about how we wanted to work together:
We need to connect the company's vision to a focused set of initiatives and features to be built.
We need to empower teams to have agency over their work.
We need to bridge the global communication gap across teams that do not have an overlap in synchronous working hours (9 am in California is 9:30 pm in India).
Our software needs to be built predictably, in the open, and at high velocity.
Aligning distributed teams around a shared goal
Aligned teams with a shared goal are successful because energy is invested in a small set of important things. Cascading objectives are a powerful resource to focus cross-functional teams in a measurable way. With cascading objectives, high-level goals are broken out by decision makers at all levels of the company (C-suite, tech leads, ICs) to increase an idea’s fidelity. Yet the true magic of the cascading objective framework stretches beyond accountability. The best products are built when we all share the story and trust each other’s expertise. We must shape the connection between a vision that we believe in and our day-to-day work together.
A good distributed product process helps everyone feel connected to our goals through collaborative touch points, documents, and roadmaps. I have broken out four product ops concepts around cascading objectives into a table to help you see how they relate to each other: Story telling, driving decisions, roadmapping, and accountability.
Story Telling
Story telling presents different challenges when working in a small distributed remote workforce. Because we do not have synchronous time together, it is necessary to develop a strong collaborative writing culture that describes how high-level goals flow into low-level tactics. In Notion this takes the form of brief templates that ensure the story is clear, concise, and relevant to the problem we want to solve.
North Star
What product goals do you want everyone to focus on and remember? The first step in getting everyone in your organization moving in the same direction is for the founder/CEO to present a clear product Vision that extends over the course of several years (why do we exist?).
Each year the vision is put into focus through a North Star ambition. This ambition is one big goal we believe will help us realize our vision. A effective North Star ambition is one sentence that clearly articulates what good would look like. This is paired with a Key Performance Indicator (KPI), or measure of whether we have achieved our goal and a paragraph where people can get more information about why the leadership team picked this direction.
Objectives
Once a North Star is established, there is enough paint on the canvas to help the leadership derive smaller Objectives that feed into our North Star. These objectives focus everyone on specific problems we want to solve to move the business in the right direction.
Objectives are agreed to and written down in Notion quarterly during leadership planning work weeks. We write a one sentence headline that describes the objective clearly and then tie this objective to a measurable Key Result that we believe will drive our KPI. Each OKR benefit from a paragraph explaining why this objective is achievable and important in driving our North Star.
Epics Themes
High-level Epic Themes capture threads of work across two week to three month windows. Epic Themes propose bets on the features and initiatives we want to execute on. They also hypothesize impact against a specific Objective. An Epic Theme consists of a business/user story that the sponsor wants to solve and a high-level summary of the solution.
Product Requirements
The product requirements doc (PRD) is the atomic unit of storytelling for tactics. A PRD is stubbed in by only giving it a title when Epic Themes are defined. However, before execution Product Requirements need to provide concrete, clear, actionable units of work scoped to about 2 weeks of effort. These concrete details support more accurate effort-sizing, scoping, and sequencing.
Decision Making
To make distributed decisions with confidence the team needed to build trust that they would be included in the right ways. I used Notion to build this trust by asking everyone involved in telling our story to participate in soliciting feedback and writing down decisions in Notion. Each story document has a Resources section with links out to any meeting notes or other documentation that supported it. This clearly separating ideation from action while keeping all inputs discoverable. In addition, to the decisions and definitions, the state of work is also managed directly in Notion using Status properties and the Kanban view. In this way, documentation and execution are done in a transparent and connected way with different owners responsible for driving the work during different phases of the development process.
Roles
Contributors at different levels in our org participate in the product development process in different ways. Being clear about everyone’s role at different stages can be a useful tool for both accountability and clarity of expectations. I use the popular RACI framework to set these expectations around the ways we want to work together. RACI stands for:
Responsible (Driving decisions) - Ensures the work reaches completion and is high-quality. They facilitate the right conversations to make an informed decision and drive the work forward in collaboration with me, the product manager.
Accountable - Though the Responsible individual drives much of the thought leadership, the Accountable individual has ultimate control over the project’s decisions. They should be able to delegate most decision-making authority to their Responsible partner while shaping the work.
Consulted - Help the Accountable and Responsible individuals make decisions, but do not get into the weeds during execution.
Informed - Kept in the loop at key stages of product development. Informed individuals don’t need to provide input. However, they should receive transparent access to documents, status and decision briefs.
Individuals do not hold the same role across the entire story. For example, we need the c-suite to be responsible for leading us in the right direction by setting the North Star, but they can’t be deep in the tactical weeds all the time. Authority to execute features that improve the product are delegated from big-picture thinkers to leads and ICs for execution. In this way, Working Groups delegate authority through cascading objectives to what we ship.
Working Groups
Working Groups represent the group of people (leadership sponsor, technical lead, IC) responsible for defining and executing Epic Themes that address a particular problem statement. Every individual assigned to a PRD affiliated with an Epic is a member of the Working Group and have an opportunity to weigh in.
Sponsors (Leadership team) are Responsible for creating Epics in collaboration with their team leads and ICs. Sponsors make sure the epic problem statement is meaningful, the work is resourced, and is sparingly a “tie breaker” for decisions.
Team leads are Responsible for defining Epics and breaking out the work into actionable PRDs in collaboration with their Sponsor. They facilitate decision making in active conversation with their working group and sponsor.
Everyone assigned to a PRD is Responsible for executing the requirements.
Cross functional teams are Consulted on Epics and PRDs. The Epic Owner collaborates with me, the product manager, to reach out to individuals that are not members of their working group for feedback that informs a better outcome.
Everyone is Informed through Notion. Product decision making is transparent and documented in detail through this product process. Informed individuals may leave helpful comments in Epics and PRDs.
Roadmapping
The story of a product doesn’t come together overnight. It is a living process that occurs over time and increases in fidelity as we get closer to the moment of execution.
We set our North Star during annual planning to make sure we are investing consistent energy into validating our business hypothesis. This guides everything we ideate on when creating Objectives and Key Results during quarterly planning.
Epics Themes are ideated on throughout the quarter with deeper consideration during quarterly planing where they are projected onto the roadmap. Sponsors and leads are responsible for collecting the ideas of their ICs and representing them in this venue. Epics represent themes for user problems and cascade down from our Objectives. It consists of a user story, hypothesized impact, and stubs the headlines and dependencies for the PRD work overview.
Concrete Product Requirement Docs that support each Epic Theme are created by each Working Group as we get closer to executing. This helps is build in an agile way where we don’t invest too much energy in an uncertain future. It consists of a user story, a set of concrete requirements, and hi-fi designs as needed. I work with engineering and design to scope PRDs, clarify requirements, and sequence them into releases over time in a series of recurring touch points linked to our release calendar.
Release Calendar: Ship Software Biweekly
When I started at Rill there was no release strategy. One of my first tasks was creating meaningful strategy for releasing software with velocity while driving product awareness. I was inspired by Firefox's open source release train.
Building with our code out in the open may feel risky because we are revealing how to create some of our magic to our competitors, but in practice it has lots of upsides. We feel comfortable making our code open source because Rill’s business model relies on serving data at scale, which means the application layer and runtime have no direct competitive advantage. Instead, by making our code openly available, it invites our technical user community to go deeper, make connections to other technologies, and also become our advocates online.
On a release train, updates are executed on time regardless of Epic completion. This gets features into our community’s hands quickly for feedback and agile iteration. To amplify the impact of each new release, I add release notes to our website to highlight our product philosophy and talented team. This has turned out to be a huge awareness-raiser for Rill. Given that our product is eye-catching, we are able to attract a lot of attention on social media channels by tweeting about product development as it is happening. The releases end up being nice bookends on work threads that engineers celebrate publicly.
Accountability
With each release we hope to make progress against our goals. We understand if we are making good decisions and executing predictably by holding ourselves accountable to measurable results and predictable releases.
Dashboards: Measurable Results
It is important to track high-level Key Performance Indicators (KPIs) and Key Results (KRs), even when growing a product from 0 to 1. The goal around these measures is best when it is specific and achievable.
Our KPI is a measure of our company North Star, usually over the course of a year. Everything we do is in service of this goal. I try to keep it simple and meaningful.
A KR is a measure that maps onto each Objective. I push for Key Results that are more specific, but impact our KPI.
I set up the telemetry needed to track our KPIs and ORKs on before our first alpha launch to ensure we were set up for success. We use google analytics for our marketing website and I designed minimal event-based telemetry for product insights. This telemetry is designed to power a self-serve Rill dashboards with drill-down dimensions to help everyone understand whether we are on track to meet our goals.
Epics: Impact
Connecting Epics and PRDs to contributors is an effective way to understand who is responsible for generating change in the product. This helps us all connect our individual contribution to the Epic bet and motivates people towards our shared vision. I connect Sponsors, Leads and PRD owners to Story pages in Notion using the a Person property when they are Responsible. This pings the owner with email alerts for each document interaction and makes it clear who is driving.
In addition to everyone understanding how they are contributing to our vision, I want us to understand if each bet is moving us in the right direction. A seed stage company going from 0 to 1 doesn’t have enough users to justify feature A/B testing. Instead, at an early stage I invest more time in qualitative insights gathered from talking to design partners and our community. These conversations inform the Epic bets we are placing during both the ideation stage and the post-execution phase.
Releases: Effort
Regular releases are a great motivational tool for the team. They’re deadline-driven and motivate the team to bias towards action. However, if we don’t take moments to pause and think, we run the risk of falling into a low-velocity rut and burning out.
A PRD review touch point at the end of each release is helpful to evaluate our velocity. I use this time to calibrate how long it takes to execute then scope and adjust our plan. I found these kinds of work burn down analyses to be the most challenging to understand in Notion because PRDs that did not get shipped on time were reassigned to a subsequent release and the history is lost. In the future, I will explore a new way understand effort against PRDs to make release scope more predictable.
Notion for distributed Product Ops
I am inspired to use Notion for product ops at Rill because of my ability to map the complex relationships between tactics and goals that I haven’t seen in Jira or Github projects. Notion is a powerful tool that allows you to create relational tables with metadata on top of a page document that can be viewed as a table, Kanban board, or timeline. This allows me to connect-the-dots between story documents, manage a release calendar, project a roadmap, and hold ourselves accountable to build great products - all in one tool.
Did you get inspired by the way I am using Notion or the way cascading objectives can build a more cohesive team? Let me know what resonated in the comments.