Frameworks are an incredibly powerful tool — but they’re not a one-size-fits-all solution. While there’s no silver bullet framework for everything, Rapha Cohen believes that using the right framework in the right situation can, in his words, “accelerate thinking, compensate for laziness, fuel creativity, and can even allow you to avoid psychological biases.” In Rapha’s case, he’s identified five useful frameworks for specific teams within his product organization.

Below, we dive into Rapha’s frameworks and provide additional color for each:

1. Goals-Signals-Metrics (GSM) Framework

What it means: Goals, Signals, & Metrics

Who it’s for: Product Managers

How to use it: The aim of the GSM framework is to select metrics by solving backward from your product North Star, or your overarching Goal. The Goal is the future state of the world if your product is successful. The Goal is something you should be able to convey in a short story.

Next, you identify Signals — evidence of user behavior that indicates you have achieved your Goal. Finally, you identify specific quantitative metrics that tell you whether you’re seeing those Signals or not.

Example: At Waze, for example, the team could set a Goal for Waze to be a user’s first choice for navigation apps. An example Signal was an increase in the proportion of user drives that leveraged Waze, which in turn very clearly informed the correct metrics to track.

Teams should be intentional about the selection of Signals. If the team focused on a Metric of miles driven with Waze, for example, it may have inadvertently created incentives to increase the number of miles that users drive for no reason. You need to adjust your ideal Signal and Metrics to actual user and societal value.

Related content: Google overview, Atlassian’s GSM workshop

2. KPI Graphs Framework

What it means: Creating a graph showing the interrelated nature of KPIs

Who it’s for: Analytics teams

How to use: Rapha believes that the KPI graph approach is superior to the more traditional KPI tree approach. Traditional KPI trees break down all of your KPIs into sub-KPIs; the problem with this hierarchical approach is that it does not take into account things like “network effects” or the interrelated nature of metrics. With KPI graphs, you develop a deep understanding of how actions in one area will affect metrics and behavior elsewhere. As Thomas Packer puts it, “a KPI graph should reduce the stress of employees. If they can understand which things really ‘move the needle,’ they can stop stressing about the ones that don’t, even when the ones that are being talked about too much.”

Example: At Uber, more riders activate more drivers, which creates shorter waiting times, which activates more riders, creating a loop. A tree model wouldn’t capture this structure.

3. HEART Framework

What it means: Happiness, Engagement, Adoption, Retention, & Task Success

Who it’s for: Designers (often used for User Journeys)

How to use: The HEART framework is related to — and often used in conjunction with — the GSM framework. HEART evaluates user experience according to five user-centered metrics: Happiness, Engagement, Adoption, Retention, & Task Success.

To implement HEART, you simply craft a table with two axes: GSM (goals, signals, metrics) live on the x-axis, while the HEART metrics are placed on the y-axis. Thoughtfully completing each box gives you a detailed framework for evaluating product success.

HEART is impactful because it allows you to think about your users and business goals simultaneously. Happiness tracks user sentiment, while engagement is about your actual metrics (ie: Are you driving more usage?). Adoption and retention are about activation and onboarding. Task success measures the extent to which you were able to complete the task in the User Journey.

Related content: Miro’s HEART Template

4. HOSKR Framework

What it means: Hypothesis, Objectives, Signals, Key Results.

Who it’s for: Feature development

How to use: HOSKR can be thought of as a hybrid between the OKR and GSM frameworks. The main difference is that HOSKR connects metrics and goals to a fundamental hypothesis.

As with other frameworks, HOSKR begins with a concrete worldview — a vision for how your product will impact the world. From that Hypothesis, you develop a series of Objectives that are evidence you have achieved your overarching goal. From there, you implement Signals that indicate user behavior is actually being impacted by your product — and the Metrics (or Key Results) to measure that. This gives you a quantitative framework to determine whether your hypothesis has been validated or not.

Related content: How HOSKR improves OKRs

5. OKRs Framework

What it means: Objectives & Key Results

Who it’s most suitable for: Teams

How to use: The OKR framework is one of the most well-known goal-setting frameworks. It is typically used for top-down objective setting throughout an organization. For those who are unfamiliar, review Google’s OKR playbook or Measure What Matters by John Doerr.

Unsurprisingly, OKRs are widely used at Waze. We had the opportunity to go deeper on how Rapha and his team leverage OKRs across the organization, and ensure they are consistently actionable in day to day work.

How do we avoid OKRs becoming a long laundry list of things to do?

This is the absolute essence of a CPO’s job — making sure that the focus always remains on outcomes, not features. The conversation should always be about what you’re trying to achieve, not what you’re going to build.

How do OKRs connect to your team structure?

Ideally, your OKRs should map to your technical infrastructure so that teams can run independently. At a high level, everyone should be aligned on expectations for how fast team structure may change.

Are OKRs the overarching framework for company-wide goals?

At Waze, the top management team develops the initial worldview and objectives. Based on those objectives, teams develop their own OKRs. The teams’ key results then inform management’s organization-wide key results. Once the organization’s OKRs are established, teams begin using their own unique frameworks.

Do you distinguish between Engineerings vs Product OKRs?

Ideally, engineering and product would have common objectives. Often, you also need engineering-specific objectives for things that can’t be captured by the user-centric/business-centric objectives. The goal isn’t for every objective to be user-centric.

How often should you set OKRs?

It depends on the stage of your business, your team, your infrastructure, etc. Don’t be shy about changing something and seeing if it works; everyone should be aligned on the possibility of change. Waze used to set OKRs yearly, then quarterly, and now they’ve settled on reviewing them every six months.

‍