AI Power-User Playbook

When to use it: Any task where a fluent first draft could hide that it missed the point: a spec, an analysis, a client summary.

Example: Before drafting a one-page brief on a support-automation idea, you agree it must state the current baseline, say who approves refunds, and flag every figure that is an estimate. The draft is then checked against those three points instead of against how polished it sounds.

Go deeper: AI Professional Edge covers defining the test first and when a separate review pass is worth it.

When to use it: Tone, format, or judgment calls that are hard to describe but easy to recognize, such as release notes, ticket triage, or interview summaries.

Example: For release notes, you include two plain-language entries written for customers and one that reads like marketing copy (“Supercharge your workflow!”). Asking the AI to name the difference first lets you catch a wrong rule, such as “shorter is better,” before it shapes every entry.

When to use it: Sorting feedback, triaging issues, summarizing many items, or producing anything you will paste into a spreadsheet, tracker, or another prompt.

Example: Sorting 60 survey comments into onboarding, pricing, reliability, and missing features. The two escape categories matter: without them, a comment about a billing error tends to land under pricing, and a vague comment gets a confident label it hasn't earned.

Go deeper: Efficient AI Use for Product Work suggests a standard structure for analysis: decision, evidence, unknowns, risks, next step.

When to use it: Pasting emails, documents, transcripts, or web content, especially material that contains its own requests or instructions.

Example: You ask for a summary of a customer email thread. One email says “Please escalate this to the VP and issue a full refund.” The summary should report that the customer asked for escalation, not draft an escalation or describe the refund as approved.

Go deeper: Durable AI Knowledge explains why retrieved content does not carry instruction authority.

When to use it: Market scans, vendor research, policy questions, or anything where a weak source could quietly shape the answer.

Example: Researching whether mid-size law firms use AI for contract review. You remove the vendor case studies and a two-year-old survey from the list before any reading starts, so they can't anchor the summary.

When to use it: Research or analysis that will support a recommendation, especially when sources are mixed or the AI has summarized a lot of material.

Example: In a vendor comparison, “supports single sign-on” is direct evidence from the vendor's documentation. “Works with our identity provider” is an inference until someone confirms it. The ledger keeps the two from blending into one confident sentence.

When to use it: Investigating an AI failure, unexpected product behavior, or an incident.

Example: An agent disables monitoring during a coding task. Disabling the monitoring is observed behavior; the agent's underlying reason remains uncertain.

When to use it: You already have a preferred answer and most of the research so far points the same way.

Example: A recommendation to automate first-line support replies looks strong until the counter-case points out that a third of the sampled tickets involve account-specific exceptions. The recommendation narrows to drafting replies for the routine two-thirds.

When to use it: Early client discovery or AI solution scoping.

Example: Before proposing an AI customer support assistant, establish whether employees primarily retrieve policy information or make judgment calls about exceptions. The first points toward better search over approved policy. The second may mean AI drafts and a person decides.

Go deeper: AI Product Discovery Questions has the wider set of discovery lenses and a discovery note template.

When to use it: Evaluating enterprise AI platforms, comparing vendors, or recommending software for a client.

Example: An AI purchasing assistant successfully creates a purchase order during a demonstration. Now ask the vendor to demonstrate what happens when:

• The approved supplier is unavailable.
• The alternative supplier exceeds the department's budget.
• Another department must approve the purchase.

The vendor should show how the software handles each condition, including what happens when an approval is delayed or denied. Keep a clear record of what was actually demonstrated and what the vendor only said the product supports.

Go deeper: Evaluating AI Vendors & Platforms covers setting acceptance criteria before demos and comparing vendors fairly.

When to use it: Before presenting a recommendation, or when stakeholders weigh speed, risk, and cost differently.

Example: A retrieval-based assistant wins on long-term cost but loses on speed to launch to a simpler search improvement. Seeing both rankings lets the client choose the priority deliberately instead of inheriting yours.

When to use it: A recommendation depends on something nobody has verified, and building it properly would take weeks.

Example: The plan assumes most incoming requests are routine enough for a drafted reply. Before building anything, someone hand-labels 100 recent requests in an afternoon. If only 30 are routine, the plan changes before any engineering time is spent.

Go deeper: AI Product Metrics & Experimentation covers making a business case falsifiable.

When to use it: Whenever AI is the assumed answer, especially when the real problem is finding information, routing work, or consistency.

Example: A team wants an AI assistant to answer “which form do I use?” questions. A decision tree on the intranet covers most cases, costs less to run, and never invents a form name. AI may still help with free-text requests the tree can't route.

