Repair a Technical Demo Scheduled Before Discovery
Turn a premature demo into a useful conversation without embarrassing buyers.
A prospect books a technical demonstration, invites several people, and sends no use case. Do not punish a group for skipping discovery. A broad request often reflects a busy calendar or uncertainty about where to begin. Your task involves turning a scheduled hour into a working conversation. The opening minutes matter more than a polished introduction because those minutes decide whether each screen answers a shared question or becomes another item for private judgment.
Arrive with a flexible plan, rather than a fixed tour. Prepare two or three possible workflows drawn from public conversation so far, then treat each one as a prompt instead of an assumption. A group with finance, operations, and technical people often wants to discuss approvals, source data, or a manager review. Ask which question would make the hour useful. Use plain language: “Which work question should guide our time today?” Wait for answers before sharing a screen.
When a group replies, “Give us an overview,” ask one more question. “At the end of our hour, what would each person need to understand before deciding on another conversation?” A finance lead might want clarity about effort around an approval step. An operations leader might want to see a handoff. A technical reviewer might need to understand where a source fits in a proposed flow. Listen for overlap. A strong first workflow often sits where two concerns meet.
Choose one user and one moment of work. “A manager reviews late requests before a weekly meeting” offers a usable frame. “Show reporting” leaves scope undefined. A defined moment gives a presenter a reason to show only a few screens. Say the scenario aloud and ask for correction. “Let us use a manager preparing for a Tuesday review. Does such a scenario match the question your group brought?” A correction before a demonstration saves everyone’s attention.
In a fictional practice situation, a buyer brings a finance director, operations manager, and systems analyst to a 60 minute session. The seller begins, “We have several areas available. Which decision would make this hour worthwhile?” The finance director says her group needs fewer manual checks. The operations manager says requests often wait during a handoff. The analyst asks where existing data enters the process. The presenter hears a shared issue: a manager needs to review delayed requests before a weekly planning meeting.
The presenter confirms a scenario in one sentence. “We will follow one manager reviewing delayed requests, then pause where an existing source enters.” The finance director agrees. The presenter shows how a manager reaches a review, looks at one request, and sends a question to another team. The presenter does not open unrelated configuration areas. After source handoff appears, the analyst asks a question. The group now has enough context for focused discussion instead of separate reactions to a general tour.
Use pauses as part of a demonstration. After a meaningful step, ask what feels familiar and what feels unclear. Do not ask whether everyone likes a screen. “Where would this step fit into your current review?” invites a practical answer. “What would need to be true for this handoff to work?” exposes missing owners, source questions, or process differences. Capture answers in a visible note. The note keeps discussion grounded when one attendee pulls attention toward a different topic.
Control scope without sounding defensive. When someone asks about an unrelated feature, acknowledge the question and connect the request to a decision. “I have noted your question. Does an answer affect whether this manager review deserves further work?” If yes, give a short answer or agree on a later session with an appropriate person. If no, place the topic in a recap. Such language protects the chosen workflow while showing respect for the person who raised an issue.
Do not treat polite attention as interest. A quiet attendee might take notes, face another deadline, or wait for a colleague. Near the end, ask each person for one open question connected to the scenario. Leave space for an answer, then name what you heard without adding a conclusion. “Finance wants to understand preparation effort. Operations wants to compare a handoff with current practice. Systems wants to identify a source owner.” A factual recap helps more than a confident declaration about enthusiasm.
The next step should match an unresolved question. If a systems analyst needs a source owner, invite an owner to a working session. If finance needs a view of manager effort, ask for one current review example. If operations needs to compare handoffs, schedule a short process discussion with someone familiar with current steps. Avoid a vague offer to continue a demonstration. A named question, attendee, and purpose gives a group a reason to return.
Prepare a one page agenda before an unknown demonstration. Leave the first ten minutes open for selecting a scenario. Reserve a middle section for one workflow and pauses. Keep the final ten minutes for questions and recap. Do not send a long questionnaire before a call when a buyer already set a demonstration. A short note with one question is enough: “Which work question would you most like to test during our session?” An unanswered note should not prevent a useful opening conversation.
Practice disagreement. One person plays a finance lead seeking an approval example. Another plays an operations manager seeking a queue view. A third plays a technical reviewer asking about data. The presenter has four minutes to find one scenario with shared relevance. Review whether the presenter named assumptions, asked for correction, and set aside unrelated detours without dismissing anyone. Repeat with a group where no shared scenario appears. In such a situation, ending early with separate follow ups often respects time better than forcing a false purpose.
After a session, send a recap within the agreed time. Name the workflow shown, question from each attendee, missing information, and proposed next conversation. Do not attach a feature catalog. In a fictional practice situation, a presenter writes to a finance director, operations manager, and systems analyst: “We reviewed a manager checking delayed requests before weekly planning. The open question involves an existing source. If Sam, who owns source access, is available, I suggest a 25 minute session next Wednesday to map a handoff.” After the group confirms Sam’s availability, the presenter sends an invitation with this opening prompt: “Sam, which source should we map first?”
Practice these next
Treat accessibility as a product and user requirement worthy of early, detailed review.
Understand the workflow behind a requested feature before deciding how to respond.
Surface the work of change while a buyer still has time to plan.
Connect telemetry, incident response, and engineering decisions before showing dashboards.
Help a buyer compare open source and commercial options across support, ownership, flexibility, and cost.
Keep pre-sale support useful while recognizing when the buyer is asking for a project.