Part III · Sell, Deliver, and Compete — Chapter 15
Discovery, demonstration, and objections
The demo should be the answer to a diagnosis. If you show the product first, the buyer must guess why it matters—and every irrelevant feature creates another reason to hesitate.
A founder opens a first call by sharing his screen. Twenty minutes later he has shown permissions, dashboards, exports, integrations, and settings. The buyer says, “Impressive—send me the deck.” Neither person can state the costly workflow, what has already failed, who must approve a change, or how success would be measured. The founder demonstrated a product and discovered almost nothing.
Run the order the other way around: establish the frame, reconstruct reality, quantify consequences carefully, map the decision, summarize, and only then show the smallest relevant proof.
Contract for an honest conversation
Begin by making the meeting safe for truth:
We have thirty minutes. I would like to understand how this works today, what is failing, and how a decision would be made. If there is a fit, I will show the relevant part of our approach. If there is not, I will say so. Does that use the time well?
This is not a script to recite. It is an agreement on purpose, time, and permission to say no. It reduces the polite behaviour that fills weak pipelines.
Research beforehand so that basic questions do not consume the meeting. Then ask about an actual past event. “Walk me through the last time this happened” is more reliable than “Would you use a tool that did this?” The first retrieves behaviour. The second invites imagination and courtesy.
Climb the question ladder
The order below moves from fact to consequence without manufacturing fear.
| Layer | Job | Useful questions |
|---|---|---|
| Situation | Establish the actual process | What starts the work? Who touches it? volved? Which systems and hand-offs are in |
| Problem | Find friction and failure | Where does it slow, break, require rework, or create anxiety? What happened last time? |
| Implication | Trace real consequences | What did that delay affect? Who absorbed the work? What customer, cash, quality, or risk consequence followed? |
| Layer | Job | Useful questions |
|---|---|---|
| Desired outcome | Define a better state | If this were fixed, what would change? Which measure would move? |
| Decision | Map how change happens | Who approves, uses, reviews, pays, or can veto? What alternatives are being considered? |
| Commitment | Convert learning into an advance | What evidence is needed next, who owns it, and by what date? |
Implication questions are powerful and therefore easy to misuse. Do not inflate a nuisance into a crisis. Ask for frequency, baseline, and source. Separate measured loss from an estimate. If the buyer says a delay “costs lakhs,” ask how it is calculated. A buyer-derived number is not automatically accurate; it is an assumption until checked.
Listen for the personal sale as well as the business sale. The organization may care about throughput, cost, or compliance. The individual may care about workload, credibility, career risk, or being blamed for a failed change. Do not exploit that vulnerability. Address it by making implementation, ownership, and evidence clear.
Take notes with permission. At transitions, play back what you heard:
The present process uses three hand-offs. The monthly failure creates about two days of rework, although the cost estimate is still unverified. The operations lead owns the result, finance approves new spend, and the contract renewal in November is the decision window. What have I missed?
That summary is more useful than a clever question. It gives the buyer a chance to correct the record and gives you a shared basis for proof and proposal.
Demonstrate the result, then the mechanism
A useful demonstration starts with the agreed outcome, not the menu. Re-state the buyer’s three most important conditions. Show how the proposed approach handles those conditions. Then show the limits and the implementation path.
Use this sequence:
1. Recall: “You said the exception queue and audit trail are the two decision criteria.” 2. Show: demonstrate those flows with representative, authorized data. 3. Connect: explain what changes in the buyer’s process, who still performs judgment, and what does not change.
4. Test: ask the buyer to compare the proof with the current method and stated criteria. 5. Record: capture gaps, owners, and the next evidence required.
Never present a mock-up as a live capability. Never use customer data without permission. Never imply an integration, control, accuracy level, or delivery date that has not been established. If a proof of concept or pilot is needed, time-box it, define success and failure in writing, identify the decision that follows, and price or scope it so both sides have a real commitment.
The best demo can end with “this is not yet suitable for production.” That sentence may delay a sale and protect a career.
Treat objections as unpriced information
An objection is not a command to rebut. It may be a request for evidence, a misunderstanding, a hidden stakeholder, a true constraint, or a polite exit. Use four moves:
Listen → Acknowledge → Explore → Respond → Confirm
The explore step prevents you from answering the wrong problem.
| What you hear | What to explore | Responsible response |
|---|---|---|
| “Too expensive” | Compared with budget, another option, or the value at stake? | Check the economics; reduce scope, phase proof, or accept no |
| “Not now” | What must change, and is there a real trigger date? | Record the trigger or remove it from active pipeline |
| “We can build it” | Is capacity, maintenance, and opportunity cost understood? | Compare alternatives honestly; internal build may be right |
| “We need to think” | Which uncertainty remains and who else is involved? | Name the missing decision and supply only relevant evidence |
| “Security or legal will object” | Which requirement, reviewer, and review path? | Involve the reviewer; never bluff or promise approval |
| “Send a proposal” | What decision will it support, and who will read it? | Agree scope and criteria before writing expensive paper |
Some objections are conditions. If the buyer requires a control you do not have, the answer is not verbal agility. It is a product decision, a scoped remediation, a different provider, or no deal. If the buyer lacks authority, work with the contact to reach the right person; do not undermine the contact. If the buyer has no priority, do not invent one.
Objection prevention is better than late rebuttal. Surface risk yourself. Ask what would make adoption fail. Bring technical, finance, legal, security, and user concerns into the process while they are cheap. A deal that seems smooth because nobody difficult has seen it is not smooth; it is untested.
Close discovery with a written record: present state, evidence, assumptions, desired outcome, decision group, review path, risks, and next action. Send it promptly and invite correction. This document equips the internal champion and keeps your future proposal anchored to the buyer’s truth rather than your memory.
· SALES pp. 10–12 and 19–23 · ASC pp. 87–89 · TABLE pp. 13–16 · GE chs. 9 and 13. Questions and examples are adapted; source anecdotes and unsupported talk-ratio claims are not treated as evidence.