The Pathfinder Method

Every AI win moves through five stages.

AI doesn't have a complexity problem. It has a focus problem. Most teams have more AI ideas than they can count, and no reliable way to choose one, build it small, and prove it worked. That is what the Pathfinder Method is for.

Every AI win moves through the same five stages, in order: WHERE to focus, WHAT to build, HOW to build it, WHO to involve, and WHY it will matter. Skip one and it stalls: the right build for the wrong gap, a tool that works but nobody adopts, a win nobody can measure. The method makes all five explicit, and keeps them in order.

You work the five for one idea at a time, and come out with a single thing worth building, not a list. Then you do it again on the next idea. That is the shape of the method: a path you walk, and a loop you repeat. Run it idea after idea, and that is how AI transformation actually happens.

It's a method, not a tool. You could run it on a whiteboard. Below, we teach it one step at a time: the question to ask, the trap that stalls most teams, and what should be different when you're done.

The Path

We call the route from idea to win The Path. One opportunity travels it end to end, through five steps in order: Idea, Focus, Build, Change, Review. You don't start in the middle, and you don't skip. Each step earns the next.

Each step covers one stage of the transformation. The step name is where you are in the work. The stage is the question you answer there. Same five, both true at once.

Idea
Where to focus
the gap
Focus
What to build
the solution direction
Build
How to build it
the lean build
Change
Who to involve
the roadmap
Review
Why it will matter
the impact
Walk the five steps

You teach yourself the method by working through five sets of questions, one set per step. Write down what you decide at each, and those five answers together have a name: The Brief. One readable deliverable, one section per stage, concrete for your project, never generic. Here is each step in turn: the questions to ask, the trap that stalls most teams, and what changes when you get it right.

Step 01

WHERE to focus

Before you can pick where AI helps, get honest about where your team's time actually goes versus where the value is supposed to come from. Most teams have never put those two lists side by side.

Do that, then pick the one gap worth closing first. Not a list of ten. One.

The trap

Teams start from the tool. "Let's use AI for X." You can't pick the right answer before you've found the right question. Start from where your time actually leaks, not from a technology.

The questions to ask

Where is our time going, where is it supposed to be going, and which gap is worth closing first?

Before

A vague urge to do something with AI.

After

One named gap, chosen on purpose, that you can point at.

Worked exampleInvoice triage
The accounts-payable team is paid to pay vendors accurately and on time. But every invoice is sorted by hand, matched to a PO, coded to a cost center, routed to an approver, which eats about three hours a day and spikes at month-end so payments slip. The gap: high-volume, rule-following work sitting on the critical path.
Step 02

WHAT to build

A gap is not a solution yet. Not every problem is an AI problem, and the wrong kind of AI is how teams waste a year. Run the gap through three questions that, together, point you at the right shape of solution.

Every opportunity is some mix of three underlying problems. Name the mix, name the stakes, and the approach follows: better tooling, AI, or an agent.

Q1Which problems are actually in play?

Every opportunity solves one to three of these. The mix points at the kind of solution.

  • The system. Data in the wrong place, software that doesn't talk, manual steps everywhere. Calls for better tools: fix the stack so the rest can work.
  • The thinking. Judgment doesn't scale, decisions queue, analysis waits on over-capacity people. Calls for better intelligence: AI that reasons alongside your team so decisions move.
  • The toil. Repetitive work drowning people, processes that need constant babysitting. Calls for better autopilot: systems that handle the running so people focus on judgment.
Q2What would you do with unlimited capacity?
Picture the ideal concretely. Not "we would be more efficient." Something like "every invoice cleared the day it arrives, with no month-end pile-up." The concrete answer is what you actually want a solution to make possible.
Q3What happens when it's wrong?
Low stakes means mistakes are cheap to catch and fix, which opens up more autonomy. High stakes means mistakes are expensive, visible, or hard to reverse, which keeps a human in the loop longer.
The trap

Reaching for the most impressive AI instead of the right one. Not every problem is an AI problem, and the wrong kind of AI is how teams waste a year.

The questions to ask

What kind of solution actually fits this problem?

Before

"We should automate this."

After

A named direction: whether the problem is the system, the thinking, or the toil, and whether it calls for tooling, AI, or an agent.

Worked exampleInvoice triage
Triage is rule-following on semi-structured documents, not judgment. That makes it the toil, not a thinking or a systems gap. The right path is AI for extraction and classification, not a full agent, because the rules are stable and a human still approves. The v1: read each invoice, propose a cost-center code and an approver, and queue it for a one-click confirm.
Step 03

HOW to build it

Most AI projects die because the first version tries to do everything for everyone. Scope a single user, a single workflow, and the smallest version that is actually useful.

Just as important, name what is explicitly not in v1, and what still needs a human eye. The first version should ship without anyone betting the company on it.

The trap

Building everything at once instead of the first version. v1 dies when it tries to serve everyone. Scope one person, one workflow, the smallest thing that is actually useful, and name what is explicitly out.

The questions to ask

What is the smallest real version we could put in front of one person?

Before

A wish list.

After

A v1 small enough to ship and honest about what it leaves out.

Worked exampleInvoice triage
Smallest useful version: an inbox watcher, an extraction step, and a review queue where each invoice arrives pre-coded with a confidence flag. It reads the AP inbox and the PO list, and writes only to the existing approval queue. Out of scope for v1: auto-approval, payment, paper invoices.
Expand: The Build Planthe HOW, built out into the agent-ready handoff
What makes a Build Plan good is not length. It is clear scope boundaries, an ordered build sequence, and verifiable acceptance criteria, so whoever picks it up builds the right v1 and can check their own work. Here is a good one for invoice triage.
The Build PlanAutomate invoice triage
Objective

