One of the toughest challenges I’ve faced while running product teams in the past is knowing which level to engage a team and when. Anyone can easily get caught up in debates about specific product details and unpacking a singular OKR status. And while that level of granularity is important, going there at the wrong time is often a major distraction for a team.

As teams scale, there’s an inflection point when you add a layer of product leadership between yourself and the teams closest to the work. I most recently felt this when Thumbtack moved from a totally flat product org to one with a lead in each key area. The processes that worked for a flat org led to a lack of clarity as the org matured.

So, how do you empower your team leads to run while maintaining visibility and giving strategic guidance?

You define a broad set of simple and tailored tools that enable a culture with clear expectations around which conversations need to happen when and why—a

.

This doc is meant to frame your own product cadence. To get started,

you need to think about three focus areas for your team, each with their own stakeholders, communication patterns, decisions and deliverables:

Why

does a team exist?

What

is a team producing?

How

does a team work?

Let’s dive into each area.

Product leaders must choose the right set of problems to solve, invest resources (PMs, designers, engineers) against those problems, and evaluate the outcomes of those investments to inform how to move forward. Broadly speaking, this set of responsibilities culminates into the planning process for your product.

As a rule, my planning process frequency is dictated by how often I shift resources in a significant way. In a company’s early days, it’s easier to be more nimble and move large parts of the team around every few months. As teams grow, big shifts in team allocation start to get much more expensive to manage, and I move to more of a 6 month view around big shifts in investments.

I start from a baseline of team charters. These are documents that help clarify:

The overarching problem the team is trying to solve and how it fits into the company’s mission.

A vision around the most important problems to solve over the course of the next 12-18 months, with a sense of the sequence in which the team will address them.

A sense of how to measure progress against that strategy.

Guiding principles within each charter then detail how the team will navigate the toughest tradeoffs and decisions as they work through their roadmaps.

These team charters are living documents that evolve on different timescales. It’s important to put charters in place as teams are formed but updating them doesn’t always line up with planning cycles. I like to have teams refresh them whenever they get insights from a major fork in the road or hit moments where they have fulfilled a lot of their vision and are looking ahead to the next big set of problems to solve.

Charter creation and updates are good moments to have discussions squarely focused on strategy and direction, independent of decisions on staffing and evaluation of execution and impact.

With team charters in place and in a good state, you can evaluate how to allocate resources across teams. Decisions around how much to invest in each team are guided by a range of:

The priorities in the company strategy, i.e., which elements are the most important to make progress on over the next period.

The maturity of the team. More speculative 0 to 1 bets are often funded with small teams that can prototype quickly whereas more mature teams with well understood impact might be quite large at scale.

The clarity of their roadmap and ideas, i.e., do you actually know what you’re getting with the resources you’re buying.

Your confidence in that team’s ability to execute on those ideas, i.e., has this team delivered in the past?

Dependencies. The nature of some teams is that they spend a more significant fraction of their time supporting other teams and thus require a higher level of baseline investment to keep the whole train running.

Since this exercise is zero-sum, you end up making some of your toughest calls. Be aware that teams that don’t get funded as much as they like may experience feelings of failure—explaining your thought process and how you made tradeoffs is critical.

As teams grow, it also becomes increasingly important that you up-level your investment decisions. Practically, this means that your role is to fund teams and not projects. And the role of your leads is to figure out the right approach for getting the right projects done.

At this point, teams identify OKRs that keep them accountable. OKRs can be a mix of metrics and milestones. If the realistic goal is to launch a feature or test in a time period, then that’s OK. Not every piece of work will have an impact that shows up in a dashboard in the same time horizon that you’re planning.

If two teams collaborate to accomplish a goal, I have both teams list the same OKR in their sections to make it clear which teams need to work together in a fundamental way. In the name of conciseness, I cap each team at no more than 5 OKRs. Forcing synthesis helps teams clarify their thinking and avoid the dreaded everything-tracker-spreadsheet.

👉

Get insight on how Pinterest structures their charters and resources by clicking the page below:

The work a team does impacts others, and a launch requires the broadest set of people to know what’s happening. Oftentimes, the core team will know about a launch plan, but it’s not always practical for every function to be adequately represented. For example:

Product Ops teams need to make sure agents are ready for customer facing changes.

Analytics teams need to know what changes went out if they’re troubleshooting changes in metrics.

SRE teams need to be ready for a change in traffic.

Legal teams need to make sure nothing was missed.

Security teams need to track whether there are any data compliance issues.

Launch calendars serve a very valuable function for providing visibility into what is happening. Counter-intuitively, they aren’t meant to capture why the roadmap looks the way it does or whether the activity had the desired impact. With such visibility, supporting functions that aren’t involved in the day-to-day execution or strategy can stay up-to-date with changes in the product.

I do not use launch calendars as an approval step; they are a lightweight communications tool and not a decision-making tool. Decisions are made either within a core team, up at the strategic planning level, or in other ad hoc reviews. A focus on communication allows each entry to be quickly input and updated. In separating communications out from the team vs. workflow within the team, you get a better outcome on broad visibility.

Your launch calendars are also not substitutes for involving key stakeholders in early-stage development. If too many people are surprised by what they see in a launch calendar, something went wrong upstream.

👉 Check out an example of a launch calendar from Pinterest by clicking the page below:

If you have built up good mechanisms for strategy, accountability, and visibility, you can then decouple the question of how a team works together. There are a number of ways tools can help a team:

Brainstorm features and prioritize a roadmap

Solicit input from key cross-functional members of the team and review ideas at the right level

Document Decisions

Track tasks, assign them to the right people

There is a benefit to having some standards across the company on these fronts, because people invariably move teams and you don’t want people learning a whole new way of working every time they switch.

However, I find it’s important to not be too prescriptive about exactly how a team operates.

The right approach is a function of the size of the team, the particular strengths of the individuals on the team, and the maturity of the product area.

There’s often a desire to tie the cadence and tools that a team uses back into the tools at the other levels because it feels like everything should add up. But that’s exactly where things start to get too rigid. In reality, it’s often easier for a team to figure out the style that works best for them and then have the PM do a separate step of synthesizing for launch calendar and planning/OKR purposes.

While a set of tools themselves can’t create a culture of empowerment in a product organization, a thoughtful approach around tools that guide the right level of discussion into the right forums can enable both alignment and autonomy.