Day 3: The Anatomy of a Workflow

7-Day email course, workbook and ultimate guide

Yesterday we talked about why PMs are well-placed to lead automation projects. You already think in workflows. You just didn’t call it that.

Today we’re going to look at the structure behind every workflow.

Every workflow has the same basic parts.

No matter how complex an automation looks, it breaks down into the same structure:

Trigger → Steps → Output.

Let’s break each part down.

1. Triggers: The Kick-off

Something has to start the workflow. That’s the trigger.

They come in three flavours:

• Time-based: It’s 9am on Monday. It’s the first of the month. It’s been 7 days since something happened.

• Event-based: A form gets submitted. An email arrives. A task gets marked complete. A file gets uploaded.

• Manual: Someone clicks a button to start it deliberately.

The trigger is the domino that starts everything else falling.

2. Steps: What happens in the middle

Once triggered, the workflow runs through a series of steps. Each step does one thing.

Common step types:

• Get data: Pull information from somewhere (a spreadsheet, a project tool, an inbox)

• Transform data: Change it, combine it, filter it, format it

• Decide: If this, do that. If not, do something else.

• Send: Push information somewhere (email, Slack, a document, another tool)

• Create: Make something new (a folder, a task, a record)

• Wait: Pause until something happens or a certain time passes

Steps are where the actual work happens. The bits you’d normally do manually.

3. Output: The end result

Every workflow produces something. That’s the output.

Outputs might be:

• A report sitting in a shared folder

• An email in someone’s inbox

• A task created in your project tool

• A record updated in a spreadsheet

• A notification sent to Slack

The output is the whole point. It’s what you would have spent time creating yourself.

Conditions: The secret 4th ingredient

Most workflows also have conditions. These are the “if this, then that” rules that add flexibility.

• If the client is in the UK, send the email at 9am GMT

• If the project is over budget, flag it in the report

• If no tasks were completed, skip the summary section

Conditions let one workflow handle different scenarios without you building separate workflows for each.

Seeing it in action

Here’s a simple example. A client onboarding workflow.

Trigger: New client fills in the onboarding form (event-based)

Steps:

1. Get the form data (name, company, project type)

2. Create a project folder in Google Drive

3. Create a project in Asana with standard tasks

4. Send a welcome email with next steps

5. Add a row to the client tracker spreadsheet

6. Send you a Slack message so you know it happened

Output: New client is set up and ready. You didn’t lift a finger.

Why this matters

When you can break any process into trigger, steps, and output, you can:

• Explain what you need to someone who’ll build it

• Spot where things might go wrong

• Identify which parts need a human and which don’t

• Scope projects more accurately

Tomorrow, we’ll add the AI layer. That’s where things get interesting.

Speak then,

Tim

───────────────────────────────────────

Your course workbook

I’ve built a guide (in Notion) to go alongside these emails.

Inside you’ll find:

- Daily AI prompts to reinforce each lesson.

- Exercises to spot opportunities in your own work.

- Space to capture automation ideas as they come to you.

Complete the exercises, and you’ll be ready for the full guide on Day 7.

Sign up for Notion (it’s free and it’s awesome).

Then get your course workbook.

Seriously, have you not got it already!?