The Forward Deployed Strategist playbook

The job in one sentence

The Forward Deployed Strategist makes sure the right thing gets built, and then proves it was worth building.

Step 1: Find where the time goes

Ask the people closest to the work one question: "What took up most of your day yesterday?" The answers tend to be specific and a little surprising. Copying figures from emailed PDFs into Tally. Chasing three signatures on a purchase order. Answering "Is my order dispatched?" for the fortieth time on WhatsApp.

Write each answer down as a task with a rough time cost. This list is the raw material for every use case that follows. Talk to managers too, and to the people who do the work. They know where the problems are; the team knows where the hours go.

Step 2: Map one process properly

Pick the most promising task and map it from start to finish. For each step, record:

• who does it and how long it takes
• what information they need and where it lives
• what decisions they make, and what rules they follow, written or unwritten
• what goes wrong, and how often

A good map shows where AI helps, where a simple rule is enough, and where a person must stay in charge. It is common to find that half the problem can be solved with a better form and no AI at all. Say so. It builds credibility for the half that does need it.

Step 3: Write the use case like a contract

A strong use case fits on one page:

1. Problem: what is slow, costly or error prone today.
2. Scope: the exact steps the system will handle, and the ones it will not.
3. Success measures: for example, the share of invoices posted without manual typing, or median first response time on support tickets.
4. Guardrails: what always needs a person's approval.
5. Data and systems: what the engineers will connect to, and who grants access.

This page becomes the basis for the technical specification, and later for acceptance.

Step 4: Prototype before you commit

AI coding tools let a strategist test an idea in an afternoon. A rough prototype shown to two real users often saves weeks of building the wrong thing. It does not need to be pretty. It needs to be close enough that a user can say "no, that is not how we do it".

Step 5: Measure after launch

Go live is not the finish line. Value shows up in adoption and in the numbers agreed in step 3. The strategist tracks both, reports them in plain language every month, including when they disappoint, and feeds what was learned into the next release.

Mistakes to avoid

• Picking a use case because it is impressive.
• Skipping the people who do the work.
• Measuring activity, such as the number of queries, and calling it success.
• Declaring success on launch day.