North Star Playbook
The guide to discovering your product’s North Star
Putting your North Star into action
Amplitude has facilitated hundreds of North Star workshops. Some teams complete their workshops, identify a metric and inputs, and then quickly fit the North Star into their workflows. For other teams, putting the North Star into action isn’t as easy, sharing statements like:
“OK! We’ve defined our North Star and have buy-in. But now what? How do we actually do it? We have an entire product process and prioritization model, and development teams already are following a feature-packed roadmap. How do we decide what to work on? Does this change our OKRs?”
Though these are significant challenges, they’re surmountable. By integrating the Framework into how you work, plan, prioritize, and review progress, you’ll reap the North Star Framework’s full benefits.
Things to watch out for
Three ways that teams struggle to implement the North Star Framework and connect it to their work include:
- They connect the features they’re building to the inputs without first defining the opportunity.
- 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. Without them, there’s a lot of “moving around” and less “true work.”
- They continue to organize their work around the tech stack, product areas, keeping people busy, predictably shipping features, and moving to the next project, instead of organizing in a way that optimizes driving the North Star’s inputs.
Dave, a banking app company, is on a mission to build an all-inclusive financial ecosystem that strives to help the four-in-five Americans who live paycheck-to-paycheck thrive. In order to solidify their product-market fit, the Dave team explored different retention loops to enhance their target users’ experience.
In their North Star Metric workshop, the Dave team discovered that retention was higher for users who added more recurring expenses to their account.
With this learning, they reworked their onboarding flow to significantly increase the average number of expenses added. And that has driven even higher retention and increased revenue: users who add expenses during onboarding are 5.7x more likely to still be using Dave three months later.
They continue to use Amplitude’s North Star Framework to ensure that all of the teams at Dave are working together to create a product their users love and want to use again and again.
Connect your framework to your work through levels of bets
Product teams use various techniques to align strategic frameworks like the North Star to their product development practices. One of several effective approaches is connecting the work to the North Star Framework through levels of bets.
What are bets?
Instead of using the word experiment, John prefers to use the word “bet.” A bet is an initiative of any size that’s associated with a potential outcome. Think of a bet akin to a hypothesis that you’re trying to prove. If the hypothesis is true, you win the bet, and if it’s false you lose. You’re “betting” that the work will produce a result. By calling it a bet, you’re making it safe for uncertainty.
Try “bets” instead of “experiments”
Though John appreciates the scientific connotation of the word “experiments,” he’s shifted his vocabulary to more often refer to bets, and less to experiments—unless we’re really talking controlled experiments like A/B testing, of course.
“As I worked with more companies and leaders, I started to notice something,” he explains. “Whenever I used the word ‘experiment,’ I would see an executive’s jaw tense and they’d sometimes think aloud ‘When will this team stop experimenting and get to work?’”
But when John started to use the word “bet,” executives—who understand concepts like risk, return, investment, and diversification—dropped their resistance. Bets make sense—they can be big or small, risky, or safe. This language teases out assumptions and beliefs in a way that is a lot less forced.
Bets can vary greatly—prescriptive or descriptive, tactical or strategic—but are always outcome-focused. In making a bet, we predict that something will happen and ask, “How is that bet working out?”
By calling it a bet, we admit that “losing” the bet is an option and that experimentation and learning are involved.
“Bets capture that perfect interplay between assumptions, desired outcomes, experimentation, risk, and reward,” John explains in his blog, Place Your Bets.
For larger initiatives or projects, you might have a portfolio of bets, where the larger project is a bet consisting of smaller bets that might be related to and dependent on each other. For example, you could have a big bet on an emerging technology which cascades into a number of smaller, more tactical feature bets. You can think of your roadmap as a portfolio of bets.
Levels of bets model
A bet is something you’re going to do, and each bet might take a different amount of time and have a different level of risk. For instance, a smaller bet might be achieved in a few weeks and is an easy safe project, and a larger bet might take more than a year and could be resource heavy and riskier. Bets can also be related, where you might achieve a series of smaller bets to accomplish a larger bet.
Teams can categorize bets into levels, and associate a specific time frame for feedback, execution, or review. Each level is related—you knock out the smaller bets to get to the larger bets. And those larger level bets—Level 0 and 1— are closely associated with your North Star Metric and inputs.
Here’s a visual understanding of these levels of bets, with an example:
*Time horizons can vary depending on your company. For instance, your level three might only take a few hours or a few days. Note that in this visualization we “flip” the North Star Framework.
Many companies get in the habit of labeling a project as “done” and calling it a day instead of learning from it. To help encourage learning, it’s important to incorporate reviews and helpful to shift the language. Instead of “to do, doing, done,” shift to “focus on next, focusing, and review” and “to try, trying, review.”
Review cycles should be a continuous loop. If your team is actively working on a level 1 bet, they might have a series of level 2 and level 3 projects that they’re working on or toward to achieve that level 1 bet. Each bet you accomplish along the way should be reviewed.
So this is what a level of bets roadmap for your North Star might look like:
Tips on using the North Star Framework with related topics
If you're already using OKRs, roadmaps, feature prioritization formulas, or other related tools, you’re probably wondering how to integrate the North Star Framework. Do your North Star Metric and inputs replace your OKRs? Should you change how you think about prioritization, non-feature work, or even your organizational 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
Many modern organizations use OKRs to set priorities and monitor outcomes. In the OKR framework, teams set objectives and define the key results that indicate progress toward achieving each objective.
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.
- Avoid 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
There are a variety of product roadmap approaches, from declarations that you’ll deliver certain features on 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 connect with the North Star at a glance.
- When building a roadmap using the North Star, prioritize the opportunities most likely to drive inputs.
- Follow up on completed roadmap items to see if they had the expected impact.
- Consider overlaying your North Star Framework on your roadmap, even conceptually.
"Making it tactical and visual can be extremely powerful,” explains John. “It helps your teams translate the North Star into something you do instead of something you did at a workshop. It’s something tactical that you can see and feel.”
Even though working on a huge physical board might be restrictive or infeasible for virtual teams, online whiteboarding tools like Miro enable teams to collaboratively achieve the same outcome.
It can be hard to wean your organization off of prescriptive, timeline- and feature-based roadmaps—so 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). Though it can feel a bit demoralizing to do this with prescriptive, solution-centric projects, establishing this connection enables you to clarify the impact you hope to generate with the project.
Rather than drafting requirement documents for roadmap items, 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 our How-to Guide: Running Your North Star Workshop for an example of a one-pager that works with the North Star.
The North Star Framework and prioritization
Prioritization is an important part of any product manager’s job. In fact, much of product management is making decisions about which option your team should work on and why.
Tips for prioritizing work using the North Star Framework
Though prioritization is a complex topic, these tips can help:
- 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.
- Looking at the visual below, 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
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 involves a lot of support systems. Without functioning support systems—like 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 include 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 your product’s overall quality and your engineering and design teams’ ability to work effectively.
Examples of system health inputs include:
- System uptime
- Cycle times
- Testing and deployment processes
- Up-to-date tooling
- New team member ramp-up time
Monitoring and course-correcting based on your system health input will ensure that your whole system is set up for long-term, sustainable growth.
Product development measurement enthusiast Troy Magennis, 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:
- Value: Do the right stuff
- Consistency: Do it predictably
- Quality: Do it right
- Speed: Do it fast
- Quantity: Do lots
- Sustainability: Keep doing it
Your North Star should already cover value, and an effective health-related input would be a composite of metrics related to sustainability, quality, and consistency. Though speed and quantity aren't the goal—because business outcomes are your goal—flow metrics can be valuable early indicators of drag and health issues.
Tips for managing non-feature work with the North Star Framework
- 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.
- If possible, visualize non-feature work as opportunities alongside your normal roadmap items. Include these opportunities in your 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
There’s no reason to overhaul your org chart when you get started with the North Star Framework—you already have enough to consider and manage. However, once your North Star is performing well and producing a few months or quarters of learning, you might turn your attention to optimizing your organizational structure to maximize 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 and 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 his book 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.”