What is the difference between product tools and a product workflow?

Tools each do their own job: Slack for conversation, docs for thinking, Jira for the work. A workflow passes the work from one tool to the next. If a person has to copy every decision from one tool to another by hand, the team has tools but not a workflow.

Why do product managers spend so much time on coordination?

Because after a decision is made, the PM often posts it in Slack, updates the doc, changes the Jira ticket and explains the reason again. None of the tools passes the decision on, so the product manager does. Being needed at every handoff can feel senior, but it spends judgement on coordination.

Should AI make product decisions?

No. The useful move is to automate what happens after the decision, not the decision itself. AI can add the decision, reason, owner and revisit condition to the Jira ticket once you approve it, and prompt you to review if the revisit condition happens. Nothing changes without your approval.

What should you record when a product decision is made?

Four things, written where the decision was made: the decision, the reason, the owner and next action, and a "revisit this if…" condition. Together they stop the decision being re-explained, clarify who moves next, and set out in advance what would reopen it.

Where do you start with automating a product team workflow?

Start with the last decision you had to explain twice. Write the four-part record for it, approve it, and have AI add it to the Jira ticket. Then set the revisit condition so the workflow asks you to review the decision if that condition happens.

Product Team Workflow: Automate What Happens After the Decision

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

According to Atlassian, 56% often have to ask someone or book a meeting.

The real cost never makes it to the calendar.

I see this every week: product teams with tools that work and a workflow that doesn't. The product manager copies every decision from one tool to the next.

The problem isn't too many tools. It's what happens after a decision. Here is what that looks like, why it costs a senior PM more than it seems, and how to hand the copying to a workflow while keeping the decision yours.

What happens after a decision today

A decision gets made in a meeting. Then the work starts:

You post it in Slack.

You update the doc.

You change the Jira ticket.

You explain why it changed, again.

None of these steps is hard. Each one takes a few minutes. But the same decision gets typed into three places by hand, and the reason behind it gets explained over and over because it was never written down where people look.

Then the gaps start. Someone who missed the meeting asks what happened. Someone else reads an older version of the doc. A ticket still describes the plan from before the decision. Each gap turns into a question, and each question comes back to the person who did the copying.

Each tool does its own job, and none passes the work on

Slack holds the conversation. The doc holds the thinking. Jira holds the work. Each tool does its own job well.

None of them passes the work to the next one. You do.

That is the difference between having tools and having a workflow. If every next step depends on you copying the decision across, you have tools. But not a workflow. Adding another tool doesn't close that gap, because the gap isn't inside any one tool. It sits between them.

For how I now pick tools so one step feeds the next, see /vault/product-manager-tool-stack.

Being needed at every handoff feels senior

There is a trap here for experienced product managers. Being needed at every handoff feels senior. You are the person who knows what was decided and why, so everyone comes to you.

But it spends your judgement on coordination. The hours go on carrying decisions between systems instead of making better ones. And because none of it is scheduled, the cost never shows up on the calendar.

One useful check: picture what happens if you are away for a week. If decisions stall, or get reinterpreted until you are back, the workflow runs through you rather than through the tools. That is a design problem in how the team works, and it can be fixed without anyone working harder.

Don't automate the decision. Automate what happens after it.

The answer is not to hand the decision to AI. The decision is the part that needs product judgement.

Don't automate the decision. Automate what happens after it. The copying, the updating and the re-explaining are the parts a workflow can carry.

Four things to write where the decision was made

Take the last decision you had to explain twice. Add four things where the decision was made:

1. The decision.

2. The reason.

3. The owner and next action.

4. "Revisit this if…"

The reason stops the re-explaining. The owner and next action stop the "who's doing this?" messages. The revisit condition says in advance what would reopen the decision, so it doesn't get reopened every time someone new asks about it.

Why the revisit line does the most work

Of the four, "revisit this if…" is the easiest to leave out, and it does a different job from the other three.

Without it, a decision has no stated end. Every new piece of information becomes a possible reason to reopen it, and every reopening comes back to the product manager. With it, the team knows the decision stands until a named condition happens. Information that doesn't meet the condition doesn't reopen anything.

A good revisit condition is something you could check, such as a metric passing a limit you agreed or a specific kind of request coming in again. A vague one, like "if things change", gives the workflow nothing to watch.

Let the workflow update the work, with your approval

Once you approve it, have AI add those four details to the Jira ticket. The decision now lives on the work itself, not in a meeting note or a Slack thread.

If the "revisit this if" condition happens, it asks you to review the decision. You don't have to remember to check. The condition does the watching.

Nothing changes without your approval. That line matters. The workflow carries the decision to where it is needed, but the decision and any change to it stay with you.

You make the decision. The workflow updates the work.

That is the whole split. Your judgement goes on the decision. The workflow does the handoffs that used to depend on you.

Start with one. Which decision did you have to explain more than twice this week?

Questions people ask

What is the difference between product tools and a product workflow?: Tools each do their own job: Slack for conversation, docs for thinking, Jira for the work. A workflow passes the work from one tool to the next. If a person has to copy every decision from one tool to another by hand, the team has tools but not a workflow.
Why do product managers spend so much time on coordination?: Because after a decision is made, the PM often posts it in Slack, updates the doc, changes the Jira ticket and explains the reason again. None of the tools passes the decision on, so the product manager does. Being needed at every handoff can feel senior, but it spends judgement on coordination.
Should AI make product decisions?: No. The useful move is to automate what happens after the decision, not the decision itself. AI can add the decision, reason, owner and revisit condition to the Jira ticket once you approve it, and prompt you to review if the revisit condition happens. Nothing changes without your approval.
What should you record when a product decision is made?: Four things, written where the decision was made: the decision, the reason, the owner and next action, and a "revisit this if…" condition. Together they stop the decision being re-explained, clarify who moves next, and set out in advance what would reopen it.
Where do you start with automating a product team workflow?: Start with the last decision you had to explain twice. Write the four-part record for it, approve it, and have AI add it to the Jira ticket. Then set the revisit condition so the workflow asks you to review the decision if that condition happens.