Performalise connects a company's objectives to what its teams do every sprint with two ladders, not one: a value ladder that asks whether the work mattered, and a work ladder that asks whether it was built and how fast. They meet at the product vision and are stitched at the sprint goal. That split is the whole model.

The instinct is to draw a single line from a ticket up to the company vision. That line is the trap. It makes a closed ticket look like progress toward the vision, and it lets a team ship fast for a quarter while nothing the customers care about moves. Keeping value and work apart, and joining them at a few clean points, is what lets Performalise show both truths side by side.

The two ladders

Value ladder

Did it matter? Evidence rolls up.
  1. Organisational Visionthe company apex
  2. Strategic Initiativea cross-product bet
  3. Product Visionthe shared hinge with the work ladder
  4. Business Objectivewith its key results
  5. Outcomelive confidence, validated from real usage

Work ladder

Did we build it, how fast? Flow rolls up.
  1. Product Visionthe same hinge
  2. Product Goalwhat the teams intend to build
  3. Epicevery strategic epic points to a key result
  4. Story and task
  5. Outputseen at the review
The sprint goal (or the window goal, for Kanban and ScrumBan teams) is where a team commits. It references both ladders and rolls up into neither. The daily plan hangs off it. This is the translation boundary: an objective becomes a sprint goal the team commits to; it is never pushed down into tickets.
Performalise goal tree, demo data: organisational vision, business objectives, product visions, product goals and sprint goals, each card with owner, teams, progress and status.
What the ladder looks like in the product (demo data). Each card carries an owner, the teams on it, progress and a status that comes from what the team said and did, never from a typed update. The right-hand branch shows one late sprint goal rolling up to an off-track product goal and an at-risk objective.

The three stitches

The ladders touch at exactly three points. They meet at the product vision, which both share. Every strategic epic points to a key result, so no strategic work is orphaned; run-the-business epics are exempt, because forcing key results onto maintenance work only breeds fake key results, and the ratio of run to strategic work is itself something the coach reads. And each sprint the sprint goal references a key result or a product goal, or both.

Two rollups, meeting in the middle

Does it scale from a ticket all the way up? Yes, but as two rollups, not one column adding up.

Flow rolls up the work ladder. Throughput, the delivery forecast and the sprint-over-sprint delta answer whether it was built and how fast. That is the predictability story.

Value rolls up the value ladder. A shipped output produces an outcome, which moves a key result, and the value signal reads that from real usage: Google Analytics 4, Microsoft Clarity, Amplitude, retention, sentiment. That is the did-it-matter story.

They meet at the product vision and stitch at the epic. A team can ship fast (flow green) while value stays flat (value amber), and the model shows both side by side instead of hiding one behind the other.

Six decisions, in plain language

  1. True progress is the team's judgement, wearing its evidence. The team authors whether an outcome happened; the signals set a confidence band around it. Between commits, a light weekly check-in keeps every key result honest: pre-filled from real usage where we can measure it, ten seconds of team judgement where we cannot, and silence itself greys the band. A “green” that disagrees with usage data is logged, never erased, and the coach surfaces the gap. Never a naked self-report, never a machine overruling the team.
  2. A bet carries how sure we are. Every link from a goal to work has a stance: assured, aspirational, or learning hypothesis. An honestly invalidated hypothesis counts as progress, not failure. When the world shifts mid-quarter, a bet can be renegotiated: closed early with its history intact and re-framed, rather than quietly rewritten or unjustly graded. This is what stops the tool rewarding output for its own sake, or punishing honesty.
  3. Validated value comes from the user, not the roadmap. A key result is validated only when real usage backs it, and validated never means proven without an experiment. Platform teams whose customer is another team get their own value read, so nobody is unmeasured.
  4. Parents constrain, teams author. Direction flows down; targets are written locally and co-authored: the owner proposes, the teams approve. No executive reaches down to set a team's number. The same rule holds at every altitude.
  5. One window model, three modes. A sprint is optional metadata on a window. Scrum commits a batch at planning; Kanban commits per item at the pull point under WIP limits; ScrumBan pulls on a trigger. The goal binding is identical.
  6. Getting faster and delivering value stay in separate lanes. Every objective is tagged value or improvement, so improvement coaching never muddles with delivery coaching. The improvement lane runs on the same machinery and lands in the retrospective.

Three altitudes

Portfolio: strategic initiatives, cross-product measures, and the alignment view: which initiatives are staffed, and where value sits against where effort sits. Product: one product served by several teams, one shared objective, targets that roll up, every measure's beneficiary named; the altitude customers feel first. Delivery: Scrum, Kanban or ScrumBan; the sprint goal as the translation boundary, and the flow and value rollups everything above is built on.

For the curious: the internal names. Inside the product and its documentation the value ladder is Portfolio Vision, Strategic Initiative, Product Vision, Objective (in an OKR set), Key Result and Outcome; the work ladder is Product Vision, Product Intent, Epic, Story, Task and Output; the sprint commitment is the Goal Commitment. The customer-facing names on this page and in the app map onto them one to one.

Why this matters for the coach

Because drift has an address. When a sprint goal slips, the model knows which product goal and which objective it sits under, so the coach can say to the team on Wednesday “this goal is at risk and here is the objective it feeds” instead of a manager discovering it in a status report the following month. And because value and work are kept apart, the coach never mistakes a fast team for an effective one, or the other way round.

Frequently asked questions

Does Performalise push OKRs down into tickets?

No. An objective is translated into a sprint goal the team commits to, and the sprint goal references the key result or product goal it serves. Tickets stay tickets. That translation boundary is the model's central design decision.

Can a ticket be linked directly to the company vision?

No. A ticket sits on the work ladder under a story and an epic; a strategic epic points to a key result on the value ladder. The two ladders only meet at the product vision and at the sprint goal, so a closed ticket never counts as progress toward the vision on its own.

What makes a key result “validated”?

Real usage: adoption, retention, sentiment, read from product analytics such as Google Analytics 4, Microsoft Clarity and Amplitude. Validated never means proven without an experiment, and Performalise says so.

Does the model work for Kanban teams?

Yes. A sprint is optional metadata on a window. Kanban teams commit per item at the pull point under WIP limits; the goal binding is the same as for Scrum.

Part of How Performalise works, the public record of how the product is built to behave. Last reviewed 27 August 2026. Corrections: josef@performalise.com.