The Ultimate Coda Handbook for Product Teams

Explore

The Ultimate Coda Handbook for Product Teams

The Ultimate Coda Handbook for Product Teams

4. Product OS

Connect your team’s hubs, meetings, and rituals to form a Product OS.

At this point, we’ve seen how the best product teams employ

1. Team Hubs⁠

2. Decision Docs⁠

, and

3. Planning, OKRs & Roadmaps⁠

to accelerate their effectiveness. Each of these are effective tools on their own.

Yet, upon digging deeper, I noticed a common trend. Many teams didn’t stop at the individual rituals. Instead, they took a step back and connected the dots between these processes. The result is a comprehensive system. I heard people using the term a “Product Operating System,” often shortened to Product OS, which feels spot on.

Let’s explore what a Product OS is and how to build one for your own team.

What’s a Product OS?

There’s a lot of variation in what a Product OS means to every company, but if I zoom out, I see three common elements of every Product OS:

An inter-connected document system. Takes all the different artifacts created through planning, collaboration, and decision-making and neatly connects them together to streamline work.

A team meeting cadence. Describes the types of meetings that will be held and lays out a manageable schedule for when they’ll be and who’ll attend.

A documented set of rituals and templates. Takes the behaviors that you expect from your product team and makes them readily accessible (often just by typing a /command in a document).

Since I heard the term so often, I started asking more teams to describe their Product OS to me. Here are a few samples of what I heard:

Example 1: Qualtrics’s “Outer loop / Inner loop” cadence

Anderson Quach and Drew Holman from Qualtrics walked me through their Outer Loop / Inner Loop system with this diagram:

⁠

⁠

Previously, Qualtrics ran this cadence in hundreds of Google docs and sheets. In their words:

“This image that looks like it was designed by Microsoft 98 has no birth certificate. It’s time at Qualtrics predates all of us :) Every step produces artifacts and every artifact produces a meeting to review said artifact which produces actions and spin off discussions and docs until we estimated that every quarter as an engineering organization we generate hundreds of documents before we are ready to take on the new quarter.”

The sheer number of artifacts required for a single planning cycle became overwhelming. So Qualtrics built a Product OS on top of Coda that connected a small set of team hubs with big rocks and roadmaps.

Here’s what the Qualtrics Product OS looks like now:

⁠

⁠

In Drew’s words:

“The outcome of every quarterly planning cycle is a stack rank of investments and an all-up view of where engineers are committing to work against a strategy. Effectively, this is how we mobilize teams to deliver on the product vision.”

Again you’ll notice that the Product OS covers similar components:

A set of artifacts: In this case, they have moved the full system to Coda. So instead of hundreds of documents, it’s done in a well-connected network of a Coda planning doc and team hubs.

A cadence: In this case named with the “outer” and “inner” frame.

A key set of rituals: These are baked into each step of the process

Example 2: Skillshare’s operating system

Matt Cooper, CEO of Skillshare, documented his Product OS in

A look at Skillshare's operating cadence⁠

. It’s a super thoughtful example of how the pieces can come together. He showed me how it works by just walking the through the left hand page list in his operating cadence doc:

⁠

⁠

Once again, you see the same pattern - a connected set of docs, an operating cadence, and a set of key rituals.

Example 3: YouTube’s 1 week / 6 week / 6 month process:

Coda CEO Shishir documented this system well in the doc

Rituals for hypergrowth: An inside look at how YouTube scaled⁠

. I still regularly send this to friends and customers looking for a baseline of how a complete system feels. This diagram captures a quick summary of how it worked:

⁠

⁠

In this case, the “ProductOS” consisted of:

An set of interconnected artifacts: In this case, YouTube used team 2-pagers, Big Rock writeups, a “Hoodie Squad” resource map, etc.

A clear cadence: the team structured planning and execution into 1-week, 6-week, and 6-month patterns.

An iconic set of rituals: Shishir included a number of them in the writeup, like Tag-ups, Bullpen, and $100 voting for prioritization.

How to create a Product OS.

Here’s a quick run-through of how to set up all three elements of a Product OS:

1. Build a connected doc system for planning, team hubs, and decisions.

Most document platforms create individual siloes of information in each doc. But Coda is very different. It enables you to connect documents together. That makes it possible take the big parts of what a product team does — planning, deciding, and executing and connect them all together.

In my experience, these benefits add up to increased velocity and team alignment. And that can make or break a product team.

So what’s the best place to start in building an interconnected doc system? We observed four common patterns of how and I recommend choosing the path that feels like it fits your organization.

Organize workspaces in folders. Some companies are used to having folders of docs to organize their workspace. That can work well if the team identifies someone to help manage the overall folder structure and ensure clear naming conventions. Organize your docs at

coda.io/docs⁠

and

read more about organizing with folders.⁠

⁠

⁠

Map docs to Slack channels. Some companies base a lot of their day to day work out of communication tools like Slack. In these teams, we often see a 1:1 mapping between docs and Slack channels. Here’s how you can

