Feature Graveyard: How Founders Can Learn From Dead SaaS

Feature Graveyard is built around a deceptively valuable founder habit: before building the next AI-powered workflow or familiar marketplace clone, investigate who tried something similar, what happened, and whether the conditions have materially changed.

A Reddit post in r/SaaS introduced Feature Graveyard as a searchable collection of more than 140 discontinued products, organized by company, category, and stated reason for their demise. That makes it more than a novelty list of failed startups. Used well, it can become the first step in a better product-discovery process: a way to replace vague competitive research with a structured pre-mortem. (reddit.com)

What is Feature Graveyard?

Feature Graveyard is presented as a database of discontinued products and SaaS experiments. The original Reddit submission describes filters for the company behind a product, its category, and its “death reason,” with the explicit challenge to check the database before launching another “Uber for X” or “AI-powered Y.” (reddit.com)

That framing is important. Most competitor research focuses on companies that survived: category leaders, current pricing pages, funding announcements, and polished case studies. Those sources tell founders what has worked well enough to remain visible. They often do not explain why adjacent bets disappeared, why a product was sunset, or which customer behavior never became durable.

A failure database shifts the research question from “Is anyone doing this?” to “What has already been attempted, and what would need to be different for this version to work?” That is a much harder question, but it is usually the more useful one.

The project also sits in a broader movement toward making product failures searchable rather than anecdotal. CB Insights, for example, has collected hundreds of startup post-mortems in founders’ and investors’ own words. Its research consistently places poor product-market fit, cash constraints, team problems, competitive pressure, and pricing or cost issues among the recurring factors in startup failures. (cbinsights.com)

A catalogue is not a verdict

The most dangerous way to use Feature Graveyard would be as an automatic “do not build” list. A discontinued product does not prove the underlying customer problem was imaginary. It may indicate that the product had the wrong distribution, timing, business model, target segment, technical implementation, or owner.

Google Glass, for example, is not proof that wearable computing is inherently unwanted. Quibi is not proof that people will never watch short-form video. A sunset collaboration feature does not prove teams do not need collaboration. These cases show that a product category is always tied to a particular context: user expectations, hardware limits, trust, regulation, monetization, buyer behavior, and the parent company’s strategic priorities.

The real value of a Feature Graveyard-style database is not that it tells founders what to avoid. It helps them identify the assumptions that need proof before they write a roadmap.

Why dead SaaS products are valuable research

Startup success stories are distorted by survivorship bias. They are easier to find, easier to celebrate, and easier to reverse-engineer into simple advice. “Launch quickly.” “Pick a niche.” “Use product-led growth.” “Add AI.” Each statement can be true in a particular setting, but none is a universal causal explanation.

Failed products preserve the counterexamples. They reveal where a reasonable-sounding thesis encountered reality.

Consider a founder evaluating an AI meeting-notes tool. A scan of active competitors may reveal dozens of products with transcription, summaries, action items, CRM syncs, and sharing features. A scan of discontinued or stalled tools could reveal a different picture:

• Users may have liked summaries but refused to change their meeting workflow.
• Buyers may have viewed the feature as a commodity included in a broader suite.
• Privacy and permission requirements may have slowed enterprise deployment.
• AI inference costs may have made a low monthly price unworkable.
• The product may have generated an impressive demo moment but poor week-four retention.

Those observations do not make the category impossible. They give the founder a test plan.

Failure is usually multi-causal

One of the biggest mistakes in startup analysis is assigning a single cause of death. “They failed because there was no market.” “They failed because they ran out of money.” “They failed because they were too early.” In practice, these explanations are connected.

A weakly differentiated product may create slow activation. Slow activation limits retention. Weak retention makes paid acquisition unprofitable. Unprofitable acquisition makes it difficult to raise capital or sustain sales hiring. Eventually, the company runs out of cash. The shutdown announcement may say “market conditions,” but the operational story started much earlier.

That is why labels such as “no market need” should be treated as starting points, not endpoints. CB Insights’ well-known analysis of startup post-mortems found that no market need was the most commonly cited issue, but companies commonly reported multiple contributing problems. (s3-us-west-2.amazonaws.com)

For builders, the practical lesson is simple: do not merely copy the database’s death reason into a slide deck. Reconstruct the chain of assumptions that preceded it.

The right way to use a Feature Graveyard

Feature Graveyard is most useful at the idea, scope, and positioning stages—not after a team has already committed six months of engineering effort. A disciplined workflow turns historical failure into a decision tool.

