The seven-step minimum viable system

This is how a workflow you have just put words to becomes a system you can actually install. It is the work I do between session one (discovery) and session two (install). It is also the move set you learn to use on your own once the engagement closes.

01. Name the trigger and the termination.

Driving question. What starts this workflow? What signals it is done?

What good looks like. A one-sentence trigger ("a new lead lands in the shared inbox") and a one-sentence termination ("the lead is logged in the CRM with a status set"). Both observable.

02. Decompose into pixels.

Driving question. What are the steps from trigger to termination, and what output does each produce?

What good looks like. A flat list of 5 to 15 pixels, each with a verb and a clear output. Anything that does not fit that shape gets flagged and decomposed further.

03. Find the energy drains.

Driving question. Which pixels cost the most time, attention, or context-switching?

What good looks like. Two or three pixels marked as expensive, with a one-line note on why ("requires switching between three systems," "happens at the worst time of day").

04. Decide what each step actually needs.

Driving question. For each expensive step: automate it, AI helps with it, or stays human but supported?

What good looks like. Every expensive step from step 3 has one of those three labels next to it.

The three kinds of help

Automate it. The step does the same thing every time, with the same inputs and the same correct answer. A computer can do this without anyone watching.

AI helps with it. The step needs something written, summarized, drafted, or shaped, and the inputs change every time. AI is good at this with the right context. A person still reads the output before it goes anywhere.

Stays human, but supported. The step needs a human call. Someone has to weigh things, read a room, or trust their instinct. The system should not make that call, but it can pull together the information that makes it easier and faster.

05. Map to the available tool stack.

Driving question. What tools do you already have, and which is the simplest fit for each redesigned pixel?

What good looks like. Each redesigned pixel paired with one tool you already pay for and at least occasionally use. Lower friction wins over marginal capability.

06. Cut to the lowest viable version.

Driving question. What is the smallest version of this redesign that would actually fix the pain?

What good looks like. A v1 spec that fits on half a page and addresses the named pain. Anything beyond v1 goes into a "next" list, not the build.

07. Plan the install, not just the design.

Driving question. Who runs this the first time? What do they need on screen? How do they know it worked?

What good looks like. A short install plan: who initiates the first run, what windows are open, what data is on hand, what the success signal looks like, who is watching.