Discovery, demo, POC, objections, and field execution.
55 min4 lessons3 retrieval drills
The promise
What you will be able to do by the end of this module
Run a discovery that produces a POC scope in the customer's own words, and know which sentences lose deals.
Run a discovery that ends with a POC success criterion written in the customer's own words.
Volunteer a limitation before it is discovered, and understand why that purchases belief in everything else.
Use the vendor-silent list as an asset rather than improvising numbers that will be checked.
Refuse a feature-grid race and redirect to a whiteboard where you can actually differentiate.
Say a credible no, so that every yes you give is worth more.
Start from what you already know
Product knowledge is the entry fee. The differentiated skill is running a room: asking the question that reframes the problem, admitting a limit before it is discovered, and leaving with a written success criterion.
01
Discovery
Move from pain to measurable change
Ask how work happens today, why it matters, what must remain, who decides, and how success will be measured. Then choose a small number of cross-product workflows that prove the target operating model.
Current state: tools, handoffs, manual steps, failure modes.
A strong enterprise demo proves visibility, automation, and support as connected workflows. Start with the customer's problem, use realistic data, make the governance visible, and close with measurable outcome.
Suggested arc
Discover an asset -> detect risk -> remediate safely -> support the user -> record the result.
Define success before installation. Limit scope, include representative complexity, test failure paths, record gaps honestly, and end with a scored recommendation rather than a pile of screenshots.
Use 4-6 agreed success criteria.
Name owner, evidence source, target, and deadline for each.
Separate product gap, configuration gap, and process gap.
Convert the result into a rollout architecture and mutual action plan.
04
Credibility
Be fluent enough to be honest
Say what the official source supports, label vendor outcome claims, and distinguish facts from design judgment. When a feature is version-, license-, OS-, or integration-specific, say you would validate it in the current documentation and POC.
Each item is tagged with how far it can be trusted. Verified means checked against official documentation; field means it is our recommendation, not a vendor claim; unpublished means NinjaOne does not state it at all.
Volunteering a limitation buys credibility on everything else
field
Background Mode not launching GPU-dependent apps, HP Mega RAID exclusion, undocumented rate limits — each disclosed unprompted purchases belief in the claims you do make. This is the highest-return habit in technical selling.
The vendor-silent list is an asset, not a weakness
field
Ring sizes, soak durations, rate limits, and exact backup retention are undocumented. An SE who says 'the vendor does not publish that, here is what I would run and why' outperforms one who improvises a number and gets checked.
A POC without a written success criterion is a free trial
field
The criterion should be a testable statement with a number and a date, agreed in writing before access is granted. Without it, success is redefined at the end by whoever is least happy.
The whiteboard beats the demo for a first technical meeting
field
A demo makes them a spectator; a board makes them a participant. The moment they pick up the marker they are designing their environment with your product in it.
Discovery
Ask these, then listen
“What has to be true in ninety days for this to have been worth it?”
Listen for: This is the POC scope, in their words. Write it down verbatim.
“Who else has to agree, and what do they care about?”
Listen for: Surfaces the absent decision maker before you build for the wrong audience.
“What would make you not do this?”
Listen for: The real objection, offered voluntarily. Most SEs never ask.
Demo path
Three moves, in this order
1
Nothing. Draw the board first.
“Can I steal your whiteboard for ten minutes?”
2
Only the two or three things they described as painful.
“You mentioned patch evidence — here is only that.”
3
The evidence trail.
“This is what you hand the person who asks you to prove it.”
Objection handling
What they say, what you say, how you prove it
“Just send us a feature comparison.”
I can, but it will not tell you much — everyone's grid says yes. What decides it is how the platform behaves at your scale. Give me twenty minutes at a whiteboard first.
Proof method: A feature grid is a race to the bottom. The board is where you differentiate.
“Can it do X?”
Sometimes the honest answer is no, or not the way you mean. Say so, then say what it does instead and let them judge.
Proof method: One credible no makes every yes worth more.
Where SEs blow it
Do not say these
Do not answer a capability question you are unsure of. 'I will confirm and come back today' costs nothing; a wrong yes costs the deal.
Do not demo everything you know. Demo only what they described as painful.
Do not leave without a written success criterion and a photograph of the board.
From NinjaOne's channel
Watch it explained
Short clips from NinjaOne's own channel that reinforce the mechanics above. Each one says why it is here and what it backs up. These are supporting context, not product demonstrations — the sourced claims stay in the mechanics section.
Why this is here: Objection handling as a discipline rather than improvisation.Watch on YouTube ↗Why this is here: Translating the board you drew into the language of the person who approves the spend.Watch on YouTube ↗Why this is here: Keeping the success criterion alive after the POC closes.Watch on YouTube ↗
Retrieval practice
Rapid fire
Answer aloud before opening each response.
01What is a good success criterion?+
A measurable outcome with a baseline, target, evidence source, owner, and deadline.
02How many demo stories?+
Usually three connected workflows are stronger than a feature marathon.
03How do you handle an unknown?+
State the boundary, identify the authoritative source, and make it a POC validation item.