From the first sentence to the delivered capability.

THE MODEL

Two kinds of requirement, and the link between them.

What a customer says and what your product can do are two different things. Most tools know only one of them, and lose the other along the way.

angajuu keeps the two apart and joins them on purpose. That is why you can still ask later where a sentence came from — and whether anything ever came of it.

In detail

• angajuu knows two kinds of requirement: the customer requirement and the product requirement. Both are shapes of one underlying thing — one table, two forms.
• A customer requirement always belongs to a project, a product requirement always to a product. Without that home, neither exists.
• The two are joined by an explicit link that a person confirms or rejects. The link records who confirmed it — and whether a human or the AI proposed it.
• A link also says how much it covers: fully (100), partly (50) or peripherally (20), capped at 100 per requirement.
• Only confirmed links count towards coverage. Anything proposed or rejected counts towards no coverage figure.
• For every customer requirement angajuu reports how many links it has, how many of them are confirmed, proposed and rejected, and the coverage that follows.

INTAKE

Your material comes in the way it is.

A spreadsheet, a ticket, a page, a document, a repository. You sort nothing beforehand and re-type nothing. What you have comes in the way it sits with you.

And you see what is arriving before it arrives. An import that surprises you is an import you have to take back — so this one does not surprise you.

In detail

• Requirements come in from Excel and CSV spreadsheets, from PDF and JSON, from Jira, from Confluence, and from a scan of your git repository.
• angajuu pre-fills the column mapping by matching your headers against English and German field names. Nothing is machine-translated on the way: a header only ever resolves to a field of the language it matched.
• Columns you do not map are not thrown away — they stay on the requirement, filed under the header they arrived with.
• The Excel and CSV import that runs off a column mapping involves no AI at all. And it stays that way: a test breaks the build the moment anyone wires an AI dependency into that path.
• On the column-mapping path, before anything is written, angajuu shows you the dry run: how many rows would be created, updated and skipped, which fields would change on each row, and every warning that came with them.
• Import the same sheet again and angajuu updates the rows it already knows instead of duplicating them, matched on an identifier you nominate as a column. It looks for that identifier across your whole organisation, not only in the target project. Nothing is deleted in the process.
• Whatever the AI reads out of your material lands in a review list first, as a pending item. You confirm, discard, merge or link each one — and only confirming creates a requirement.

REFINE

The raw sentence becomes a brief.

What came in is nobody's brief yet. In Refine you take on one sentence after another until it holds — and you are not alone while you do it.

Nothing moves on just because it is old. It moves on because somebody looked at it and decided.

In detail

• Every customer requirement sitting in Draft or In Review collects in one single queue. The count beside it in the sidebar counts exactly those two states, and it is fetched again as soon as a screen has changed the queue.
• The refinement screen puts five tabs side by side: the requirement itself, its coverage, conflicts someone has declared, the source and the activity. Coverage, conflicts and activity carry their count beside the tab name before you open them.
• A requirement that came out of an import keeps a chip naming where it came from, and that chip leads back into the import session. If it came in over the column mapping, what stands in it is what the import wrote: file, sheet and row number.
• You confirm each sentence, decline it with a written reason, or skip it. angajuu will not take an empty reason; skipping writes nothing and only moves your session on by one. Confirming takes the sentence from Draft to In Review.
• A sentence only leaves Draft for In Review once it has a title, a description of at least 50 characters, a named source and — if it is a customer requirement — a project. That check runs on exactly that one transition.
• What juujuu would change about a sentence, it does not write itself. Its proposals cover title and description, one per language, and are set word against word — a field is written only once you tick it.
• juujuu's hints appear once your organisation has stored a Claude key. Without one, the panel stays empty.

PLAN

What first, and what for.

Requirements with no order are a list, not a plan. Here they get a place: a product, a release, a date.

And you see what has been asked for most often — not as an opinion, but computed from what your customers told you.

In detail

