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. And it can help you track and predict pricing shifts and category signals to inform your positioning.
AI can help group and cluster recurring themes from customers’ feedback, tickets, calls, etc. Additionally, it can tag them using pattern recognition.
Something that is quite commonly known, but I will still put it. AI can help to examine product usage, user retention, and funnel data to highlight where the impact is more.
AI can help you collect resources for a certain task that challenge the working hypothesis. This can be important to brainstorm ideas before any decision is made.
AI tests and evaluates the current plan against counterexamples and explores outliers to help you understand where it breaks.
So the idea here is to use AI to its strength. Because we just cannot delegate tasks without thoroughly studying each task. That will be a waste of time and tokens.
Work the Product Leader Retains
PL can decide which tasks require more attention.
PL can decide which customer and market segment the company should target or cater.
They can judge whether an AI-generated output 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 owns 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. This is important because it changes what the team needs from documentation.
Let me explain.
In many cases, a working demo you build in a couple of days is faster than the long spec. Because the demo is not complicated. Once you add more specs and, through listening to customer feedback and integrating new technologies, the product becomes more complicated and much harder to maintain
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 explains how she uses Claude Code to build agents against pre-production API specifications. Her approach exposes and finds out weak abstractions, unclear naming, and UX problems that no document review would surface.
Now, keep in mind that the prototype does not replace human 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 AI 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 — it is an extension of what your imagination looks like. It is not the final product. The prototype helps you to explore various angles of the same intention: how the product tastes and feels with different combinations of design and different implementations of the AI.
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 blog so far points us toward a four-tier framework. This framework categorizes product by:
How much judgment it carries and
How much of it should stay on the leader’s desk?
1. Eliminate
The eliminate tier is for work that is repetitive, predictable, low-risk, and easy to verify. For example,
Note formatting structures meeting notes, specs points, and similar docs into reusable templates.
Standard meeting preparation assembles context and information before recurring calls by reviewing email, Slack messages, Linear, etc.
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, limited scope, and recognizable outputs.
Market research that researchers and consolidates competitor positioning, pricing changes, and public roadmaps into a comprehensive view.
Feedback clustering clusters support tickets and feedback with proper labels.
Competitive comparison essentially builds feature matrices from public documentation.
Initial data analysis runs cohort splits, funnel drops, and research,
Prototype variations generate two or three alternative workflows or UIs for the same product with different approaches or preferences.
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 the work that is sort of ambiguous, strategically consequential, and dependent on organizational context. Essentially, these works are medium-to-high-risk.
Product strategy chooses the investment the company will make.
Prioritization decides what ships this cycle and what waits.
Positioning defines the category in which the product competes.
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, high-risk, or accountability.
Accepting product risk decides what the company is willing to sacrifice. It can be:
Product release
Feature release
Lowering prices
Changing market strategy to place the product successfully.
Resolving team conflict, labeling the disagreement, and closing it.
Making HR 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 falls short.
Meaning, faster output can feel like progress, and that is true up to a point. But faster is not the same as better and reliable.
A better definition of the “role” changes based on the work at hand. It is not about how many new specs or documents you release in a week. It is about the quality of the decision you made. And it is also 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, 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.