Who Should Not Buy Competitor Demo Research

TrustRadius asked 1,862 B2B technology buyers how they bought software last year. The average shortlist ran to 2.7 products.

That number is why this page exists. Your competitive set is not your category. It is the two or three names that sit beside yours on a list most buyers have half drawn before they speak to anyone, and naming those companies is the first thing a competitor demo project needs from you.

Three kinds of company should not commission this work: one that cannot name its competitors, one that cannot say what it wants to learn, and one that wants the software itself tested. The first two are not ready yet, and both can be. The third wants a different service.

If You Cannot Name the Competitors, Start There and Not Here

We can build the list. Sometimes we do, out of your own deal data and the market around it, and it is a perfectly good piece of work. It is still better when the names come from you.

The reason is not effort. A competitor list is a claim about who you lose to, and a claim you did not make yourself is one you can disown later. When the findings land and one of them stings, a list we wrote becomes the thing under discussion, and the project turns into an argument about scope instead of an argument about price, product, or pitch.

A real competitor is a name that shows up on a buyer’s shortlist beside yours. In the same TrustRadius survey, most of those buyers had heard of the product they eventually chose before they started researching at all, and two thirds bought their first choice.

Which is a small, early, specific set, and nothing like a category map. The count goes wrong in both directions from there. Teams overcount by listing everyone with a similar landing page. They undercount by leaving out the incumbent spreadsheet, the internal build, and the option of doing nothing for another year.

Once the names exist, the work starts before any demo is booked. The page below is from our public example board: every vendor gets a profile built out of public record first, so the questions we carry into the call are not questions their website already answers.

None of that can begin from a category. It begins from a list.

If you do not have one, the work to get one takes an afternoon and it is yours to do. Read the last twenty deals you lost and write down who took them. Ask three reps which name they hear most in a competitive call. Go back through recent discovery recordings and note which vendors your buyers bring up unprompted. If the same two or three names keep appearing, that is your set. If nothing repeats, you have a positioning question rather than a research project.

If You Cannot Say What You Want to Learn, You Get Coverage Instead of Answers

A list of names is half of what a project starts from. The other half is the part people arrive without.

Every project opens with a kickoff that settles the competitors, the objectives, and the specific questions we will ask. We can help shape the questions. The objectives have to be yours, and they are load-bearing in a way that sounds procedural until you watch it happen. A demo occurs once. The questions we carry into that room are the only questions asked in it, and a vendor who has just given a 90-minute walkthrough does not schedule a second one to cover the thing nobody thought of. An objective missing at kickoff is not a thinner report. It is a conversation that never happened.

The objectives page above is from the same public example board, and the five stages beside it are the shape every project follows. What changes between projects is the question list, and the question list is where a project is won or lost before anything is booked.

A wish and an objective read almost the same on a kickoff call. Understand their pricing is a wish. Find out what their floor is on a 200-seat deal, what conditions ride on it, and how long the quote stays good is an objective, because it names something specific enough to change what you do next.

Chief Mystery Officer

Mystery Demo

The difference between a good demo and a useful one is a list. Without it you get the tour the vendor gives everybody, which is well made and tells you nothing you could not have read. With it, the same hour goes somewhere else entirely, because the third follow-up question is where people stop reciting and start thinking, and you only get to a third follow-up question on a subject you came in caring about. We have left rooms with a complete recording and very little to say, and it was never the vendor’s fault.

None of this is an argument about whether the fee is worth paying, which is a separate question with its own page: the return case for competitor mystery shopping weighs the cost against the decision it settles. The question here comes earlier. A decision has to exist before anything can be weighed against it.

So the homework is short, and it is not research. Write down the three decisions you face this quarter that turn on something you do not know about a competitor. Fill all three and you have a brief. Fail to fill one and the project is early, and no amount of recorded demo will fix that.

If You Want the Software Tested, That Is Someone Else’s Job

The first two are questions of readiness. This one is not, and it is the only one of the three that no amount of preparation changes.

We sit through the demos, ask everything worth asking, collect what the vendor sends afterwards, and write the read. We do not test the product. We are inside their sales process as a buyer, never inside their software as a user.

What that gives you is everything that happens in front of a seller: what they demonstrated live against what they only described, what they said when we asked the awkward question, what the quote covered and what it left out, how they behaved when we named a rival. That last one is the whole subject of a competitor sales tactics review.

The comparison page above does the demonstrated-against-asserted work: each vendor’s claim, next to what could be seen in the room. It is a strong instrument and it has a limit. It tells you what a vendor could show under friendly conditions, on their data, on their machine.

Usually what someone means by testing the tools is a nearby question worth answering: is this product any good. We answer a different one, which is what they claim, what they will show, what they charge, and where those three disagree. How the product behaves on your data, whether the integration still holds in week six, whether your team finds it usable on a Thursday afternoon: those come from a paid pilot, from a trial your own people run against a scorecard, or from an evaluation firm that does hands-on bake-offs. Different instrument, different price, and asking us for it would get you a careful version of the wrong thing.

Two of These Are Timing. The Third Is Not.

The first two are homework, and homework gets done. A company that could not name its competitors in March walks in with a list in May. A company that could not say what it wanted to learn usually finds out the next time it loses a deal it expected to win. Neither is a permanent no, and neither is a criticism.

The third does not move. Nothing about a longer project or a bigger budget turns demo research into product testing, because the constraint is not the depth of the work. It is where the work happens. We are in the conversation, and the conversation is not the product.

Which makes the honest test one you can run before you contact anybody. Name the competitors. Name what you want to learn about them. Then ask whether the answer lives in what those companies say, show, and send, or in what their software does once you own it.

If it lives in the conversation, that is our half of the work: we build the buying scenario, book and sit every demo, record them, chase the follow-ups, and hand back a board with a page per competitor and a read on what it all means. Your half is the two lists. Bring both, or bring the half you have and we will pressure test it before anything gets booked.