North Star Playbook

Amplitude has facilitated hundreds of North Star Framework workshops. Some teams leave the workshop, identify a metric and Inputs, and then quickly fit the North Star into their workflows. For other teams, putting the North Star into action is not so easy. From such teams, we’ve heard statements like this:

"OK! We’ve defined our North Star and everyone seems to have buy-in. But now what? How do we actually do it? I mean, we have a whole product process and prioritization model, and development teams already are following a roadmap filled with features. How do we decide what to work on?"

These are not small challenges. Without integrating the framework into how you work, plan, prioritize, and review progress, you’ll miss out on the North Star Framework’s benefits.

The Work

We call the activities teams use to make their product "the work." When we use this term, we’re referring to day-to-day tasks of product-making: researching, designing, coding, testing, refactoring, prototyping, experimentation, and the like.

Some teams will be more prescriptive and prioritize specific features that target a specific Input. Other teams will be less prescriptive, prioritizing opportunities that are likely to influence specific Inputs, but giving designers and developers autonomy to identify the actual features. No matter which way your team works, the key is maintaining a clear connection between your work and your North Star.

The following are some common reasons that teams struggle to put the North Star Framework into action and to connect it to their work.

1. They connect features and things to build immediately to the Inputs, missing out on the important step of defining the opportunity.
2. They fail to use enabling constraints like work in progress or process limits, timeboxes, force-ranking backlogs, and structured reviews. These constraints help teams sense and respond.
3. Without them, there’s a lot of "moving around" and less "true work" (to read more about the concept of "true work," see Jun Nakamuro’s post, Re-Translating Lean from Its Origin).
4. They organize around the tech stack, product areas, keeping people busy, predictable shipping features, and moving to the next project, instead of organizing in a way that optimizes directly driving the North Star’s Inputs.

Product teams use a variety of techniques to align strategic frameworks like the North Star to their product development practices. One approach we like is connecting the work to the North Star Framework through levels of bets. Please note, we’re describing this model to explain important principles and to help teams avoid common pitfalls—not to claim that there is just one right way.

In this level of bets model, the North Star is joined to a board-like visualization of work underway and in queue. The North Star and the board are connected through a series of what we call bets. Picture the North Star and the board sitting side by side with decreasing levels of bets labeled across the top, like this:

Key features include:

• The North Star Framework, including business results, the North Star Metric, and Inputs
• Using Bets and Bet Levels to connect day-to-day work to the North Star Metric
• Different time horizons for different Bet Levels to acknowledge different feedback loop lengths
• A force-ranked queue of opportunities to encourage focus and promote organizing around the North Star Framework across multiple teams
• Explicit review stages to promote learning and not just labeling things "done"
• Changing the language from "to do, doing, done" to "focus on next, Focusing, and Review," and "To Try, Trying, Review" to separate opportunities from experiments and encourage learning
• Work in progress limits to improve flow and help identify bottlenecks

Here is a short video walkthrough of this approach:

Connect the North Star to the Working Board with Levels of Bets

Notice the connections among the elements of the North Star, and then the connections between the North Star and the items on the board. You can draw similar lines connecting your North Star and working board.

We call these connections bets. You are betting that the work or the Input will produce the result. The word "bet" is well suited to describing risk, impact, assumptions, and uncertainty.

The more distant the bet is from the ultimate goal of business results, the higher the level. Level 0 and Level 1 bets are connection points within the North Star Framework. Level 2 and Level 3 bets connected to work on the board. All levels are connected.

Here is an explanation of these bet levels, using the Burger King North Star as an example.

Notice how the Burger King example tells a coherent story spanning the one- to three-week work on functionality (the Level 3 Bets) all the way up to the bets underpinning the connection between the North Star Metric and long-term business results (the Level 0 Bets).

Try "Bets" instead of "Experiments"

I personally like the word experiment. It feels rigorous, scientific, and learning-focused. It feels…right, to me. But, over the years I’ve shifted my vocabulary to more often refer to bets, and less to experiments.

Here’s why

As I worked with more companies and leaders, I started to notice something. Whenever I used the word "experiment," I would see an executive’s jaw tense. They’d nod, but you could sense confusion. "An experiment?" they thought (and sometimes even said aloud). "When will this team stop experimenting and get to work?" Or I would notice that whenever they wanted a team to do something, that same executive would co-opt my language and say something like, "Oh, it is just an experiment! Give it a try!"

I started to use the word "bet," and noticed something very interesting. Executives, who understand concepts like risk, return, investment, and diversification, dropped their resistance. Bets make sense. Bets can be big or small. Bets can be risky or safe. Good bets can sometimes lose, and bad bets can sometimes win.

With bets, I discovered a language to tease out assumptions and beliefs in a way that was a lot less forced.

Perhaps you are already using related tools like OKRs, roadmaps, or feature prioritization formulas. You’re probably wondering how to integrate the North Star framework with these tools. Does a North Star Metric and Inputs replace OKRs? Or should you change the way you think about prioritization, non-feature work, or even the design of your org chart?

You can integrate the North Star Framework with other techniques or structures that product teams commonly use:

• The North Star Framework and OKRs
• The North Star Framework and Roadmaps
• The North Star Framework and Prioritization
• The North Star Framework and "Non Feature Work"
• The North Star Framework and Organizational Design

Many modern organizations use OKRs (Objectives and Key Results) to set priorities and monitor outcomes. In the OKR framework, teams set objectives, and then define the key results that indicate progress towards achieving each objective. Managers measure the OKRs on a regular cadence to ensure the business is working on the right priorities, while tactics or interventions are up to individual contributors or teams.