1. Search for the job, not just the product name

Start with obvious category and company searches. Then broaden the query around the underlying job to be done.

If the idea is “AI inbox management,” search for email triage, productivity assistants, prioritization, workflow automation, executive assistants, and customer-support routing. If the idea is a “creator CRM,” search for influencer tools, sponsorship management, media databases, fan communities, affiliate workflows, and link-in-bio products.

The point is to avoid false confidence caused by naming. Failed products often describe the same customer problem using vocabulary that has since changed.

2. Build a failure-pattern table

For every relevant discontinued product, collect the evidence in a simple table. Do not rely on memory or a one-line label.

This exercise forces precision. “A competitor failed” is almost useless. “A self-serve tool aimed at individual users could not retain them after the initial setup task, while enterprise buyers required integrations it could not afford to build” is actionable.

3. Separate execution failure from thesis failure

A product can disappear for reasons unrelated to demand. A parent company may change strategy, face an acquisition, consolidate overlapping tools, shift resources to a larger opportunity, or discontinue an experiment before it reaches maturity.

Ask three questions:

1. Was the user problem real and painful? Look for repeated customer complaints, existing workarounds, or budget already allocated to the job.
2. Did the product solve the problem better than alternatives? A good problem with a weak workflow still produces low adoption.
3. Could the business capture enough value? Even a beloved tool can fail if distribution, gross margin, implementation cost, or willingness to pay makes the economics untenable.

A discontinued product where users were disappointed may be a more promising signal than one nobody noticed. The former can point to a real job with an unsolved delivery or business-model problem. The latter may indicate that the supposed pain was never important enough to create a habit.

4. Turn history into falsifiable tests

Every historical failure should produce a testable statement about your own idea.

For example:

• Historical finding: users abandoned a tool after an initial novelty period.
• Your hypothesis: the workflow is recurring because it is triggered by a weekly operating process.
• Test: measure whether early users complete the core action in at least three separate weeks without founder intervention.

Or:

• Historical finding: customers resisted paying for a standalone feature.
• Your hypothesis: the feature is valuable when bundled into a revenue-critical workflow.
• Test: ask buyers to choose between a paid pilot and their existing workaround before building the full product.

This is the central move. Research becomes valuable only when it changes what the team tests next.

The AI product problem: novelty is not retention

Feature Graveyard arrives at a particularly useful moment for AI founders. Modern model capabilities make it possible to produce an impressive prototype in days, while coding agents and no-code tools reduce the cost of shipping a convincing first version. That lowers the cost of experimentation, but it also lowers the barrier for competitors to copy surface-level features.

Jason Lemkin recently argued that go-to-market channels are not broken, but that product moats are shrinking to months in many AI markets. His broader point is that traditional sales and marketing motions still matter, yet fast-moving categories create an intense demand for products that are meaningfully differentiated rather than merely adjacent to the latest model release. (saastr.com)

A dead-product database can help teams distinguish between two very different kinds of AI ideas:

• An AI capability that removes repeated, expensive, error-prone work inside a trusted workflow.
• An AI flourish that creates a one-time “wow” moment but no reason to return.

That distinction matters because activation and retention are not interchangeable. A viral launch can produce thousands of signups. If users do not return, refer colleagues, connect their data, or pay to keep the workflow running, the launch did not validate a sustainable product.

The “AI tourist” warning

ChartMogul’s research on AI-native SaaS describes an “AI tourist” problem: customers experiment with a new tool, then move on when the value is not durable enough to justify renewal. Its analysis examined thousands of software businesses and emphasizes that recurring revenue needs to be assessed through retention, not just early adoption or contracted ARR. (chartmogul.com)

For a founder studying Feature Graveyard, this changes the research lens. Do not only ask whether a former AI product was technically feasible. Ask whether users developed a recurring behavior around it.

Useful questions include:

• Does the product fit into a workflow that already happens every day, week, or month?
• Does a user lose meaningful progress, insight, revenue, compliance coverage, or team coordination by leaving?
• Is the AI output easy to verify and act on?
• Does the product become more useful as it learns from approved data, team conventions, and repeated use?
• Is the real differentiation in the model, or in proprietary workflow, integration, distribution, and trust?

If the only answer is “the output is more impressive than a spreadsheet,” that is not enough.

What death reasons can teach founders

A searchable “death reason” is powerful because it makes patterns visible across different categories. But each category of failure should lead to a different response.

No market need

