A Demo Is a Re-Audition When They Have Already Said No

I was brokering a partnership between two clients of mine. One had built an internal tool for a technical operations problem. The other was a services firm with deep credibility in exactly that market. On paper it is the obvious pairing: one side has the product, the other has the access.

I spoke to the services firm's founder, who liked the idea and proposed a sequence — technical demo first, with his specialists in the room, then a product conversation, then a joint go-to-market plan. That struck me as sensible. Demo first, then GTM. You cannot plan a market approach for a product nobody in the room has seen.

I took it back to the product side's chief executive expecting agreement. He said no, and his reason reorganised how I think about sequencing.

The objection I didn't see coming

His point was not that the product wasn't ready. It was that the specific engineers who would sit in that demo had already evaluated the tool once and passed on it. Showing them an early build again invites a second rejection, and a second rejection would land on his own build team — the people who made the thing — as confirmation that the work was not good enough.

He was not making a product-readiness argument. He was making a morale argument about a team that was not in the room, would never be in the room, and would nonetheless carry the outcome.

I had not weighted that at all. I was optimising for the shortest path to a commercial conversation. He was protecting the people who have to still be motivated on the Monday after.

What we did instead

We agreed to write the functional and non-functional requirements for the solution first, and only then take something to the partner — to the founder, during a scheduled visit, rather than to the technical team that had already declined.

The substitution is small and the effect is not. A demo asks is this good enough? A requirements document asks is this the right thing to build, and what would you need in it? Same two parties, same product, opposite posture. One is an evaluation. The other is a co-design.

And it does something else that I only appreciated afterwards: it lets the build team find their own gaps before anyone external does. Writing down what the thing must do surfaces every place it currently doesn't, privately, in their own document, on their own terms. That is a completely different experience from having the same list read back to you by a stranger who is deciding whether to work with you.

The generalisable version

When you are re-approaching a party that has already said no, a demo is a re-audition. Lead with a requirements document instead.

The supporting rules I would now apply without thinking:

• Ask who carries the outcome of the meeting, not just who is in it. The people most affected by a rejection are frequently the ones who never attend. In an internal-build situation that is almost always the engineering team, and their sponsor is the only person who can see the risk clearly. When he objects on grounds that sound soft, that is usually the reason.
• Change the audience as well as the artefact. Going back to the same evaluators who declined is asking them to publicly reverse themselves. Going to their principal, with a different document, gives everyone a face-saving route to yes.
• When brokering between two parties, you do not own the sequencing. I had a plan endorsed by one side and assumed it was the plan. It wasn't. As the intermediary my job was to carry a proposal, not to have already agreed one — and to hold the second party's constraint as seriously as the first party's preference.
• Read the objection for its category before you argue with it. "Not yet" that means not ready and "not yet" that means not to them look identical and need entirely different responses. I nearly answered a relationship objection with a product-readiness argument.

Where this goes wrong

Requirements-first is also the perfect disguise for avoidance. A document nobody has committed to reading, with no date, is procrastination that looks like diligence — and I have a documented weakness for exactly that failure mode. The version that works has both ends nailed down: a named reader and a fixed window, driven by an external calendar rather than my own.

The honest counter-argument, too: sometimes the first rejection was simply correct, and no amount of reframing fixes a product that does not solve the problem. Requirements-first has a useful property here — if writing down what the solution must do reveals that the existing build is nowhere near it, that is the answer, and it arrives before anyone has spent a meeting discovering it in public.

The addendum: the artefact was the smaller half

Two days later the same thread moved again, and it corrected my own summary of it.

First, the sponsor's caution held up. He restated the objection in plainer terms — they rejected us before — and deferred the whole conversation to a scheduled executive visit. The requirements-first framing survived contact, which is the only evidence I actually have that it was right.

Then, the day after that, the decision went somewhere I hadn't predicted: skip the previously-rejecting team entirely and build a purpose-made demo for the visiting principal.

Read against the piece above, that looks like a reversal. It isn't, and understanding why is the part worth keeping.

What I wrote as two parallel rules — change the artefact, and change the audience — are not parallel at all. The audience change is load-bearing. The artefact change was mostly a way of achieving it. Once the audience is genuinely different, a demo stops being a re-audition, because nobody in the room is being asked to reverse a position they took in public. The thing that made the original demo dangerous was never the demo. It was who was watching.

So the rule is sharper than I first wrote it:

When re-approaching a no, change the audience first. Then choose the artefact that suits the new audience. A requirements document suits evaluators you need to bring alongside. A demo suits a principal who has never seen the thing and is deciding whether the partnership is interesting. Leading with the artefact question — demo or document? — is asking the second question first.

The test that distinguishes a legitimate change of approach from a relapse: has anyone in the room previously said no to this? If yes, you are re-auditioning regardless of what you bring. If no, you're presenting to a new audience and the old constraint doesn't apply. I nearly recorded my own reversal as inconsistency, when it was actually the rule working — just not the rule I thought I'd written.