pin a doc to the top of your Slack channel⁠

⁠

⁠

Create “go links” for key documents. Some companies have short link services that make it possible to type ‘go/’ and then a word to navigate to links inside the company. We see a lot of teams use “go links” and there are a few different vendors. Our main tip is to put the go/link in the title of the document. For example, a document might be titled “Product Roadmap (go/roadmap).” The “go link’ in the title helps reinforce how people can navigate back to this document.

⁠

⁠

Create a product team home. Some companies have wikis as a part of their culture. Most of the teams we saw had some form of product team home that contained key information like their

team roster⁠

useful links⁠

, and other details.

⁠

⁠

Although these four methods were helpful, we also heard feedback from teams that were pushing those boundaries. Specifically, teams asked for a deeper connection between documents. We recently rolled out two new capabilities that enable an unprecedented level of connection and control between docs. Let me describe how each of them works.

Embed full pages within other docs. Recently, Coda launched ‘Sync Pages’ which enables you to take a page (or multiple pages from one doc) and embed it in another doc. This means that your planning and decision pages can be directly embedding into your team’s hubs. What’s an example of this? A simple one would be taking your company strategy memo and making it the first page of a team hub.

⁠

⁠

For more details on how it works, check out

this page⁠

Two-way cross doc means tabular data can flow across docs. In many companies, we’ve helped replace a network of spreadsheets or disconnected siloes of data with central tables of data. That could be something like a team roster, a detailed roadmap, a database of bugs, a list of customers and much more. With

two-way cross doc⁠

, you can pull a central table of data into multiple documents so that data is not getting copy and pasted throughout the organization. The best part is, you can edit the data in either place and trust that it will stay up to date!

⁠

⁠

With these two in place, you can now achieve an inter-connected doc system that looks like this at a high level.

⁠

So what does that look like in practice?

It’s incredibly flexible and can be customized to your team, but here are a few of the common patterns for integration.

(a) Team hubs with company OKRs embedded inside them.

Asking teams to update their OKRs in a doc they don’t work out of everyday is tough. It’s easy to set those company OKRs and forget them. But when they are integrated directly into a team hub, where teams spend their day, they start to naturally encounter the same OKRs.

One way to do this is to use two-way cross doc to pull OKRs into each team’s hub from the companies central table of OKRs. Then each team can filter the OKRs to just their team and keep them up-to-date in both places.

⁠

⁠

(b) Decision docs inside team hubs pulled into the doc for your decision forum.

If a team is operating out of a team hub, then they are probably documenting their decisions there. And that’s great, they are making decisions in close proximity to where the rest of the work is happening! When it comes time for a product review or decision meeting, they shouldn’t have to move that work or recreate it somewhere else.

With sync pages in Coda, the team can embed their decision doc or writeup directly into the doc that runs the product review. It can live in both places! That makes it easy for both the team working on implementing the decision, and the team reviewing the decision.

⁠

Sync pages - Decision docs in decision forum (4).png

⁠

(c) Product Team home becomes a centralized and living space for the whole team.

In a fast-paced environment, it’s tough to keep track of what your teammates are shipping and learning. What if you could centralize that without creating more work?

One other pattern we’ve seen is taking a product team wiki and making it 10X more useful. With sync pages, your team home can not only organize useful links, but it can also embed company OKRs, company strategy, key decision from your review forum, and pages from the hubs of each major product effort. And of course, everything stays in sync. It’s pretty magical to see it all live together in one place!

⁠

⁠

2. Map your meeting cadence to accelerate planning and execution.

To put a Product OS into action, having a clear and collaborative decision-making processes is very important. And being able to connect all the artifacts in a sensible way is a critical step.

Typically, the next step is to map out the cadence of how the team’s meetings will run. There are generally two altitudes of meeting cadence:

Planning — your team’s planning cadence that happens on a longer time frame, often every quarter, every other quarter, or every year.

Execution — your team’s execution cadence that is often set on a weekly or monthly cadence.

For planning cadence, I’ll refer you back to

3. Planning, OKRs & Roadmaps⁠

, because setting that cadence is very related to developing your planning process. Here I’ll help you develop your execution cadence, or your weekly and monthly calendar.

Here are a few of my learnings and tips for setting up your meeting cadence:

a. Define your broad meeting categories.

When people don’t understand the point of a meeting, it’s likely to fail before it starts.

One successful approach that I’ve seen is creating a simple taxonomy that creates shared language. I’ve seen a bunch of companies adopt our founder’s taxonomy to help create clarity in the organization. The three types are below, and you can

watch this talk⁠

that Shishir and Yuhki, Figma CPO, gave at Figma Config for more details.

Cadence — recurring meetings that help hold each other accountable to a goal.

Catalyst — meetings with emergent group of people brought together to discuss a specific topic.

Context — meetings that increase connection and shared perspective.

