In this chapter, you will learn:
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.
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.
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:
Here is a short video walkthrough of this approach:
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).
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.
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:
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
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:
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.”
It can be hard to wean your organization off of prescriptive, timeline- and feature-based roadmaps. Be patient and focus on impact.
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.
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:
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:
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.
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.