gtmskills.com

Reference file

Discovery patterns

discovery-patterns.md

Discovery patterns

What GTM leaders say when they describe their AI GTM transformation. These come from discovery calls with GTM leaders and from GTM community discussions, and are paraphrased and anonymized. Use them to recognize where a typed answer belongs and to name a gap in words the leader already uses. They are patterns, not statistics: never quote a share or a count from them.

How to open (before the questions)

The best discovery conversations on this topic follow the same five steps. When the leader wants a conversation rather than a quick audit, use them as the frame around the question bank:

  1. Outcome and reason for change. "What is the main initiative right now, and why now?" "If this works, what changes in the business?"
  2. The current motion, not the stack. "Where is pipeline coming from today, and what does that motion look like step by step?"
  3. The bottleneck. "Where in the funnel are you trying to change performance, and what is the biggest friction there?" Then quantify it: volume, time, conversion.
  4. Ownership and boundaries. "Who builds and maintains this? Can other people contribute to it?" "What must a human own, and what can run without one?"
  5. Success and the economic case. "What does success look like at 30 and 90 days?" "Is there a budget case, and what proof would earn more?"

Ask how the organization works, then place it against what good looks like. Do not ask leading questions that only have one acceptable answer.

Tells by level

01 Mostly manual

  • "We bought licences and people use it, but I couldn't tell you what it changed."
  • "It depends on who is prompting."
  • Research, list building and follow-up still described as rep hours.

02 AI as an answer engine

  • "We connected it to the CRM and the call recorder, so we can ask it anything."
  • "AI is adding noise, not simplifying the work." Dashboards report outcomes but do not tell anyone what to do next.
  • AI use is spread across the org with no central operating layer: every team has its own tools and experiments.
  • The leader describes integration (everything connected, the data accessible in one place) and calls it a shared layer. Run the logic test.

03 AI as an action engine

  • "We have agents running and we're seeing productivity gains, but each one was built separately."
  • One technical operator (often a GTM engineer or a RevOps lead) built most of it, and the question is whether anyone else can contribute without breaking it.
  • "Every time we want to change something, someone has to go into the tool it was built in."
  • Hidden maintenance: prompts, integrations and vendor changes break workflows, and nobody owns finding out.
  • Concern about a rep's name going out on a message they never approved.

04 Shared AI layer

  • Teams describe iterating on different parts of the funnel (pre-qualification, deals, renewals) from the same foundation.
  • The questions shift to measurement and investment: which workflows earn more budget, and how to prove impact beyond activity counts.

Pains by function

Founder or CEO

  • Pipeline is thin or depends on referrals and partners; the founder's own time is the bottleneck.
  • Pressure to grow without matching headcount.
  • DIY agents that someone now has to maintain; uncertainty about which proof justifies more spend.
  • Under-tested: the build, buy or staff decision, accountable ownership, business-outcome proof, and whether the operating model changes alongside the tools.

Marketing

  • High-intent website traffic and demand not acted on; anonymous visitors never become meetings.
  • Person-level signals that never become an account view.
  • MQL-to-SQL conversion stalls; follow-up after events and webinars is manual and slow.
  • Content quality drifts when anyone can prompt; attribution is weak.
  • Under-tested: buying-group resolution, lifecycle decisions, brand and claims control, pipeline attribution.

Sales

  • Reps act as order takers; research and account mapping eat selling time.
  • Outbound conversion is low and AI-written outbound decays when messaging is not kept current.
  • Unclear who owns creating pipeline when it is short.
  • Adoption and judgment risk: where AI should stop and the rep should take over.
  • Under-tested: the human and agent boundary, call evidence reaching the CRM, pipeline accountability, spreading what works from one rep to all of them.

RevOps and GTM engineering

  • Fragmented tools and AI experiments; the stack spread across the CRM, enrichment tools, automation tools and code.
  • CRM fields with no evidence behind them; uncontrolled writeback polluting the system of record.
  • One technical operator as the bottleneck for every change.
  • Under-tested: architecture, provenance, change control, workflow ownership, safe self-service.

Customer success

  • Under-adoption, noisy health signals, incomplete setup, weak proof of value.
  • Operating knowledge concentrated in a few people.
  • Under-tested: one model for renewals and expansion, value stories built from real usage, validating risk scores before acting, reusable CSM knowledge.

Patterns that cut across every function

These come up often enough that one production-readiness question belongs in every audit:

  • Who owns a workflow after launch, and what happens when its builder leaves.
  • How you find out a workflow broke after a model, prompt or vendor change.
  • What data an AI workflow may access, especially in regulated industries.
  • Whether AI output is checked before it reaches a customer or the CRM.
  • Whether anyone can see why an AI recommended an action.
  • What a workflow costs per useful outcome, and whether it moved pipeline or revenue.
  • How the build, buy or hire decision gets made.