3 reasons to run your product team on Coda

When I meet with other Product Leaders, we often discuss the patterns that I’ve observed in working with some of the world’s best product and design teams like Spotify, Uber, Block, Zoom, Figma and hundreds of others.

I feel very fortunate to get the chance everyday, and, for the last 7+ years, to think about how tools shape the impact of a product team. Along the way, I’ve formed some pretty strong opinions about why teams should run on tools like Coda instead of the alternatives. So here are my three reasons you should run your product team on Coda.

Reason 1: Product Teams need a single source of truth, not multiple siloes.

Let’s start with an observation. Nearly every product team we talk to has accumulated lots of packaged software. A tool for OKRs, a tool for meetings, a tool for tasks, a tool for specs, and the list goes on. In talking to these teams, I often ask, “It’s Tuesday morning at 9:30am. What’s in your browser?” And inevitably, they pull up a bunch of docs, sheets, and other packaged software. Ten tabs to get one project done.

The rationale for doing the day-to-day work in docs and sheets is pretty simple. The team needs a flexible surface where they don’t have to conform to the tool. That makes sense. But the unfortunate outcome of all of these tools is that it creates multiple siloes of critical information. Said differently, the day-to-day product development process is threaded through five different systems. And the “solution” to this disparate array of tools is painful for everyone involved. Product people end up spending valuable time copy-pasting from one tool to another, or re-creating the same basic artifacts across multiple tools. What a waste of time. Worse, the cost incurred is mostly “hidden” from the organization because the work is usually absorbed by the willing but overworked Product Manager.

I spent 10+ years working this way in my former product roles at Google and YouTube. Nowadays, I get to use Coda for every part of our product development process. And I’d never go back to that world knowing that a team can have it all in one place—a single source of truth instead of five independent sources. Tactically, our PMs are no longer sending lots of different links to docs for specs, dashboards, tasks, and other essential elements. Instead, they start by creating a team hub, which serves as a single link and container for all their work.

Then something neat occurs: the hub grows and evolves with the needs of the team. The Product Manager may start the hub by creating clear meeting notes and follow-ups (something I’m a big believer in). And once they solidify a next step, they typically write a product brief. At that point, an engineer may add with a table outlining tasks, a designer may embed a Figma prototype, and a researcher might add a new page with a research plan.

The team’s work is in one place: meeting notes, briefs, tasks, plans, and more. A single source, instead of five sources. That makes it easy as a team member to find what you need to get work done. But more importantly, the data is all connected.

Team hubs have four big benefits for product development:

1. One link, not five or more. There is never confusion about where to go if you’re on the team. The team’s hub always contains what you need to get work done.
2. The information is all connected. That means no longer doing silly things like downloading CSVs or copy-pasting across tools. Tasks can easily reference specs, dashboards can have explanations written around them while they live update, meeting notes can pull-in detailed plans, and much more.
3. Get attention by simply adding a new page. As the team evolves, you’ll naturally want their attention on new information. So instead of sending them more links, you can simply add another page in the hub. That way, the team will naturally encounter the new information while they do their work.
4. Bonus, you get a clear historical record. One unexpected outcome of using team hubs for years is that it also creates a nice historical record as new people join the company. So a new person joins and says, “Why did we make that decision?” and in a world of lots of tools, you have to go try to reconstruct history across a bunch of tools. And in our case, you just go find the team hub from that effort, and often it will have good meeting notes or a decision log.

It’s interesting to see the contrast between this decentralized style and some other companies. The team can evolve their workspace as the project or team evolves, versus having to fit into the constructs of several different systems. When you live in the world where your notes, goals, and specs are disconnected from your task management system, you may have a problem that you don’t know exists.

Reason 2: Product Teams should design their ideal rituals, not let them be defined by other tools.

My view is that the best product teams use their tools to create rituals, the processes team’s rely on every day. The system is leveraged on top of the tool. It reminds me of a favorite quote from James Clear in his book, Atomic Habits: “You don’t rise to the level of your goals, you fall to the level of your systems."

There are two real problems with using a handful of tools to accomplish a single product effort.

