In this guide
- Everyone is telling the truth
- Why a standard review can’t see it
- Four positions for every objective
- Diagnose before you react: LAGS
- The response for each cause
- A worked example: the service network
- Make outcome lag impossible to miss
- What outcome-lag detection needs from the software
- How Profit.co shows outcome lag
- Questions this article answers
Key Takeaways
- →Outcome lag is the pattern where everyone is telling the truth: the work is done, the result hasn’t moved, and no single row is wrong.
- →A standard review can’t see it, because it lives in the correlation between a priority and a KPI, and the dot has no owner who reports on it.
- →Diagnose with LAGS in order: Lag window, Adoption, Gearing, Swamping. Each has a different response and a different decision-maker.
- →Adoption is the most common cause by far. The work finished; the behavior it was meant to create never arrived.
- →Swamping is the explanation everyone reaches for first and the one that is right least often. Be strict with it.
- →Four structural fixes make it impossible to miss. None needs software to start; all are far easier to sustain with it.
The most expensive pattern in a hoshin review is the one where every owner is telling the truth. Here’s how to diagnose it, cause by cause, while there’s still time to act.
Everyone is telling the truth
It’s the September review. Nine of twelve annual priorities are green. Three of the five KPIs on the X-matrix are behind plan, one of them badly. The meeting walks through the priorities first, and each owner gives an accurate account: the service centers are open, the pricing tool has launched, the supplier program has signed its partners. Then the KPI owners report, also accurately: services share of sales is flat, price realization is short, scope 3 emissions haven’t moved.
The meeting ends with a request to accelerate. Nobody says the obvious thing, because nobody in the room is looking at the obvious thing: the work that was chosen to move those KPIs is largely done, and the KPIs haven’t moved.
That pattern is outcome lag. It’s more common than missed deadlines and more costly, because a late priority is visible to everyone and a finished priority that changed nothing is visible to no one.
Why a standard review can’t see it
Hoshin reviews are organized by row. Each priority reports its progress; each KPI reports its value. Outcome lag doesn’t live in any row. It lives in the correlation between a priority and a KPI, the dot on the X-matrix, and the dot has no owner who reports on it.
A second problem makes it worse. Priority progress is usually measured as completion: milestones hit, centers opened, tools launched. Completion can reach 100% while the change the priority was meant to cause stays at zero. The status is honest. It’s just measuring the wrong thing.
Outcome lag is when the work chosen to move a result is on plan, and the result is not. It’s the clearest sign that a bet on the X-matrix is losing.
Four positions for every objective
Put initiative progress on one axis and KPI progress on the other and every objective lands in one of four places. Each position calls for a different conversation.
The quadrants used in Profit.co’s four-quadrant chart.
| Position | What it means | The question to ask |
|---|---|---|
| On the right track | Work and results are both moving | Is the pace enough to hit the target? |
| Early stage | Neither has moved much yet | Is this the plan, or is the work late? |
| Unexpected wins | Results are ahead of the work | What else moved this KPI, and is our dot overstated? |
| Outcome lag | Work is ahead of results | Which of the four causes below is it? |
Unexpected wins deserve a moment, because teams tend to celebrate them and move on. A KPI that moves without the priority that claimed it means either something else is driving it, or the correlation is weaker than the matrix says. Both are worth knowing before next year’s plan gives the same priority the same credit.
Diagnose before you react: LAGS
The instinct in an outcome-lag review is to push harder or cut the priority. Both are premature. Outcome lag has four distinct causes, and the response to each is different. Check them in this order, which runs from the cheapest and most likely to the most expensive.
L — Lag window: has enough time passed?
Some effects take time. Contract attach rates rise as renewals come up; emissions fall as new suppliers ramp. If the correlation was planned with a lag window and the window is still open, this isn’t outcome lag yet. It’s early. Leave it alone and confirm the date the window closes.
If nobody set a window, set one now and say plainly that it’s being set after the fact. That honesty matters: a window invented in September to explain a flat KPI will be extended again in December.
A — Adoption: is progress measuring activity or change?
This is the most common cause. The priority reports what was done, not what changed as a result. The pricing tool launched on time (100%) but a fifth of quotes are priced with it. The centers are open but technicians are still dispatched from head office. The work is finished; the behavior it was meant to create hasn’t arrived.
The response is to change how the priority is measured. Replace milestone key results with adoption key results, such as the share of quotes priced through the tool, and let the status fall honestly to amber. The priority isn’t failing. It was never as far along as its status suggested.
G — Gearing: does the mechanism hold?
If the window has passed and adoption is real, look at the leading signal that was supposed to connect the work to the result. Service centers are open and busy, yet attach rates in their territories are no higher than elsewhere. The work is engaging; it just isn’t turning the wheel the matrix said it would.
This is a losing bet in the plain sense. The correlation was wrong. The response is a countermeasure if there’s a credible one, or retiring the priority and moving its people and budget to a bet that is working. Either decision belongs in catchball between the priority owner and the KPI owner, not in a status meeting.
S — Swamping: is something larger masking the effect?
Sometimes the mechanism works and the KPI still doesn’t move, because an external force is pushing the other way. A demand slump in one region, a currency swing, a competitor’s price cut. The priority may be holding the KPI flat when it would otherwise have fallen.
Test this with a comparison: territories with the priority against those without, or the KPI’s other drivers against their own trend. If the priority is outperforming its comparison, keep the bet and revisit the KPI target through catchball, recording why. Be strict here. Swamping is the explanation everyone reaches for first and the one that is right least often.
The response for each cause
| Cause | Response | Who decides |
|---|---|---|
| Lag window | Hold. Confirm the window’s closing date and review again then. | KPI owner |
| Adoption | Re-measure the priority by adoption. Reset its status honestly. | Priority owner |
| Gearing | Apply a countermeasure or retire the priority and reallocate. | Both owners, through catchball, escalated if resources move |
| Swamping | Keep the bet. Revisit the KPI target and record the external cause. | Both owners, approved one level up |
Retiring a priority mid-year is the hardest of these, because the people who delivered it did nothing wrong. It helps if the kill signal was agreed at planning, before anyone had work at stake. The decision then reads as the plan working as designed, not as a judgment on the team. The case for setting those signals up front is in The X-Matrix Is a Set of Hypotheses. Treat It Like One.
A worked example: the service network
Here is LAGS applied end to end to the case from the opening. The priority is to open six regional service centers; it is graded primary against services share of sales. By September the priority reports 88% and the KPI has barely moved.
| Check | Evidence gathered | Finding |
|---|---|---|
| L, lag window | The correlation record set a window of two quarters after each center opens. Four centers opened in March and April, so their windows closed in September and October. | Window closing now. Not early. |
| A, adoption | All six centers are staffed and taking work. But 70% of service calls in their territories are still dispatched from head office, because the routing rules weren’t changed. | Adoption gap. The centers exist; customers aren’t being served from them yet. |
| G, gearing | In the territories where routing was changed, contract attach rate on new equipment rose from 22% to 31%. | Mechanism holds where adopted. |
| S, swamping | Equipment sales in two territories fell after a competitor’s price cut, reducing the base for attach. | Minor; doesn’t explain the main gap. |
Illustrative diagnosis.
The diagnosis is adoption, and it points to a cheap fix: change the routing rules, and measure the priority by the share of calls served locally rather than by centers opened. The status falls honestly from 88% to around 35%, the routing change becomes a countermeasure with an owner and date, and the bet is kept, because the gearing evidence says it works where it has actually been tried.
Without the diagnosis, the September review had two likely outcomes, both wrong: push the service team to “accelerate” work that was already finished, or conclude the service-center strategy had failed and retire it. The evidence supports neither.
Most outcome lag isn’t a failed strategy. It’s a finished project that nobody connected to the way work actually flows.
Make outcome lag impossible to miss
Asking managers to be more candid about finished priorities that changed nothing rarely works. Each owner is already being candid about their own row. The better fix is structural: change the conditions so the pattern can’t hide.
- Lead with the quadrant. The monthly review opens with the objectives in outcome lag, not with a walk through every row.
- Require an adoption measure. No priority is approved at planning without at least one key result that measures change, not completion.
- Store the window on the dot. Every primary correlation carries its lag window, so “too early to tell” has a date.
- Agree the kill signal in advance. Set at planning, recorded with the correlation, checked each month.
None of these needs software to start. All of them are much easier to sustain when priority progress and KPI progress sit in the same place, so the comparison happens automatically rather than when someone has time to build it.
What outcome-lag detection needs from the software
That last sentence is the whole buying argument for this article, and it is worth making concrete. Outcome lag is a comparison between two numbers that almost always live in different places: initiative progress, owned by a delivery team, and KPI progress, owned by a function. Four things decide whether the comparison happens by itself or waits for someone with a spare afternoon.
| What detection needs | Why it matters | How to test it in a demo |
|---|---|---|
| Both progress values on one model | If initiative progress and KPI progress live in two systems, the comparison is a monthly report, not a view | Ask to see one objective with both plotted against each other |
| An exception queue | A quadrant chart nobody opens detects nothing. The cases have to arrive as named items | Ask what the review is handed, not what it can navigate to |
| Lag windows stored on correlations | Without a date, “too early” is an opinion that renews itself every month | Ask what happens on the day a lag window closes |
| Adoption measures as first-class | The most common cause is invisible if priorities can only be measured by completion | Ask how a priority is measured by something other than percent complete |
Row two is the one most demos skip and most rollouts need.
Row one is where the specialist-versus-platform question actually bites. If hoshin priorities sit in one tool and the KPIs they serve are reported from a scorecard or an OKR software subscription elsewhere, the four quadrants can only be drawn by hand, monthly, by someone senior enough to judge the numbers. That is exactly the work a tool was bought to remove, and it is the arithmetic purpose-built hoshin kanri tools vs strategy execution platforms runs through in full.
Row two deserves a sentence of its own because it is where good products and demo-friendly products diverge. Showing a quadrant chart is easy. Putting the three objectives that entered outcome lag this month in front of a chair who did not go looking for them is a different feature, and it is the one that decides whether the pattern gets caught in month four or month nine.
How Profit.co shows outcome lag
Profit.co’s exception queue flags each correlation whose hypothesis didn’t hold, and initiative escalation flags delivery problems, so outcome lag reaches the review as a named item rather than something someone has to spot. The four-quadrant chart on each objective plots KPI progress against initiative progress, using the same quadrants as above.
From any flagged item, or from a red or amber bowler chart cell, the owner opens a countermeasure A3 anchored to the gap. It moves through Plan, Do, Check and Act; its check stays “not yet judged” until the expected lag has passed; and a missed check opens a new revision on the same gap instead of overwriting the old one. The LAGS diagnosis happens inside it: the lag window comes from the correlation, adoption and gearing from the leading measures, and swamping from a comparison group.
An Act decision on a correlation, to keep, downgrade or upgrade it, is written to that correlation’s strength history and linked to the A3. A decision that would change a committed target opens a catchball session; the original commitment stays as the baseline. The full walkthrough is on the hoshin kanri software overview, and the A3 itself in Writing a hoshin A3.
Because Hoshin Kanri, OKRs and Goals and Balanced Scorecard share the Essentials plan and one data model, the KPI half of every comparison is already there: a team key result checked in by its owner updates the hoshin objective it feeds, so the quadrant redraws itself. Where the board measure comes from balanced scorecard software on a separate subscription, that half arrives a month late and the hoshin kanri x matrix shows last cycle’s position. The 30-day free trial is long enough to plot one real objective and find out which quadrant it is actually in.
Free Product Demo
See where your matrix has outcome lag today
A 30-minute walkthrough, tailored to your team.
Book a free demo
What happens in the call
How your teams set goals, track progress and review results.
Strategy, performance, projects and engagement on one platform, with AI.
A practical path to align teams, execute faster and drive results.
Questions this article answers
A pattern where the work chosen to move a result is on plan and the result is not. On a hoshin X-matrix it shows up as green priorities correlated to flat or red KPIs.
Four things: the effect hasn’t had time to appear, the priority is measured by completion rather than the change it should cause, the assumed mechanism doesn’t hold, or an external force is masking the effect.
Adoption. The priority’s work is finished, such as a tool launched or centers opened, but the behavior it was meant to change hasn’t followed. The fix is to measure the priority by adoption and reset its status honestly.
Open the monthly review with objectives in the outcome-lag quadrant, require an adoption measure on every priority, store lag windows on primary correlations, and agree kill signals at planning.
Hold initiative progress and KPI progress on one data model, hand the review an exception queue rather than a chart to navigate, store lag windows on correlations, and treat adoption measures as first-class.
Only by hand. If priorities sit in one system and their KPIs in another, the comparison becomes a monthly report someone has to build, which is the work the tool was bought to remove.
