Friday, 2pm, status meeting. Four slide decks, three truths, two spreadsheets in different states — and by the end nobody knows whether the release holds.
Nobody in that room did bad work. Every deck is honest and was right when it was made — on four different days, from four sources, each number passing through a person who summarised it on the way. Whoever sits at the end of that chain gets results with no provenance, and answers for them anyway.
And still everyone leaves that room slightly uneasy. Not because a number is wrong, but because nobody can say which of the four is currently true — and because everyone suspects next Friday will go the same way.
So this is not about running better status meetings. It is about the difference between a number somebody assembled and a number you can trace — a difference that sounds technical and decides which questions you still have to ask on a Friday.
Four tiles instead of four slides
The angajuu home screen is not a welcome page. It tries to reduce the week to four numbers you can click: “Releases at risk”, “Milestones due within 30 days”, “Unplanned demand” and “Refinement backlog”. Each tile carries a rating — Alert, Warning or No risk — and takes you to where the counted items live.
What sits behind the numbers is unglamorous, and that is the point. “Releases at risk” counts live releases whose committed points exceed the capacity on file, or whose effective deadline falls before their own target date. “Unplanned demand” counts product requirements with a demand score above zero and no release — the score itself appears on no screen; the tile only counts how many carry one. No forecast, no opinion. Four queries.
Two properties of this screen matter more than its numbers. The first is the rating. At 25 items, “Unplanned demand” flips from Warning to Alert, and the same 25 governs the refinement backlog. That number is chosen, not derived, and the source says so about itself. The colour is an invitation to look. Read as a verdict, it is a traffic light nobody calibrated.
The second is a row that sits permanently in “My lane” and that no sales conversation would invent: “Items assigned to you aren't tracked yet — this lane only shows products, releases and links you own.” There is no assignee field on a requirement in angajuu, nowhere in the model. The row is reserved before the six slots are handed out, so that a busy day can never push it off the screen.
That is not an apology, it is a boundary. Who is working on what sits on the board in Jira; which sentence applies, what state it is in and how far it is covered sits in angajuu. A tool that guessed here — the last person to comment, say — gets caught out the expensive way: first you stop believing that number, then the ones beside it.
One more detail belongs in the honest account: the “Milestones due within 30 days” tile counts correctly, but the click lands on the planning screen — there is no milestone screen at all. “Unplanned demand” leads to the “Demand” tab, which shows synergy clusters rather than the list it just counted. You get the signal, not the breakdown.
Numbers you can trace
Coverage in angajuu is not a stored figure: no column, no nightly job, no value somebody calculated once and then forgot. Every percentage comes into being the moment somebody asks for it, out of the confirmed links between customer requirements and product requirements — full counts 100, partial 50, peripheral 20, capped at 100. Proposed and rejected links count zero.
That has an uncomfortable consequence: the figure can be lower today than last week without anyone having broken anything — one new customer requirement is enough. A metric that can only go up is not measuring reality but the mood of whoever maintains it.
Living with that is leadership work. A number that is allowed to go down is the only kind of number anyone still believes the third time they see it.
A report somebody has to assemble is out of date on the day it is finished.
The difference from a slide is not accuracy, it is repeatability. A slide is an assertion about a Tuesday; a report is a query. Run it again tomorrow, and if the figure has moved there is a reason you can follow down to a single requirement. A number you cannot open is not a number — it is a rumour with a decimal point.
A question that stays asked
The third thing leadership can stop doing is rebuilding the same analysis every week. Lists in angajuu carry saved views: a set of filters that gets a name and stays as a tab above the list. Six kinds of list can do this — requirements, projects, products, customers, imports and releases. Four ship from the start, three on requirements and one on imports: “Unassessed”, “At-risk coverage”, “Unsized” and “Awaiting review”, in English in the German interface too, because they come from the database and never pass through the translations.
What matters more is what such a view actually is: not a saved answer but a standing question. “Unsized” asks every morning what has no estimate — and unsized work counts zero in every points total, which makes a release look emptier than it is. A standing question does not age. Its limit: the interface creates and activates views, but cannot rename, share, delete or duplicate them. Mistype the name and you live with it.
What is not on screen yet
In progress Underneath all of this sits a planning model that computes more than the interface shows: rolling points totals per release — while it is committed or in progress — and per project, written by a service that checks hourly and writes at most once a day; committed points against the capacity on file; a suggestion of which requirement fits which release if you pack by earliest deadline. All of it is in the database, none of it has a screen. angajuu says so itself: the “Timeline” tab and the whole “Deliver” screen carry the badge “Coming in 2026.09”. The Timeline is meant to lay every product's releases against each other so schedule conflicts show up before they happen; Deliver is meant to show Jira sync health, burn-downs per release, and the drift between what is planned here and what Jira is executing. Until then, what is above is all there is.
What leadership should stop asking for
The practical part is short and consists of leaving things out. Stop asking for weekly status decks: each costs somebody an evening, ages overnight, and produces numbers whose provenance only its author knows. Ask five things instead, all already answered:
- Which customer promises have not one confirmed link behind them? Gap Analysis, as PDF or Excel.
- Which releases have committed more than their capacity allows? The “Releases at risk” tile, one click.
- How much demand is sitting in no release? The “Unplanned demand” tile.
- What has been untouched in refinement for over two weeks? The “Attention” section.
- And who is working on what? No screen here answers that. That is in Jira.
Access is cheap but not free of consequence: the Viewer role reads the entire organisation and writes nothing — it is explicitly not narrowed to an area. Only the Member role is narrowed, and it sees only what it has an assignment for. So a leader who reads along sees everything; there is no in-between.
Back to Friday, 2pm. The status meeting stays, and it should. What goes is the Thursday evening before it — and what remains is a meeting where everyone looks at the same figure and argues about the decision instead of the number.
What changes about that meeting is undramatic: it no longer opens by reconciling four accounts of the same week, it opens with the first real question. Nobody misses the twenty minutes that went.
How these figures come into being on the day somebody produces them — requirement by requirement, link by link — is in A day as a Product Owner. And why the link between a customer ask and a product requirement is the real work, without which every figure here stays empty, is in From customer voice to product requirement.