What You Still Own When AI Does Product Work
AI can help investigate a problem, challenge a plan, and recommend what to build. Here is what you remain responsible for when you use that help.

Updated September 26, 2026: The earlier version overstated what AI cannot do. This revision separates its growing contribution to product work from our responsibility for the decisions we act on.
I use AI for product work every day. The actual thinking: testing an argument, finding ambiguities, working through alternatives, and writing a specification somebody can build from.
An argument for product leadership that depends on AI being bad at those things will age badly.
The useful question is how to use that help while staying responsible for what happens next.
Let it contribute to the decision
There is no reason to reserve the first draft of a product decision for a person. Ask AI to identify assumptions, compare approaches, find contrary evidence, and suggest questions you have missed. Give it access to relevant material and inspect what it actually used.
AI can also participate in gathering new information. Anthropic's Interviewer, for example, conducted adaptive interviews with 1,250 professionals using a research plan reviewed by humans. That is a specific example of AI acquiring information from people. It does not establish that every important customer conversation should be automated. Research methods and limitations
The distinction matters. We should evaluate the quality and coverage of the investigation instead of assuming only a person can investigate.
Keep evidence separate from a plausible explanation
A generated persona is a hypothesis about a customer. An interview is evidence about what someone said. Observed behavior is evidence about what someone did. Each can help, and each answers a different question.
A convincing recommendation can blur those differences. Human consultants can do that too.
Before acting, ask which claims came from customers, which came from records or research, and which are inferences. Then identify what you still need to learn. A polished specification should not hide an unanswered question about whether anybody needs the thing.
Give decisions a memory
A decision needs a record that survives the conversation where it happened: what was chosen, why, which evidence supported it, and what would cause it to change.
That record can be available to people and agents. Ask both to compare a new proposal against it. If the recommendation changes, inspect whether the evidence changed or the question was merely phrased differently.
Consistency is useful when it protects a sound decision. New evidence should still be allowed to change your mind. Refusing to reconsider for ninety days is a poor rule if a customer shows you that the underlying assumption is wrong tomorrow.
Name who acts on the answer
Suppose the recommendation is to stop a feature that a customer has been promised. Someone has to make the call, explain it, negotiate the consequences, and check what happens afterward.
Those responsibilities belong to the people running the business, even when AI helped produce the recommendation. Hiring a consultant does not remove the need to agree who has authority and what that person is responsible for.
For a founder working alone, that person may be the founder. An existing team may already have someone who does it well. Outside product leadership earns its place when it improves the decisions and follow-through enough to justify its cost.
Make the next decision inspectable
For the next significant product choice, write down five things:
- The problem and whose experience should improve.
- The evidence you have and the assumptions you are making.
- The alternatives, including leaving things as they are.
- Who can decide and who will carry the decision through.
- What result would make you continue, change course, or stop.
Use AI throughout that work. Let it challenge the draft. Check its evidence. Invite another perspective where the consequences justify it.
Then return after the work reaches users and compare what happened with what you expected. Being responsible for a product includes noticing when your own recommendation was wrong.