Methods can be added on top of a flexible foundation. A foundation cannot be added on top of a method.
In this guide
- Interchangeability Is About the Foundation, Not the Screens
- Why You Can’t Bolt Hoshin Kanri Onto an OKR App
- Most Large Organizations Already Run More Than One Method
- The Real Test: One View Across Different Methods
- History Has to Survive the Change
- Methods Keep Evolving Too
- What to Look For in Strategy Execution Software
- Frequently Asked Questions
Key Takeaways
- →Six building blocks sit under every method: an outcome, a measure, an owner, a horizon, a relationship, and a stream of updates. Methods are arrangements of those six.
- →Foundations are expensive to change because reports, permissions, notifications, integrations and history all assume the existing structure.
- →Large organizations already run several methods at once. The practical goal is not one method everywhere, but one view across all of them.
- →Manual consolidation before each review introduces delay, error and interpretation. A shared foundation removes all three by putting the connection in the data.
- →AI assistants reason about the structure underneath. On a shared foundation one capability serves every method; on a single-method app each feature is rebuilt for the next.
Interchangeability Is About the Foundation, Not the Screens
Supporting several strategy methods is a decision about foundations, not a feature. Every method shares the same underlying building blocks and differs only in how they are arranged and presented. A platform that models the blocks directly can change method by changing the arrangement, not the data.
The previous article described what happens when a vibe-coded OKR app meets a second strategy method: workarounds, broken reports, and eventually a rebuild. A reasonable response is to ask why the app cannot simply be extended. If AI can build an OKR tracker in a weekend, surely it can add Hoshin Kanri in another.
It can add screens that look like Hoshin Kanri. What it cannot easily add is the thing that makes multiple methods useful: a common foundation that lets them share people, data, history, and reporting. That foundation has to exist before the methods do.
Every strategy method has its own vocabulary and its own way of presenting work. OKRs speak of objectives and key results. The Balanced Scorecard speaks of perspectives, measures, and strategy maps. Hoshin Kanri speaks of breakthrough objectives, annual priorities, and the X-matrix.
Underneath the vocabulary, though, they share common building blocks: an intended outcome, a way of measuring it, an owner, a time horizon, a relationship to other outcomes, and a stream of updates. A platform designed for several methods models those building blocks directly, and treats each method as a way of arranging and presenting them.
The Six Shared Building Blocks, by Method
| Building block | OKRs | Balanced Scorecard | Hoshin Kanri |
|---|---|---|---|
| An intended outcome | An objective | An objective inside a perspective | A breakthrough objective, stepped down to annual priorities |
| A way of measuring it | Key results with start, target and current values | Measures carrying targets and thresholds | Targets agreed for each annual priority |
| An owner | Objective and key result owners | A named owner per measure | Owners agreed through catchball, often with an executive sponsor |
| A time horizon | The quarter | Continuous, reviewed on a cycle | Multi-year, stepped into annual commitments |
| A relationship to other outcomes | Parent and child alignment | Cause and effect, drawn as a strategy map | Correlation, drawn on the X-matrix |
| A stream of updates | Check-ins against key results | Periodic measure updates against threshold | Review against annual priorities and improvement work |
Read across any row and the same block appears in three costumes. Read down a column and you have a method. That is the whole idea: model the rows, and the columns become configuration rather than code.
When the foundation works this way, changing methods means changing the arrangement, not rebuilding the data. When the foundation is shaped around one method, every other method has to be forced into a structure that was never meant for it.
Why You Can’t Bolt Hoshin Kanri Onto an OKR App
Software foundations are expensive to change because everything else is built on top of them. Reports, permissions, notifications, integrations, and history all assume a particular structure. Change the structure, and every one of those parts has to change with it.
This is true regardless of how the code was written. AI tools make individual changes faster, but they do not reduce the number of things that depend on the foundation, and they do not remove the need to test that everything still works. In practice, a team trying to add a second method to a single-method app faces a choice between a large, risky rewrite and a growing pile of special cases.
Most Large Organizations Already Run More Than One Method
It is common to talk about a company’s strategy method as if there were only one. In larger organizations, there rarely is. Product and engineering teams often prefer quarterly OKRs. Finance and operations tend to run on KPIs and scorecards. Leadership may plan in multi-year themes. Acquired businesses keep the practices that worked for them.
Forcing everyone onto a single method tends to create resistance, and the method that fits one part of the business may be a poor fit for another. The more practical approach is to let each part of the organization use what suits it, while giving leadership one coherent view across all of it. That is only possible when the methods share a foundation.
There is also a practical benefit for people. Employees move between teams, and leaders are promoted across functions. When methods share a foundation, a manager who moves from product to operations keeps working in the same system, with the same habits and the same history, even though the method changes around them. When each method lives in a separate tool, every move means learning a new system and leaving old commitments behind.
See Hoshin Kanri and OKRs on One Foundation
The Real Test: One View Across Different Methods
The value of interchangeable methods shows up most clearly at the top of the organization. A leadership team wants to see how strategy is progressing across the whole business, not separately for each method in use. It wants to know which strategic themes are on track, which are at risk, and where a problem in one unit might affect another.
With a shared foundation, this view is natural. A scorecard measure in finance, an OKR in product, and a Hoshin priority in operations can all connect to the same strategic theme and roll up into one picture. Without a shared foundation, someone builds that picture by hand in a spreadsheet before every review, which is exactly the work strategy software was supposed to remove.
That manual consolidation is more than an inconvenience. It introduces delay, because the picture is only as current as the last time someone assembled it. It introduces error, because figures are copied between systems by hand. And it introduces interpretation, because whoever builds the spreadsheet decides how different methods translate into one view. A shared foundation removes all three by making the connection part of the data, not part of someone’s preparation for a meeting.
History Has to Survive the Change
When an organization moves from one method to another, it should not lose what it has learned. Past goals, measures, and progress are valuable evidence. They show how reliable forecasts have been, which teams set realistic targets, and how performance has changed.
On a shared foundation, history survives a change of method because the underlying records stay the same. Only the way they are arranged and presented changes. On a single-method app, history is shaped by the old method and must be translated, often imperfectly, into the new one. Some of it is usually lost along the way.
Methods Keep Evolving Too
Interchangeability is not only about switching between established methods. The methods themselves keep developing. Organizations combine them in new ways, adapt them to their own cultures, and increasingly use AI to draft goals, summarize progress, and prepare reviews.
A foundation that separates the building blocks from the method can absorb these developments without disruption. New ways of working become new arrangements of familiar pieces. A single-method app must be modified each time, and each modification adds to the code its maintainers must understand.
This matters especially for AI. Assistants that draft objectives, suggest measures, or summarize progress work best when they understand the structure underneath. On a shared foundation, the same AI capability can serve every method because it reasons about the same building blocks. On a single-method app, each new AI feature is designed around one method and has to be redesigned for the next.
What to Look For in Strategy Execution Software
If you are evaluating strategy software, test method flexibility directly. Ask to see the same organization running OKRs in one unit and a Balanced Scorecard in another, with one leadership view across both. Ask what happens to history when a team changes method. Ask whether a strategy map, a set of OKRs, and a Hoshin plan can connect to the same strategic themes.
Then ask the same questions of any app you have built yourself. The difference in the answers is usually the clearest measure of what the foundation was designed to do.
Profit.co runs OKRs, the Balanced Scorecard and Hoshin Kanri on one data model for exactly this reason, so a second method is a configuration rather than a migration. If you want the background on what each method is actually for before testing any platform against it, there is a separate guide to strategic planning frameworks.
Interchangeable strategy methods are one of those capabilities that seem unnecessary on the first day and essential by the third year. They depend on a decision made at the very beginning: whether to build a foundation for strategy execution in general, or an app for one method in particular. Vibe coding makes the second choice very fast. Only the first one lasts.
Foundations are one kind of hidden cost. The next article turns to a more familiar one, which turns out to be far less simple than it looks: the cost of the people.
Build on a Foundation, Not a Method
Frequently Asked Questions
You can add screens that look like Hoshin Kanri. What is hard to add is the shared foundation that lets methods share people, data, history and reporting. That foundation has to exist before the methods do, which is why retrofitting means a rewrite or a growing pile of special cases.
Six building blocks: an intended outcome, a way of measuring it, an owner, a time horizon, a relationship to other outcomes, and a stream of updates. The methods differ in how those blocks are arranged, named and presented, not in what they fundamentally hold.
Yes, and most large organizations already do. Product teams tend to prefer quarterly OKRs while finance and operations run on continuous KPIs and scorecards. The requirement is a shared foundation, so leadership gets one view instead of a spreadsheet assembled before every review.
On a shared foundation it survives, because the underlying records stay the same and only the arrangement changes. On a single-method app, history is shaped by the old method and has to be translated into the new one, usually imperfectly and with some of it lost.
Ask to see one organization running OKRs in one unit and a Balanced Scorecard in another, with a single leadership view across both. Ask what happens to history when a team changes method. Ask whether a strategy map, OKRs and a Hoshin plan can connect to the same strategic themes.
Assistants that draft objectives, suggest measures or summarize progress work best when they understand the structure underneath. On a shared foundation one AI capability serves every method because it reasons about the same building blocks. On a single-method app, each feature has to be redesigned per method.
