building-sales-team

- Deciding when to hire sales vs continue founder-led selling

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "building-sales-team" with this command: npx skills add oldwinter/skills/oldwinter-skills-building-sales-team

Building Sales Team

Scope

Covers

  • Deciding when to hire sales vs continue founder-led selling

  • Designing the first sales team (pilot AE/SDR/hybrid) and hiring sequence

  • Hiring for repeatability (avoid “one heroic rep” dependency)

  • Setting a minimal operating cadence (ramp plan, metrics, coaching loop)

  • Technical / product-heavy selling: “sales that can pass for PMs”

When to use

  • “We’re ready to hire our first AE / SDR—help me design the plan.”

  • “Should we hire sales now or wait until the motion is repeatable?”

  • “Create role scorecards + an interview loop for early sales hires.”

  • “We’re starting product-led sales—how do we run a small pilot team?”

  • “Build an onboarding + 30/60/90 ramp plan for the first reps.”

When NOT to use

  • You need to get first customers / validate ICP from scratch (use founder-sales first)

  • You’re scaling a mature sales org (territories, forecasting, multi-layer management)

  • You need legal/HR advice, compensation plan legal review, or employment compliance guidance

  • You want generic hiring advice without a defined sales motion and measurable readiness gates

Inputs

Minimum required

  • Company stage (pre-seed/seed/Series A+) and current GTM motion (PLG, outbound, enterprise, inbound)

  • Current funnel baseline: last ~50–100 “at-bats” if available (first meetings → closed-won), win rate, typical ACV, cycle length

  • ICP + product complexity (how technical is the sell; who must be convinced)

  • Current resources: founder time, CS/support involvement, marketing demand, budget/headcount constraints

  • Timeline + success definition (e.g., “2 reps ramped to $X pipeline/month in 90 days”)

Missing-info strategy

  • Ask up to 5 questions from references/INTAKE.md.

  • If data is missing, proceed with explicit assumptions and deliver two options: (A) “Hire now (pilot)” vs (B) “Wait + founder-led milestones to hit first”.

Outputs (deliverables)

Produce a Sales Team Build Pack in Markdown (in-chat; or as files if requested):

  • Context snapshot (stage, motion, ICP, constraints, targets)

  • Readiness gate (hire-now vs wait) with measurable criteria

  • Team design + hiring sequence (who to hire first/second; when; why)

  • Role scorecards (AE/SDR/hybrid) + evaluation criteria (incl. product depth bar)

  • Interview loop + practical exercises + scoring sheet

  • Onboarding + 30/60/90 ramp plan + coaching/metrics cadence

  • Risks / Open questions / Next steps (always included)

Templates: references/TEMPLATES.md

