agentleFS
poorvith-mppoorvith-mp/skills-sales-support/skills/discovery/SKILL.md

discovery

Skill0 starsChanged 2 months agoMITView on GitHub

Structure discovery calls: question design, current-state mapping, and gap quantification. Use when running sales discovery calls or BANT qualification.

26 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use specify, plan and 5 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • ArvorCoSkill

    specify

    Create feature specification from natural language description. Use when starting a new feature or creating a spec. Triggers on: create spec, specify feature, new feature spec.

    Also in 3 projects that use this

  • BlockSkill

    plan

    Draft a TDD, PRD, or lightweight plan in the conversation without committing it.

    Also in 5 projects that use this

  • Hugging FaceSkill

    implement

    Make tests pass. Invoke after /write-tests produces failing tests.

    Also in 6 projects that use this

  • nicolasestremSkill

    brainstorm

    Structured idea generation and solution exploration with systematic analysis.

    Also in 4 projects that use this

  • MicrosoftSkill

    init

    Also in 3 projects that use this

  • AnthropicSkill

    architecture

    Create or evaluate an architecture decision record (ADR). Use when choosing between technologies (e.g., Kafka vs SQS), documenting a design decision with trade-offs and consequences, reviewing a system design proposal, or designing a new component from requirements and constraints.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 24 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before dialing, write down: *"Based on their tech stack and recent hiring surge, they are likely experiencing [Specific Bottleneck] causing …

    line 24
  2. Distinctive:

    Ask questions you couldn't learn online: *"How is your platform team currently structured between cloud infrastructure and product feature …

    line 28
  3. Distinctive:

    Never end with "I'll send some slides."

    line 49

“Common” is measured: kept by at least 6 in 10 of the 24 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

discovery

Core Philosophy

Sales discovery is not an interrogation where an SDR fires off a 20-question checklist from a CRM script. Discovery is a collaborative diagnostic interview. Top sales professionals uncover the root cause of organizational dysfunction, quantify the latent cost of inaction, and help buyers understand the true scope of their problem better than they understand it themselves. If discovery is done right, the solution and pricing become obvious.


4-Step Diagnostic Discovery Framework

Step 1: Pre-Call Intelligence & Hypothesis Formulation

  1. 15-Minute Pre-Call OSINT:
    • Review LinkedIn: Buyer's background, tenure, recent promotions, engineering pedigree.
    • Inspect Company Tech Stack: BuiltWith, Wappalyzer, public GitHub repositories, Job Postings (which indicate what tools and languages they are currently hiring for).
  2. Formulate a Plausible Hypothesis:
    • Before dialing, write down: "Based on their tech stack and recent hiring surge, they are likely experiencing [Specific Bottleneck] causing [Business Consequence]."

Step 2: The Diagnostic Question Flow (SPIN + Gap Selling)

  1. Situation (Context without Prying):
    • Ask questions you couldn't learn online: "How is your platform team currently structured between cloud infrastructure and product feature squads?"
  2. Problem (Pain Exploration):
    • Probe the friction: "Where does the deployment process slow down between a pull request getting approved and landing in production?"
  3. Implication (Cost of Inaction):
    • Quantify the organizational bleeding: "When that deployment pipeline fails at 6:00 PM, what happens to the engineering on-call rotation? How many developer hours are burned remediating it?"
  4. Need-Payoff (Future State Vision):
    • Let the buyer articulate the value: "If your engineers could deploy schema migrations with zero risk of locking tables, what would that unlock for your quarterly release roadmap?"

Step 3: Gap Quantification & The Cost of Inaction (COI)

  1. Quantifying the Financial Bleed: $$text{Annual COI} = (text{Frequency of Incident / Year}) imes (text{Hours to Fix}) imes (text{Blended Hourly Dev Cost}) + text{Downtime Revenue Loss}$$
  2. Securing Agreement on the Math:
    • Rephrase the calculation back to the buyer: "So between developer time and customer SLA credits, this issue is costing your organization roughly $180,000 annually. Does that align with how your leadership views this?"

Step 4: Qualification & Mutual Next Steps

  1. MEDDPICC Quick Calibration:
    • Metrics: Verified quantifiable COI.
    • Economic Buyer: Identified who has budget approval authority.
    • Decision Criteria: Technical, commercial, and security requirements.
    • Decision Process: Steps to contract sign-off (legal, procurement, security).
  2. Closing the Call with a Mutual Action:
    • Never end with "I'll send some slides."
    • Schedule the exact date and time for the technical demo / architecture review with specific key stakeholders invited.

Deliverable Format: Discovery Call Brief (DISCOVERY-BRIEF.md)

# Sales Discovery Brief: [Company Name]

## 1. Call Snapshot & Participants
- **Account**: [Company Name] | **Domain**: [URL]
- **Attendees**: [Buyer Name, Title] | [Vendor Rep, Title]
- **Current Tech Stack**: [AWS, Kubernetes, Go, PostgreSQL]

## 2. Diagnostic Findings (The Current State vs Desired State)
- **Current State**: [Describe manual / broken status quo]
- **Primary Technical Pain**: [Specific bottleneck identified]
- **Root Cause**: [Why existing tools fail]
- **Desired Future State**: [Buyer's ideal workflow]

## 3. Cost of Inaction (COI) Quantification
- **Incident Frequency**: [e.g. 4 outages / quarter]
- **Engineering Hours Lost**: [~40 hours per incident @ $100/hr = $16,000]
- **Direct Revenue Impact**: [~$25,000 in SLA refunds]
- **Total Annual Bleed**: **~$85,000 / year**

## 4. MEDDPICC Calibration
- **Economic Buyer**: [VP of Engineering - sign-off required >$30k]
- **Decision Criteria**: [SOC 2 compliance, CLI ergonomics, <5ms latency]
- **Timeline / Catalyst**: [Must solve before Q4 peak traffic on Nov 15]

## 5. Agreed Next Step
- **Next Meeting**: Technical Architecture Demo on [Date/Time]
- **Attendees Required**: Buyer to invite Lead Platform Architect

Worked Example: Platform Tool Discovery Call

  • Hypothesis: Engineering team growing rapidly, causing database migration collisions.
  • Dialogue Discovery: Uncovered that a recent bad schema migration caused a 3-hour outage on Black Friday, resulting in $120,000 in lost transactions and executive scrutiny.
  • Quantification: Quantified total business impact at $210,000 including lost dev productivity.
  • Outcome: Scheduled technical POC review directly with the VP of Engineering; deal closed in 21 days at $48k ARR.

Verification Checklist

  • Pre-call research verified tech stack and buyer role prior to meeting.
  • Open-ended diagnostic questions uncovered root cause, not just symptoms.
  • Cost of Inaction (COI) is quantified with concrete numerical estimates.
  • Economic buyer and decision timeline are identified.
  • Call concludes with a firm calendar date and time for the next milestone.

Anti-Patterns

  • Feature Spraying: Showing product UI or slide decks in the first 20 minutes before diagnosing the problem.
  • Interrogation Mode: Reading through a rigid checklist of 15 BANT questions like a bureaucrat.
  • Accepting Surface Pain: Stopping at "deployments are slow" without asking why they are slow and what it costs.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.