Show the Alternatives Customers Actually Use—Not Just Competitor Logos
Show the Alternatives Customers Actually Use—Not Just Competitor Logos
Most comparison slides are built backwards. Someone opens a design tool, drops four logos in a row, types a checkmark under the company's own name, and calls it a competitive landscape. The customer is nowhere in the picture. Neither is what that customer does on a Tuesday afternoon when the problem shows up.
A comparison earns its place when it shows a real choice. That means the alternatives a customer would actually weigh for a specific task: another product, a different category of tool, a spreadsheet, an internal system, asking a colleague, or doing nothing at all. Each option needs a reason to be there. Each difference needs a basis. And "we're better at it" is not a basis; it's a conclusion looking for evidence.
Define the situation before naming the alternatives
Start with the customer, the task, and the constraint that makes a decision necessary. Not the market. The market is where you go to find candidates, not the thing that decides which ones belong on the slide.
The same vendor can be essential to one buyer and irrelevant to another. A booking tool with a generous free tier is a real option for a five-person studio and a rounding error for a hospital scheduling operating theatres. Recognition doesn't qualify a logo. Fitting the decision does.
Consider a fictional small architecture practice we'll call Marlow & Reed — invented for this article, along with everything that follows about it. Eight people, two meeting rooms, one studio manager named Priya who currently spends part of every morning refereeing double-bookings. The task is narrow: let people reserve a room and see whether it's actually free. The constraint is that Priya is not going to administer a second job.
That's the situation. Any alternative we list has to answer to it.
The current method is an alternative, not a punchline
The temptation is to describe what the customer does today as a mess the product will rescue them from. Sometimes it is. Often it isn't, and treating a working method as a straw man tells the reader you haven't talked to anyone.
For Marlow & Reed, four options plausibly address this task:
- The shared calendar they already use. One calendar, two rooms' worth of events, no approval step. It costs them no additional subscription or training, and it works until two people claim the same room at the same time. Its strength is familiarity. Its constraint in this example is that people no longer trust an entry to mean a confirmed reservation.
- An internal request-and-approval process. A form, a shared inbox, Priya confirming by message. This is partly what happens now, unofficially. As a deliberate option it buys accountability — someone checks before a room is committed — at the cost of Priya's attention and a delay between request and confirmation.
- A dedicated booking product. Purpose-built scheduling, room-level availability, rules about who can book what. The capability the other options lack is a live, trustworthy view of which room is free right now. Whether any specific product does this well is a question for current first-party documentation, not for this article.
- No immediate change. Live with the double-bookings, or patch the calendar convention and see if that holds. This can be rational when the disruption is occasional and changing the method would cost more than handling it.
Note what's missing: a competitor logo table. Also missing: any claim that the spreadsheet is "clunky" or that the current calendar is "chaotic." Those are verdicts we haven't earned. What we have is a described method, a stated strength, and a stated constraint. That's enough to compare.
The inclusion grounds here are stipulated teaching conditions — Priya's observed behavior is invented for the example, not surveyed. In a real pitch, that's the part you'd verify: which of these four the customer actually does now, and which they've actually considered. If you can't say, mark it as a hypothesis rather than presenting it as fact.
Criteria should come from the work, not from your feature list
A comparison table assembled around the company's best features will always favor the company. That's not a comparison; it's a victory lap with columns.
Derive criteria from the task. For room booking, the decision hinges on a few things that actually change what Marlow & Reed would do:
- Can someone see confirmed availability without asking? If yes, the coordination load drops. If no, Priya stays in the loop regardless of what tool is used.
- Is there an approval step, and who owns it? Some practices need one — client-facing rooms, expensive equipment. Some don't, and an approval step is pure friction.
- What does adoption cost? New logins, new habits, a new place to check. This is why the current calendar keeps winning even when it's worse on paper.
- What happens when two people want the same room? The failure mode matters more than the happy path.
Now the comparison can hold unlike things together honestly. A dedicated product and a shared inbox aren't the same kind of object, but both can be asked whether they show confirmed availability and whether they require a human in the middle. Where a matrix forces a category error — checking "real-time sync" against a shared inbox — a short task-based comparison does more work than a row of ticks.
Inclusion evidence and difference evidence are not the same evidence
Two separate questions are hiding inside one slide.
Why is this option here? That comes from the customer's world: interviews, workflow records, the thing people actually do. Priya confirming reservations by message explains why a deliberate request-and-approval process belongs among the options. In this example the behavior is stipulated; in a real pitch it would need evidence.
What does this option do? That comes from the option itself: current first-party product documentation, a demo, a spec. The booking product's availability view is difference evidence. It's about the product, not about whether this customer cares.
Neither substitutes for the other. A customer saying "we'd never use approvals" tells you the criterion matters; it doesn't tell you which tools have approvals. A product page listing a feature doesn't tell you the customer would switch for it.
Keep three states visible: confirmed facts, bounded observations, and unknowns. An unknown is not a negative. If we don't know whether a given booking tool handles recurring reservations, the honest cell is "unknown," not a cross. Filling that cell with a mark decides the comparison on the reader's behalf using evidence we don't have.
In the Marlow & Reed example, the unsupported capability is deliberately left open: whether the dedicated product handles the practice's recurring Monday studio meeting cleanly. Nobody in the invented scenario checked. It stays unknown. An earlier draft marked it as a weakness; that was a guess dressed as a finding, and it came out.
What the row of logos would have said instead
Here's the rejected version, the one most decks actually ship:
Us ✓✓✓✓✓ | Competitor A ✓✓ | Competitor B ✓ | Competitor C —
Four recognizable names, one clear winner. It answers a question nobody asked — "which of these logos is best?" — and answers it using criteria chosen to produce the winner. It leaves out the shared calendar, the inbox, and doing nothing, which happen to be the three options the customer is most likely to keep. And it treats every unmarked cell as a loss, including cells nobody has evidence for.
The comparison we can actually stand behind looks more like this:
For eight people, two rooms, and one studio manager: the shared calendar is still free and still familiar, but an entry no longer means a confirmed reservation, so it stays viable only while the practice tolerates that doubt or patches the convention. The request-and-approval route adds accountability but keeps Priya in the loop. A dedicated booking tool is the only option built to show confirmed availability without asking anyone — if the practice will adopt it. Doing nothing is not the honest baseline here: the double-bookings arrive most mornings, so the question is which method replaces the current one, not whether to change.
That version doesn't pretend the product wins on every row. It says which alternative each option is up against, on what grounds, and where the evidence stops.
End where the decision starts
Sequoia’s business-plan guidance includes direct and indirect competitors among a company's alternatives. That is one investor’s framing, not a universal deck structure. It prompts a wider comparison; the customer’s task still determines which options belong in this one.
What belongs is whatever the customer would actually weigh. Name them, say why each one is in the frame, and separate what you've observed from what you're proposing. Then compare on criteria that change the decision rather than criteria that flatter the product.
A good comparison slide reads less like a leaderboard and more like an honest map of the choice. The reader should be able to point at each option and say why it's there. If they can't — if the only thing holding the slide together is which names are recognizable — you've designed a logo arrangement, not a comparison.
Frequently asked questions
Why shouldn't a comparison slide start with a row of competitor logos?
Most comparison slides are built backwards: four logos, a checkmark for the company, and no customer. A comparison earns its place when it shows a real choice, so it should start with the customer, the task, and the constraint that makes a decision necessary.
Which alternatives belong on a comparison slide?
The alternatives a customer would actually weigh for a specific task: another product, a different category of tool, a spreadsheet, an internal system, asking a colleague, or doing nothing. Each option needs a reason to be there, and 'we're better at it' is not a basis.
How should comparison criteria be chosen?
From the task, not the company's feature list. For the fictional room-booking example, the body uses whether someone can see confirmed availability without asking, whether there is an approval step and who owns it, what adoption costs in logins and habits, and what happens when two people want the same room.
What is the difference between inclusion evidence and difference evidence?
Inclusion evidence comes from the customer's world—interviews, workflow records, what people actually do—and explains why an option is in the frame. Difference evidence comes from the option itself—current first-party documentation, a demo, a spec—and explains what that option does. Neither substitutes for the other.
How should unknowns be handled in a comparison?
Keep three states visible: confirmed facts, bounded observations, and unknowns. An unknown is not a negative; if nobody checked whether a booking tool handles recurring reservations, the honest cell is 'unknown,' not a cross. Filling that cell with a mark decides the comparison using evidence you do not have.