In this chapter, you will learn:

How to think about the relationship between your North Star and your daily work

About levels of bets and how to place them

How to integrate the North Star Framework with other methods and practices, like OKRs, roadmaps, and organizational design

So Now What?

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.

Things to Watch Out For

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

They connect features and things to build immediately to the Inputs, missing out on the important step of defining the opportunity. ). 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.

Connecting the Framework to the Work through Levels of 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:

, 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

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.

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).

Coach's Tip 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.

Tips on Using the North Star Framework with Related Topics

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

The North Star Framework and OKRs

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.

The North Star Framework and 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:

Keith Nottonson from Optimizely describes the power and purpose of this visualization:

“The benefits of a large physical information radiator have always felt obvious to me: visibility, transparency, and alignment on both the process and the work. It is one thing to argue over a line item in a spreadsheet, an issue in a ticketing system, or an update on a slide; it’s an entirely different matter to be confronted by all the work in flight in relation to each other as they navigate through the various stages of a system’s workflow. The wall also helped us evolve our processes over time. It allowed us to move from focusing only on what was in development to an end-to-end customer kanban board.”

Try to link all of the “work” on your roadmap to your Inputs and North Star no matter what resolution it is (problem, solution, big bet, small bet). While it might be a tad demoralizing to do this with prescriptive, solution-centric projects, by establishing this connection, you are clarifying the impact you hope to generate with the project.

Rather than drafting requirement documents for items on your roadmap, consider developing succinct one-pagers that make your bets explicit and transparent. A roadmap of one-pagers is far more powerful than a roadmap of one-word project/feature names. See Appendix X for an example of a one-pager that works with the North Star.

The North Star Framework and 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:

of the opportunity to drive the Input.

or experiments is preferable to one big bet or experiment.

or influence, not to maximize the amount of work completed.

friendliness.

.

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:

The North Star Framework and Non-Feature Work

that meets the needs of everyone involved (customers, the team, the broader community, etc.).

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 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.

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)

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:

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

The North Star Framework and Organizational Design

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:

for an extended period of time. Amplitude refers to this product team structure as pods.

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.”

Chapter in Review