Case Study
Visibility Wasn’t the Product. The Decision Was.
How I built an operating layer across fragmented systems, audited the dead ends in my own product, and rebuilt it around decisions people could actually complete.
The situation
The information existed, but it was fragmented.
The Events operating model was already established. But understanding one program meant moving among a forecast model, a performance source, a finance source, a planning system, communication tools, and other systems of record.
Those systems were not the problem. Each one owned something important. The problem was that nobody could see the whole operating picture without assembling it by hand.
The design bet
The design bet was centralize, never replace.
I did not want to create another source of truth for information that already had a trusted home. The operating layer would read from those systems, join the information, show where each fact came from, own only genuinely new information, and carry decisions back to the right place when appropriate.
That exposed the first structural problem: the systems did not share one reliable way to identify the same event. You cannot centralize information if the sources cannot agree on what thing they are talking about. We adopted a canonical identifier upstream instead of maintaining a fragile layer of guesses inside the product.
The first build
The first version made the operating model visible. It brought status, readiness, tasks, ownership, proposals, portfolio choices, budgets, performance, follow-up, and post-event learning into one operating surface without asking people to abandon the systems they already trusted.
It also treated trust as part of the product. A number could be current, stale, unavailable, or genuinely unknown. Missing values appeared as unknown—not as a convincing zero—and freshness stayed attached to the source that supplied the fact.
Reporting and meeting outputs came from the same underlying information instead of being rebuilt as separate stories. Monitoring began moving from one person remembering what to chase toward system-supported follow-up.
I built Event Hub with Claude Code as the implementation partner. I designed the product, operating logic, workflows, architecture decisions, domain rules, tests, and acceptance criteria; AI helped translate that design into working software.
The turn
Then I asked for adversarial reviews of my own product. The brief was simple: gaps, not praise.
The audits found screens that looked useful but stopped before the work was complete. A proposal could exist without reaching a real decision. A portfolio change could be created without a clear submit, review, decision, and effect. Some controls had no meaningful downstream behavior. Some built functionality was no longer connected to the product at all.
That was the turn: a screen is not a workflow. Visibility was not the product. The decision was.
The failure produced a rule I still use: No action ships without its consequence, its undo, and its terminal state. If someone can create, edit, or request something, the product has to answer what happens next, who decides, what changes, whether it can be reversed, and how everyone knows it is finished.
I rebuilt the dead-end paths around complete decision lifecycles, gated consequential decisions instead of general participation, made activity history durable, connected actions to outcomes, and removed controls that did not do real work.
The same standard changed other decisions. Built-and-tested functionality was deleted when it no longer deserved a place in the product. A planned write-back was retired after security review showed it could not be scoped safely enough, so that step stayed human-confirmed. And when two sources drifted apart, the fix made unmatched records visible instead of letting missing information keep presenting itself as zero.
- 01Create — Make the proposed change or request visible
- 02Submit — Move it into a real review path
- 03Decide — Give the right role an explicit choice
- 04Effect — Apply the outcome where the work actually lives
- 05Close or reverse — Record the terminal state and preserve an undo path
What this proved
The operating layer is now used across Events, Sales, business leaders, Finance, and Marketing leadership without requiring those groups to abandon the systems they already trust.
That is an adoption outcome, not a claim about hours saved, revenue gained, or errors eliminated.
What the system proved is simpler: the useful product was not the one that showed everything. It was the one that made clear what needed to happen next, who could decide it, what the decision would change, and whether the information underneath it could be trusted.