OKRs vs KPIs vs roadmaps: where the North Star Framework fits

I have seen a lot of organizations try to solve the gap between strategy and execution by adding one more layer of structure.

Sometimes that structure is OKRs. Sometimes it is a new KPI dashboard. Sometimes it is a more detailed product roadmap. Sometimes it is a stricter Scrum setup. Sometimes it is a scaled agile framework. Sometimes it is a broader strategy model like Balanced Scorecard.

None of these are wrong.

In fact, most of them are useful when they are used for the right purpose.

The problem is that they often get asked to solve more than they were designed to solve.

An OKR framework can help you express ambition, but it does not automatically explain which problems are most important to solve.

A KPI dashboard can show that something is moving in the wrong direction, but it does not automatically create shared understanding around what to do next.

A roadmap can communicate product direction, but it can also become a list of promised features without a clear connection to customer value.

Scrum can create rhythm and delivery focus, but it does not by itself explain why a sprint goal matters strategically.

And scaled agile frameworks can help coordinate large organizations, but they can also become heavy when what the organization really needs is more clarity, not more process.

This is where I believe the North Star Framework becomes useful.

Not as a replacement for all other frameworks, but as a way to connect the missing pieces between strategy, problems, goals and the work people actually do every day.

The problem is usually not strategy itself

In my experience, strategy is rarely where things break first.

Most leadership teams can explain where they want the company to go. They may use different words, and the strategy may be more or less sharp, but there is usually some form of direction.

The harder part starts when that direction needs to become something teams can actually work with.

That is where the gap appears.

The strategy sounds reasonable in a leadership presentation, but a few weeks later product teams are discussing features, marketing is planning campaigns, sales is handling customer promises, customer success is escalating recurring problems and engineering is trying to balance new development with system health.

Everyone is busy.

Everyone can explain their local priorities.

But the shared line between company direction and daily work is often much weaker than people think.

This is why organizations often reach for another framework. They do not necessarily need more process, but they can feel that the current way of working does not create enough alignment.

The question is not whether frameworks are useful.

The question is what part of the problem each framework is actually solving.

Traditional North Star Framework vs this version

The traditional North Star Framework is usually centered around a North Star Metric and a set of input metrics.

The North Star Metric should capture the value customers get from the product, act as a leading indicator of future business success and help teams align around what matters.

The input metrics then describe the factors that influence the North Star Metric.

That is a strong model.

It helps organizations avoid measuring only financial outcomes or output metrics, and it gives product and marketing teams a better way to talk about customer value and sustainable growth.

But I have also seen a practical limitation.

Many descriptions of the North Star Framework explain what to measure, but they do not always go far enough in explaining how to live with that direction in everyday work.

You can define a good North Star. You can define strong inputs. You can even agree that the work should connect to them.

But the day-to-day question still remains:

• What should we focus on this cycle?
• Which problem are we solving right now?
• How do we know whether this work is connected to the strategy?
• How do we make the connection visible to people outside the product team?

That is the reason I use a more operational version of the North Star Framework.

In this version, the chain looks like this:

North Star -> Product Drivers -> Top Problems -> Current Goals -> The Work

The important addition is not only more layers. The important addition is the logic between the layers.

Product Drivers describe the forces that move the organization toward the North Star. They correspond quite well to input metrics in the traditional model, although I use them a little more broadly as strategic drivers rather than only metric inputs.

Top Problems describe the most important problems to solve right now in order to advance those drivers.

Current Goals describe concrete outcomes for a specific cycle.

The Work describes the activities, experiments and tasks needed to reach those goals.

This makes NSF less of a metric model and more of an operating model for alignment.

It does not stop at defining what matters.

It helps the organization see why something matters, what is blocking progress and what work should happen next.

OKRs vs North Star Framework

OKRs are one of the most common ways to create focus in modern organizations.

At their best, OKRs help leadership and teams express ambition in a clear and measurable way. They force a conversation about outcomes rather than activities, and they can make priorities more transparent across the organization.

That is valuable.

But OKRs often run into trouble when they move from presentation to practice.

A team may have an objective. It may have key results. It may even agree that the key results are important.

But the framework does not always help the team understand which problems are blocking progress, which assumptions need to be tested or how the work in the next few weeks should connect back to the broader company direction.

This is where the North Star Framework can make OKRs stronger.

I do not think the right message is:

Stop using OKRs and use NSF instead.

A better message is:

Use NSF to make the logic behind your OKRs visible.

For example, an OKR might say that the company wants to increase activation among new users.

That can be a good goal.

But NSF would push the organization to go one layer deeper:

• Which Product Driver does activation support?
• What Top Problem is currently preventing new users from reaching value?
• What Current Goal should a team focus on this cycle?
• What Work gives us the best chance to learn or improve?

In that sense, OKRs are good at describing the outcome you want, while NSF is good at showing the chain of reasoning from strategic direction to actual work.

