Building your first real Strategy Map (and why that's important)

Key Takeaway: A Strategy Map is the single artifact that connects strategy to execution. Without one, strategy lives in a deck and execution lives in a project tracker, and the two never meet. A real Strategy Map has 5 components: Ultimate Goal, Strategic Pillars (how-to-win choices), OKRs (change goals), KPIs (maintenance goals, the metrics of business as usual), and Initiatives (the work that moves an OKR or KPI). A better Strategy Map is clearer and simpler: anyone can see in 30 seconds how their work connects to strategy, every Initiative has a parent goal, and rigid Key Result→Objective cascading is replaced with directional alignment.

If you've ever sat down to build a complete goal tree for your organization, you know the feeling. It's deceptively hard. You have a strategy. You have OKRs. You have KPIs. You have Initiatives. You have company goals, team goals, and maybe even individual goals. And somewhere in the middle, there's the question of how all of this should connect.

The frustrating part is that there's no single right answer. I've worked with hundreds of companies on this, and what I've learned is that there are usually a few valid ways to structure the same goal tree, each of which would more or less work. But not all of them work equally well. Some paths create clarity, alignment, and momentum. Others create administrative overhead, fake alignment, and quiet team resentment.

There are really two hard problems hiding inside "build the Strategy Map." The first is identifying what kind of thing each intention actually is. Is this a Strategic Pillar, an OKR, a KPI, or an Initiative? The same intention can often be plausibly classified in 2 or 3 different ways, and putting it in the wrong category creates real downstream pain.

The second hard problem is figuring out how each goal should cascade. Should company OKRs always be broken down into team OKRs? And, if so, how? Do you go down to the individual-level? When should you not cascade something at all?

We'll get to cascading later, because you can't cascade well until you know what each thing actually is.

But let’s first take a look at what “good” really means and why it’s worth investing time into building a Strategy Map for your business.

The importance of a Strategy Map

Before we get into the mechanics, it's worth being honest about what a (good) Strategy Map actually does for the business, and what its absence quietly costs you.

A Strategy Map is the single artifact that connects strategy to execution. Without one, strategy lives in a deck and execution lives in a project tracker, and the two never really meet. Leadership keeps repeating the strategy in all-hands meetings while teams keep shipping work that doesn't obviously support it. The disconnect isn't usually because teams are doing the wrong things on purpose. It's because nobody ever drew the line from the Strategic Pillars all the way down to the actual work, in a way that anyone could see.

When the Strategy Map is solid, a few things change:

Prioritization gets easier, because every new idea has to find a parent in the map (a Strategic Pillar, an OKR, or a KPI) or it doesn't make the cut. Roadmaps get sharper, because Initiatives that don't tie to a goal stop getting greenlit. Cross-team conflicts get less political, because the map makes it obvious whose work is supposed to move which number, and where the real dependencies are. New hires get up to speed faster, because they can look at the map and understand in 10 minutes what the company is trying to do, instead of inferring it over 6 months.

There's also a quieter benefit that doesn't get talked about enough. A real Strategy Map forces leadership to be specific. You can't put "we want to be the best" on a Strategy Map. You have to declare a Strategic Pillar, a target for a KPI, an Objective with a deadline. The act of building the map exposes the places where the strategy is still vague, and gives the leadership team a forcing function to actually decide. Many of the companies I've worked with discover, halfway through their first real Strategy Map exercise, that they don't fully agree on the strategy yet. That's not a failure of the exercise. That's the exercise doing its job.

And then there's what it costs you not to have one. Strategies that read well in the boardroom but never move the company. Teams setting OKRs that don't connect to anything above them. Initiatives shipping on time without any of the underlying metrics moving. Quarterly reviews where everyone is "on track" and the business still misses the year. These aren't execution problems. They're Strategy Map problems.

A good Strategy Map doesn't make a bad strategy succeed, but it does make a good strategy actually executable. That's the whole point.

The components of a Strategy Map

A Strategy Map isn't just a hierarchy of OKRs. A complete one usually has 5 distinct components, each with a different role.

Ultimate Goal

This sits at the very top. It defines what winning looks like for your organization. As we've written elsewhere, a good Ultimate Goal answers 3 questions: what's the purpose of your organization, who is it for, and when will you consider the venture a success. The Ultimate Goal sets the playing field. It defines which battles you're choosing to fight, and what success on that field looks like.

Strategic Pillars

These are your how-to-win choices on that playing field. A Strategic Pillar answers questions like "how are we going to differentiate ourselves?" or "how are we going to win against our competition?" You should aim for 3 to 5 Strategic Pillars. Together with your Ultimate Goal, they form your strategy.

Strategy isn't time-bound. You don't "finish" a Strategic Pillar the way you finish a goal. You either keep choosing to compete on that ground, or you change your strategy. The success of a Strategic Pillar is measured through KPIs (which also don't have deadlines), not through Key Results.

This is the most important distinction to get right, and it's where most Strategy Maps start to break. Strategy and goals are not the same thing. Strategy is the choice of how you're going to win. Goals are what you're going to deliver inside that strategy.

OKRs

These are change goals: time-bound, ambitious goals that measure something you want to change. An Objective, by definition, has a deadline, typically a quarter or a year. Key Results define how you'll measure progress against it. OKRs don't always sit underneath a Strategic Pillar. An OKR can contribute to a Strategic Pillar (translating a strategic choice into a specific change this cycle), to a KPI (driving a meaningful jump in a metric you normally just maintain), or to another OKR (a team OKR that supports a Company OKR). All 3 are valid parents.

KPIs

These are maintenance goals: goals that measure something you want to maintain. Revenue. Churn. Uptime. NPS. Cost per acquisition. KPIs are still goals. You set a target, you own the number, you're accountable for it. They're just a different kind of goal from an OKR. An OKR measures something you want to change. A KPI measures something you want to maintain. KPIs are the metrics of business as usual: the dials you watch every week to know whether the business is running well and whether your Strategic Pillars are working. KPIs don't have deadlines either, but for a different reason than Strategic Pillars: you always want them healthy, you don't want them to "finish."

Initiatives

These are the projects and tasks people actually do to move an OKR or a KPI. Initiatives aren't goals, they're work. "Run a customer reactivation campaign" is an Initiative. "Launch the new onboarding flow" is an Initiative. "Hire 2 SDRs" is an Initiative. Initiatives align to a parent goal: either to an OKR (the work that will move a Key Result) or to a KPI (the work that will keep a maintenance number healthy or pull it back into the healthy range). If an Initiative doesn't have a parent goal, that's a red flag. It's either an OKR or a KPI that hasn't been named, or it's work that probably shouldn't be on the roadmap.

A good Strategy Map connects all 5. Ultimate Goal at the very top, defining what winning looks like. Strategic Pillars below, defining how you'll win. OKRs sitting wherever change needs to be driven, whether that's underneath a Pillar, against a KPI, or in support of another OKR. KPIs running alongside, measuring whether the Pillars are working and whether the business stays healthy. Initiatives sitting underneath OKRs and KPIs, where the actual work lives. Each component plays a fundamentally different role. The mistake most companies make is collapsing them into one ("everything is an OKR") or treating them as completely unrelated systems.

For the deeper distinction between metrics, KPIs, and Key Results specifically, we've written about that in a separate piece. It's worth reading if the line between KPIs and Key Results still feels blurry to you.

What makes one Strategy Map better than the other?

If there's no single right answer, what makes one version of a Strategy Map better than another?

I think it comes down to 3 things:

Clarity

Can anyone in the company, at any level, look at the Strategy Map and understand what the organization is trying to achieve, how their team contributes, and what they personally should focus on? If the answer is "yes, in 30 seconds," your map is working. If they need to click through 4 layers and read 12 OKRs to figure out where they fit, the map is too complex.

Understanding

Can each team articulate, in 1 sentence, how their OKRs support a Strategic Pillar or a Company OKR, and how their Initiatives support those OKRs? Not in jargon. In plain language. If they can't, either the OKR isn't connected to the strategy, or the connection is too abstract to be useful.

Administrative overhead

How much time per cycle does the Strategy Map itself cost the organization, in drafting, reviewing, updating, reconciling? The right answer is "not much." If your teams are spending more time maintaining the map than they're spending using it to make better decisions, the map is fighting you instead of helping you.

The best Strategy Maps I've seen optimize for all 3. They're simple enough that anyone can navigate them. They're connected enough that every team knows how their work matters. And they're light enough that maintaining them doesn't become a job in itself.

Hard problem 1: is this a Strategic Pillar, an OKR, a KPI, or an Initiative?

This is where almost every team gets stuck, and it's the part of building a Strategy Map that nobody really warns you about.

You'll be in a planning session and someone will say: "Customer retention is really important to us." Great. Is that a strategic choice (a Strategic Pillar)? A change goal we're driving this cycle (an OKR)? A maintenance goal we're keeping within a healthy range (a KPI)? A piece of work we're committing to (an Initiative)? You can make a credible argument for several of them.

This is the categorization problem, and it shows up constantly. Some examples I've seen real leadership teams debate:

• Is "expand into the U.S. market" a Strategic Pillar, or an OKR for this year?
• Is "become the most trusted brand in our category" part of our strategy, or an Objective for this quarter?
• Is "improve our gross margin" a KPI we want to monitor, or an OKR we're actively driving this cycle?
• Is "reduce churn from 8% to 5%" a Key Result inside an OKR, or just a KPI target?
• Is "redesign the pricing page" an OKR, or actually just an Initiative under a conversion-rate OKR?

The answer to each of these matters, because it determines how the intention gets structured, owned, and tracked. Putting it in the wrong category doesn't just create a labeling problem. It creates real downstream pain. A maintenance goal dressed as a change goal drains attention every cycle on a number that was never meant to dramatically move. A change goal dressed as strategy keeps getting written into the strategy deck without ever getting the time-bound, owned execution that would actually move it. A piece of strategy dressed as a quarterly OKR keeps getting "set" and "reset" every cycle without ever being treated as the durable choice it actually is. And an Initiative dressed as an OKR makes the team accountable for completing the work rather than for moving the number the work was supposed to move.

[fs-toc-omit]The 4 tests that tell you which category something belongs in

When you've got an intention on the table and you're not sure where it fits, apply these 4 tests in order.

Test 1: Is this a choice, a change, something to maintain, or work to do?

• A choice about how we're going to differentiate or which key challenges we're going to tackle? → It's part of your strategy. Strategic Pillar.
• Something we want to change, by a specific date? → It's a change goal. OKR.
• Something we want to maintain, with no end date? → It's a maintenance goal. KPI.
• A specific piece of work, project, or task someone will do? → It's an Initiative.

"Compete on best-in-class onboarding experience" is a choice about how you're going to win against competitors. That's a Strategic Pillar. "Reduce time-to-first-value from 14 days to 3 days by Q4" is something you want to change on a deadline. That's an OKR. "Maintain CSAT above 4.6" is something you want to maintain. That's a KPI. "Rebuild the onboarding flow with embedded checklists" is a piece of work that will help move that OKR. That's an Initiative.

Test 2: Is this measurable, or is it work?

• A measurable outcome? → OKR or KPI (use Test 1 to tell which).
• A specific piece of work or project? → Initiative

This is the easiest way to separate Initiatives from goals. A goal is a measurable outcome. An Initiative is the work you do to achieve that outcome. "Launch the new pricing page" is work, so it's an Initiative. "Increase pricing-page conversion from 2% to 4%" is a measurable outcome, so it's a Key Result inside an OKR. The Initiative aligns to the OKR. Both can be tracked, but only one is a goal.

Test 3: Does it have a deadline?

• Yes, it has a clear end date? → OKR (or an Initiative, which also has a delivery date)
• No, because it's a durable choice about how we compete? → Strategic Pillar
• No, because we always want this maintained? → KPI

Deadlines separate change goals and Initiatives from everything else. An Objective, by definition, has a deadline. Initiatives have delivery dates too. Strategic Pillars don't. KPIs don't either, but for a different reason: you're not trying to "finish" a KPI, you're trying to maintain it indefinitely.

Test 4: What does success look like at the end?

• "We achieved this specific outcome by this date"? → OKR
• "We continued to be known for this, year after year"? → Strategic Pillar
• "We maintained this number within the healthy range, week after week"? → KPI
• "We shipped this thing, on time and as scoped"? → Initiative

Strategic Pillars don't have an end state in the way change goals do. You don't "finish" being known for product quality, or having the best customer support, or being the easiest tool to use in your category. OKRs have very clear end states. The Key Results either got hit or they didn't, on or before the deadline. KPIs have ongoing states. You're either inside the healthy range or you aren't, and you're always trying to stay inside it. Initiatives have completion states. They either shipped or they didn't.

In my experience, applying these 4 tests together resolves most categorization debates within 5 minutes. The cases that remain genuinely ambiguous tend to be the ones where the intention is actually a combination (e.g., "expand into the U.S. market" might break down into a Strategic Pillar about which markets you're competing in, plus several OKRs that operationalize the expansion this year, plus a few new KPIs you'll start tracking, plus a long list of Initiatives that move all of them).

Hard problem 2: figuring out how each goal should cascade

Once you've categorized everything, the second hard problem shows up immediately: how does this goal connect to the rest of the Strategy Map? Which OKRs roll up to which Pillar or higher-level OKR? Which Initiatives sit under which OKR or KPI? And, just as important, what should not be cascaded at all?

This is where most Strategy Maps get unnecessarily complicated, and where one specific bad pattern shows up over and over again.

Rigid cascading (Key Results becoming Objectives) doesn't work

Let me be blunt about this. The model where a Company-level Key Result becomes the Objective of a team below, whose Key Results then become the Objectives of teams further down, is a bad model. It gets recommended in some classic OKR books, but in practice it almost never works. We've explained in detail why in our piece on what Measure What Matters got wrong.

The short version: an Objective is an Objective because it meets certain criteria. It's qualitative, it provides direction, it keeps the team focused on the bigger picture. A Key Result is something else entirely. It's quantitative and measurable. When you turn a Key Result into an Objective just because it got assigned to another team, you end up with a quantitative Objective, which is really just a Key Result in disguise. The team loses the qualitative direction that Objectives exist to provide.

It also creates a structural mess. If Key Result A2 becomes Objective B, then progress on the parent Objective A depends on the new Key Results B1, B2, and B3 measuring the exact same thing as the original A2. Otherwise the math breaks. In practice, the math always breaks. Whether something is an Objective or a Key Result shouldn't depend on whose point of view you're looking from.

So: don't do rigid KR→Objective cascading. It looks neat on a slide and falls apart everywhere else.

What to do instead: directional alignment

Teams see the Strategic Pillars, the Company OKRs, and the company-level KPIs. Each team writes its own OKRs, with the requirement that every Objective they write has an explicit parent: either a Strategic Pillar, a Company OKR, or a KPI. The team's Key Results are theirs to define, based on what they think will actually move the parent.

The map connects, but it connects on Objective-to-parent links, not on Key Result-to-Objective links. You get alignment without forcing every team into a quantitative Objective they don't believe in. We've also covered this in our piece on cascading versus directional alignment.

Many layers vs. few layers

Should you have Strategic Pillars, Company OKRs, Department OKRs, Team OKRs, and Individual OKRs? Or just Company OKRs and Team OKRs?

Fewer layers almost always wins. Every additional layer adds review cycles, drafting work, and the risk of teams writing OKRs that exist mainly to fill the layer. A Strategy Map with 5 layers can look impressive in a strategy deck and feel exhausting in practice.

The simplest version that still gives you what you need usually involves Strategic Pillars at the top, Company OKRs (3 to 5 per cycle), and Team OKRs (3 to 5 per team), with KPIs running alongside at the levels they matter and Initiatives underneath the OKRs and KPIs that need active work. Sometimes a department layer is genuinely useful. Sometimes individual OKRs make sense for specific roles. But the default should be fewer layers, not more.

This is closely related to a question we've explored in should senior leadership teams have their own OKRs: just because a layer exists in your org chart doesn't mean it needs its own layer in your Strategy Map.

Shared OKRs vs. duplicated OKRs

Some priorities require multiple teams to work together. A new market launch involves Sales, Marketing, Product, and Customer Success. A reliability program spans Engineering, Support, and Product.

You have 2 options. You can create a single shared OKR that all relevant teams own jointly. Or you can have each team write its own version of the OKR, each with its own KRs.

Shared OKRs are usually better. They reduce duplication, create real cross-functional accountability, and prevent the "we hit our piece but the company didn't move" outcome that happens when teams optimize their slice in isolation.

Top-down vs. bottom-up vs. middle-out

The 3 classic approaches to building the map. Pure top-down (leadership writes everything, teams accept). Pure bottom-up (teams write everything, leadership stitches it together). Middle-out (leadership writes the top, teams write their own, then you reconcile).

Most successful Strategy Maps come from middle-out. Leadership defines the Strategic Pillars and Company OKRs and the company-level KPIs. Teams then write their own OKRs that support those, with the freedom to choose what they're going to focus on and how, and they add the Initiatives they think will actually move those OKRs. Leadership validates the team OKRs to make sure nothing important is being missed.

This approach respects two things at once: that strategy has to come from the top, but that the people doing the work usually have better insight into how to deliver it than anyone above them. It's roughly the approach we recommend in our piece on setting OKRs with your team.

The most common mistakes

Across hundreds of organizations, the failure patterns are remarkably consistent:

• Treating everything as an OKR. Companies turn KPIs into "OKRs," Strategic Pillars into "Annual OKRs," and Initiatives into "OKRs" because the framework feels cleaner when everything fits one format. The result is Strategy Map bloat and confusion about what's actually a strategic choice, a change goal, a maintenance goal, or just work to be done.

• Too many layers. Every "let's add a layer to capture this" decision compounds into a map that nobody can hold in their head.

• Rigid KR→Objective cascading. Key Results from one level become the Objectives of the team below. It looks tidy and almost never works in practice. Use directional alignment instead.

• Initiatives without parent goals. Projects on the roadmap that don't tie to any OKR or KPI. Either the underlying goal hasn't been named, or the work shouldn't be on the roadmap.

• Duplicating goals across teams instead of using shared OKRs. Each team owns "their version" of the same goal, nobody is fully accountable, the goal moves slowly.

• Treating the map as set-in-stone. Reality changes, but the map never does. By month 2 of the quarter, the map no longer reflects what the organization is actually working on.

The good news is that all 6 of these are fixable. They just require leaders willing to make the map simpler and more honest, even if the original version felt more "complete."

How to build your Strategy Map, step by step

When you sit down to design or revise your Strategy Map, here's a sequence that tends to produce better results than the default "let's map everything perfectly" approach.

1. Define your Ultimate Goal. What does winning look like for your organization? Which battles are you choosing to fight, and when will you consider the venture a success?

1. Choose your 3 to 5 Strategic Pillars. These are your how-to-win choices on the playing field your Ultimate Goal defines. Together with the Ultimate Goal, they form your strategy.

1. Identify the KPIs that measure your Strategic Pillars and your business health. Revenue, churn, gross margin, NPS, runway. These don't change quarterly. They run alongside the map, telling you whether the Pillars are working and whether the business stays healthy.

1. Set 3 to 5 Company OKRs per cycle. Each Company OKR should contribute to a Strategic Pillar, to a KPI you want to dramatically move this cycle, or in some cases to another higher-level OKR. Make the parent explicit. These are the changes you're driving this quarter or year.

1. Let teams draft their OKRs in response. Each team picks 3 to 5 of their own Objectives, each one contributing to a Strategic Pillar, a KPI, or a Company OKR, plus the team-level KPIs that matter for their function. Encourage shared OKRs where the work cuts across teams. Don't let teams cascade by turning a parent Key Result into their Objective.

1. Add Initiatives underneath the OKRs and KPIs. For each OKR and each KPI that needs active work, list the Initiatives, the actual projects and tasks, that will move it. Every Initiative needs a parent goal. If you can't name the parent, the Initiative doesn't belong on the roadmap.

1. Reconcile, don't dictate. Leadership reviews team goals to make sure the company-level priorities are covered. If a Company OKR isn't being supported by any team, that's a problem to solve.

1. Stop there. Don't add layers just because you can. The simplest version of the map that gives you clarity, alignment, and ownership is the right one.

For the deeper mechanics of how alignment actually works, we've written a more detailed companion piece on OKR alignment that covers vertical and horizontal alignment in more depth.

[fs-toc-omit]One question to ask at your next planning round

Here's the concrete move for this week.

At your next planning round, take every intention on the table, every idea, target, project, "we should do this," and ask one question for each:

"Is this how we're choosing to win, something we want to change, something we want to maintain, or work we'll do to move one of those?"

The answer tells you exactly where it belongs. Choices about how you're going to differentiate or tackle market challenges become Strategic Pillars. Things you want to change, by a deadline, become OKRs. Things you want to maintain become KPIs. The specific work to move any of those becomes Initiatives.

You'll be surprised how many debates this single question resolves. The arguments that felt like "we disagree about strategy" turn out to be "we just hadn't agreed on whether this was a strategic choice or a change goal." The Key Results that felt forced turn out to be KPIs in disguise. The OKRs that kept getting reset every quarter turn out to be Initiatives that needed an actual parent goal. The OKR that no team could move turns out to be a piece of strategy that was never named as one.

The goal of the Strategy Map isn't to be complete. It's to make the company easier to run. The simpler version that accomplishes that, with each intention categorized properly, always wins.

[fs-toc-omit]How Perdoo helps you build your Strategy Map

Building a Strategy Map from scratch in a spreadsheet or a slide deck is doable, but it gets messy fast. That's exactly the problem Perdoo is built to solve. Perdoo gives you a dedicated home for each of the 5 components, so your Ultimate Goal, Strategic Pillars, OKRs, KPIs, and Initiatives are all native objects in the system, not improvised cells in a grid. Every Objective is required to have an explicit parent (a Strategic Pillar, a KPI, or another OKR), so directional alignment is enforced by the tool itself and rigid KR→Objective cascading is structurally avoided. Initiatives align to the OKRs and KPIs they're meant to move, which means no orphaned projects on the roadmap. The result is a Strategy Map that's actually clear at a glance: anyone in the company can open Perdoo and see how their work connects to the strategy, without anyone maintaining a separate diagram. If you want to architect a clean Strategy Map without inventing the structure yourself, start for free or request a demo.