I joined to find where AI could create leverage. The common approach is to collect use cases, rank them by excitement, and start building. I started by watching how work actually happened instead, function by function, session by session.
The request was
“Find the AI use cases and start automating.”
Discovery showed
The evidence pointed somewhere else. In most workflows the model could already do the task. What was missing was the context the model needed, a clear definition of the work, someone who owned the outcome, systems that could write back, and enough trust for anyone to act on the output.
Once that pattern repeated across 36 sessions, the question stopped being 'what can AI do here' and became 'what has to be true before AI can improve this work.' That reframe is the case study. It changed what I built, what I measured, and what I told the executive team.
- 36 discovery sessions across GTM, engineering, finance, and operations, focused on how the work runs rather than what people wish it did.
- Decomposed 100+ GTM tasks into inputs, judgment, context sources, and handoffs.
- Designed 23 experiments to test specific conditions, not general enthusiasm.
- Stood up 4 pilots where the conditions were already close enough to succeed.
Exhibit
What Actually Blocked the Work
| What it looks like | What it actually needs | Fix owner | |
|---|---|---|---|
| 01Missing context | Output is generic or wrong | Retrieval into real systems of record | Data + Ops |
| 02Undefined work | Every person runs it differently | A written definition of done | Function lead |
| 03No owner | Pilot stalls after the demo | One named outcome owner | Exec sponsor |
| 04Disconnected systems | Human copies output by hand | Write-back and notifications | Engineering |
| 05No trust | People check every result | Evaluation, sampling, visible rules | AI Ops |
Model capability appeared as the primary blocker in a small minority of the tasks I looked at.
Exhibit
The AI Ops Method
- 01
Observe
Sit with the work as it runs today
- 02
Decompose
Break it into tasks, context, judgment, handoffs
- 03
Test conditions
Run a narrow experiment against one blocker
- 04
Build the condition
Context, ownership, connection, rules
- 05
Then automate
Add the model once the work can hold it
- 01A repeatable AI Ops discovery and decomposition method other leads can run without me.
- 02A prioritized experiment portfolio tied to conditions rather than to tooling.
- 03Four pilots with named owners, defined outcomes, and evaluation in place.
- 04An executive narrative that moved the conversation from tool selection to operating conditions.
- Discovery
- Ran all 36 sessions myself and did the synthesis.
- Framing
- Changed the thesis when the evidence stopped supporting the original one.
- Method
- Turned the findings into a method rather than a slide.
- Executive
- Presented the reframe and the sequencing to leadership.
- The company's AI thesis shifted from use-case hunting to condition-building.
- 23 experiments and 4 pilots sequenced against evidence instead of enthusiasm.
- A shared vocabulary for why an AI project stalls, which made the failures diagnosable.
- The method now sits underneath the GTM operating system, the task assessment framework, and the engineering discovery work.
The hardest part was saying out loud that the question I was hired to answer was the wrong question. It landed because I had 36 sessions behind it. Evidence buys you the right to change the frame.