Product thinking
AI Features Are Not the Same as AI Leverage
A launch team can use faster summaries, cleaner checklists, and better draft emails. But it may also need help seeing the decision underneath the work.
Imagine a launch with real pressure on every side. Marketing may need the date to stick because campaigns, customer expectations, and competitive windows are already in motion. Leaders may want the timeline to hold because the market can read a delay as lost momentum. Engineers and product managers want people to use what they built, and shipping is often the fastest way to learn.
None of that is wrong. Time-to-market matters. Competitors can make a company look slow or out of step. But a smaller group of leaders may still be worried about quality. They see the known flaws, the support burden, the trust risk, and the chance that the launch will teach the organization the wrong lesson.
A helpful AI feature can summarize the bug list, draft the launch email, update the checklist, and file follow-up tickets. All of that saves time. But the higher-leverage question is different: how can those leaders make the tradeoff visible, concrete, and easier for the whole team to reason about?
I am trying to separate two kinds of help. Some AI features make the existing work faster. A more useful version helps a leader see the tradeoff clearly, balance speed against trust, and turn a judgment call into a decision the company can actually carry through.
Convenience is useful. It does not always create leverage.
A lot of AI product work today creates real convenience. That matters. Shortening a search, improving a draft, summarizing a thread, or turning notes into a checklist can make a day noticeably better.
But convenience and leverage solve different problems. Convenience makes an existing loop smoother. Leverage may change where the loop should exist at all.
I use three levels to separate useful shortcuts from real leverage. The boundaries are not perfect, but they help explain why some AI features feel helpful without changing how the work actually runs.
The first level is Q&A: lower the cost of knowing. The second is task help: lower the cost of small actions. The third is leverage: find the smallest human judgment that changes the outcome.
Q&A machines reduce the cost of knowing
The Q&A machine is often the first place AI becomes useful in a work product. It answers questions like: "What did this person say about this topic?" "When is my next meeting with this team?" "What is this policy?" "Where is the latest doc?" "What did we decide last time?" "Who owns this?"
These questions are not trivial. Knowing is expensive in modern work. Context is fragmented across messages, meetings, docs, tickets, comments, approvals, and people's memories. Much of work is really reconstruction work: finding the latest state, understanding how we got here, remembering who said what, and locating the source of truth.
Reducing the cost of knowing is valuable because it lowers the cost of orientation. A Q&A system can help someone join a project, catch up after time away, understand an escalation, or find the artifact they need without asking three people for help.
But Q&A usually does not create large leverage by itself. It helps the user understand the current state. It does not necessarily change the state. The old information system becomes more searchable, which is useful, but the work underneath can stay just as tangled.
The risk is that we confuse better retrieval with better work. A person can find the answer faster and still be stuck in the same decision loop, the same approval loop, the same handoff problem, or the same ambiguous ownership boundary.
Task assistants reduce the cost of small actions
The second level is the agentic task assistant. It does things like triage a queue, draft a reply, batch approve low-risk expenses, make a message sound better, fix grammar, summarize a thread, or create tickets from meeting notes.
These assistants can be genuinely useful. There is a lot of repetitive work in knowledge work. A system that removes small irritations can create real relief. If it drafts the message, cleans up the note, creates the ticket, and reminds the right person, that is a better experience than making the user do every mechanical step.
Still, many of these assistants mostly make existing workflows smoother. The message remains a message. The ticket remains a ticket. The approval remains an approval. The doc remains a doc. The human still lives inside the same loop, only with better drafting and faster handoffs.
That can be worth building. But it may not be a fundamentally new work system. The system is faster, but the shape of the work is mostly unchanged. The AI helps the user push the old objects around more efficiently.
This is where the word "agent" can hide the real question. If an agent performs more small actions inside an old workflow, it may be useful without being high leverage. The question is not only "Can the agent act?" It is "Is this the action that matters?"
Not more motion. Better consequence.
A goal I do not trust is "largest amount of work." It is easy to imagine a great AI system as one that does the most work for us: more emails sent, more docs created, more meetings recorded, more tickets closed, more code shipped, more approvals processed, and more people unblocked.
But more work can simply mean more motion. And more motion can be dangerous.
A system that optimizes for motion can look productive while making the organization less effective. It can unblock people in the wrong direction. It can generate documents that create false alignment. It can close tickets without resolving the underlying issue. It can produce status updates that make coordination feel complete when the real decision is still unresolved.
One question I would rather ask is:
Where is the smallest human judgment that creates the largest net-positive outcome?
"Net-positive" is doing a lot of work in that sentence. It does not mean more activity. It includes customer trust, quality, speed, morale, risk, opportunity cost, future maintenance burden, precedent, coordination cost, and whether the organization is moving in the right direction.
For me, that changes the product shape. I would not start by trying to automate the most visible activity. I would look for the moment where a small amount of human judgment, applied with the right context, changes the trajectory of the work.
The wrapper changes the work
A model can make certain cognitive operations much cheaper: reading, drafting, classifying, comparing, and planning. But the product around the model decides what that cheaper cognition is pointed at. Does it draft another status update, or does it ask why three teams need the same status update every week?
The practical product question becomes: who decides, what context is visible, which tradeoffs are considered, what the system is allowed to do, how decisions propagate, and how outcomes are judged later?
If the product layer is just a prompt box bolted onto old software, the model's capability gets expressed through the old units of work. It answers questions, drafts messages, edits docs, files tickets, and moves records. Those are useful. But they may not be the highest-leverage use of the model.
A product layer like this could look for judgment points. Where is the decision that changes the work? Where is ownership ambiguous? Where does repeated work point to a missing policy? Where are two teams using the same words but meaning different things? Where does one human call prevent a lot of downstream waste?
The product may need the work graph
A prompt box is a powerful interface because it is open-ended. But open-endedness is not the same as context. If the system does not understand the work graph, the model can sound smart while remaining blind to consequence.
By work graph, I mean the relationships among people, goals, decisions, blockers, dependencies, commitments, artifacts, permissions, risks, policies, historical outcomes, confidence levels, blast radius, and feedback loops. Some of this can be represented explicitly. Some of it may need to be inferred. Some of it is better left under human control.
Without that graph, the model can summarize a thread without knowing which decision matters. It can draft an update without knowing what tradeoff is unresolved. It can close a ticket without knowing that the same issue will reappear next week. It can approve work without seeing the precedent being created.
My current read is that this is why many AI features feel impressive in the moment but do not change the system. The model has language context, but not enough consequence context. It sees the text around the task, but not the obligations, risks, dependencies, and feedback that give the task meaning.
Simulation is not prediction
"Simulate" can sound too confident. A model cannot predict the future. Work is too social, too dependent on incentives, trust, timing, and incomplete information.
The point is more modest: the model can make possible consequences explicit enough for better human judgment.
That kind of simulation is structured reasoning. If we choose Path A, who benefits? Who is blocked? What risk increases? What precedent do we set? What future work do we create? What trust do we build or damage? What will this make easier or harder six months from now?
First-degree consequences are the immediate visible results. The launch ships. The customer receives the exception. The expense gets approved. The ticket closes. The meeting is scheduled.
Second-degree consequences are downstream behavior, precedent, risk, trust, coordination cost, future maintenance burden, or strategic drift. The launch increases support load. The exception becomes an expectation. The approval pattern teaches people the policy does not matter. The closed ticket hides a recurring product issue.
I would not want the product layer to pretend it knows which path is correct. I would want it to help the human see the decision with more of the consequence surface exposed.
Product launch: the decision is the work
Consider a product launch where the company has good reasons to move quickly. Marketing has campaign dates, customer commitments, and competitive windows to manage. Executives may worry that delay gives competitors room to define the category or make the company look slow. Engineering and product want the work in customers' hands so the team can learn from real use.
At the same time, a few leaders may still be worried. Maybe the product works in the happy path but fails in important edge cases. Maybe support is not ready. Maybe the launch will create trust damage that is much harder to measure than the launch date itself. The tradeoff is more specific than "speed bad, quality good." The question is what kind of speed the company is buying, and what risk comes with it.
A Q&A machine can summarize bugs, internal threads, customer feedback, support notes, and launch criteria. That is useful because it reduces the cost of getting oriented. An agentic assistant can draft the launch email, create the checklist, update the status page, and file follow-up tickets. Also useful.
But the leaders worried about quality need more than summaries and drafts. They need help making the tradeoff specific enough for the whole room to discuss. A system like this could compare the real paths: ship broadly, limit the rollout, delay, or ship with a narrower promise. What competitive risk comes from waiting? What trust risk comes from shipping? Which customers will notice first? What will support have to absorb? What metric will tell us whether the decision was right?
I would not want AI to tell the leader what to decide. The useful version helps the leader turn a vague quality concern into a concrete tradeoff: evidence, options, assumptions, second-order costs, competitive context, and a decision record. It gives the quality concern enough shape to be weighed fairly against the urgency to move.
After the human decision, the system can help carry it through: launch plan, support guidance, customer messaging, roadmap notes, follow-up owners, and an outcome review. Did support volume match the estimate? Did a limited rollout reduce risk? Did the delay improve quality, or did it mostly move uncertainty into the future? This is where the decision becomes real work, not just a debate in a meeting.
Customer escalation: the response is not the whole decision
Now imagine a customer escalation. A customer wants an exception.
A Q&A machine can summarize the customer history, agreement terms, past support issues, and previous commitments. An agentic assistant can draft a response, schedule a follow-up, and create an escalation ticket.
The harder judgment is whether to grant the exception, refuse it, or offer a temporary workaround. Granting the exception may preserve trust but create precedent. Refusing may protect the product boundary but damage the relationship. A workaround may buy time but add support burden or fragment the roadmap.
A system like this could compare those paths, surface the second-degree consequences, and ask the human to make the tradeoff-aware decision. It would then propagate the decision into the customer message, internal notes, follow-up owner, support guidance, and any policy or roadmap implication. Later, it would track whether the decision helped or created new cost.
I would not want the system to hide the value judgment. Whose trust matters? Which precedent is acceptable? How much support burden is worth carrying? Those are human questions.
Expense approvals: repeated work may be a design smell
Expense approvals are a small example, but useful. Batch approving low-risk expenses saves time. A Q&A machine can explain the expense policy. An agentic assistant can approve obvious cases, reject incomplete ones, and ask for missing receipts.
But the high-leverage move may be different. The repeated approvals may exist because the policy is unclear. People may be asking for approval because they do not trust their interpretation. Managers may be approving the same category every week, which means the organization has accidentally turned policy ambiguity into recurring coordination labor.
A better system might notice the pattern and ask a human whether the policy needs to change. If approved, it could help update the policy, communicate the change, adjust approval rules, and track whether future approval load decreases.
This shifts the work from processing repeated approvals to removing the cause of repeated approvals. That is closer to leverage.
Cross-team misalignment: same word, different assumptions
Many coordination failures are semantic. Two teams use the same word but mean different things. Or they agree on a plan while carrying different assumptions about ownership, timing, API behavior, launch scope, or customer impact.
A Q&A machine can summarize what each team said. An agentic assistant can draft an alignment email. Both help.
A system like this could try to detect the mismatch itself. It might notice that one team is using "ready" to mean feature-complete, while another means support-trained and customer-safe. It might show likely consequences: duplicate work, incompatible APIs, launch delay, customer confusion, or a late change in ownership.
Then it would ask for a source-of-truth decision. Which definition are we using? Who owns the boundary? What needs to change in the doc, roadmap, tickets, and team follow-ups so the decision becomes real?
The useful shift is catching the hidden ambiguity before the organization spends weeks executing different plans under the same label.
Hiring and resource allocation: headcount may not be the bottleneck
Resource planning is another place where the obvious task may not be the highest-leverage task. A team thinks it needs more headcount.
A Q&A machine can summarize the hiring plan, open roles, workload, and project commitments. An agentic assistant can draft a job description, create an interview plan, and schedule loops.
But the bottleneck may not be headcount. Ownership may be unclear. The team may be blocked on a dependency. There may be too many priorities. Sequencing may be poor. One decision from another group may unlock more than two new hires.
A system like this could help compare interventions: hiring, cutting scope, changing ownership, resolving a dependency, or resequencing work. It would not decide alone. But it could make the bottleneck question harder to skip.
That is the shift. The model can help create the job description. I would want the product to ask whether the job description is the right artifact to create.
The human moves from labor to judgment
A good version may not remove humans from the loop. It may move humans to the highest-leverage point in the loop.
Current systems ask humans to do a lot of coordination labor: read every thread, remember context, connect dots, rewrite updates, repeat decisions, chase owners, reconcile conflicting docs, notice that two teams are misaligned, remember what happened last time, and translate judgment into artifacts.
I would want an AI system to ask humans for different things: judgment, values, tradeoffs, taste, accountability, final calls, and exceptions. The machine can prepare the surface. The human still owns the decisions that matter.
This is a more modest view of automation than "the AI does the work." It says the AI can reduce the cost of reaching the right judgment point, not simply increase the amount of activity around the old one.
Failure modes
This idea has plenty of ways to go wrong.
The first failure mode is optimizing for measurable motion instead of net outcome. Emails sent, tickets closed, documents generated, and approvals processed are visible. Trust, quality, morale, future maintenance burden, and strategic drift are harder to measure. A bad system will chase the visible thing.
The second is over-trusting simulated consequences. A model can make a path sound coherent without being right. I would keep simulation in the role of decision support, not prophecy.
The third is a bad or incomplete work graph. If the system does not understand the real dependencies, permissions, owners, risks, and history, it may surface the wrong judgment point with great confidence.
The fourth is permission collapse. A system that acts across tools can accidentally flatten boundaries that exist for good reasons. Access, approval, confidentiality, and blast radius are product constraints, not administrative details.
The fifth is invisible value judgment. "Net positive" depends on whose outcome matters. A decision can be good for speed and bad for quality, good for one team and costly for another, good this quarter and harmful later. I would want the product to make those values visible instead of baking them into the system quietly.
The sixth is organizational politics. Surfacing leverage points can reveal hidden bottlenecks. The issue may be unclear ownership. A team may be overloaded. The roadmap may have too many priorities. A policy may be incoherent. A useful system can make hidden tension visible, and not every organization will be ready for that.
The shape is still unresolved
The final interface is still open. It might not be a dashboard, inbox, canvas, graph, or chat. It may be some shape we have not invented yet.
The old software objects do not disappear. Messages, docs, tickets, meetings, approvals, permissions, and audit trails still matter. In many cases they are exactly what make work safe enough to coordinate.
I am more interested in AI products that do not simply place a model inside every old workflow. They ask what the model makes newly possible, then design the product around judgment, consequence, propagation, and learning.
The question changes from "How do we add AI to existing software?" to "What should the product around the model actually do?"