Build it on their wall, one question at a time.

Twelve moves that take a blank whiteboard to a complete picture of what NinjaOne does — without ever presenting. Ask, draw, validate, repeat.

The twelve moves

Ask. Draw. Validate. Repeat.

Step through it. The board on the left builds exactly as it would on a real wall — nothing is erased, and each mark is the answer to the question above it. Every move applies to everyone except step 11, which is MSP-only and should be skipped for an enterprise buyer.

Frame · step 1 of 12

Draw the frame before the content

1 · Ask this first

“If this whiteboard were your environment, what are the big pieces? Do not be precise — just name the chunks.”

2 · Listen for

They name tools ("we have Intune and a ticket system")Tool-centric org. They will evaluate you on feature parity. Move them to outcomes early.
They name teams ("desktop, server, security")Org-chart-centric. Your board must show delegation and scope or they will not believe it fits.
They name pain ("patching is a mess")Best case. Start the board at the pain and build outward.

3 · Now draw

One horizontal line across the middle third of the board. Nothing else.
Write ESTATE on the far left, OUTCOMES on the far right.
Leave the entire middle empty and say you will fill it together.

4 · Say it roughly like this

I am going to keep this simple. Over here on the left is everything you own — every device, every user, managed or not. Over here on the right is what the business actually asks you for: keep it running, keep it safe, prove it. Everything in the middle is the machinery that gets you from left to right. That middle is what we are going to draw together.

5 · Validate before moving on

“Before I fill in the middle — is there a piece of your world that does not fit on either end of that line?”

Why this move

An empty frame creates a container the customer wants to fill. It also quietly establishes that tools are a means, not the subject.

Where SEs blow it

Do not draw the NinjaOne console first. If your product appears before their problem, every subsequent question sounds like a setup.

Before move one

Open with a story, not an agenda slide

Do not open with an agenda or a company slide. Open by asking for the board and telling one short story about someone like them. This is the whole thing said out loud, before a single mark is made:

Before we look at any product, can I steal your whiteboard for ten minutes? I want to draw how I think your environment works — can you correct me as I go along? You know this place and I do not, so the corrections are the useful part of this meeting. Last month I did this with a team about your size, and forty minutes in their own service desk lead pointed at the board and said 'that gap is why we are here.' I would rather find your version of that gap than show you features you do not need.

Permission

“Can I steal your whiteboard for ten minutes?”

Consent turns the room from audience to collaborators.

Invite correction

“Can you correct me as I go along?”

A direct request for participation. It asks them to do something rather than announcing your own fallibility, and a customer who corrects you is engaged — one who nods is leaving.

Proof it works

“Their own service desk lead pointed at the board.”

A short story about a peer beats any claim about your product.

Frame the goal

“I would rather find your gap than show you features.”

Signals you are not here to spray capabilities. Buys you the room.

After the room

The board is the deliverable

Photograph it before you leave

The board is the artefact. Photograph it with their additions visible and send it within the hour with nothing added — no logo, no product names they did not say. It becomes the reference document for every later conversation and it is in their handwriting.

Transcribe the corrections, not the drawing

Your follow-up should lead with what they corrected. 'You told me the unmanaged count is closer to 400 than 150' proves you listened. Re-describing your own diagram proves you did not.

Convert the last answer into POC criteria

The answer to the final question is the POC scope. Write it as a testable statement with a number and a date, get agreement on it in writing, and refuse to expand it later without trading something.

Know which box you cannot defend

Every board has one box you drew faster than the others. Find it before the next meeting and either learn it properly or say plainly that you will bring someone who owns it.

Verified sourcesNinjaOne policies: types, inheritance, and assignment ↗NinjaOne policies: condition types breakdown ↗Windows patch management: performing ring deployments in NinjaOne ↗NinjaOne IT Asset Management ↗NinjaOne Unified Backup ↗

Whiteboard tips

Put the marker in your hand, not the clicker

A demo makes the customer a spectator. A whiteboard makes them a participant. The moment they stand up and correct your drawing, they have started designing their own environment with your product in it — and they will defend that design internally when you are not in the room.

01Ask before you draw. Every mark on the board should be the answer to a question you just asked.
02Draw their estate, not your architecture. If the board could be drawn identically for any other customer, you are presenting, not discovering.
03Validate out loud after every panel. 'Did I get that right?' is the highest-value sentence in the session.
04Leave the mistakes visible. Crossing something out because they corrected you is proof you were listening.
05Never write a product name until the customer has described the problem it solves. Products go on the board last, as labels on boxes that already exist.
06Stop drawing when they start drawing. That is the win condition.