Watch the AP mailbox, extract each invoice's fields, propose a cost-center code and an approver, and drop it into a human-confirm queue. Done when a clerk confirms a pre-coded invoice in one click on the top-volume category, with under 15 percent needing re-coding.

In scope / out of scope

In: one mailbox, extraction, coding from the existing rules, a review queue with confidence flags and one-click confirm. Out (v1): auto-approval, payment, ERP writes, paper invoices, multiple mailboxes.

Shape

Intake watcher, then extractor, then coder (rules table plus a confidence score), then review queue, then on confirm write to the existing approval queue.

Interfaces and integrations

Read-only: the AP mailbox, the PO list, the coding-rules table. Write: the existing approval queue only. No ERP write in v1.

Data

Invoice record: source message id, vendor, PO number, amount, currency, line items, confidence, proposed cost center, proposed approver, status. The rules table is a read-only input.

Build sequence

1) Intake and store raw invoices. 2) Extraction to structured fields with a confidence score. 3) Coding from the rules table. 4) Review queue with confirm and edit. 5) On confirm, write to the approval queue. Each step independently verifiable.

Acceptance criteria

One real invoice flows intake to extract to code to queue to confirm to approval queue, end to end; time-to-queue under target and re-coding under 15 percent on the pilot category after two weeks; a human confirms every item.

Constraints and guardrails

Read-only everywhere except the approval-queue write. A human confirms every invoice, no autonomous action. Follow existing conventions, add no new ERP integration. Don't log full invoice bodies; restrict access to the AP role.

Open questions

Which mailbox protocol and auth are available? Does a coding-rules table already exist, or is it captured during the shadow week? What is the exact write interface to the approval queue?

Step 04

WHO to involve

A solution nobody adopts is a solution that failed. Name the people involved, then cast a destination worth aiming for and the one small move that starts now.

Not "roll it out," and not a wish list either. A roadmap: an ambitious destination, the waypoints on the way, and a first Checkpoint small enough to hit before you check in again.

The trap

Treating it as a tech project, not a change in how people work, or casting a plan so big it never gets a first move. Name the people, aim at a destination worth reaching, and commit to one small Checkpoint you can hit before the next check-in.

The questions to ask

Who needs to be involved, what does this look like 90 days out, and what is the one small move that starts now?

Before

"We'll roll it out."

After

A destination worth reaching, the waypoints on the way, and one small Checkpoint, with a first move, a who, and a date.

Worked exampleInvoice triage
Destination, 90 days out: invoices never touch a hand between arrival and the approval queue, and the AP team spends its time on exceptions, not sorting. Waypoints: pilot on the top-volume vendor category, then expand coding to every category, then raise the confidence threshold enough to skip manual review on routine invoices. First Checkpoint: the AP lead, one AP clerk, and IT shadow one week of real invoices to capture the actual coding rules, then pilot goes live on the top-volume category in 30 days.
Expand: The Roadmapthe WHO, cast as a destination and a first Checkpoint
What makes a Roadmap good is not ambition alone. It's a destination worth reaching, a small number of waypoints on the way, and a first Checkpoint concrete enough to start now. Here is a good one for invoice triage.
The RoadmapAutomate invoice triage
Destination

90 days out: invoices never touch a hand between arrival and the approval queue. The AP team spends its time on exceptions, not sorting.

Waypoints

1) Pilot live on the top-volume vendor category. 2) Coding rules expand to every vendor category. 3) Confidence threshold rises enough to skip manual review on routine invoices.

First Checkpoint - outcome

Pilot live and confirmed by the AP clerk on the top-volume category.

First Checkpoint - who

The AP lead, who owns the rules. One AP clerk, the daily user. IT, for inbox access.

First Checkpoint - first move

Shadow one week of real invoices to capture the actual coding rules.

First Checkpoint - due

30 days.

Step 05

WHY it will matter

A vision without a number is a vision you can't check. Name the outcome you expect and the metric that proves it, before you build.

That's what you come back to once the work ships: The Return, where you score it, bank what changed, and set your next Checkpoint. It's also what earns the next project.

The trap

Skipping the number. If you can't say what better looks like, you can't tell whether it worked, and you can't earn the next project. Name the outcome and the metric before you build.

The questions to ask

What outcome do we expect, and how will we know it worked?

Before

"This should help."

After

A specific outcome and a number you will come back to check.

Worked exampleInvoice triage
Expected outcome: triage drops from about three hours a day to under thirty minutes, with fewer slipped month-end payments.
Success metric: median time-to-queue per invoice, and under 15 percent needing manual re-coding after two weeks.
This is the promise you come back to check once the work is done.
Then you come back

One win, then the next.

The Path takes one idea to one win. The Loop is what comes next. You act on the first Checkpoint, then come back for The Return: score what happened, bank what changed, and set the next Checkpoint. That result becomes the thing you point to, and it surfaces the next idea worth doing.

We call it The Loop: capture, pathfind, act, return, then capture again. One trip down The Path is a win. Repeating it through The Loop is the transformation. That practice, end to end, is the method.

Capture→Pathfind→Act→Return→next Capture
Now go run it

Reading the method isn't doing the method.

Find some time, and start with step one. Your best AI project is waiting for you.

Find your best AI project See plans

Allow advertising cookies?

We use advertising cookies to measure our ads and show you relevant ones. You can change this anytime on our Data and privacy page, or read our Privacy Policy.