This does not necessarily mean users never expressed interest. People are polite in interviews, enthusiastic about hypothetical solutions, and willing to try free products. The stronger signal is whether they sacrifice money, time, reputation, or an existing workflow to adopt the solution.

What to test: a paid design-partner commitment, a switch from an existing workaround, or repeated use of a narrow manual prototype.

Ran out of cash

Cash failure can mask a product or business-model problem, but it can also reflect a timing mismatch. A company may have needed longer sales cycles, more integrations, or more customer education than its runway allowed.

What to test: the full path from initial interest to paid implementation. Model time to first value, onboarding effort, gross margin, sales cycle, support burden, and the minimum number of customers needed to fund the next stage.

Outcompeted or commoditized

Sometimes a larger platform bundles the feature. Sometimes the market fragments into cheaper alternatives. Sometimes the original product lacks a distribution advantage.

What to test: why a customer would choose you if a suite provider offers 70% of the functionality. Be specific: better data, a regulated workflow, faster implementation, a unique channel, a stronger integration, or a segment that incumbents ignore.

Poor timing

“Too early” is often an attractive explanation because it preserves the founder’s original idea. Sometimes it is true. Hardware costs may fall, APIs may become available, regulations may change, or buyer behavior may shift. But timing should be demonstrated, not asserted.

What to test: identify the concrete constraint that prevented adoption before and document why it has changed. “AI is popular now” is not a sufficient answer. “A new standard exposes the required data, and three target customers have budgeted for compliance automation this quarter” is much stronger.

Pricing and cost problems

An appealing product can still be structurally unprofitable. AI makes this especially relevant: high inference or human-review costs can conflict with a low willingness to pay, while usage-based pricing can make customers anxious about unpredictable bills.

What to test: willingness to pay before optimizing the product. Run a pricing conversation with a defined package and a clear usage boundary. Track cost to serve at the customer level, including onboarding, support, review, infrastructure, and model costs.

Strategic shutdown

A discontinued product owned by a major company may have been deprioritized because it did not fit the company’s portfolio, not because customers did not value it. That can create openings for focused startups, but it can also signal that the product depended on ecosystem advantages a startup cannot replicate.

What to test: interview former users. Ask what they used before, what they moved to after the sunset, what they miss, and whether they would pay a specialist to restore the job the product performed.

A practical product pre-mortem for SaaS founders

Studying dead products is only half the work. The other half is conducting an honest pre-mortem on your own concept before the sunk-cost effect takes hold.

Gather the founders, product lead, engineer, growth owner, and—if possible—a customer-facing teammate. Assume it is 18 months from now and the product has failed. Then write the plausible reasons without defending the idea.

Use this prompt:

“It is September 2027. We shut down because our product never became a durable business. What happened first?”

Then sort the answers into a working risk register.

This framework is less glamorous than shipping a large beta, but it is faster. It also creates a written record of what the team believed before evidence arrived. That makes it easier to update the strategy rather than rationalize weak results.

Product history should inform positioning, not just features

Founders often use competitive research to make feature checklists. Feature Graveyard suggests a better outcome: use history to make sharper positioning choices.

Suppose several products in a category died because they targeted “small businesses” broadly. The lesson may not be “small businesses are a bad market.” It may be that the category contains radically different jobs, budgets, buying processes, and maturity levels.

A better wedge might be:

• Independent accounting firms preparing month-end client reports.
• B2B agencies managing approval workflows for regulated clients.
• Ecommerce operators reconciling returns across two specific platforms.
• Field-service companies dispatching crews in one geographic region.

Narrow positioning is not merely a marketing tactic. It is a product-design constraint. It determines which integrations matter, which language resonates, what data you need, how implementation works, and whether customers can recognize value quickly.

For email infrastructure or marketing products, this can be especially concrete. “Better email delivery” is vague. “Reduce invalid trial signups before a product-led onboarding sequence” is a specific operational problem with measurable impact. Teams testing that workflow can start by using an email address verification tool to separate a real data-quality issue from a broader activation problem.

What the original Reddit discussion reveals—and does not reveal

The original r/SaaS post is concise: it introduces the database, explains its filters, and asks which dead product deserves a proper autopsy. At the time captured in the supplied source, there were no top comments to analyze, so there is no meaningful community consensus to overstate. (reddit.com)

That absence is worth noting because product communities often rush to turn a single example into a universal lesson. A database like this will be most useful when people add evidence, source links, shutdown statements, customer reactions, and competing interpretations—not just punchy labels.