First, in the case of packaged software, the team that’s building the tool you’re using doesn’t know your team. And how could they? They are probably thousands of miles away and couldn’t possibly be tuned into your team’s specific needs. This is one reason so many people go back to docs and sheets, despite paying lots of money for specific tools for things like project management and meetings. Their work doesn’t conform nicely to a one-sized fits all approach. They need a more flexible way of expressing how their team wants to work, in order to have the most impact.

The second problem with using a handful of tools to accomplish a single product effort is that it’s nearly impossible to create a coherent system across them. You’ve got notifications coming from three different tools, the same data being entered multiple places, and critical information that is constantly out of date. So most teams are left to use duct tape and chewing gum to glue it all together. This is an impossible, and unnecessary task.

With Coda, you can have the best of both worlds.

1. Thousands of example docs with solutions to specific problems.
You can find clear, opinionated solutions to specific problems in our Gallery. Product Leaders from some of the best product teams like Stripe, Figma, Meta and others have docs that explain valuable learnings, and how you can adopt their ideas while tweaking to fit your organization.
2. Powerful extensions to flexible docs and tables like Automations.
Coda can serve as your team’s tool for docs and wikis but go much further. Our customers create customized workflows that fit their team using a combination of tables of data and automations that trigger at the perfect time for their team.
3. Deeply integrated with other tools through Packs.
Coda’s integration layer, called Packs, means that you can pull in data from key sources, and push data back out when you need it. That means you can do things like send a customized Slack notification or email to communicate proactively, or pull in the perfect set of Jira data to keep the team on track. You can have confidence that we integrate with your tools given our extensive library of more than 400 Packs.

Reason 3: Product Teams can drive decisions that stick and keep a record of it.

Let’s start with a question. Why is decision-making a hot topic on every product team?

My view is that a team’s impact is directly tied to their ability to make decisions and have those decisions stick. If that’s the case, then it’s easy to see why decision making is a critical topic for every product team.

These days, many decisions are made in live discussions in meetings or within comments in a doc.

But too often, the same three problems occur with decision-making processes:

1. Decision rituals aren’t defined. The decision-making ritual itself and the key people aren’t well defined up front, so everyone creates their own process.
2. Unstructured feedback slows everything down. The team gets feedback that is unstructured, and all looks the same, eg. comments in a Google Doc. The result is that it’s hard to parse and act upon.
3. The highest paid person or the loudest dominate discussions. In-meeting questions and discussions often center around the loudest voice, instead of the questions critical to unblocking a decision.
   The reason I’d never go back to using another tool for decisions maps pretty closely to these problems.

With Coda, product teams can:

1. Decision making rituals are well defined with templates. Define a template for decision making, and craft a review cadence that makes sense for them.
2. Feedback is structured and easier to act upon. Gather structured feedback to help guide decision making, ensure that the team can act on it, and also create a nice historical record.
3. Discussions are driven by upvoting the topics that people want to discuss.

Let’s take each one of those in other tools, and how that contrasts with Coda.

Here’s what it looks like without Coda and with Coda for defining the ritual and key people.
Jira

Coda

Here’s what it looks like without Coda and with Coda for gathering structured feedback to help make a decision more effectively.

Google Docs

Coda

Here’s what it looks like for an in-meeting discussion to be structured so that the group focuses on the most important questions.

Google Docs

Coda

Consistently great decision making can be the difference between below average and great product teams. It’s my belief that teams can make more informed, faster decisions, that are more likely to stick by using Coda.

What next?

So, how would I start? I’d start by figuring out what change you’d like to see in your organization and mapping one of the things I talked about above to that. For example:

• Individual product teams — I’d like my product teams to operate off a single source of truth. In this case, I’d recommend having one or two teams try building out a team hub.
• Company level — I’d like us to be more thoughtful about our rituals and ensure we’re creating the tools we think will lead to the highest impact. Here’s a link to the best docs in our Gallery. Personally I’d start with your team wiki, planning process, or OKRs.
• Decision making — I'd like for us to have a better decision process. In that case, I'd start by creating a template for decisions, and also try using a log for key decisions. Take a look at The Ultimate Coda Handbooks for Product Teams - a comprehensive set of my recommendations.