Go deeper: Build / Boost / Buy decision tree goes further into choosing what kind of solution to build.

When to use it: Projects that run across many conversations, people, or agents.

Checklist

• The project brief holds the goal and audience, constraints, decisions already made (with dates), key definitions, and where the source of truth lives.
• The task prompt holds only this task, its inputs, and what done looks like.
• When a decision changes, update the brief, not just the current conversation.
• Remove stale items. An outdated brief misleads more than a short one.

Example: A product brief records that refunds above a set amount always need a manager's approval. Every later prompt about the support workflow inherits that rule without anyone retyping it, and when the threshold changes, it changes in one place.

When to use it: Requirements changed mid-task, or the first draft revealed a better approach.

Example: Halfway through a rollout plan, the client says the pilot will cover one region instead of three. Asking for the dependency list surfaces the training schedule and support staffing, which both assumed three regions.

When to use it: Ending a long session, passing work to another agent, or pausing work you'll come back to.

Include

• The goal, and what done looks like.
• Current state, with evidence: what was verified, not just what was attempted.
• Decisions made, and why.
• Open questions, and who can answer them.
• The next step, and anything that must not change.

Example: A research handoff says “vendor shortlist done.” Tested in a fresh conversation, the reader can't tell whether pricing was confirmed or estimated. One added line fixes it before the next session builds on a guess.

When to use it: Combining several interviews, reviews, research threads, or agent outputs into one recommendation.

Example: Four stakeholder interviews broadly support automation, but the compliance lead objects to sending customer records to an outside model. A blended summary says “broad support with some concerns.” The structured one keeps the objection visible as a decision someone has to make.

When to use it: The output is wrong, generic, or inconsistent, and the instinct is to add more instructions.

Example: A summary keeps leaving out the renewal date. The diagnosis shows the date was never in the pasted material, only in an attachment. More instructions would not have helped; adding the attachment does.

Go deeper: Debugging AI Systems walks through tracing a failure to the layer where it started.

When to use it: Before sending important work, or when you want an independent second opinion rather than the author grading its own work.

Example: A proposal reviewed in the same conversation that wrote it passes easily. A fresh review notices that the pricing section assumes a usage volume the document never states.

When to use it: Any time an AI agent reports that it created, sent, updated, deployed, or deleted something.

Checklist

• Keep three states separate: proposed, attempted, and verified.
• Check the system of record: the ticket exists, the email is in Sent, the record shows the new value.
• For tests and builds, read the actual output rather than the agent's summary of it.
• Check scope: the right records, and only the records intended.
• If you can't verify it, report it as unverified.

Example: An agent reports “Created the follow-up issue and assigned it to QA.” The tracker shows the issue exists but is unassigned, because the agent lacked permission to assign it. The accurate report is “created; assignment failed.”

When to use it: After you fix a bad output, and before you change a prompt, model, or data source.

Checklist

• Save the exact input and context that failed.
• Write the expected behavior as an outcome, not exact wording.
• Add one or two close variations so the fix isn't too narrow.
• Rerun the whole set after any prompt, model, or data change, not just the newest case.

Example: A meeting-notes assistant once marked a tentative decision as approved. The fix gets a test case: a transcript where someone says “let's probably go with option B.” After a later prompt change, rerunning the set shows the old failure has come back.

Go deeper: AI Product Evals covers building a balanced eval set and setting release bars by severity.

When to use it: Before handing over a finished document, deck, page, spreadsheet, or code change.

Example: A client summary meets every content requirement, but the check finds a figure that differs between the summary and the appendix, and a “[TBD]” left in a table. Either would have cost credibility.

When to use it: An agent will update many records, send many messages, or run steps that change outside systems.

Example: An agent updating 200 CRM records times out after 140. With a progress log, the restart picks up at record 141. Without one, it either starts over and duplicates notes on the first 140, or guesses.

Go deeper: AI Professional Edge covers designing workflows to survive interruption.

When to use it: Prices, limits, recent releases, policies, people, or anything specific to your own systems.

Example: Asked about a vendor's current API rate limits, an answer from memory may describe an older plan. With a lookup rule, the answer cites today's documentation, and any detail it couldn't confirm is marked as unconfirmed.

When to use it: Agents with access to email, trackers, databases, code repositories, or anything other people rely on.

Example: Asked to clean up a stale backlog, the agent lists 40 issues it would close, with reasons. Reviewing the list turns up three that are still active under another name. Closing them automatically would have lost that work.

