Skip to main content
Last reviewed: 2026-08-30 · Reading edit: 2026-09-06 Start with a task that is slow, costly, or frequently done badly, rather than with a new AI product. Compare an AI approach with simpler alternatives, estimate the benefit and effort, and choose a small test your team can actually adopt. Name the work problem; Compare possible fixes; Choose a bounded test Reading guide: name the work problem → compare possible fixes → choose a bounded test.

​
Use this when

  • The calendar is a pile of AI pilots with no shared problem statement.
  • Every function wants a different copilot, and none of them move the quarter’s number.
  • You are about to buy from a community list of “GTM AI tools.”
  • The team is tired of tool-of-the-month.

​
Do not use this when

  • There is no ICP and no number. Stay in ICP and GTM planning.
  • You already picked the problem and need stages, gates, and recovery. That is AI workflow.
  • You need a bake-off once the job is named. That is MarTech governance.
  • You need a custom GPT’s instruction skeleton. That is ai-teammate-brief.md—after the job exists.

​
A few useful terms

​
Keep this in mind

Pick the problem first. If you cannot name it in one sentence the CRO would recognize, you are shopping. A possibility that is only “try this model” is not a possibility. It is a catalog.

​
How to do it

​
Step 1: Name the business problems

Three at most. Pipeline missing, quality rotting, hiring gap, cycle slipping, onboarding stalling—this quarter. Then ask why until you have a cause you can act on, not a slogan. “We need AI” is not a cause. “Qualified people never reach the case-study stage because we only post the role” is.

​
Step 2: Compare AI and non-AI options

For each problem: outreach, a human hire, a process change, a compensation change, a page, an agent, a stop-doing. If the only row is a vendor, you jumped.

​
Step 3: Estimate benefit, confidence, and effort

Payoff. Is this a 5% lift you will not feel, or a change that would rewrite the plan? Demand a unit: pipeline, cycle days, hours returned that you will reinvest, win rate on a named slice. “Reps will be more productive” is not a payoff. Probability. Proven in a company like yours, or a speculation you are taking because the upside is large enough. Write which. Perspiration. Map every other team that must make this a top-three priority. A “one director, one month” project that also needs dashboards, training, and a narrative is a four-team project. A useful comparison—not a law: (payoff you believe × probability you believe) / perspiration. If the high-payoff bets all have terrible probability given current load, change the problem. That is the framework working.

​
Step 4: Check whether the team can adopt the change

The technology is usually less scarce than change. Principles that keep the frontline:
  • Start with work that makes the job easier, not a keynote agent.
  • Prefer tools that live where the team already works. A sixth surface is how you lose them.
  • Size enablement to the change: a Slack note, a written standard plus meeting time, or formal training. Most companies under-staff the last two.
  • One bet at a time with enough attention to finish. Random experiments train people to tune out.
When the bet is chosen, it becomes a row in the experiment ledger: hypothesis, decision, kill date.

​
Worked example (illustrative)

Sales-assist cybersecurity. Not Owner.com, not your vertical.

​
Copy: selection card (fill)

  • Company problem (this quarter):
  • Root cause we can act on:
  • Possibilities (include at least one non-AI):
  • Payoff in a number we will defend:
  • Probability and why:
  • Perspiration by team (not only the sponsor):
  • Priority call (do / wait / pick another problem):
  • Experiment row we will open if we do:
Working file: ai-use-case-score.xlsx.

​
Before you start

  • The problem is a company goal, not a vendor category.
  • At least one possibility is not software.
  • Payoff is a number, not “AI transformation.”
  • Perspiration names other teams.
  • Frontline can see how this makes the week easier.
  • We are not running three AI bets with no owner.
  • A community logo sheet did not pick the winner.

​
Metrics

Do not count tools trialed, or a CRO’s public “zero bad AI bets” story, as your selection system.

​
Common mistakes

  • Starting from a demo.
  • Incremental busywork dressed as payoff.
  • Ignoring other teams’ calendars.
  • Adding a surface the team will not open.
  • Switching tools before one bet embeds.
  • Copying another company’s hiring-sprint tree as your problem.
  • Pasting a Pavilion AI spreadsheet into the stack.
Where the motion sits on the ladder is GTM AI maturity. How the chosen job is staged is AI workflow. How you try to disprove it is experimentation. Which SKU may do the job is MarTech governance. Instructions for a teammate come last: ai-teammate-brief.md.

​
Sources and evidence boundary

This is an owner-maintained operating synthesis. It is not a decision-science textbook, not employment advice, and not an endorsement of any CRO’s win rate. Problem-first selection, a full possibility set, payoff × probability versus organizational load, and adoption as the scarce skill are distilled from a public write-up of a use-case method (Cannonball GTM, The Five P’s Framework, discussing a talk by Kyle Norton). That essay is a method prompt, not a source to copy. Owner.com performance claims, “zero bad bets,” Opportunity Solution Tree examples, and enablement slogans in the piece are not this library’s facts. A circulated community list of AI products is not a substitute for Step 1. A survey in which more firms report using AI than attributing EBIT to it (McKinsey, The State of AI) is a reminder to pick a P&L problem—not a reason to import their 2026 percentages as your business case.
Copyright © 2026 Ivan Xu. All rights reserved. See the copyright and reuse terms. Canonical source: github.com/weilun88313/B2B-Playbook