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.
The AI Readiness Playbook for Product Teams (Part 2 of 3)
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:
- Time to complete (red / yellow / green)
- Value of the output (red / yellow / green)
Force-rank these as a team. A useful constraint: tell the group that at least 20% of tasks must be assigned red, and at least 20% green. Force ranking without that guardrail tends to collapse into "everything is yellow," which tells you nothing.
Beyond time and value, the same database structure lets you layer in more: task owners, tasks that go unused or seldom-used, which stakeholder group each task's output actually serves, and which tool is the primary interface for each task. If you're building this from scratch, a PM job description is a reasonable starting skeleton as long as it reflects what actually happens.
Step 6: Plot and assess priorities
Once time and value are assigned, you can draw insights from groupings. Replace red / yellow / green with 1 / 2 / 3 for easier plotting as desired.
- Red time + green value → worth investigating. High cost, high payoff — a strong automation candidate.
- Red time + red value → cut candidates. Low payoff isn't worth the cost whether it’s automated or not.
- Green time + green value → these are already working. Don't over-engineer them in phase 1
- Green time + red value → worth evaluating. Quick wins that could serve motivational or team PR purposes, but can also be busywork.
The force-ranking exercise is meant to surface orders of magnitude, not precise scores — treat the grid as a conversation starter with your team. The goal is to walk away with roughly 20 tasks worth optimizing based solely on time and value.
That narrowing is the whole point of this step. Twenty tasks is small enough to reason about individually and large enough to reveal real patterns — which is exactly where Part 3 picks up.▫
Next up in Part 3: we take these ~20 tasks, filter them against the outcome factors from Part 1, and run them through an AI-appropriateness lens — landing on the 3–5 tasks actually worth building first.