How to Organize Your Product Team Around Your North Star

How to organize your team is one of the most important decisions a product leader makes because how your organization is designed determines how it performs.

As we’ve grown, we’ve iterated on many product org structures at Amplitude. The structure we’ve found most effective emanates from the product North Star. Once you’ve defined your North Star—the key measure of success for the product team—we recommend structuring your team into autonomous groups to drive that outcome for your business.

THE NORTH STAR PLAYBOOK

Align your team around your North Star Metric

Read our comprehensive guide to discover how to create shared language and vision with your North Star Metric.

📚Download the playbook >>

At Amplitude, we refer to this product team structure as ‘Pods.’

But before I explain how pods work at Amplitude, it’s important to understand that there is no one size fits all organizational structure for product development. “The first rule of organizational design is that all organizational designs are bad,” Ben Horowitz wrote in 2010. You need to figure out what you’re optimizing for. Define the principles that matter most to you and design around that.

For us, we knew that the best product decisions come from those who are closest to the customer, and as any company grows it becomes harder, not easier, for those individuals to make autonomous decisions. So we came up with the following tenets to preserve customer-centricity at Amplitude:

1. Minimize dependencies – The pod should be autonomous and have all of the resources they need to make decisions on their own. So each pod has a product owner, design owner and tech owner, as well as access to the product analytics solution they need to make decisions day to day.
2. Align around vision not direction – Each pod clearly articulates their 6+ month vision, 6 week objectives and key metrics they’re trying to move. They align with leadership on that but have the autonomy to own their backlog, deciding whether they should build 1.1 of a feature or start on something new.
3. Reduce communication overhead – Keep pods small; no more than 4-5 people.

We’re also believers that you get no points for originality, so we looked at the practices of two of our favorite product-led companies to help us define our process.

Amazon: Two Pizza Team Rule

The rule is simple, but profound; keep your teams to no more than what could be fed by 2 pizzas. Amazon uses this rule to help encourage high autonomy and innovation, because communication overhead scales very poorly after ~6 people. The larger a group, the more process problems member’s encounter in carrying out their work.

Spotify: Squad Model

A lot has been written about the Squad model, where Spotify broke existing Scrum processes and reinvented what it meant to be Agile for their organization. While this model has continued to shift and change as they’ve grown, the core guiding principles for them have been autonomy and alignment.

On autonomy, each Squad can decide what to build, how to build it, and how to work together while building it.

On alignment, leadership’s role is to make sure that they clearly communicate what problems need to be solved and why. They believe both work together to increase motivation, quality, and speed of learning.

Amplitude: Pods

We define pods as small autonomous groups of people defined by their common objective and measure of success. These objectives are tied to the broader product strategy, and as such can shift around depending on the needs of our users and the business.

At any point in time we might have 6-10 pods across a 35 person Product Development team, some of which we call Core pods that live in perpetuity and others we refer to as Strategic pods that might just last for 6 weeks but are critical to the company.

Core Pods are aligned against the customer journey and problem areas that we have identified as driving our North Star. For example, at Amplitude our North Star is Weekly Querying Users (WQUs), and we break that down into its core drivers of Weekly Querying Accounts and Weekly Querying Users per Account.

We then map Users per Account against our customer journey – this is a hypothetical example but it looks something like this:

Types of Pods

To increase WQUs we have Core Pods focused around these drivers and the user personas that represent them in our product. For example, we have an Enabler pod trying to reduce onboarding time, an Advocate pod focused on the needs of a power user, and a Novice pod driving expansion by making valuable consumption significantly easier.

And then we have Strategic Pods like a GDPR pod that focused on the upcoming European regulation, or experimental pods exploring how we can use machine learning to solve core problems in product analytics. And over time those will either migrate into existing Core Pods or become their own pods.

The final component of a pod is its measure of success. These are captured in the Pod Charter, a single page product document that also outlines the vision, objectives and team for that pod. We break down success metrics in the following way:

1. What’s your BHAG (Big Hairy Audacious Goal) for your North Star – the 10x metric that matches your 10x vision?
2. Given that outcome, what’s your leading indicator of that? For example, for our Novice pod its around increasing 1st week retention.
3. What is your 6 week goal – that’s your input metric. Where are you going to be 6 weeks from now?

Pods then present their impact towards these metrics in product reviews, while also working with leadership to assess any changes to direction based on learnings from their work.

Final thought

Organizing a product team is hard but having a north star makes it easier because you can align a team around specific goals with outcomes. We’ve tried many organizational designs and found pods to be the one that works best for us because it minimizes dependences, aligns us around a vision, and reduces communication overhead.