July 14, 2026

If you haven't read Part 1, start there. We identified the outcome framework and the emotional-to-metric translation this whole series builds on.

Mapping the Work

We're going to converge on specific, tangible tasks — because generic guidance is easy to nod along to and impossible to act on. Then, once we've got a foothold, we'll diverge again to see where that same approach applies elsewhere.

Step 3: Track what already exists

This step is inventory, not diagnosis—resist the urge to editorialize here. You don't need to know why things are the way they are today; that's a rabbit hole for another day. Right now, you just need the high-level baseline of what exists today. Step 3 and 4 may require you to go back and forth:

• Resources — FTEs, PTEs, contractors, interns, fractional help
• Tools — manual, automated, and AI-assisted, at both the individual, team, and org level
• Processes — how work actually moves, not how the wiki says it moves
• Artifacts — the meetings and artifacts that structure the work
• Dependencies — what you need from other teams, and what they need from you

Step 4: Map how product operations actually work

This exercise is useful for more than AI resource planning — it's just good operational hygiene. Start with high-level buckets, then add layers underneath. As you go deeper, you'll notice something useful: tasks that require judgment and autonomy tend to live higher in the hierarchy — that's where AI agents eventually make sense. Tasks with specific outputs, templated, and repeatable triggers live lower — that's AI workflow territory.

Use your step 3 “Track what already exists” material as a springboard for this documentation. You’ll be tempted to add aspirational tasks and responsibilities–I would resist that urge. It’s difficult to understand the time and value a task provides if you don’t do it today. Rather, that type of modeling should be worked into the Step 2 outcome statement with corresponding metric.

A spreadsheet/database format may be easier to manage the future steps versus a visual hierarchy, but here's a hierarchy sketch for a B2B SaaS product org showing the task bucketing:

The exact hierarchy is yours to define — but the goal is to land on isolated, individual tasks. Product teams may end up with over 100 of them, depending on the team’s charter and level of granularity. Precision matters here: if posting a weekly update in Slack is functionally different from posting the same update to a self-serve dashboard, list them separately. They're not the same task just because they share the same intent.

Step 5: Add evaluation metadata

Once you've got your task list, layer evaluation metadata on top. For our purposes, two subjective rankings do most of the work:

1. Time to complete (red / yellow / green)