I spent the last year building a fintech SaaS platform that unified legal and financial investment workflows across systems most companies keep deliberately separate. The user journey map for that product was easy. Draw the screens, draw the clicks, done. The map that mattered was invisible: who has to say yes before any of it ships, and in what order.
Call it the approval graph. Most product teams don't draw it because it's not glamorous and it doesn't fit in a Figma file. So it lives in people's heads, differently, in each head. That's the actual root cause of most "why is this taking so long" conversations, not the code.
The Four Signatures
On an enterprise fintech product, the same four counterparties showed up on almost every feature, just in different proportions:
- Legal, who cares whether the thing is defensible if a client or regulator ever asks "show me."
- Compliance, who cares whether the process, not just the outcome, can be audited.
- Delivery, who cares whether it's buildable in the sprint you said it was buildable in.
- Operations, who cares whether the humans running this thing day to day can actually run it.
A feature is not scoped until you can name, specifically, what each of legal, compliance, delivery, and operations needs to see before they'll stand behind it. Skip a signature and you haven't saved time. You've just moved the negotiation to after the feature ships, where it costs ten times as much.
Why silence gets mistaken for agreement
This failure mode came up more than once, on more than one team. A PRD goes out. Legal doesn't comment. Compliance doesn't comment. Everyone reads that as approval. It usually isn't. It's "I didn't have a strong enough opinion to interrupt my week for this," which is a completely different thing from "yes."
The gap only shows up later, at UAT, when someone finally looks closely enough to have an opinion. Now it's not a comment on a doc. It's a blocked rollout.
Silence is not a signature. If you can't point to the sentence someone agreed to, you don't have agreement. You have an assumption wearing a suit.
What closes the gap
Three habits made the difference for me, none of them clever:
1. Name the four before you write the first line
Before drafting a BRD, I write down which of the four have a real stake in this specific feature and what "approved" looks like for each. Sometimes it's three. Sometimes it's all four. Naming them first stops me from writing a document optimized for the reader I already know, at the expense of the one I forgot.
2. Get a real answer, not a non-answer
"Any objections?" invites silence. "Given this design, would you sign off on it as-is?" invites a real answer. The second question is more annoying to ask and a lot cheaper to have asked.
3. Let the ceremony do the enforcing
Running sprint planning, reviews, and retros across multiple teams (Nexus, in our case, not single-team Scrum) only works if the ceremony is where disagreement is expected to surface, not where it's expected to be smoothed over. I started treating a quiet review as a yellow flag, not a green one.
None of this is why rework dropped by 30 percent on its own. It's what made the other changes stick: once the four signatures were explicit, the ceremonies had something concrete to check against instead of a vibe.
The map is the deliverable
Most PMs think their job is to specify the feature. On a regulated product, specifying the feature is the easy half. The actual job is specifying who needs to agree to it, in what order, and getting each of them to a real yes before a single sprint starts. Draw that map first. The feature map draws itself after.