How I Bring Structure to Ambiguity

The request is useful, but it isn’t always the problem.

A finance team wanted to close faster. The visible problem was a slow reconciliation process. The deeper issue was that contract logic lived across PDFs, Salesforce, Snowflake, spreadsheets, and the judgment of Finance specialists. The company was reconstructing the truth every month because it had never encoded that truth once.

A consumer company wanted a chatbot. Once I looked at the work, the bigger constraints were fragmented knowledge, almost no baseline measurement, duplicated workflows, and unclear ownership across three brands.

An enterprise software company wanted AI use cases. After 36 discovery sessions, more than 100 mapped workflows, and roughly 400 decomposed tasks, the evidence pointed somewhere else. The models could often perform the isolated task. They were blocked by missing context, undefined processes, disconnected systems, absent ownership, and a lack of trust.

That changes the question.

Instead of asking, “How do we implement the requested technology?” I ask, “What would have to be true for this result to work?”

Sometimes the answer is AI. Sometimes it is deterministic automation, a better query, clearer ownership, a shared source of truth, or documentation that people can actually use. I care more about solving the problem than proving that the most advanced technology belongs in the solution.

Most complicated problems become easier to understand when you follow the work closely enough.

I want to know:

• What starts the process?
• What information does someone need?
• Where does that information live?
• Who moves it between systems?
• What decision are they making?
• Which rules are documented?
• Which rules exist only in someone’s head?
• What happens when the normal path fails?
• Who owns the exception?
• How does anyone know the result was good?

I listen to the people doing the work because they usually understand the system’s real behavior better than the process diagram does. A workaround may look inefficient from a distance, but it often exists because a system is missing information, a policy conflicts with reality, or someone is protecting the business from a failure no one else can see.

That knowledge belongs in the design.

In the finance reconciliation work, interviews with specialists surfaced rules and edge cases that had never been documented. In customer support, recurring contacts revealed product defects, content gaps, and expectation problems. In product organizations, conversations with Sales, Support, and Implementation exposed commitments entering the roadmap through channels the formal planning process could not see.

The point is not to admire the complexity. It is to understand why it exists well enough to simplify it without removing the judgment that makes the work reliable.

A lot of business work contains three different kinds of effort that have been bundled together.

There is work that should be exact: calculations, matching, validation, routing, permissions, or policy checks.

There is work that requires interpretation: evaluating an unusual contract, weighing product harm, reviewing a borderline result, or deciding whether the available evidence is strong enough to proceed.

Then there is coordination work: finding information, copying it between systems, recreating context, notifying the next person, and checking whether someone followed up.

Those categories should not receive the same solution.

In the finance system, extraction and reconciliation were separated from the financial decision. Production extraction used deterministic rules and document-processing technology. ARR and iACV calculations remained deterministic in Python and Snowflake. Finance retained approval authority for unusual cases.

The system automated roughly 89% of contracts, but the remaining 11% was not treated as failure. It was the part of the work where the rules were incomplete, the evidence conflicted, or human judgment still mattered. A process that had taken about a week became a five-minute run followed by no more than half a day of exception review.

That is a better result than claiming 100% automation while quietly asking people to clean up the consequences.

I’m comfortable changing the framing when the work stops supporting the original idea.

During one enterprise AI engagement, the initial plan was to identify use cases and begin automating. The discovery work produced 23 possible experiments, but it also revealed a repeated set of blockers: context, process definition, ownership, connection, and trust.

That evidence changed the strategy.

Instead of launching 23 pilots and hoping activity would eventually become progress, I prioritized four to run first. Each had an owner, a defined outcome, an evaluation plan, and a cost ceiling. The remaining opportunities were sequenced for later consideration. They were not rejected, and they were not presented as equally ready.

This is an important part of how I make decisions. I don’t confuse a long opportunity list with a strategy. Strategy requires sequence. It means deciding what needs to happen first, what evidence that work should produce, and what later decisions the evidence will inform.

Ambiguity becomes dangerous when assumptions stay hidden.

I bring structure by separating:

• What is working
• What is known
• What is assumed
• What remains unknown
• What needs a decision
• What requires more evidence
• Who owns the next move
• What happens if the assumption is wrong

This does not eliminate uncertainty. It makes uncertainty usable.

When I evaluated age-assurance requirements across multiple markets, the output was not a false promise of compliance. The work compared assurance methods, privacy implications, accessibility, conversion risk, vendor options, implementation cost, and regulatory exposure. It produced a configurable architecture and a decision-ready business case.

The system did not launch while I was there. That distinction matters. The successful outcome was a defensible decision and a buildable path, not completed implementation.

Delivery does not always mean shipping software. Sometimes it means giving leaders enough structure to make a consequential choice without pretending the uncertainty is gone.

