What it looks like when a team actually uses it

After people upload their receipts, they have to match each one to the right charge on their company card — by hand, one at a time. It's tedious, and it's the exact step where expense reports stall and people give up. Support tickets pile up. As card spending grows, the manual work grows with it.

Instead of writing a long specification and waiting weeks to see anything, the product manager works alongside an AI assistant and builds a working version that day — not a slide, not a mockup, something stakeholders can actually click and try. Because the company's standards are already in the room, what gets built looks and behaves like the real product, not a throwaway.

Stakeholders respond to real behavior, not a description of it — and the team learns the thing that matters most: a wrong match is worse than no match, because it can send money to the wrong place. So the goal isn't "match as much as possible." It's "only match when we're sure." Trust is the constraint. You learn that by watching people use the thing, not by guessing in a meeting.

The team runs the working version against real (anonymized) past data and finds the setting that's accurate enough to trust — matching the large majority of receipts while almost never getting one wrong. The judgment call — how sure is sure enough — gets written down, with the reasoning, so a year from now anyone can see why it was set where it was.

Engineering builds the real thing from the version that was already validated — not from a document that might be out of date. And the busywork around it — the tickets for the engineers, the checklist for QA, the documentation — is generated from the one place the work already lives. The product manager never re-types the same thing into five different systems. That re-typing is the tax this removes.

After launch, the team checks whether it actually helped, against the original problem. Here's the honest part: the previous feature this team shipped — a faster way to upload receipts in bulk — turned out not to move the needle at all, because uploading was never the real bottleneck. That uncomfortable result is exactly what pointed them at matching. Nothing was swept under the rug; the lesson became the next, better bet.

Stakeholders react to working software before engineering commits real time. The wrong-thing-built-then-discovered cycle gets cut off at the start.

One source feeds the backlog, the documentation, and the test plan automatically. No one spends their week translating the same intent into five different tools.

Every decision keeps its reasoning, in order, forever. When a choice is questioned three quarters later, the "why" is on the record — not in someone's memory.

The team checks whether each release moved the metric it was meant to, and lets honest results redirect the next decision. It learns instead of guessing.