In this chapter, you will learn:
Some teams are able to converge on a North Star Metric and its Inputs after a short workshop session and a bit of follow-up. Other teams require more facilitation, collaboration, and troubleshooting. And that is OK. You want your North Star to reflect the heart of your product strategy and your value to customers, so it’s worth taking time to resolve misunderstandings and ensure alignment.
The difficulties teams experience often fall into two categories: struggling with shared understanding, or falling into common traps.
If you’re experiencing this, try:
If you’re experiencing this, watch out for:
If you are facilitating a North Star workshop, we recommend that you read this chapter so you can be prepared for misunderstandings or challenges that might bubble up. With these actionable tips in your back pocket, you’ll be able to cut through conflict and align your team.
Often, if a team seems to struggle to converge on its North Star, it’s because teammates lack a common understanding of their product’s purpose or what customers value. If your team is struggling with shared understanding, we suggest you dig into beliefs, your product vision, and key value exchanges.
Beliefs
Every person in an organization approaches a business problem or product opportunity with beliefs and biases. These often describe:
We’ve found that identifying these beliefs can help you define and implement an effective North Star. If you fail to uncover the beliefs of your colleagues, you may leave unresolved tensions within a team, miss opportunities to align, and overlook unique perspectives about your product.
The following are examples of statements that contain beliefs.
One simple way to identify beliefs: Ask your North Star team to spend a few minutes independently filling in one or more of these templates. The goal at this point is to cast a wide net that catches biases and assumptions, so be sure to remind your team that there are no wrong answers.
Designers and Developers Should Embrace Belief Elicitation
Many product designers are concerned that decision makers don’t understand the ROI of user experience (UX). Similarly, developers often struggle to explain the value of non-feature or non-customer-facing work, like tooling, refactoring, and technical debt reduction.
Belief mapping is a great opportunity to get these concerns on the table. Developers should explain what they believe will happen if technical debt continues to mount. Designers should outline how they believe that under-investment in UX will result in customer pain.
Your business may have already done the important work of crafting a product vision statement. These existing statements of product vision can be great catalysts to teasing out a good North Star.
As your team defines your North Star, review your product vision statement. Ask yourself: *What does this statement say that is distinct or foundational? What can we learn about our product’s value from this statement?*
Here are a couple hypothetical vision statements of fictional products. Note how these statements contain insights about the product’s value that might help a product team design a good North Star.
“For the film aficionado, our documentary streaming service is the world’s most authoritative source of expertly curated short films, expert commentary, and informed community.”
What we learn from this statement:
Questions this statement raises:
“For the boutique maker of bottled goods, our label-design app is the most reliable way to produce high-quality but affordable label designs that fit your manufacturing workflow while distinguishing your product on the shelf and your brand in the marketplace.”
What we learn from this statement:
Questions this statement raises:
Some teams find that their vision is too broad to inform their North Star—or maybe the vision doesn’t exist at all. Such teams should consider revisiting their beliefs and collaboratively defining their product vision.
There are many models for writing a vision statement. One simple template was popularized by Geoffrey Moore in Crossing the Chasm
For [target customer] who [need or opportunity], the [product] is a [product category] that [key benefit]. Unlike [competitive alternative], our product [statement of primary differentiation].
Don’t Manufacture Certainty when Formulating Your Strategy
We’ve seen it happen repeatedly: when a team is expected to finalize a strategy, they may manufacture certainty. The team equates their uncertainty with a lack of confidence or skill. So they manufacture a strong point of view, even when—below the surface—there are a lot of questions lurking. Your North Star and Inputs should represent your current thinking, wants, questions, and all.
For example, a team we worked with was under a great deal of pressure to come up with a personalization strategy. Their presentations were impressive, and they incorporated this element into their North Star Framework, but the team glossed over key assumptions about the limits of personalization.
Even with complex products, you can typically isolate a handful (3-6) of essential actions or events where customers derive value from the product. These key value exchanges demonstrate the true essence and intent of the product. If possible, they should be reflected in your North Star.
To identify key value exchanges, visualize the customer journey. As you do, note those important moments where your product solves a problem for the customer or enhances a customer’s ability to accomplish a goal. These moments—where the customer’s investment in time, attention, energy, money, are rewarded with meeting their needs—are the key value exchanges.
Tristan Harward, a UX Manager at Rapid7, recommends starting with a short collaborative activity to make a high level map of all the activities your users go through in your product. “Try to brainstorm or capture every major thing users do or accomplish on post-its, then identify what’s most valuable afterward by voting or rating,” suggests Tristan. “That way, you’ll get a more complete view of the journey to value.”
By organizing the key activities in your product, you’ll start to see patterns in value you might not have picked up on otherwise, and that’s a good start.
Tristan Harward, UX Manager at Rapid7
To jump-start your North Star process, it’s useful to capture your existing shared understanding of your customer experience. It’s even better to include existing research that you may have already done, or to follow up with additional research to understand what your users really value. As Tristan says, “By organizing the key activities in your product, you’ll start to see patterns in value you might not have picked up on otherwise, and that’s a good start.”
For many products, some key value exchanges happen outside the actual product—for example, the concert-goer arriving at their chosen seat is a key value exchange for a ticketing app. Don’t exclude these important stories just because they don’t occur within the product itself. You may also find yourself guessing about the customer journey, or using an idealized version of the journey. This is a good signal to either do a bit more research, or to make those assumptions explicit (e.g. “We’re not exactly sure if this is what our customers are doing, but this is our best guess at the moment”).
Avoid these common problems as you design your North Star
Has your team struggled to converge on a North Star? First of all, that’s normal (and valuable). If you’re struggling, spend some time digging into potential causes of this disagreement and divergence.
We’ve noticed several challenges that teams might experience.
Yes, “measurable” is a characteristic of a good North Star on our checklist, but watch out for getting too concerned too soon with determining exactly how you’ll calculate the metric or its Inputs. This is especially common for companies with a long history of struggling to predict customer success. They disregard promising concepts because they aren’t yet sure how to measure them.
It’s important to focus on important decisions and on reducing uncertainty, as Douglas W. Hubbard’s book How to Measure Anything: Finding the Value of “Intangibles” in Business reminds us.
Myth: When you have a lot of uncertainty, you need a lot of data to tell you something useful.
Fact: If you have a lot of uncertainty now, you don’t need much data to reduce uncertainty significantly. When you have a lot of certainty already, then you need a lot of data to reduce uncertainty significantly. In other words—if you know almost nothing, almost anything will tell you something.
For example, say you’re converging on the idea of Project Health as a North Star Metric. You agree that Project Health is a hallmark of your product strategy, and your sales team already pitches Project Health to the market. However, you aren’t yet measuring Project Health—you don’t even know how you would measure it. Don’t disregard the metric. Instead, identify how you might measure it, even if it’s imperfect. After all, you need to start somewhere. If you could simply reduce uncertainty regarding your claims and focus, imagine what that might be worth.
Even after teams review the product formula and examples of the combined effect of a North Star Metric and Inputs, it can be difficult to shift focus from driving the metric to driving the Inputs.
By design, the North Star Metric is not immediately actionable—the Inputs are where you apply actions.
If you find yourself thinking only about the metric, revisit Inputs. Do some brainstorming or group mind-mapping about the formula of Inputs that produces the metric, and vice versa. It is perfectly normal to jump back and forth between the two. Try the depth, breadth, frequency, and efficiency heuristic, asking the team how it translates to your product and business.
Workshop participants are often sure that their company needs more than one North Star. Certainly, in some cases, when a company has distinct lines of business with different customer bases, this might be true. However, the number of times one metric will suffice outnumbers situations that require multiple North Stars by a large margin.
Here’s an example. A large bank has dozens of consumer banking “products” (savings accounts, checking accounts, investment accounts, etc.). From a balance sheet and organizational chart perspective, it makes sense to call each of these things “products.” But do customers view these as distinct products? Or do they view the bank as a single product: a trustworthy partner in their quest for financial independence? In this case, a single North Star for all consumer banking products is usually appropriate.
Challenge the need for multiple North Star Metrics. Look for real boundaries in terms of users, their needs, and the strategy to meet those needs. Note where products are actually “packages” or add-ons.
In workshops, we often observe a moment when the real world catches up to a team. They start with enthusiasm, but then realize that their company has so many problems that they fear they can’t ever actually change. It’s the classic “it’ll never work here” syndrome, exacerbated by the lack of a common framework.
Your company may currently do many things imperfectly. You focus on vanity metrics, chase short-term revenue, run a feature factory, crank out features to close deals, organize around the tech stack (not value streams), or routinely abuse metrics and KPIs. That’s natural, and shouldn’t prevent you from making progress towards the North Star Framework. There are two strategies here that can be especially effective: