Every week, founders present investment theses built around a comparison: “We are building the Slack for X” or “Think of it as Notion for Y.” These analogies serve a communication purpose — they help a listener quickly form a mental model of an unfamiliar product. They do not serve a validation purpose. Using an analogy as evidence that a market exists is not market research. It is a description of what was possible for a different team, with different resources, in a different competitive environment, at a different moment in technology adoption. The fact that Slack succeeded does not tell you whether your product will succeed. It tells you that a team communications tool found a large market in 2013.
Market validation by analogy is the most common and least useful form of validation because it feels like evidence while providing almost none. The founder who says “Slack proved people will pay for better workplace communication” has described a historical fact. They have not described their market, their customer, their competitive environment, or their distribution path. The analogy works as a shorthand for explaining a category. It fails as a substitute for the investigation that determines whether a specific product, offered by a specific team, at a specific price, can find enough customers to build a business.
Why analogies fail as validation evidence
An analogy identifies a structural similarity between two products — both serve communication, both address information management, both automate a workflow. What it cannot transfer is the specific combination of conditions that made the analogy product succeed. Those conditions include the state of the competitive market at the time of launch, the distribution advantages the founding team brought (Slack launched to a developer-adjacent audience already familiar with IRC), the timing relative to a platform or behavior shift, the specific features that drove initial adoption versus the features that drove retention, and the customer segment that converted early before the product reached broad appeal.
Each of these variables is context-specific. The conditions that made Slack viable in 2013 are not the conditions you are operating in today. The enterprise communication market in 2013 had Microsoft as a slow-moving incumbent with aging tools and no modern real-time alternative. That specific gap is closed. Building a “Slack for X” in 2025 means entering a market where buyers have already formed habits around communication tools, have already evaluated whether to consolidate or fragment their tool stack, and are already aware of a range of alternatives. The analogy describes the gap as it existed. Your market is the gap as it exists now, which requires its own investigation.
The second failure of analogical validation is selection bias. Founders cite the analogies that worked — Slack, Notion, Figma, Stripe — and draw general conclusions from the specific outcomes of a small number of exceptional companies. For every Slack-for-X that succeeded, there are dozens that failed to find the same structural conditions in a new domain. The failures are not cited in pitch decks. They do not become reference points because they do not have the brand recognition that makes the comparison legible. The analogies available to a founder are systematically sampled from the right tail of outcomes, which makes them systematically misleading about the probability distribution they are representing.
What analogies actually measure
An analogy measures whether a category has demonstrated demand in at least one context. That is a useful signal and not one to dismiss entirely. Knowing that team communication tools can build large businesses is relevant background for a founder building in that space. The problem is treating category demand as a substitute for product-specific demand.
Category demand tells you that some version of the job your product addresses has been valuable enough that customers have paid for it. It does not tell you that your version of the job, offered at your price, through your distribution channel, to your specific customer segment, will be valuable enough to build a business around. Those variables — version, price, channel, segment — are precisely the variables that kill products in categories with proven demand. Most failed products in successful categories did not fail because nobody wanted the category. They failed because the specific product did not work for the specific customer in the way the customer needed.
A founder who validates by analogy has established the floor — the category is real — without establishing whether they are above or below it. Everything interesting about market validation happens between the floor and the outcome.
How to move from analogy to actual market validation
The goal is to replace the analogy with specific evidence about your product, your customer, and your competitive environment. These steps describe how.
-
Name the specific customer, not the category. An analogy points at a category of customer — “teams that struggle with communication.” Market validation requires a specific customer: job title, company size, industry, current workflow, specific trigger that makes the problem urgent enough to pay for a solution. Write one sentence describing the specific person who will buy your product first. If the sentence describes a category rather than a person, the customer is not yet specific enough to validate against.
-
Identify the alternative your customer is currently using, not the one the analogy disrupted. The analogy describes what a market looked like before the analogy product entered it. Your market is what it looks like after that product succeeded, spawned competitors, and established buyer expectations. The relevant competitive alternative is the one your target customer uses today, not the one that existed when your analogy was founded.
-
Find ten people who match your specific customer definition and talk to them about their current behavior. Not about your product. About what they currently do, what breaks, and what they have already tried. If you cannot find ten people who match your specific customer definition, the definition is wrong. If you find them but they do not have the problem the analogy suggested they would have, the analogy was misleading about where demand actually lives.
-
Test one specific claim before testing the product. Analogies generate broad hypotheses — “enterprises will pay for better X.” Before testing the product, test the most specific claim your product depends on. Not “will people pay for better meeting summaries” but “will the specific team lead at a 50-person B2B company pay $40 a month to reduce the time spent distributing meeting context to team members who were not in the meeting.” The more specific the claim, the faster a test can produce actionable signal.
-
Identify one condition that made the analogy succeed that does not exist in your context. Every analogical reference has at least one context-specific success condition that does not transfer. Find it. If Slack succeeded because developers already used IRC and were a natural early adopter bridge, and your product has no equivalent early adopter group with pre-existing relevant habits, that is a distribution problem your analogy did not account for. Naming this gap is more useful than the analogy itself.
What founders should do with analogies instead of discarding them
The right use of an analogy in market validation is as a hypothesis generator, not as evidence. “Slack proved that team communication can build a large market” is a hypothesis that a specific communication problem exists at scale. That hypothesis is worth investigating. It is not worth citing as proof.
Analogies are also useful for identifying where the analogy broke down for other “X for Slack” attempts — what conditions those teams assumed would transfer and did not, what they misread about the structural similarity, and what the category looks like after several well-funded attempts have already competed in it. The failure cases in an analogy category teach more about the market than the success case does, because the success case describes a moment that no longer exists. The failure cases describe the market as it is.
The founder who uses an analogy well says: “Slack demonstrated that team communication is a solvable and monetizable problem. These five Slack-for-X products failed in the last three years. Here is what I think they got wrong about the specific customer, and here is the specific evidence I have that my version of the problem is real and unaddressed.” That is not validation by analogy. It is validation informed by analogy, anchored in specific evidence. The analogy provides orientation. The evidence provides the argument.
