Performalise runs on one loop: idea, goal, ticket, code, deploy, usage, and back to the next idea. Every capability reads from it or writes to it. Two facts about the loop decide everything else: the tracker is its least reliable point, and value is validated at the far end, from what users do.

Most delivery tooling draws a line. Idea at one end, deploy at the other, DORA, DX and SPACE metrics along the way. A line tells you how fast work moved. It cannot tell you whether the work mattered, because the evidence for that arrives after the line ends, from people using the thing. Performalise draws the line as a loop: usage comes back to the next idea, and the goal ladder reads both directions.

The Performalise loop: idea, goal, ticket, code, deploy, usage, and back to the next idea. The ticket is the least reliable point; usage is where value is validated. Validated by real usage, not the roadmap. Ideathe next one starts hereGoaltwo ladders,one commitmentTicketJira · Azure DevOps · Linear · Asanaupdated by hand, after the factCodecommits, PRs, review flowDeploywhat actuallyshipped, and whenUsageadoption, retention,sentiment
The six points. Dashed: the human-updated tracker. Solid teal: what is observed without anyone typing. The heavy arc is usage feeding the next idea.

The six points, and what is read at each

  1. Idea. Where the next thing enters. Product Discovery runs it through five stages (value, OKR fit, stakeholders, feasibility) before it is allowed into a sprint. The idea inherits whatever the loop learned last time round.
  2. Goal. The idea becomes an objective on the value ladder and a product goal on the work ladder; the sprint goal is where the team commits. Read: which key result or product goal each commitment references. Nothing is pushed down into tickets.
  3. Ticket. Jira, Azure DevOps, Linear or Asana. Read: tickets, sprints or cycles, goals and status changes, through a read-only, revocable token. Not read: attachments, comments on untracked items. This is the one point where a person records what happened after it happened.
  4. Code. GitHub. Read: commits, pull requests and review flow, never the source. This is where "in progress" gets checked against whether anything moved.
  5. Deploy. Vercel, Supabase and GitHub release events. Read: what actually shipped, and when. Nothing else.
  6. Usage. Google Analytics 4, Microsoft Clarity, Amplitude, Pendo. Read: adoption, retention and session behaviour at team and product level, never individual identity. This is where a key result becomes validated, and validated never means proven without an experiment.

Why the tracker is the least reliable point

Not wrong. Late, and partial. A ticket status is typed by someone, after the fact, with whatever they remember and whatever the board's workflow allows. On the homepage example, PERF-214 was called blocked in the standup while the board still said in progress. Neither the person nor the tool did anything wrong. The status just arrived later than the truth, and said less. Performalise reads the tracker as one witness of six and weighs it against the standup, the commits and the deploys. The gap between them is the said-versus-did signal. The tracker stays the system of record; it stops being the only witness.

Closing the loop: usage feeds the next idea

A shipped output produces an outcome; the outcome moves, or fails to move, a key result; the key result's confidence updates from real usage. That reading travels two ways. Up the value ladder, so a manager sees on Wednesday that a goal is at risk and which objective it feeds. And forward, into the next discovery item, which arrives carrying evidence instead of enthusiasm. That forward path is the antidote to the feature factory: a team can ship every sprint and still watch the value line stay flat, and the loop shows both.

What the loop is not

  1. Not a pipeline. A pipeline ends at deploy. The loop comes back.
  2. Not engineering metrics. DORA, DX and SPACE describe the code and deploy points well, and stop there. Performalise reads them and keeps going to usage.
  3. Not a status report. Nobody types a second status for Performalise. The loop is read, not filled in.

Where you see it in the product

Product Discovery sits at the idea point. The goal ladder and the sprint commitment sit at goal. Predictability reads ticket, code and deploy together to forecast in ranges. Value Intelligence and Company Analytics read usage back into the ladder. Hans and Lotte coach at every point, and escalate only drift from goal and blockers the team cannot clear itself.

Frequently asked questions

Does Performalise need product analytics to work?

No. Without Google Analytics 4, Microsoft Clarity, Amplitude or Pendo connected, the loop still runs from goal to deploy and the coaching, drift and forecasting all work. What changes is the far end: value stays unvalidated, and the goal ladder says so rather than colouring a key result green on a self-report.

Do we have to keep our tracker perfectly up to date?

Keep it as you do today. Performalise reads the tracker as one point of six and weighs it against the standup, the commits and the deploys. The gap between the typed status and the observed one is itself a signal: it is where said versus did comes from.

What if we do not deploy continuously?

The loop does not need continuous deployment. Deploy is read from release events whenever they happen, weekly or per sprint. Fewer deploy points mean the usage signal arrives in larger steps, and the forecast range says so.

Is the loop per team or per product?

Both. Each team's loop feeds its own sprint goals and forecast. At product level the usage point is shared, because several teams' outputs land in one product, which is where the value ladder reads validated value.

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