A friend and fellow product leader recently asked me:
“What are the best rituals you’ve seen that my product team should adopt?”
In that moment, it struck me that despite having seen tons of interesting rituals from many product teams, I didn’t have a clear answer for him.
I’ve worked in product for over 15 years. I spent nine years at Google and YouTube, and for the last seven years I’ve helped build Coda from zero customers to over 50,000 teams using the product. As part of my role as the CPO, I’ve been very fortunate to interview hundreds of product teams.
So in response to my friend’s prompt, I set out to create the single definitive handbook to frame the most interesting product team rituals and how to adopt them in Coda. I’ve distilled common problems and insightful approaches into a set of templates, customer stories, and advice on how to run key product rituals.
But first, I want to start by saying a big thank you to product leaders from Zoom, Snap, Figma, Spotify, Pinterest, Block, Grammarly, Tonal, and many others who influenced our thinking and contributed to this handbook.
I’d love to hear your feedback as you give it a read — you can find me on
consolidate 10 tools into a single source of truth.
Problem: 10 tools to get one project done makes teams feel disorganized and chaotic.
Nearly every product team I talk to has accumulated lots of packaged software. A tool for OKRs, a tool for meetings, a tool for tasks, a tool for specs — the list goes on. When a product team shows me their starting point, they pull up a bunch of docs, sheets, and other packaged software almost every time. We’re all used to it, but if you step back, it’s kind of crazy.
As a product leader at Snap put it to me:
“We keep track of all our requirements, release dates, A/B tests, and dependencies in spreadsheets, and write dozens of documents to communicate with stakeholders. All of that becomes stale the instant they have been shared.”
That’s a lot of wasted time.
Teams who anchor their collective workdays in a single source of truth, like a Team Hub, experience a calmer workday.
Solution: Team Hubs provide a single source of truth for each team.
As a product leader, you want your team to feel organized and poised to drive impact.
One way to do this is to reduce the siloes and unnecessary duplication of information. A pattern that we’ve observed in some of the most reputable product teams is consolidating their work into a single hub, instead of a tool for every part of the project. That gives the team a single destination to collaborate: one place to take meeting notes, write briefs, track project details, review metrics, gather feedback, and more. We’ve seen this pattern at companies like Block, Qualtrics, Spotify, Zapier, Multiverse, Ironclad, and many more.
Team Hubs connect all your critical work into a single doc.
One doc capable of bringing your team’s tools together. It almost sounds too good to be true, but it’s not. In the
Problem: Decision-making in traditional documents is messy and unstructured.
The topic of decision-making comes up in almost every conversation I have with other product leaders. I usually hear a range of problems, from “decision-making has slowed down” to “decisions get questioned and reversed too often.”
Often, the primary way teams get feedback is in comments in a Google Doc. But comments are a terrible place to debate and make decisions. Comments in documents were created primarily for spelling and grammar, not complex decision-making.
As one CEO put it to me:
“It feels like the most important decisions in our company are jammed into the 100-pixel panel hanging off the side of our Google Docs. Is that really the best we can do?”
Most companies don’t realize there’s a better way.
Solution: Decision Docs in Coda create a clear structure for feedback and decisions.
Over a million Decision Docs have been created in Coda, making it our most common type of doc. Here’s an example of what that looks like in action:
Decision Docs give stakeholders a more interactive space to share feedback.
page, I’ll explain why product teams at companies like Zoom, Luxury Presence, Outreach, and many more choose Coda for decision docs over Google Docs and other alternatives. The patterns we see in the best decision-making rituals boil down to a few simple things.
First, they aren’t just PM theatre, they lead to actual decisions on hard topics. To do so, these teams intentionally design their ritual to gather clear input from a range of stakeholders. That makes it easier for the driver of the decision to action the feedback and keep moving after the meeting.
Second, they create an ongoing system for ensuring decisions are made, documented, and communicated to the organization. That way, you don’t get decisions in a vacuum. Decisions get clear inputs and have clear outputs that are transparent to the organization.
It’s a deep topic, and one that we spend a lot of time thinking about.
Problem: Tool sprawl creates siloes for strategy and execution.
Effective planning processes are hard to create and evolve. But they are essential to a product team’s success!
Many product teams struggle with the sheer number of artifacts and meetings required each planning cycle. You have meetings with the executive team, individual team planning, company share-outs, and more. You may have strategy memos, planning exercises, OKR reviews, and strategy presentations in tandem.
It can quickly get overwhelming. Docs and sheets get shared around the organization, and things feel disorganized. One product lead told me:
“We have over 200 docs and sheets for our annual planning process... It’s impossible to keep track.”
The result is a team that isn’t aligned at the end of a planning process (quite literally the opposite goal of planning), which in turn can kill velocity.
Solution: One place for your whole planning process, that leads naturally to execution.
We’ve seen some incredibly thoughtful planning rituals from companies like Pinterest, Qualtrics, Figma, Outreach, and Snap. These rituals have a few things in common.
First, they consolidate what often lives in dozens or even hundreds of documents and spreadsheets, and put them into one place. This is seamless in Coda, where you can write strategy memos in text alongside tabular data like OKRs. So instead of a graveyard of dozens of docs and spreadsheets, these teams have a planning hub where they can centralize their efforts.
Second, these planning hubs cover the entire planning process, not just one part. An all-too-typical path for planning is a confusing dance of siloed tools. No one can keep up as planning migrates from a doc to a spreadsheet, back to a doc, to spreadsheets linked inside docs, to a final presentation. With Coda, you can do the whole process — from kickoff, to planning exercises, to documenting the resulting strategy and OKRs in a single place.
Third, they create a system to make sure the plans you make actually get executed. With Coda, strategy and OKR dashboards can live in multiple places to keep progress front and center. And check-ins and updates can be automated to whatever cadence fits your team.
Planning that used to be fragmented across docs, sheets, and slides can now live in one doc.
The real power of Coda can be found when you take the three pillars above and create a connected system. The concept is to move your team from individual systems for planning, doing, and deciding to an interconnected system to run your entire product process.
We’ve seen that teams who bring their systems together as a Product OS create incredible leverage and headspace for everyone. Teams with a complete system tend to feel organized and systematic in their approach to building product.
A complete Product OS ties your team’s planning, execution, and decision-making systems together.
The benefits are numerous, but to call out a few:
Quick progression to execution — Teams can shift directly from planning to execution without changing contexts or systems of record.
Clearer decision making and records — Teams can connect the product or company decision-making directly to their team’s work.
No duplicate work — Teams don’t need to duplicate ‘status’ work, they update one place instead of several.