Founding Sales for Founder-Led B2B Selling
Build and diagnose founder-led B2B sales using Peter Kazanjy's public method.
Based on Peter Kazanjy's public method.
Not affiliated with or endorsed by Peter Kazanjy. Each step cites the public work it comes from: 3 sources.From free-pilot interest to paid proof
Identifies the missing sales proof and makes a paid engagement the next founder experiment.
Illustration from the skill's worked example, not a recorded run.
What it does
When your agent should reach for this skill.
Use this skill when a founder or first seller needs to acquire early B2B customers, diagnose stalled selling, prepare customer-facing materials, or transfer a working sales motion to other people. Its central deliverable is a sales working packet: an evidence-based stage assessment, the assets needed for the next experiment, and a review plan. Scale the packet to the user's request rather than producing every possible asset. 12
Treat selling as a process the founder discovers, tests, documents, and teaches. A fundraise, enthusiastic pilot, or experienced sales hire does not establish a transferable motion. Start with the earliest missing proof, including delivered customer value, and make that proof the purpose of the work. Read the relevant sections of the method before drafting. 2
This package uses public presentations, an interview, and a website overview. It excludes book text. References distinguish source-backed guidance from package conventions for making the work reviewable. Citations identify the method's basis; customer claims still need customer evidence. See references/sources.md.
The method
11 steps, restated from Peter Kazanjy's public work. Numbers link to the sources.
1Bound the assignment
Identify the requested asset, product, target buyer, available evidence, price, and constraints. Record missing inputs as questions or assumptions. Use the scope and evidence fields in templates/output-template.md; do not invent traction to make a draft persuasive.
2Find the earliest unproven stage
Separate problem discovery, demonstrated value, payment, repeatable sales, and transfer. Include implementation results when judging progress. Choose one next proof and an observable exit condition using the maturity rules in references/method.md. 2
3Define a narrow customer profile
Specify organizational conditions, pain indicators, and relevant people. Separate the user, champion, and budget authority. Mark inferred fit and timing as unverified. Apply references/method.md before selecting prospects. 3
4Construct a commercial narrative
Connect the current workflow, its consequences, inadequate alternatives, the proposed change, and supporting evidence. Include the buyer's personal stakes when relevant. Label estimated economics and retain their inputs using references/method.md. 3
5Prepare only the necessary assets
Derive an outreach draft, presentation outline, or call plan from that argument. Keep each asset directed toward its next commitment. Follow templates/output-template.md and compare the transformation in examples/worked-examples.md.
6Plan discovery before demonstration
Research available facts, set a meeting objective, and prepare branches about current practice, specific failures, consequences, and urgency. Let answers change the conversation. Use references/method.md, especially its guidance for prospects who do not acknowledge pain. 3
7Show the relevant solution and ask for progress
Connect demonstrated capabilities to acknowledged problems. Request a specific next meeting, evaluation, or purchase suited to the stage. Capture the buyer's response using the conversation and commitment fields in templates/output-template.md. 23
8Carry the agreement into customer success
Record procurement steps, implementation ownership, a baseline, and a business outcome to validate with the customer. Payment and usage answer different questions. Consult references/method.md before counting a deal as proof. 2
9Diagnose the bottleneck and revise
Review activity, stage progression, objections, and delivered outcomes together. Distinguish poor fit, weak explanation, and product or implementation failure. Choose a focused next test using references/method.md, retaining uncertainty when evidence is sparse. 3
10Transfer only a demonstrated motion
If justified, define seller stage fit, training, supervision, and independent execution criteria. If premature, explain the missing proof and prepare the founder's next experiment. Apply references/method.md rather than treating hiring as a cure for discovery problems. 23
11Review and deliver
Run checklists/review-checklist.md, resolve failures, and provide the requested packet with assumptions, evidence gaps, owners, and a next review date. Mark unused sections as premature or outside scope; preserve useful drafts without implying they have been tested.
Worked example
How the method plays out on one case.
1: A free pilot mistaken for a sales motion
Scenario
DispatchLoop routes delivery exceptions for regional operators. Three friendly pilot customers use it without paying. Two report fewer unresolved exceptions, but there is no agreed baseline. The founder wants an outreach email and a job description for a VP of Sales.
Weak first draft
DispatchLoop is an AI-powered logistics platform for all transportation companies. Our pilots love it and we save every operator 50% of dispatch costs. We are hiring a VP of Sales to establish our go-to-market strategy and close enterprise accounts. Our outreach will say: Want to see the future of logistics? Book a demo of our intelligent platform.
The draft turns sentiment into an outcome claim, defines an unusably broad market, skips the willingness-to-pay question, and assigns discovery of the motion to a new leader.
Improved working packet
Stage assessment: Value creation remains incompletely evidenced. Free adoption is observed, customer reports of improvement are reported, and willingness to pay is unknown. Validate a business result with the existing pilots while preparing founder conversations about a paid engagement. Do not call the motion repeatable or publish the 50% claim. 2
Initial profile hypothesis: Regional delivery operators with dispatch staff manually assigning recurring exceptions across several routes. Start with the operations manager responsible for resolution and establish who approves software spending. Route expansion is a possible timing signal, subject to discovery. Exclude operators with rare exceptions or an existing system that resolves the problem satisfactorily. 3
Value argument: Dispatchers currently coordinate exceptions through calls and spreadsheets. Delays can leave ownership unclear. DispatchLoop proposes routing an exception to an owner and surfacing unresolved work. The prospect must confirm the current process, cost, and gap before the founder presents the solution. 3
Illustrative economics: If discovery validates 40 monthly hours of avoidable coordination and a $30 hourly labor rate, the capacity-value estimate is $1,200 monthly. At a proposed $400 monthly price, the gross capacity value is three times the fee. This is not $1,200 of cash savings: released time, adoption, and implementation effort remain unverified. The calculation is a package convention for making the business case inspectable.
Outreach draft, assuming the expansion signal is verified:
Subject: Exception handoffs after your route expansion
Hi Maya, your announcement describes three added delivery routes. Are dispatchers still assigning delivery exceptions through calls and spreadsheets? DispatchLoop routes each exception to an owner and shows unresolved work. We are testing whether that reduces coordination time. Would a 20-minute conversation about your current exception process be useful next week?
Discovery branches:
- If coordination is manual, ask for the last exception that remained unresolved and who handled it.
- If the current tool works well, ask what remains unsatisfactory. Stop the pitch if there is no relevant gap.
- If ownership is unclear, ask what the delay caused and how frequently that happens.
- If the pain matters, ask who would evaluate a change and approve payment. 3
Demo and commitment: Walk through detection, assignment, escalation, and resolution of one exception matching the prospect's account. Summarize the acknowledged gap, then ask whether a defined paid evaluation would be appropriate. Confirm procurement and implementation responsibilities before treating agreement as a sale. 23
Next experiment: The founder and pilot operations leads establish a baseline and measure coordination time and unresolved exceptions over an agreed four-week window. In parallel, the founder conducts six conversations with independently qualified non-beta accounts. The six-call batch and four-week window are illustration choices, not Kazanjy thresholds. Review whether customers validate useful improvement and whether any qualified buyer agrees to a paid engagement. If outcomes disappoint, investigate delivery before adding more prospects. 23
Hiring decision: Defer the VP role as a mechanism for inventing the motion. If appointment setting or onboarding constrains learning, consider scoped support while the founder keeps ownership of selling and method development. 2
Rules that made the difference
Separating value creation from value exchange removed the false claim that free pilots proved sales readiness. Narrowing organization and persona improved qualification. Discovery preceded screens. The economics separated capacity from cash. The next experiment paired payment learning with delivered value instead of using a hire to conceal uncertainty. 23
1 more worked example in examples/worked-examples.md.
What's in the package
7 files, pinned at d5668a9. Open any file on GitHub.
SKILL.mdEntry point the agent loads: when to use the skill and the procedure.6,081 bytesLICENSEApache-2.0 license.10,756 bytesreferences/method.mdThe method in full, step by step, with citations.16,369 bytesreferences/sources.mdEvery public source the method is built from.2,098 bytesexamples/worked-examples.mdWorked examples showing the method applied end to end.9,364 bytestemplates/output-template.mdThe output format the agent fills in.9,139 byteschecklists/review-checklist.mdChecks the agent runs before handing back the result.6,830 bytes
Sources
The public work this skill is built from. Read Peter Kazanjy's originals.
- Founding Sales: The Founder Led Sales and Startup Sales Handbook URLfoundingsales.com
- Peter Kazanjy, Founder-Led Sales: A design pattern for iterative startup GTM development and execution URLdocs.google.com
- Founders: Here's how to get your sales pitch in ship-shape, Peter Kazanjy, In Depth podcast and public transcript URLreview.firstround.com
The skill file also covers: Files in this skill. Read the full SKILL.md.
Edge wrote this skill from Peter Kazanjy's public writing and talks listed above. It is not affiliated with or endorsed by Peter Kazanjy. If something misrepresents the method, write to [email protected] and we will correct or remove it.