• A release is a dated commitment to exactly one product: a target date, optionally a declared capacity in points, and a path that only runs forwards — draft, committed, in progress, released. None of those steps goes back; cancelling stays open as long as nothing has been released.
• A milestone is a date inside a customer project, and one release can serve milestones in several projects at once — exactly the duplication you would otherwise keep by hand. Whether a milestone is planned, at risk, missed or met is computed on every read and stored nowhere.
• Sizing is one single field per product requirement: XS to XL, which is 1, 2, 3, 5 and 8 points. Anything unsized counts zero points — and how many of those there are stands on the planning board beside the points, so that a column never looks light merely because nobody sized it.
• How loudly a product requirement is being asked for is computed: per confirmed link, the asking customer requirement's priority — critical 8, high 5, medium 3, low 1 — times the share not yet covered. The sum is then weighted by a breadth factor: three projects needing the same thing weigh more than one project shouting. What is counted is projects, never customers.
• Every one of those numbers opens up: angajuu shows the score, its base and its breadth, and below that every single ask with its priority, its coverage and its contribution. Asks from projects you may not read stand in it as one shared row — counted, but not broken out.
• Where the unplanned work would go, angajuu proposes at the press of a button: earliest deadline first, demand breaking ties, and only into releases that fall early enough and still have capacity. That is computed, not guessed — no language model orders anything here; juujuu may at most add a sentence about why something could not be placed anywhere. None of it is written: you decide whether the proposal becomes real.
• When two customer requirements from different projects ask for the same thing, angajuu finds them — from 75 % semantic similarity, and only across project boundaries, because a duplicate inside one project is not a synergy. Out of such a group you make one product requirement; you give it a title and a product, and the links to the members are created as a proposal, not as a fact.

DELIVER

The sentence becomes a ticket, and you keep hold of the thread.

The building happens where your team already works. angajuu sends the requirement over and does not lose sight of it in the process.

What happens over there comes back into your view — so that “is that in yet?” is a question with an answer.

In detail

• You send a requirement to Jira as an issue: a product requirement becomes an Epic there, a customer requirement a Story, the priority is translated onto Jira's ladder, and the new issue's key then sits on the requirement. You can trigger it on the requirement itself — and for several product requirements at once from the list.
• Commit a release and angajuu creates or updates the matching version in Jira and stamps it onto every issue already sent over from that release's scope. That holds for your own products with a Jira project key on them; if a single issue fails, it is recorded and the rest carries on.
• The status sync with Jira only reads: it fetches the issues and asks whether Jira has shipped the release's version, and it writes nothing back. That is true of this sync — not of angajuu as a whole: when a requirement is handed over and when a release is committed, angajuu does write to Jira.
• Which Jira status means “done” for you hangs on the product and is stored there in the wording of your board, once you have entered it; what comes preset are the English default terms. A status nobody has mapped is treated as in progress and recorded at most once per run in the sync log, instead of being silently interpreted.
• The implementation status a person has set to “verified” is not changed by any sync again: it never downgrades it and never sets “verified” itself either. What comes back from Jira is only planned, in progress and implemented.
• By itself, angajuu moves a customer requirement to “delivered” only once it has at least one confirmed link, is fully covered, and every one of those links is implemented or verified. That is the automatic path. By hand, somebody can still take it from “in progress” to “delivered”, and an import can write the status outright.
• Four things from this section have no screen of their own today: triggering the sync, the report on the divergence between the plan and Jira, the per-product status mapping and the burn-downs. They run in the background or over the API — you cannot look at them in angajuu.

REPORT

What is covered, and what is open.

In the end one question counts: has anything come of what we promised? angajuu answers it without anybody having to keep a spreadsheet up to date first.

And where there is nothing, that is written down too. A gap you can see is a gap you can talk about.

In detail