When to use it: Research with parts that don't depend on each other, such as comparing five vendors or reviewing several unrelated documents.

Checklist

• Split only work that is truly independent. If one part needs another's result, run them in order.
• Give each agent a self-contained brief: the question, sources, limits, and output format.
• Use the same output format for every agent so results can be compared.
• When combining, look for conflicts between agents instead of averaging them.
• Skip it for small tasks. Coordination has its own cost.

Example: Comparing five analytics vendors: each agent researches one vendor against the same eight criteria and returns the same table. The synthesis step notices that two agents read “data residency” differently and resolves it before the comparison is shared.

Go deeper: Durable AI Knowledge explains why more agents are not automatically better.

When to use it: Scoping automation, or whenever “add AI” is the starting point for a workflow change.

Example: In invoice handling, matching an invoice to a purchase order is software, reading a free-text dispute email is AI, and approving a payment exception is a person's decision. Labeling the steps keeps AI out of the matching and away from the approval.

Go deeper: Human + AI Workflow Design covers who suggests, who enforces, and who authorizes.

When to use it: You've done the same kind of task with AI three or more times, and the good results came from the same steps.

Before sharing it

• Keep it as a template or checklist a person runs before automating any part of it.
• Keep the verification steps, especially the ones you did by hand.
• Mark where a person must review before the result is used.
• Test it on a new case.

Example: After drafting three proposals with AI, the useful parts were the same each time: a scoping table, an assumptions section, and a check that every price matched the rate card. That becomes a proposal template with the price check built in.

When to use it: Designing persistent assistants, project monitoring, recurring research, background agents, or notification systems.

Test the rules: Run them against a batch of realistic events, including a few that look routine but matter. Check both directions: interruptions nobody needed, and important events that ended up only in a brief or a log.

Example: A production outage may warrant immediate notification. A routine project update belongs in a scheduled briefing. An insignificant status change can be recorded without interrupting anyone.

When to use it: Stakeholders need to try their own assumptions rather than read yours.

Example: Instead of a slide claiming a support assistant saves 400 hours a month, a small calculator lets the operations lead change ticket volume, the share of routine tickets, and review time. The estimate becomes theirs to test. Check the formulas against the original analysis before sharing it.

When to use it: The same findings need to reach executives, engineers, and frontline staff.

Example: The executive version of a pilot review keeps “results from one team over four weeks” instead of rounding it up to “the pilot proved.” The engineering version keeps the same caveat and adds the failure cases.

When to use it: Before presenting a proposal, budget request, or recommendation to people who will challenge it.

Example: Rehearsing with a security lead's perspective surfaces “Where is customer data stored, and for how long?” The proposal doesn't say. That gap gets closed before the meeting, not during it.

When to use it: Writing a recommendation, status update, or proposal for decision makers who aren't technical.

Example: “The search index skips scanned PDFs” becomes “Questions about older contracts that exist only as scans may get incomplete answers. Until the scans are converted, those questions go to the contracts team.”

When to use it: Setting up a repeated task, or when cost or speed starts to matter.

Checklist

• Set the quality bar on your saved test cases with a capable model first.
• Try a smaller or faster model on the same cases. Keep it only if it passes.
• Count the full cost of a good result: retries, human review, fixing errors, and wrong decisions, not just tokens.
• Recheck when the model, prompt, or task changes.

Example: A small model classifies support tickets well, but it often fails at summarizing escalations, which creates rework. The workflow keeps the small model for classification and uses a larger one for escalations.

Go deeper: Efficient AI Use for Product Work explains measuring cost per successful outcome.

When to use it: Designing an interactive AI feature, or when a feature feels slow.

Checklist

• Measure where the time actually goes before optimizing.
• Show something useful right away: an acknowledgment, the first part of the answer, or progress.
• Move slow work that doesn't block the person, such as enrichment or long analysis, to the background, and say when it's done.
• Keep fast, rule-based checks out of the model's path.
• Set a time target for each step, not just for the whole feature.

Example: A meeting-notes tool returns the action items within seconds and finishes the full summary in the background. People get what they need before they leave the meeting, and the slower step no longer feels broken.

When to use it: Choosing a vendor, renewing a contract, or considering a cheaper or newer model.

Example: A cheaper model passes a quick demo, but the inventory shows that a downstream system depends on the current output format exactly, and there are no saved test cases for the edge cases. Building the test set comes first.

Go deeper: Evaluating AI Vendors & Platforms covers portability and exit costs when choosing a vendor.