Tips for using the North Star with OKRs

• OKRs are usually point-in-time goals. Teams want to produce a result in a timeframe. The North Star Framework is less prescriptive about time. Be mindful of this.
• Try framing OKRs as the impact your Level 2 Bets will have on one or more Inputs.
• Be wary of aiming for a quarterly goal that no longer makes sense.
• Watch out for a team packing the quarter with deliverables instead of focusing on an outcome.
• Some teams find that linking their work to Inputs—and setting goals based on the expected impact of their work on Inputs—means that they can safely retire OKRs.

There are a variety of approaches to product roadmaps, from declarations that you’ll deliver specific features at specific dates to thematic roadmaps that broadly sequence categories of opportunities without specifying timeframes or actual functionality.

Tips for using the North Star Framework with roadmaps:

• In general, the North Star works best when integrated with theme-based roadmaps that account for uncertainty over time.
• A roadmap should explain how both in-progress and planned work connects with the North Star at a glance.
• When building a roadmap using the North Star, focus on prioritizing the opportunities most likely to drive Inputs.
• Be diligent about following up on completed roadmap items to see if they had the expected impact.
• Consider overlaying your North Star Framework on your roadmap, even conceptually.

Here, for example, is an actual physical "roadmap," in the form of a kanban board, with a North Star and its Inputs as integral parts of the board design.

The board maps to the components of the North Star Framework as follows:

Prioritization is an important part of any product manager’s job. In fact, much of product management is making decisions about which of various options a team should work on and why. Prioritization is a complex topic, and treatises have been written about various models.

Tips for prioritizing work using the North Star Framework:

• When prioritizing, consider both the influence of the Input on the North Star and the likelihood of the opportunity to drive the Input.
• A series of small bets or experiments is preferable to one big bet or experiment.
• Prioritize based on expected value or influence, not to maximize the amount of work completed.
• Teams often obsess about duration estimates. Much more valuable—in most product-led situations—is to consider forecasted value and experimentation friendliness.
• Don’t be afraid to prioritize multiple experiments or bets against a single high-value opportunity.
• Watch out for big batches of work with infrequent opportunities to learn and pivot.
• Prioritize to work in ways that support the approach on the left versus the approach on the right:

One way to think of a product-led company is to imagine the whole company as a value creation system that meets the needs of everyone involved (customers, the team, the broader community, etc.).

The goal of such a system is sustainable value creation, which invariably will involve a lot of support systems. Without functioning support systems—the circulatory, nervous, and digestive systems of the company—you start to see drag on the value creation system, like this:

This is why we often suggest that teams consider including a system health indicator Input in their North Star. This Input can cover critical, non-feature factors that users might not directly experience but that indirectly affect the product’s overall quality and the ability of engineers and designers to work effectively. Examples of factors that can drive a health indicator Input include system uptime, cycle times, testing and deployment processes, up-to-date tooling, and even the time it takes for a new team member to get up-to-speed.

Monitoring and course-correcting based on this Input will ensure that the whole system is healthy and set up for long-term, sustainable growth. Troy Magennis, product development measurement enthusiast, says, "Most important is that health is a balance. It is not just one thing, and you can’t just focus on one thing." Troy describes six areas to consider when thinking about health indicators:

• Do the right stuff (Valuable)
• Do it predictably (Consistency)
• Do it right (Quality)
• Do it fast (Speed)
• Do lots (Quantity)
• Keep doing it (Sustainability)

Your North Star should already cover Valuable. An effective health-related Input would be a composite of metrics related to Sustainability, Quality, and Consistency. Though Speed and Quantity are not the goal (outcomes are the goal), flow metrics can be valuable early indicators of drag and health issues.

Tips for managing non-feature work with the North Star Framework:

1. Think of your company as a value-creation system. Then identify the top handful of things impacting the flow of value-producing work through this system.
2. If possible, visualize non-feature work as opportunities alongside the normal roadmap items. Include these opportunities in the roadmap.
3. Consider including a system health indicator Input in your North Star Framework.
4. Reframe technical debt as drag on value to emphasize how it limits impact and affects business results.

We recommend that you don’t overhaul your org chart when you get started with the North Star Framework, as you’ll already have plenty to consider and manage. Once your North Star is performing well and producing a few months or quarters of learning and success, you can turn your attention to optimizing your org structure to get the most out of the North Star.

Tips for designing an organization around the North Star Framework:

• Consider letting a team or group of teams focus on a single Input for an extended period of time. Amplitude refers to this product team structure as pods.
• Organize to minimize handoffs. Start together whenever possible.
• Organize your teams around what is valuable. Resist letting your current organizational structure force decisions about value and priorities. Be cautious about organizing around features, workflows, touchpoints, technologies, actors, etc. that do not align with your North Star and Inputs.
• Remember that there is no optimal organizational structure for product development. As Ben Horowitz, cofounder and general partner at Andreessen Horowitz, writes in "The Hard Thing About Hard Things: Building A Business When There Are No Easy Answers", The first rule of organizational design is that all organizational designs are bad.

• A challenge for some teams is connecting the North Star Framework, including the metric and Inputs, to their models and methods for prioritizing daily work.
• If you can already connect your work to your North Star relatively easily, by all means do so.
• We like a model in which levels of bets connect a North Star to a board-like breakdown of priorities. Levels of bets enable a team to trace tasks occuring in short timeframes to much longer-term goals.
• The North Star Framework can be integrated with other models of planning, prioritizing, and managing work, like OKRs and roadmaps.