1) POV
Most people treat a decision as a moment. Gather information, weigh it, pick an option. In enterprise product work that is rarely where decisions break down.
What I have seen repeatedly in enterprise rooms is smart people looking at the same problem and still not solving the same thing. One function optimising for speed, another for completeness, another for what they can commit to downstream. Without someone making that visible, the room spends its energy on the wrong debate and lands on a decision nobody fully owns.
I have also seen what happens when tradeoffs stay implicit. The decision gets made, work starts, and three weeks later someone raises the thing everyone privately knew but nobody said out loud. The cost is not just time. It is the trust that leaks out of a team when people feel the obvious things went unsaid.
So over time I stopped thinking about decisions as moments and started thinking about the work that makes those moments clean. Three questions I now ask before any significant call:
Are we solving the same problem, or do people just think we are? Misaligned problem statements dressed as solution debates are the most common reason decisions stall or get reopened. I get to shared definition before options enter the room.
What are we actually trading, and can we make that visceral? Not a pro-con list. A real articulation of what each path costs the user, the team and the product over time. When tradeoffs are honest and visible the room stops negotiating preferences and starts making real calls.
What would have to be true for this to fail? I assume the decision breaks before committing. Then I build guardrails and fallback paths upfront rather than scrambling for them later.
2) Decision 1: workflow-native wedge vs full CLM suite
The first big call in CM Pro was also the one that shaped everything that followed.
The problem: A full standalone CLM suite was the vision. But validating it would take time and reaching enterprise-complete parity in v1 with established players was unrealistic.
The tradeoff: Faster time to value and adoption confidence versus suite completeness in the first release.
How we decided: We made the tradeoff visible to the room. The cost of building too broad too early was real. The cost of a focused wedge was a product that might feel incomplete against full-suite competitors.
The call: Build the lifecycle backbone and workflow-native experience first, grow surface area based on real friction signals.
Pre-mortem: Risk was feeling incomplete to customers evaluating against competitors. We defined MVP-complete explicitly, communicated what was deferred and why, and tied the phased roadmap to real evidence rather than assumed feature parity.
3) Decision 2: de-linking contract cases from legal architecture in CM Pro
With the wedge shipped and adoption growing, the architecture debt we had knowingly carried started surfacing in user feedback. This decision was harder because it meant revisiting something already built.
The problem: Every contract case in CM Pro sat inside a legal case by default. As the product grew to serve procurement, sales and IT workflows, the combined record became unwieldy. User friction across every persona traced back to the same root: the architecture.
The tradeoff: Changing the architecture meant real engineering cost and sequencing risk. Staying put meant friction compounding with every new workflow added.
How we decided: We built three to four approaches with honest tradeoff comparison tables alongside each, not to recommend an answer but to make the cost of each option visible. We brought this into a broader stakeholder room. Once the tradeoffs were laid out clearly the debate shifted from whether to act to how and when.
The call: De-link contract cases from legal architecture for the larger good of the product.
Pre-mortem: Risk was sequencing and engineering overhead. We built a phased approach with explicit milestones before committing.
4) Decision 3: external access to legal services in LSD
This decision was not a product architecture call but a user access and experience call with real security implications. The obvious solution turned out not to be the right one.
The problem: A customer wanted to extend legal services to external parties, vendors, contractors, anyone outside the org. Everything sat inside ServiceNow and required a login. External users would need an account for something they might use once a year.
The tradeoff: Stripped portal with login versus a no-login public-facing request flow with token-based follow-up access.
How we decided: Rather than defending the no-login approach as a design preference we took it to testing with internal and external users. Evidence came back clearly. Account creation friction was causing drop-off before requests were even submitted.
The call: Token-based no-login flow. Request without an account, return with a token to check status.
Pre-mortem: Security and governance concerns were real. We built explicit guardrails around those before the decision was final, not after.
5) What these have in common
Three different decisions, three different rooms, three different kinds of stakes. But the same moves underneath: get to shared problem definition before options enter the room, make tradeoffs honest and visible, and assume failure before committing so guardrails get built in rather than bolted on.
None of these were won by having the best answer. They were won by making the problem visible enough that the right answer became hard to argue with.
That is the system. Not a loop. A way of seeing.