You can invent your own categories of course. I’m here to tell you that having some type of shared language will help you sidestep a lot of unnecessary frustration. When people come to a meeting that is marked as ‘Catalyst’ they know they are there to discuss something specific and/or make a decision. And when they come to a meeting marked as ‘Context’ they know not to expect a decision to come out of it.

b. Define your unique meetings and their rituals.

Many meetings are pretty standard, like a company all hands, or a team’s standup.

But sometimes you want to design a meeting around a unique insight. I’ve seen lots of examples of this, but here are three that I can wholeheartedly recommend adopting.

Tagup

Bullpen

Catalyst

That’s a short summary but if you’re interested, I suggest reading about these in much more detail here.

Bonus: Run a meeting audit.

If you want to get a baseline understanding of how your teams are operating, I recommend running a meeting audit. It’s an incredibly enlightening exercise and only takes a few steps.

To run an audit, start by making

a copy of this doc⁠

. Then have your product leaders or leadership team sync their calendars into the doc. Next you’ll run the evaluation on what types of meetings they’re having, and how effective they are. You’ll end up with an output that looks something like the picture below.

⁠

⁠

Doing this exercise at the start will help drive a better discussion about what changes you want to make and help you develop an action plan to improve your meeting cadence.

Once you’ve gone through these steps, you should be able to publish your meeting cadence to your product team or the company. If you’re curious, you can read the chapter from Shishir’s forthcoming book on

this topic here⁠

. And for an example, see

Skillshare’s system⁠

3. Make templates for key rituals that reinforce your team’s culture.

You’ve got all your artifacts set, and your meeting cadence is in order. The last step in your ProductOS is to document and create templates for the team’s core rituals. Once you create a doc of your ritual, it’s easy to re-use that doc as a template across the organization.

Here’s a quick walkthrough of what custom templates look like. Your templates are now just a /command away.

⁠

⁠

The common templates that I recommend putting into templates:

Decision doc template: read more and see example templates in the

2. Decision Docs⁠

page.

Team Hub: read more and see example templates in the

1. Team Hubs⁠

page.

Strategy writeup: read more and see example templates in the

3. Planning, OKRs & Roadmaps⁠

page.

Dory & pulse: customize

the template⁠

to fit your organization.

And not directly product oriented but also very useful in running your organization:

1:1 template: create guidance and a template for running 1:1s like Jenny’s from

Square’s approach.⁠

⁠

Offsites: create your own template for running off-sites like

Claire from Stripe⁠

⁠

Putting it all together.

Once all those pieces are in place, your docs are connected, your cadence is set, and your rituals are published, and you’ll have a Product OS ready to go. It will probably look something like this:

⁠

You can now send out the link to your team (go links if you use them) and maybe have a launch party!

⁠

FAQ

What’s the difference between a Team Hub and a Product OS?

Great question. A Team Hub and a Product OS can certainly seem synonymous since they can both operate as a system for dynamic collaboration. As outlined above, a Product OS contains 3 elements:

an interconnected system of artifacts necessary for work

a team meeting cadence

a documented set of SOPs and rituals

A Team Hub can certainly contain all three elements, and often does, but it might only make up part of a Product OS. You can also think of a Team Hub as a concrete artifact (e.g. each team within a product org might have their own team hub document), whereas a Product OS is the holistic ecosystem that interconnects all your org’s collaborative artifacts (e.g.

Team Hubs⁠

Decision Docs⁠

Planning docs⁠

, etc).

Where should I start with my Product OS?

Simple starts for anyone:

Try starting with embeds to organize key artifacts within a team hub doc. Copy a

quickstart team hub template⁠

and immediately gather your team’s most common docs/tools as

full-page embeds⁠

. Rather than asking others to do anything new, this lets everyone continue working in the tools and platforms they’re used to, while immediately bringing more organization to the team.

Choose a use case that you’re leading. This requires little to no buy-in from others, and can start getting your team familiar with how Coda enhances process. For instance, many PMs use Coda for write-ups like

Decision Docs⁠

and

PRDs⁠

to accelerate better quality decision making.

Suggestions for leaders:

Try to kill a meeting no one likes with Coda. Similar to

what Yuhki did at Figma⁠

, listen for meetings that no one liked in 1:1s, then try to recreate a streamlined version of that ritual that improves the outcome while saving everyone valuable time.

Engineer success with a small, trusted team. Teams tend to naturally mimic the rituals of other teams with good reputations. So I would try to find a small, fast-moving team with some autonomy that would be open to testing out a new way of operating, and if done well, could show the rest of the organization how to follow suit.

Can Coda help me setup a Product OS?

Absolutely. We know that designing or redesigning a holistic Product OS can feel challenging, but Coda (the people & the product) is with you. We have a team of solutions engineers, customer success managers, and more to help you think about your system as a whole, and reimagine what’s possible. This handbook is also a compilation of our favorite templates, testimonials, and tactics from some of the best product teams running on Coda.

Reach out to us here⁠

to start your journey from idea to implementation.

⁠

Check out

Resource Appendix⁠

for a compilation of all the templates and external links mentioned above.

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.