I prefer the smallest useful test that can answer the question that matters most.

When launching a classroom communication product inside an established education company, demand was visible. Commercial viability was not. The new product had a different user, buyer, budget owner, adoption path, buying cycle, and renewal logic.

I held the work with two design-partner districts for two quarters while those assumptions were tested. The company did not open broader sales until the product and commercial model had enough evidence.

That patience created speed later.

The product grew from 2 design partners to 436 districts in two years, reached approximately $5 million in annual recurring revenue, and reduced the sales cycle from roughly three to six months to one to two months. It did not require a post-launch rebuild.

The decision was not simply whether to build the product. It was what had to be learned before scaling it.

I don’t trust automation goals that have not defined success.

Containment can look successful when a customer has simply given up. Accuracy can hide different consequences for false positives and false negatives. Faster output can move more work downstream. A model can perform well while the surrounding product still makes a bad decision.

In a music platform’s support operation, search success was below 10%, roughly 7% of tickets were being lost, and the knowledge base had grown to 691 articles. The visible problem looked like the support bot. Much of the failure was actually in retrieval, content quality, routing, and measurement.

The work began with rebuilding the Help Center and search, then connecting conversations to escalations, repeat contacts, satisfaction, and retention. Resolution became the primary measure.

Search success increased to approximately 90%. Lost tickets fell below 1%. Automation reached roughly 80%, and resolution improved from 44% to 75%.

The metric mattered because it changed what the team fixed.

I assume systems will encounter missing information, conflicting evidence, unusual cases, and people who disagree with the result.

That is not an edge condition to address after launch. It is part of the product.

For an AI-generated music detection system processing roughly 700,000 tracks a day, a model score could not become an enforcement decision by accident. A percentage point represented thousands of real artists.

I evaluated four vendors on the platform’s actual catalog rather than relying on published benchmarks. We optimized for precision because falsely accusing a legitimate artist carried serious product harm. The system kept prediction and platform action as separate states, routed borderline cases to people, and included artist communication, review, and appeals.

The final system reached 99.75% precision while preserving lower recall as an intentional tradeoff. That was not a technical compromise hidden inside the model. It was a product decision made around the consequences of being wrong.

I’m not interested in strategy that ends at the presentation.

I work across product, operations, data, AI, policy, workflow design, systems integration, measurement, and adoption because complicated problems rarely respect the lines between those disciplines.

Depending on the work, that has meant:

• Writing SQL and Python to test financial rules
• Designing APIs and review states
• Connecting Salesforce, Notion, Snowflake, Slack, and workflow orchestration
• Building shared evidence pipelines with deterministic privacy controls
• Defining confidence thresholds and escalation behavior
• Creating product intake and commitment practices
• Designing operating procedures, evaluation plans, and autonomy levels
• Working with Legal, Finance, Product, Engineering, Support, Research, Sales, and Operations around the same decision

I build enough of the system to find out whether the strategy survives contact with real information, real users, and real constraints.

A technically correct system that does not fit the work is not finished.

The output has to reach people where decisions happen. Context needs to travel with the task. Results may need to write back into the system of record. The next person needs to know what changed and why. Someone needs to own exceptions, maintenance, and measurement.

In one GTM system, useful AI work was trapped inside isolated chat conversations. People still had to reconstruct context, copy the result, update another system, and notify the next person.

The solution connected the information and the workflow. Reusable skills, persistent context, integrations, orchestration, write-back, and notifications became part of the product. Roughly 120 people across GTM and revenue operations used the resulting system.

The AI output was only one part of the design. The handoff was the product too.

Structure should make decisions more consistent. It should not freeze the company in place.

While leading product at an education technology company, the customer base grew from approximately 1,400 districts to about 4,000. The product organization added teams, products, markets, and commitments. I rebuilt the operating model three times because the system that worked at one stage was not sufficient for the next.

The consistent pieces were the decision path: how work entered, what evidence it needed, who owned the choice, what tradeoffs became visible, how launches were reviewed, and whether customers adopted what had been built.

The implementation changed with scale.

That is how I think about structure. It should reduce repeated confusion while leaving room for the organization to learn.

My process is not a rigid sequence, but it has a consistent shape.

I listen until I understand how the work actually happens. I separate evidence from assumption and rules from judgment. I look for the hidden coordination holding the process together. I reframe the problem when the evidence requires it. I make the decision, owner, risk, and next step visible. Then I build far enough to test whether the idea works in the real system.

I define success before scaling. I preserve human authority where the consequences or context require it. I treat exceptions, adoption, and measurement as part of delivery.

That is how I bring structure to ambiguity. I don’t make the mess look neat. I make the work clear enough to decide what should happen next.