• The Report screen carries a coverage matrix: one row per customer requirement, one column per product, a percentage in every cell. The row total counts every confirmed link on that requirement regardless of product; the column total is the mean of that column's cells. A cell with no link is not left blank — it shows 0 % and is marked as a gap.
• Requirements can be nested inside one another. A group's coverage is then the mean of its direct children; links hanging on the group itself deliberately do not count towards it. The report's coverage tree shows customer requirements nested exactly that way — a state per row, covered, partial, proposed or open, and beside it a fraction: confirmed links over confirmed plus proposed. Rejected ones appear in neither figure.
• The gap report lists every customer requirement that has not one confirmed link, and counts them by priority — critical, high, medium, low. You can narrow it to one project and one priority; once it has been generated, the buttons for a PDF and an Excel export sit beside it.
• You read coverage off the screen, not out of a file. Despite its name the coverage report carries not one percentage — it lists title, kind, priority and status — the gap report carries none either, and the coverage matrix, which is where the percentages are, has no export control at all.
• Home is a cockpit: four tiles, each with a count and an urgency — releases at risk, milestones due in the next 30 days, unplanned demand, and the refinement queue. Clicking a tile takes you to the list behind it. Below them sit the rows that need attention, and per product a bar of covered, partial and gap.
• For each project angajuu writes a product requirements document: introduction, scope and goals as prose, the requirements sorted into groups, plus acceptance-test checklists in both languages. Each new edition takes the next number for that project, and you can export it as PDF or as Markdown. It needs a stored Claude key — without one, generation stops with an error and nothing is saved.
• Under each customer requirement the document names the product requirements whose link to it is confirmed — by title, not as a percentage.

ALWAYS ON

What holds at every station.

• The library Beside the journey sits the library: products, projects, customers and requirements, each its own list in the sidebar. Sidebar, command palette and keyboard chords all read one registry — the chords themselves reach the stations of the journey, not the library.
• The command palette Ctrl-K, or Cmd-K on a Mac, opens a palette over everything — it searches your data, runs the actions of the screen you are standing on, jumps to the destinations from the navigation and shows where you were last. The one shortcut that still fires from inside a text field.
• What you may see Lists show you what you may see instead of refusing the whole page: a row that is not yours is simply absent. You are turned away only when you call up a single thing directly. That holds for the analyses too — read exactly one project and you see no synergy at all, because a synergy takes two.
• Roles and assignments Four organisation roles, plus assignments per product and per project. The assignments are what narrow a member: a member reads the products they own, the projects they manage, and the products those projects use. Administration, product management and read-only accounts read the whole organisation anyway — reading the whole organisation is not itself a write permission.
• Separate organisations One organisation's data does not lie open beside the next one's: a global query filter sits on the tenant-bound tables, and every request that belongs to an organisation is checked against it on top of that. Both together, not one instead of the other.
• Your own credentials You bring the credentials for Jira and Confluence, for GitHub and for Claude yourself — encrypted with AES-256-GCM, every record with its own salt and its own nonce, either for the whole organisation or for you alone. angajuu also records when a connection was last verified.
• Where your text goes For the Claude features, your requirement text leaves the deployment and goes to Anthropic's interface. The similarity search underneath — import duplicates, refinement suggestions, synergies — does not: it runs on an embedding service the shipped deployment operates itself. That is about where your text goes, not about where angajuu runs: the EU note in the footer belongs to this website, not to the application.
• Without a Claude key With no key stored the AI features do not collapse — but each one gives way differently. The refinement hints vanish without a word, the schedule suggestion keeps its conflicts and drops only the reasoning beside them, and the product requirements document fails with an error message. There is no single rule for it.
• Two languages The interface comes in German and in English, and you choose which one you work in. Make no choice and the browser's language decides, defaulting to English.
• Saved views Each of the six lists — requirements, projects, products, customers, imports, releases — remembers the views you save yourself: for you alone or for the whole organisation. Requirements and imports also come with a few seeded ones nobody can edit or delete. Changing many rows at once happens on the requirements list: status, size, release and the handover to Jira for product requirements, priority and needed-by date for customer requirements.