A strong community contribution would look like this:

• Link to the shutdown announcement or founder post-mortem.
• Separate confirmed facts from inference.
• Explain the target user and business model.
• Identify what changed in the market since the product launched.
• Name the surviving alternatives and why they survived.
• State the one hypothesis a new founder should test first.

That transforms a graveyard from a collection of cautionary tales into living research infrastructure.

The limits of a dead-product database

No product database can eliminate founder judgment. It also has predictable blind spots.

First, shutdown information is incomplete. Companies often communicate in broad language, while the most revealing data—retention, CAC, churn by segment, gross margin, sales-cycle length, and internal conflict—is private.

Second, high-profile failures are overrepresented. A database may include famous consumer launches or large-company sunsets because information is easy to find, while quiet bootstrapped failures remain invisible. That can skew pattern recognition.

Third, categorization creates false certainty. “No market need” may be the headline, but a more accurate explanation might be “market need existed, but the product required a costly behavior change before users could experience value.”

Fourth, a historical database cannot prove causation. It helps generate better hypotheses. It cannot replace interviews, prototypes, paid pilots, cohort analysis, and close observation of real users.

The right posture is neither fatalism nor optimism. Treat the evidence as a reason to test more precisely.

A founder’s 30-day anti-graveyard plan

If you are early in a SaaS or AI product idea, use the next month to reduce the risks that historical failures expose.

1. Days 1–3: Map the category. Search Feature Graveyard, CB Insights post-mortems, shutdown announcements, acquisition notes, review sites, and old product pages. Capture at least 10 relevant predecessors or adjacent attempts.
2. Days 4–7: Interview for behavior. Speak with 10 potential users about the last time the problem occurred. Ask what they did, what it cost, what broke, and who approved the workaround. Avoid leading questions about your solution.
3. Days 8–12: Write the risk register. Turn each repeated historical failure into an assumption, a leading indicator, and a cheap test.
4. Days 13–20: Sell a narrow pilot. Offer a clear outcome, a defined scope, and a price. A paid commitment is not the only signal, but it is far stronger than praise.
5. Days 21–26: Deliver manually if needed. Do the work behind the scenes before automating it. Observe where users hesitate, what data is missing, and which steps they value enough to repeat.
6. Days 27–30: Make one hard decision. Continue, narrow the segment, change the pricing model, change the workflow, or stop. Write down why.

This approach is not about avoiding risk altogether. Every startup is a bet under uncertainty. The point is to choose the uncertainty deliberately rather than discovering it after the team has built a polished version of an unvalidated assumption.

Conclusion: Study the dead, then build for the living

Feature Graveyard is valuable because it reframes discontinued products as research artifacts. The central lesson is not that founders should avoid ideas that have failed before. Most worthwhile categories have a history of failed attempts.

The lesson is that similarity at the idea level is not enough. A new product needs a specific answer to what has changed, who has the painful job, why they will switch, how the workflow becomes habitual, and why the economics support a durable company.

In an AI market where prototypes are cheap and surface-level differentiation can vanish quickly, that discipline matters even more. A well-run product autopsy does not kill ambition. It helps founders direct ambition toward assumptions that can survive contact with real users.

FAQ

What is Feature Graveyard?

Feature Graveyard is presented as a searchable database of discontinued products, with filters such as company, category, and stated reason for discontinuation. Its purpose is to help founders research prior attempts before building a similar SaaS or AI product. (reddit.com)

Should a failed SaaS product stop me from entering a market?

No. A past failure is evidence to investigate, not a final verdict. Determine whether the previous product failed because of weak demand, poor distribution, pricing, timing, execution, strategic prioritization, or a problem your version can genuinely solve.

What is the biggest lesson from dead SaaS products?

The most useful lesson is to test the assumptions behind the failure. If a previous product suffered low retention, test repeat use. If it was commoditized, test your differentiation. If it ran out of cash, test implementation cost, pricing, and sales-cycle reality.

How can AI founders avoid building a novelty feature?

Anchor the AI capability to a recurring, high-value workflow. Measure repeat behavior after the first use, not just signups or demo enthusiasm. Durable products create a reason to return, not merely a reason to try.

Are startup failure databases reliable?

They are useful but incomplete. Public post-mortems and shutdown announcements can reveal patterns, yet they rarely contain full internal data. Use them to form hypotheses, then validate those hypotheses with customer interviews, pilots, product analytics, and financial modeling.