Start With the Business Outcome

Ask a team what their workflow does and you will get a description of its steps. It sends an email, then it creates a task, then it waits three days, then it sends another email.

Ask what it is for and the room gets quieter. Usually the answer is a restatement of the steps with an adjective attached: it makes sure leads get followed up. Sometimes it is an efficiency claim: it saves the reps time.

Neither of those is a business outcome, and the difference matters more than it sounds like it should. A workflow whose purpose is “make sure leads get followed up” is finished when it has followed up, which means it is finished the moment it sends the last email, whether or not anything happened. Every rule you write later inherits that. The exit conditions will be about steps completing. The definition of done will be about steps completing. The SLA, if there is one, will measure how fast the steps completed. And then someone asks whether the workflow is working, and there is no answer available, because nobody wrote down what working would look like.

What a business outcome sounds like

The decision in the previous pillar returned an outcome for Priya Shah: qualified. That is a classification. It is not work, and nothing about it says what should now happen.

A qualified inbound request results in a booked conversation with the right seller, or a recorded reason why it did not.

Read what that one sentence does. It names the result. It names the quality bar, which is the right seller and not any seller. It refuses to let the workflow finish by simply running out of steps, because or a recorded reason why it did not makes an unsuccessful outcome an explicit result rather than an absence. And it is falsifiable: you can look at a hundred qualified requests and count.

That last property is the one worth protecting. If you cannot count whether the outcome happened, you have written a mission statement.

Why this chapter is first

Every invariant later in this guide traces back to a failure of the business outcome. The exit rules exist because a workflow that keeps running after the outcome is impossible is wasting somebody's attention. The duplicate rule exists because two workflows chasing the same outcome produce one outcome and two sets of work. The stall state exists because a workflow that is waiting forever has not failed, and that is exactly why nobody notices.

You cannot argue about any of those against a vague outcome. Which is why the vague outcome survives: it is the version of the sentence nobody can disagree with, and that is not a strength.

Carry this into your business

Take a workflow you already run and write its outcome as one sentence with two halves. Most teams find the second half is missing entirely, which means every record that finished without the result is currently indistinguishable from every record that achieved it.