Direct Answer
A strong B2B SaaS demo is not a guided product tour and its purpose is not to collect polite yeses. It is a decision system that helps both sides establish whether a costly problem, credible fit, buying path, and workable next step exist. If they do not, an early and respectful no is more valuable than a trial that consumes onboarding, hosting, support, and customer-success time before churning.
In his MicroConf talk, Giant Rocketship founder Dustin Puryear builds that system across three stages: make the right demo easy to book, use discovery to demand evidence rather than agreement, and finish with an owned next action plus same-day follow-up. His sharpest operating rule is simple: show no more than three features, and let each one answer a problem the prospect has already demonstrated.
Watch the Talk
Video and framework credit: Dustin Puryear's MicroConf talk. Puryear is the founder and CEO of Giant Rocketship, a SaaS platform for IT service providers. Giant Rocketship's first-party history says he entered IT more than 20 years ago and founded his MSP in 2002. This article turns the talk into an independent operating guide; Puryear's comments about the peer group are practitioner observations, not published market benchmarks.
What "Get to No" Actually Means
Sales teams can accidentally optimize for agreeable meetings. The prospect nods, the presenter calls the demo successful, and nobody establishes whether the problem is frequent, expensive, owned, urgent, or funded. The result is not a pipeline. It is deferred ambiguity.
Puryear's economic argument is specific to B2B SaaS: a bad customer can be unusually expensive. The vendor may configure an account, migrate data, train users, pay infrastructure costs, answer support questions, and absorb custom requests before learning that the product was never a serious fit. MicroConf's current sales guidance reaches the same practical conclusion from another angle: indecision and ghosting are often worse than a direct no, leads should be qualified before a demo, and the call should demonstrate value rather than train the buyer on every control.
| Outcome | What it tells you | Best next step |
|---|---|---|
| Qualified yes | Problem, evidence, stakeholder, timing, and implementation path align. | Start the agreed trial, security review, technical validation, or commercial step. |
| Qualified no | A durable mismatch exists and more persuasion will not fix it. | Explain the reason, point to a better route when useful, and close the opportunity cleanly. |
| Not yet | The fit may exist, but a trigger, budget, owner, or dependency is missing. | Set a real revisit condition and date; do not keep an immortal "maybe" in the forecast. |
| Unknown | The call produced opinions but insufficient evidence. | Assign one small evidence-gathering action or disqualify until the missing fact exists. |
Before the Demo: Make the Right Path Obvious
In Puryear's peer-review group, more than half of the reviewed companies made demo registration difficult to find, often hiding it on a contact page or deep in the footer. His recommendation is to make the demo call to action "loud and proud" across the site. That is a useful default for sales-led SaaS, but the verb matters less than routing the buyer correctly.
| Buying motion | Primary CTA | Where a demo fits |
|---|---|---|
| Enterprise or high-touch | Book a demo | Visible on product, solution, pricing, case-study, and comparison pages. |
| Hybrid | Start free and book a demo | Let smaller teams self-serve while routing complex accounts to sales. |
| Product-led | Start free | Reserve demos for high seat counts, compliance needs, migration, or procurement. |
| Early validation | Talk to the founder | State who the conversation is for and what the prospect will leave with. |
The page around the CTA should answer four questions before anyone gives up a calendar slot: who the product is for, which problem it solves, what typically makes an account qualified, and what the call will cover. Transparent boundaries help poor-fit visitors choose a self-serve plan, documentation, a partner, or a later conversation without feeling rejected.
Use a two-message reminder sequence
- Immediately after booking: confirm the date, timezone, meeting link, attendees, expected length, agenda, and reschedule route. Ask for one preparation item only if it materially improves the call.
- About 24 hours before: repeat the meeting link and expected outcome, list who should attend, and make rescheduling easier than silently missing the meeting.
Puryear says reminders were missing from almost every demo his group reviewed, including his own process before he corrected it. That is another practitioner observation, but the fix is inexpensive and measurable: compare qualified show rate before and after the sequence.
A Short Qualification Form That Does Real Work
Puryear argues that the form should let wrong-fit prospects self-select out. If a product is economical only for 500- or 1,000-user organizations, the ranges should not imply that a two-person company is the ideal buyer. The humane implementation is transparent segmentation, not artificial friction.
| Field | Why it earns a place | Routing example |
|---|---|---|
| Work email and company | Connects the meeting to an accountable organization. | Flag duplicates and route existing customers to support or success. |
| Role in the decision | Shows whether the user, evaluator, champion, buyer, or approver is attending. | Ask for the missing stakeholder only when their presence matters. |
| Users, locations, tickets, or another economic unit | Tests whether account scale matches the delivery and pricing model. | Offer self-serve for small accounts and sales-assisted evaluation for larger ones. |
| Problem to solve | Gives the seller a hypothesis, not a conclusion. | Route non-product questions to the right resource before the call. |
| Current process or system | Surfaces migration, integration, and status-quo competition. | Bring the right technical material or specialist. |
| Timing or trigger | Separates active evaluation from general research. | Use a later educational route when no buying trigger exists. |
A 30-Minute B2B SaaS Demo Cadence
Technical founders often start by sharing the product. Puryear says he made the same mistake: without context, the interface is visual noise. He recommends using a sales deck to pace the conversation and reinforce a consistent story, with the product appearing later as evidence.
| Time | Stage | What must happen | Exit test |
|---|---|---|---|
| 0:00-2:00 | Intro and agenda | Confirm time, participants, purpose, and the decision or ask at the end. | Everyone agrees on the call's destination. |
| 2:00-10:00 | Discovery | Test the problem, frequency, impact, workaround, owner, urgency, and evidence. | A material use case is demonstrated, not merely acknowledged. |
| 10:00-13:00 | Problem story | Connect their evidence to a brief, credible story about the problem and current alternatives. | The prospect corrects or confirms the problem model. |
| 13:00-17:00 | Business outcome | Explain the change the decision maker buys: less risk, cost, delay, interruption, or uncertainty. | The outcome maps to a priority the buyer owns. |
| 17:00-23:00 | Maximum three feature proofs | Show only the shortest product sequences that prove the stated outcomes. | Each proof resolves one discovery point. |
| 23:00-27:00 | Risk and objections | Address price, data, hosting, security, migration, support, and competition as relevant. | Unknowns have an owner and due date. |
| 27:00-30:00 | Ask and next action | Choose trial, technical validation, stakeholder review, proposal, later trigger, or no. | One owner, date, and success condition are recorded. |
Puryear suggests spending about 20% of the demo on the first slide because discovery matters more than slide velocity. Treat that as a heuristic, not a timer. If the buyer supplies enough evidence in four minutes, continue. If ten minutes produces no specific example, the call may already have found its answer.
Replace Agreement With Evidence
A prospect will often agree with a broadly worded problem because agreement is socially easy. Puryear's correction is to ask for an example. The sequence moves from a claim to a real event, then from the event to measurable consequences.
Problem hypothesis:
"Teams like yours often lose track of urgent tickets during handoffs."
Evidence question:
"Walk me through the last time that happened."
Diagnostic follow-ups:
- How often does it happen?
- Who notices first, and who owns the recovery?
- What is the current workaround?
- What did the last incident cost in time, risk, or customer impact?
- What has stopped you fixing it already?
- Why evaluate a change now?
- Who else must agree that the result is good enough?Silence is part of the method. Puryear describes deliberately leaving a noticeable gap so the prospect has space to enter the conversation. Use that pause to listen, not as a pressure tactic. Do not answer your own question, manufacture discomfort, or treat hesitation as consent.
Tell a problem story, not a generic problem statement
A statement such as "ticket management is inefficient" is too abstract to be memorable. Puryear recommends a story: the situation that exposed the problem, why the software was created, what it solved, and what it still does not solve. The admission of a boundary matters. It helps the buyer compare reality rather than a perfect marketing claim.
Decision Makers and Influencers Are Buying Different Things
Puryear observes that an influencer pictures themselves using the software, while a decision maker pictures the business operating without the recurring problem. A single demo often contains both, so the narrative needs business outcomes and concrete workflow proof.
| Stakeholder | Question in their head | Evidence to show | Avoid |
|---|---|---|---|
| Economic buyer | Is this worth the money and change? | Cost of status quo, expected impact, implementation load, risk, and ownership. | A feature catalogue without economics. |
| Operational owner | Will this remove a recurring problem? | Before-and-after process, alerts, exceptions, controls, and reporting. | Promising effortless adoption. |
| End-user champion | Will this make my daily work better? | Short workflow proof using a recognizable scenario. | Only executive-level abstractions. |
| Technical reviewer | Will it integrate, remain secure, and be supportable? | Architecture, data flow, access boundaries, logs, testing, and support model. | Improvised answers to security questions. |
| Procurement or legal | Can the organization contract for this safely? | Terms, pricing, data processing, security documentation, and timeline. | Introducing them after the planned start date. |
The Three-Feature Limit
In the Q&A, Puryear's answer to a founder with a large platform is direct: demo no more than three features. Discovery should influence which three, but the prospect should not be allowed to turn the call into an improvised technical expedition. Puryear recommends short 20- to 40-second product moments.
The useful unit is not a feature. It is a proof chain:
Discovery evidence
-> one relevant capability
-> visible result
-> buyer confirms meaning
-> return to the decisionFor example: "You said urgent tickets wait 30 minutes before assignment. Here is the incoming ticket, the skill-and-availability rule, and the assignment record. Would this remove the handoff you described, or is a control missing?" That is a product proof. A ten-minute settings tour is training.
Turn Every Repeated Objection Into a Reviewed Slide
Puryear recommends adding recurring questions to the deck: price, hosting, data, security, or any point that catches the presenter unprepared. The deeper principle is to turn sales conversations into a maintained evidence system. Do not hide objections. Answer them consistently, link to proof, and review them when the product or policy changes.
| Log field | Purpose |
|---|---|
| Exact buyer wording | Preserves the language prospects actually use. |
| Segment and stakeholder | Shows whether the objection belongs to a particular ICP or role. |
| Approved answer | Prevents improvisation and unsupported promises. |
| Evidence link | Connects the answer to pricing, architecture, policy, case study, or product behavior. |
| Owner and last reviewed | Keeps security, legal, product, and commercial answers current. |
| Deck placement | Decides whether to preempt the objection or answer it when raised. |
| Outcome | Records whether the answer resolved, delayed, or disqualified the opportunity. |
Competition belongs in this library too. Puryear warns founders not to claim they have none: doing nothing, continuing with spreadsheets, hiring another person, or using an adjacent tool are all alternatives. A credible comparison explains the conditions under which your product is the better fit and the conditions under which it is not.
A Same-Day Follow-Up That Preserves the Decision
Puryear calls post-demo work the graveyard in his peer-review group. His minimum is an agreed next action, a personalized email sent that day, and a follow-up sequence. Giant Rocketship's own later sales writing reinforces the process-first lesson: document what should happen after a lead arrives, then make the CRM execute that playbook.
Subject: [Company] - agreed next step for [problem]
Hi [Name],
Thanks for the clear discussion today. You described:
- Problem: [specific workflow or event]
- Evidence: [frequency, example, or impact]
- Success condition: [what must improve and how it will be judged]
What we confirmed:
- [Relevant capability and boundary]
- [Commercial, data, security, or implementation point]
Open item:
- [Question] - owner: [person] - due: [date]
Next step:
- [Action] - owner: [person] - date: [date]
- Decision criterion: [what makes this a yes, no, or later]
If I misunderstood any point, reply with the correction and I will update the record.
Best,
[Name]A nurture sequence should be finite and relevant: the promised recap, the evidence or answer requested, a useful case that matches the stated problem, and a close-the-loop message. Respect the recipient's expectations, applicable consent and privacy rules, frequency limits, and opt-out. Automation should preserve context, not create an excuse to pursue someone indefinitely.
Measure Decision Quality, Not Applause
| Metric | Why it matters | Warning sign |
|---|---|---|
| Qualified show rate | Tests CTA, form, routing, and reminders together. | Bookings rise while relevant attendance falls. |
| Pre-call disqualification | Shows whether poor fits receive a better route before consuming a slot. | Every form submission reaches the calendar. |
| Time to clear decision | Rewards honest yes, no, and not-yet outcomes. | Opportunities remain in "maybe" without a dated condition. |
| Next-step acceptance | Measures whether the call produced an owned action. | Seller sends proposals that nobody requested. |
| Trial activation and paid conversion | Connects the demo to actual use and purchase. | Many trials start but the promised workflow is never completed. |
| Onboarding effort | Reveals whether the segment is economical to serve. | Closed deals require repeated unplanned work. |
| Early churn and support burden | Tests whether qualification predicted customer success. | A high close rate produces weak retention or exceptional support load. |
| Recurring objections | Feeds product, documentation, pricing, and sales enablement. | The same surprise appears on every call. |
Build the Peer-Review Loop
The most transferable part of Puryear's method may be the group around it. Every two weeks, founders review a real sales demo, complete a shared form, and discuss the evidence. A small team can recreate the mechanism internally without exposing prospect data unnecessarily.
- Select one call. Obtain appropriate permission for recording and internal review, then redact secrets and unnecessary personal data.
- Score independently. Review CTA-to-call fit, discovery evidence, talk ratio, stakeholder coverage, problem story, feature relevance, objection handling, and next-step clarity.
- Separate observation from interpretation. "The buyer gave no example" is evidence. "The buyer did not care" is a hypothesis.
- Choose one change. Update one form question, slide, discovery prompt, proof, or follow-up rule before the next review.
- Check the next cohort. Measure whether the change improved show rate, decision clarity, activation, or customer quality.
Demo review scorecard (0 = absent, 1 = partial, 2 = clear)
[ ] Buyer and seller agreed on the agenda and final ask
[ ] Prospect supplied evidence of the problem
[ ] Current workaround and cost of inaction were understood
[ ] Relevant decision maker, champion, and reviewer were identified
[ ] Problem was told as a specific story
[ ] No more than three features were shown
[ ] Every feature mapped to discovery evidence
[ ] Material risks and objections had sourced answers
[ ] Competition included the status quo
[ ] Next action had an owner, date, and success condition
[ ] Same-day recap preserved the prospect's wordsVideo Chapters
- 00:00 - Dustin Puryear and the demo peer-review group
- 01:23 - Make the demo signup loud and proud
- 01:56 - Qualifying forms that let poor fits self-select out
- 02:56 - The reminder almost nobody sends
- 03:31 - Why the slide deck drives the demo
- 05:03 - The B2B sales demo cadence
- 05:22 - Why the agenda slide matters
- 06:22 - Why the goal is a no, not a yes
- 07:43 - Spend more time on the intro and discovery
- 08:29 - Use silence to make space for the prospect
- 09:27 - Problem story beats problem statement
- 10:01 - Decision makers versus influencers
- 10:48 - Turn recurring objections into slides
- 11:54 - Next action, same-day email, and follow-up
- 12:26 - Q&A: handling a large feature set
Bottom Line
The best part of Puryear's playbook is not a clever closing line. It is the refusal to confuse activity with progress. Make the correct buying path visible, qualify with transparent criteria, discover with evidence, tell a specific problem story, show three relevant proofs, answer objections from a maintained source, and leave with an owned decision.
A good demo can end in a paid next step. It can also end with a clear no that protects the prospect and your team. The failure state is the comfortable middle: a long product tour, vague enthusiasm, no accountable next action, and another opportunity that nobody is willing to close.
Sources and Link Map
- Original MicroConf talk: SaaS Sales Demos: Why Getting a No Is Better Than a Yes - primary source for Dustin Puryear's peer-group observations, cadence, discovery method, three-feature limit, and follow-up recommendations.
- MicroConf: How to build a lean SaaS sales machine - first-party guidance on qualification, concise demos, value-led selling, follow-up, and documenting the playbook.
- MicroConf: Efficient outbound sales for SaaS - first-party guidance on ICPs, founder-led demos, using sales conversations as product and marketing evidence, and trial conversion.
- Giant Rocketship: official website - current product and company context.
- Giant Rocketship: Dustin Puryear background - first-party account of his IT, MSP, and SaaS history.
- Giant Rocketship: Build a follow-up playbook first - Puryear's later process-first argument for documenting follow-up before automating it.