What Product Leaders Should Stop Doing Now That AI Can Do It
A practical framework for removing low-leverage work without outsourcing judgment.
TL;DR: For product leaders who have adopted AI, they certainly became busier rather than freer. The argument that this blog presents is elemental. And that is, leverage is not the ability to complete every task faster; it is the discipline of deciding which tasks should no longer consume much of your attention. This blog presents a four-tier framework — Eliminate, Delegate, Accelerate, and Own. This sorts product work by the importance it requires and by how much of it should stay on the product leader’s desk.
Teresa Torres shares something very interesting in her blog. She describes that she wakes up to work already finished. She mentions agents that run overnight on an always-on Mac Mini. She has multiple agents that work on various tasks, for instance,
A podcast-manager pulls interview research before her next guest,
A sales-admin assembles account context before every sales call, and
A coding-manager files her Monday retrospective.
She does not press start on any of it, and the artifacts are completed and ready before she gets to work.
Leveraging AI does not come from completing every product task faster. It, essentially, comes from deciding which tasks should no longer consume product-leadership attention.
To put it more clearly, not every task needs our entire attention.
Faster Work Is Not the Same As Leverage
AI enters product work at three levels. Sometimes these levels can get a bit confusing. Let’s discuss them briefly.
Efficiency
We can refer to efficiency as the same person working on the same task but faster. An AI assistant drafts the weekly update, and the product lead edits, adds nuance, and publishes. The artifact still ships from the leader’s queue. Queue here essentially means the set of deliverables. Efficiency is real, but it is a constraint. Meaning, the limitation is the number of hours the leader has to review what has been produced.
Delegation
Delegation is when an agent takes on a well-defined task, and the product leader supervises the result. This is usually via continuous feedback and brainstorming.
Take the weekly product update as an example. Composing it by hand can take about an hour or two. The work is tedious, like pulling status from Jira, Linear, etc. It is essentially chasing owners and stitching the pieces into a readable report. Too much back and forth, along with cut, copy, and paste.
An agent assembles the same update from source systems, flags initiatives without clear owners, and prepares a draft report. Then, the product leader reviews it in a few minutes rather than composing it in an hour. The leader still edits, but only where their judgment is required.
Elimination
Elimination is when the workflow itself is redesigned.
Take the weekly product update again. Instead of one person pulling numbers into a report every week, the tools that hold the numbers already show the current state. Anyone who wants to know where a project stands opens the dashboard. In this case, the update does not become faster to write. It stops being written at all.
Colin Matthews, in his Lenny’s Newsletter piece How Top PMs Increase Their Leverage With AI, shares in this manner — writing text, then creating artifacts, then, at the top rung, “delegate complete to-do items to AI.” He also notes that “as you ascend each ladder rung, you get an order of magnitude more leverage.”
OpenAI’s How Agents Are Transforming Work describes the same methodology from the other side: assign, answer when stuck, review, redirect, and approve. The ladder is effective and quite handy. Quite a number of product leaders reside on the first two rungs.
Producing more is not leverage when the organisation must still read, review, coordinate, and maintain everything produced.
Stop Doing Recurring Coordination Work
The clearest work to move off a product leader’s default workload is the recurring coordination that surrounds every scheduled event. This would inherently mean the preparation before, the notes during, the follow-up after, and the copying of one document into the format of another.
Torres’s three named agents, as mentioned previously, sit on an always-on Mac Mini, and they cover exactly this spectrum of work.
Interview prep: Pulls research on upcoming podcast guests before the call.
Review documents: Creates the transcript-review doc for each new episode.
Permissions: Sets sharing on the doc so the guest and editor can open it.
Sales context: Assembles background on the account before every sales call.
Follow-up tasks: Files the next actions after each conversation ends.
Task hygiene: Updates her task-management system so the queue stays current.
The important thing to note here is not that Claude writes a better summary than a junior team member would. But essentially it is that Torres no longer initiates each step. The entire automation or workflow runs whether or not she is at her desk.
Jess Yan’s arrangement aligns well with Torres’s.
In Product Development in the Agentic Era, Yan describes an adoption-analytics agent. This agent has database access and persistent memory, a developer-sentiment monitor that orchestrates parallel research agents, and a demo-building agent connected to GitHub.
The supervision model is adopted across various companies and labs. OpenAI’s How Agents Are Transforming Work and its companion blog Work With Codex From Anywhere describe the same idea. That is, assign, answer questions when the agent is stuck, review findings, redirect when needed, and finally approve at the end. The intermediate steps do not require the human’s attention.
It is vital to realize that the human’s attention is a scarce resource, but the workflow is not.
A task can be necessary without requiring direct execution by a product leader.
Delegate Analysis, But Retain Ownership Of The Conclusion
Research and analysis are strong delegation candidates. On the contrary, product conclusions are not. And confusing the two is where AI adoption most reliably damages the work.
Sachin Rekhi, in How I Use AI as a Product Manager, names the limitation directly.
AI produces what he calls “a solid B product strategy.” This means it “will typically lack any novel insights, offer no strong opinions on what direction to pursue, and fail to challenge conventional wisdom.”
The reason for this issue structural and not temporary.
Essentially, the probabilistic nature of the models “steers you back to consensus,” which is not something that you want. This is precisely the opposite of what strategy requires. The area where AI is genuinely valuable is upstream of the conclusion, including research, synthesis, critique, and the exploration of contradictory evidence.
Work AI Can Prepare
AI can be extremely beneficial at tracking competitor moves, pricing shifts, and category signals to inform their positioning.
AI can help group and cluster recurring themes from feedback, tickets, calls, and reviews into named patterns.
It can help to run first-pass cuts of usage, retention, and funnel data to highlight where the numbers move.
AI can collect sources that challenge the working hypothesis before the decision is made.
AI tests and evaluates the current plan against counterexamples and cases where it breaks.
AI can draft options with reasoning laid out for the leader to evaluate.
So the idea here is to use AI to its strength. Because we just cannot delegate tasks without thoroughly studying the task itself. That will be a waste of time and tokens.
Work the Product Leader Retains
PL can decide which sources deserve more attention.
PL can choose which customer segment the company will serve.
They can judge whether a signal is strategically important.
They can effectively select which cost the company is willing to accept.
PL can tag/label what the team will not pursue this cycle.
PL own the outcome once the call is made.
Torres is explicit about how the boundary between analysis and final result should feel in practice. She writes that teams should treat the AI-generated outputs and metadata as working artifacts, not findings.
The teams should “engage with them, correct them, collaborate with the AI.” The metadata becomes common ground for argument, where you can explore a great deal of information. This allows you to continually learn and provide feedback to the AI.
AI-assisted analysis should make evidence and uncertainty more visible and tangible, not hide them behind a polished recommendation.
Replace Some Documents With Working Evidence
It is much easier to build things now, thanks to the agentic workflow. That changes what teams need from documentation.
In many cases, a working demo you build in a couple of days is faster than the long spec. And it is usually more honest, too.
Jess Yan puts it plainly that “A spec that reads elegantly in a doc can fall apart the first time you try to build against it.”
Jess uses Claude Code to build agents against pre-production API specifications. Her approach exposes weak abstractions, unclear naming, and UX problems that no document review would surface.
Now, keep in mind that the prototype does not replace judgment. It essentially replaces the illusion that a document alone can validate it.
When implementation becomes cheaper, a functioning prototype can answer questions that a polished specification cannot.
Apple’s WWDC session on prototyping with Xcode agents demonstrates the same idea. Here the agents generate design alternatives, populate realistic content, test empty states, and refine interactions. One key phrase to highlight from the demo is that teams should “not delegate critical thinking to these tools.”
As I understand it, the prototype is a probe, not a final product.
Reduce or Replace
Replace early concept ideas with a working prototype that demonstrates the intent.
Replace static interaction with a running interface that shows the user behavior.
Cut off any explanations of untested behavior until someone has actually run the flow.
Retain
Record what decisions and rationale were chosen and why.
Name and label the constraints the product must respect.
List all the possible failures the team has already acknowledged.
Fix the non-negotiables for shipping.
Assign the person accountable.
The Practical Framework: Eliminate, Delegate, Accelerate, and Own
The examples so far point us toward a four-tier framework. This framework categorizes product work by:
How much judgment it carries and
How much of it should stay on the leader’s desk.
1. Eliminate
This tier is for work that is repetitive, predictable, low-risk, and easy to verify.
Note formatting structures meeting notes into a reusable template.
Standard meeting preparation assembles context packets before recurring calls.
Routine follow-ups generate predictable next steps on a schedule.
Information transfer copies data between different workflows.
First-pass status reporting drafts weekly rollups from source systems.
The product leader designs the workflow and reviews the exceptions.
2. Delegate and Review
This tier is for work with clear inputs, bounded scope, recognizable outputs, and reversible errors.
Market research that pulls competitor positioning, pricing changes, and public roadmaps into one view.
Feedback clustering clusters support tickets and interview notes by theme.
Competitive comparison essentially builds feature matrices from public documentation.
Initial data analysis runs cohort splits, funnel drops, and retention pulls.
Prototype variations generate two or three alternative flows for the same problem.
Draft experiment plans, hypotheses, metrics, and guardrails in a first pass.
The product leader verifies the evidence and determines what to do next.
3. Accelerate but Retain Ownership
This tier is for work that is ambiguous, strategically consequential, and dependent on organizational context.
Product strategy chooses the bets the company will make.
Prioritization decides what ships this cycle and what waits.
Positioning names the category the product is competing inside.
Problem framing states the question the team is actually solving.
Product narrative narrates the story customers and the company share about the work.
AI generates alternatives, challenges assumptions, and identifies what is missing. The product leader owns the conclusion.
4. Keep Human-Owned
This tier is for work that involves authority, trust, conflict, risk, or accountability.
Accepting product risk decides what the company is willing to break.
Resolving team conflict labels the disagreement and closes it.
Making people decisions to hire, move, or part with teammates directly.
Communicating bad news, such as delivering slipped dates, cutting scope, and making wrong calls yourself.
AI may assist in the preparation, but the human remains visibly accountable.
Recover Attention, Not Merely Time
When it comes to using AI in our daily workflow, there is a difference between being productive and leveraging AI efficiently. And I suppose, this is where AI adoption most often stalls.
Meaning, faster output can feel like progress, and that is true up to a point. But faster is not the same as better.
A better definition of the “role” changes what the work is really for. It is not about how many documents you push out in a week. It is about the quality of your decisions. And it is about the attention you have left to make them well.
A high-leverage product leader builds systems that take recurring work off their plate. They use AI to expand and test and even challenge their thinking. And they protect their attention for the decisions that need real customer understanding, real organizational context, and real accountability.
The opportunity here is not to make the existing product leadership role run faster. But it is to remove the work that pulled product leaders away from the important tasks. That is customers, product quality, and difficult decisions.