KPI management vs North Star Framework

KPI management is essential in almost every business.

You need to know whether revenue is growing, churn is increasing, conversion is dropping, uptime is stable, acquisition costs are under control and customers are getting the support they need.

Without KPIs, you are flying blind.

But KPIs are not the same as strategy, and they are not the same as execution.

A KPI tells you that something is happening.

It does not automatically tell you why it is happening, whether it is the most important thing to focus on right now or what kind of work would create the most meaningful change.

This is where many organizations get stuck.

They have dashboards everywhere. They have graphs. They have reports. They have weekly business reviews.

But when you ask teams how their current work connects to the most important strategic movement in the company, the answer is often less clear.

The North Star Framework helps turn selected signals into focused action.

If a KPI tells you that activation is weak, NSF helps you ask:

• Is activation part of a Product Driver?
• What is the real problem behind the weak activation?
• Is it a product problem, a communication problem, a customer expectation problem or something else?
• What Current Goal should we set for the next cycle?
• What should we do first in order to learn or improve?

KPIs are signals that may result in a Top Problem, such as "customer activation is declining", for one or many departments to try to solve.

NSF helps the organization decide which signals deserve focus, what problems they point to and what work should happen because of them.

Balanced Scorecard vs North Star Framework

Balanced Scorecard is a broader strategy management framework that looks at performance from multiple perspectives, often including financial performance, customer value, internal processes and learning or organizational capability.

The strength of Balanced Scorecard is that it prevents leadership from looking at the business through one lens only.

That is useful, especially in larger organizations where short-term financial metrics can easily dominate the conversation.

But Balanced Scorecard can also become a reporting model more than a working model.

It can help leadership describe the business from several perspectives, but it does not always help teams understand what to do differently this month.

The model can show that customer satisfaction matters. It can show that internal process improvement matters. It can show that learning and capability matter.

But there is often still a missing operational link between those perspectives and the work happening in teams.

The North Star Framework is more focused on that operational link.

It does not try to describe the whole business from every angle. Instead, it helps the organization create a visible chain from long-term direction to the problems and goals that matter right now.

So I would not position NSF as a replacement for Balanced Scorecard.

I would position it as a more practical layer for turning strategic intent into everyday alignment.

Balanced Scorecard can help you understand the business.

NSF can help teams move in the same direction.

Product roadmaps vs North Star Framework

Product roadmaps are useful because organizations need a way to talk about direction over time.

Customers want to understand where the product is going. Sales wants to know what is coming. Marketing wants to plan launches. Customer Success wants to prepare customers. Engineering wants to understand future technical needs. Leadership wants to see that product development supports company strategy.

A roadmap can help with all of that.

The problem starts when the roadmap becomes the strategy.

When that happens, the organization starts to optimize for delivering the roadmap rather than learning whether the roadmap still represents the best path forward.

Features become promises. Dates become commitments. The conversation shifts from value to delivery. And over time, the roadmap can turn into a long list of things someone once believed were important.

The North Star Framework changes the conversation by placing problems before solutions.

Instead of asking only:

What are we going to build?

NSF asks:

• Which Product Driver are we trying to move?
• What Top Problem is standing in the way?
• What Current Goal should we focus on now?
• What Work is most likely to create progress or learning?

This does not make roadmaps unnecessary.

It makes them more honest.

A roadmap should express what we currently believe is a good path forward, based on what we know today.

NSF helps explain why those roadmap items matter and gives the organization a way to change direction when learning shows that something else is more important.

In a healthy setup, the roadmap is not the source of truth for strategy.

It is one possible expression of the strategy.

Scrum vs North Star Framework

Scrum is not a strategy framework, and I think it is unfair to criticize Scrum for not solving strategy.

Scrum is meant to help teams work iteratively, inspect and adapt, and create a rhythm for delivery and improvement.

That is valuable.

But many organizations implicitly treat Scrum as if it should also solve prioritization, strategic alignment and business clarity.

It does not.

A Scrum team can have good sprint planning, good standups, good retrospectives and a well-maintained backlog, but still be working on things that are poorly connected to company strategy.

The sprint goal may be clear locally, but unclear strategically.

This is where NSF fits very naturally.

In many agile teams, the lower levels of NSF already exist in some form.

A sprint goal is similar to a Current Goal. A sprint backlog is similar to The Work.

What is often missing is the upper part of the chain.

• Why is this goal important?
• Which problem does it solve?
• Which Product Driver does it support?
• How does this connect to the North Star?

That is why I often describe Scrum and NSF like this:

Scrum is the engine.

NSF is the navigation system.

The engine helps the team move. The navigation system helps the team understand where it is going and why that direction matters.

SAFe and scaled agile vs North Star Framework

SAFe and other scaled agile frameworks exist because coordination becomes hard when organizations grow.

When many teams work across shared platforms, dependencies, compliance requirements, customer commitments and long-running initiatives, informal alignment is often not enough.