Workflow (7 steps)

  1. Intake + stage gating (should we hire now?)
  • Inputs: User context; references/INTAKE.md; any funnel history.

  • Actions: Identify the GTM motion and whether the founder has achieved a repeatable baseline. Look for: (a) organic demand/hand-raisers (if PLG), and/or (b) a repeatable win rate from first meeting → close (target range often ~15–25% over ~50–100 at-bats). Decide: Hire now vs Wait.

  • Outputs: Context snapshot + readiness gate decision + assumptions/unknowns.

  • Checks: The decision is tied to measurable evidence (or clearly labeled assumptions).

  1. Define the “repeatable motion” you’re hiring into
  • Inputs: ICP, use case, pricing/packaging, current discovery/demo flow.

  • Actions: Write a 1-page “sales motion spec”: qualification, first meeting agenda, demo/pilot criteria, pricing guardrails, common objections, and what counts as an “at-bat”. Clarify founder vs rep responsibilities for the next 60–90 days.

  • Outputs: Sales motion spec + handoff boundaries.

  • Checks: A new rep could run the next 10 deals with this spec without inventing the process.

  1. Choose the initial team topology (pilot-first) + sequence hires
  • Inputs: Motion spec; readiness decision; budget; pipeline sources.

  • Actions: Select the simplest starting shape:

  • PLG/hand-raisers: attach yourself to a pilot AE and/or SDR and run it as a learning pod (not quota theater).

  • Outbound: consider an SDR+AE sequence (or a hybrid rep) depending on deal complexity.

  • In very early stages: use founder/CS/support to close a subset of deals until the motion is proven. Build a hiring sequence that enables A/B testing: if feasible, hire two reps close together to avoid “one data point” dependence.

  • Outputs: Team design + hiring plan table (roles, timing, success criteria, risks).

  • Checks: The plan creates comparability (two reps or comparable cohorts) and protects learning time.

  1. Write role scorecards (hire for product depth + learning ability)
  • Inputs: Motion spec; team design; customer/technical context.

  • Actions: Draft scorecards for each role (AE/SDR/hybrid). For technical products, set a “PM-like” bar: reps should demonstrate product intuition, curiosity, and the ability to earn engineer trust. Translate insights into “must-have signals” + “red flags”.

  • Outputs: Role scorecards + evaluation rubric.

  • Checks: Scorecards are specific enough that two interviewers would rate candidates similarly.

  1. Build an interview loop with practical tests
  • Inputs: Scorecards; references/TEMPLATES.md (interview kit).

  • Actions: Define stages, interviewers, and exercises (e.g., mock discovery, objection handling, written follow-up email, product deep-dive, “explain to 10 engineers” test). Add structured scoring and a debrief protocol to reduce gut-feel hiring.

  • Outputs: Interview plan + question bank + score sheet.

  • Checks: Every interview maps to a scorecard signal; pass/fail criteria are explicit.

  1. Create onboarding + ramp plan (and a simple management system)
  • Inputs: Motion spec; expected pipeline sources; enablement assets (or create minimal ones).

  • Actions: Build a 30/60/90 plan: training, shadowing, call reviews, pipeline targets, activity guardrails, and demo/pilot readiness. Define weekly cadence (pipeline review, call coaching, experiment review). Preserve the “A/B test humans” approach by tracking rep-to-rep differences and diagnosing process vs person.

  • Outputs: Onboarding plan + ramp targets + coaching cadence + metrics list.

  • Checks: Ramp targets are measurable; coaching loop is scheduled; “definition of done” exists for each phase.

  1. Quality gate + finalize
  • Inputs: Draft pack.

  • Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Add Risks / Open questions / Next steps and identify what would change the hire/wait decision.

  • Outputs: Final Sales Team Build Pack.

  • Checks: A stakeholder can approve the plan and start hiring this week (or confidently defer with clear milestones).

Quality gate (required)

  • Use references/CHECKLISTS.md and references/RUBRIC.md.

  • Always include: Risks, Open questions, Next steps.

Examples

Example 1 (first AE hires):

“Use building-sales-team . We’re seed-stage B2B SaaS. Founder has closed 12 customers; last 60 first meetings → 14 closed-won (~23%). ACV $12k. We want to hire our first AEs. Output: a Sales Team Build Pack with readiness gate, hire-two plan, role scorecards, and interview loop.”

Example 2 (PLG → PLS pilot):

“Use building-sales-team . We have steady inbound hand-raisers from our product. We want a pilot AE/SDR pod to close mid-market upgrades. Output: team topology, hiring sequence, and a 30/60/90 ramp with coaching cadence.”

Boundary example:

“We have no repeatable sales motion or ICP yet—hire a VP Sales to ‘figure it out’.”

Response: recommend founder-led discovery/validation first (use founder-sales ), define readiness milestones, and return to this skill once a motion can be written down and measured.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

personal-productivity

No summary provided by upstream source.

Repository SourceNeeds Review
General

kubectl

No summary provided by upstream source.

Repository SourceNeeds Review
General

obsidian-dashboard

No summary provided by upstream source.

Repository SourceNeeds Review
General

finding-mentors-sponsors

No summary provided by upstream source.

Repository SourceNeeds Review