A larger structure can help.

SAFe gives organizations roles, ceremonies, planning structures and portfolio mechanisms that can make coordination more explicit.

For some companies, especially large enterprises, that may be exactly what is needed.

But for many scaleups and mid-sized companies, the problem is slightly different.

They do not necessarily need a full enterprise agile operating model.

They need a way to scale alignment without adding too much weight.

They need to keep the connection between strategy and work visible. They need to reduce dependency on individual leaders carrying all context in their heads. They need to help teams understand priorities without turning the organization into a meeting machine.

This is where NSF can be a lighter alternative, or at least a lighter first step.

NSF does not try to prescribe the full operating model of the company.

It gives the organization a shared structure for direction, problems, goals and work.

That structure can live alongside existing agile practices, whether the organization uses Scrum, Kanban, quarterly planning or something more customized.

SAFe helps coordinate complexity.

NSF helps create clarity.

Sometimes you need both.

But if the organization mainly struggles with strategic alignment, unclear priorities and fragmented visibility, it may be wise to start with the lighter tool before reaching for the heavier one.

A practical comparison

Framework	What it is good at	Where it often struggles	How NSF helps
OKRs	Expressing ambition and measurable outcomes	Connecting goals to problems and daily work	Makes the reasoning behind the goals visible
KPI management	Tracking performance and business health	Turning signals into focused action	Connects selected signals to drivers, problems, goals and work
Balanced Scorecard	Giving leadership a broader strategic view	Becoming too distant from daily execution	Translates strategic intent into operational focus
Product roadmaps	Communicating product direction over time	Becoming feature lists or delivery promises	Connects planned work to problems and strategic drivers
Scrum	Creating team rhythm and iterative delivery	Explaining why the work matters strategically	Adds strategic context above sprint goals and backlog
SAFe / scaled agile	Coordinating many teams in complex organizations	Becoming heavy when the core problem is clarity	Offers a lighter visual alignment layer

The missing layer is usually the problem layer

One of the biggest differences between NSF and many other strategy or goal-setting approaches is the explicit problem layer.

Many frameworks move quickly from strategy to goals.

That can look efficient, but it often hides the most important conversation.

If the goal is to increase activation, what is the problem?

Do users fail to understand the value? Do they get stuck in onboarding? Do they invite the wrong colleagues? Do they lack the right data? Do they not trust the product yet? Do they reach value, but too slowly?

Each of these problems could lead to very different work.

If the organization skips the problem conversation, teams may still be aligned on the goal, but completely misaligned on what needs to be done.

This is why I believe Top Problems are such an important part of the model.

They slow the conversation down in the right place.

They create a bridge between strategic ambition and concrete execution.

They explain for a broader audience why we choose to focus on a specific Current Goal.

They also make it easier for different departments to contribute.

A product team, a marketing team, a sales team and a customer success team may all be able to help solve the same Top Problem, even if their actual work looks very different.

That is where alignment becomes practical rather than theoretical.

NSF Board: making the structure visible

A framework only creates value if people can actually use it.

That is one of the reasons I built NSF Board.

You can work with the North Star Framework on a whiteboard, in Miro, in FigJam, in a spreadsheet or in another digital tool. The tool is not the most important thing.

The most important thing is the conversation the structure creates.

But there is a reason a dedicated board helps.

NSF Board is designed around the actual chain of the framework:

North Star -> Product Drivers -> Top Problems -> Current Goals -> The Work

That means the board does not just show tasks.

It shows why the tasks exist.

It makes it possible to see the connection between strategic direction, current priorities, ongoing work, status updates and learnings in one place.

For leadership, that creates visibility without needing another status deck.

For teams, it creates context without adding another planning framework.

For the organization, it creates a shared picture of what matters right now and how the work connects to the bigger direction.

That is the real point of NSF Board.

Not to replace Jira. Not to replace Scrum. Not to replace OKRs. Not to replace your roadmap.

But to make the connection between strategy and execution visible enough that people can move inside it.

You can also read more about the thinking behind the framework in North Star Framework from the Trenches.

Final thought

The hard part is rarely choosing a framework.

The hard part is understanding what kind of clarity the organization is missing.

If you lack ambition and measurable outcomes, OKRs may help.

If you lack performance visibility, KPI management may help.

If leadership needs a broader strategic overview, Balanced Scorecard may help.

If teams and stakeholders need directional product planning, roadmaps may help.

If teams lack delivery rhythm, Scrum may help.

If a large organization needs coordination across many teams, SAFe or another scaled agile approach may help.

But if the real problem is that strategy does not clearly become problems, goals and everyday work, then the North Star Framework fills an important gap.

It gives the organization a shared chain of reasoning.

Not just where are we going.

But what moves us there, what stands in the way, what we are focusing on now and what work we believe will make a difference.

Because strategy does not fail when it is written down.

It fails when people cannot use it.