Incorrect AI referrals need evidence of a real customer task

An assistant claiming that your product has a feature is not a reason to build it. People arriving and trying to complete a coherent task are a reason to investigate. Keep those two kinds of evidence separate. An incorrect referral can reveal useful product information when observed behavior supports it, but correcting expectations remains a valid response when the requested work does not fit the product.

Looking back from November 2026, Adrian Holovaty's 7 July 2025 account of Soundslice provides a concrete example. He reported finding failed uploads of ChatGPT screenshots containing ASCII guitar tablature. He then found the assistant recommending a Soundslice import capability that did not exist. Soundslice subsequently built an importer. That is the founder's account of a particular sequence, not an independently measured market study.

The attempted task carries more information than the recommendation

A false recommendation tells you something about what the assistant generated. An attempted import tells you that a person took another step. The person had an input and sought an outcome. That difference is why the Soundslice story is more useful for product thinking than a screenshot of an invented feature alone.

Even an attempted task leaves questions unanswered. A visitor may be curious, may misunderstand the expected output or may have arrived because the assistant overstated several parts of the service. Repeated attempts can also come from the same misunderstanding. Do not turn evidence that people tried an action into evidence that they will adopt the product, pay for it or remain customers.

For an illustrative product investigation, begin by describing the input, the desired output and the point where the current product stops helping. Then check whether the people involved recognize that description. This does not require accepting the assistant's proposed solution. A person may want a useful result that an existing route already supplies once it is explained correctly.

The business decision follows that distinction. Building an import format can be sensible when it feeds an existing activity the product already supports. Building an unrelated system to match an assistant's confident description can create a second product with a different operating burden. The external recommendation does not assign that burden to anyone capable of maintaining it.

Product fit needs a decision beyond repairing embarrassment

False expectations can make a service appear broken. That creates pressure to respond quickly, particularly when visitors have already invested effort. But embarrassment is a poor substitute for deciding what belongs in the product. The response should account for both the immediate failed task and the obligations a new feature would create.

Consider an illustrative importer that accepts a new kind of document. Acceptance is only the beginning. The team needs to decide what output is trustworthy enough to show, how users can correct mistakes and what happens when the input cannot be interpreted. If these responsibilities fit the existing product, an extension may be coherent. If they require expertise or ongoing service the team cannot supply, a clear explanation may serve users better.

The strongest counterargument is that conventional discovery can miss opportunities that arrive through unusual channels. Waiting for perfect evidence would make many useful small features impossible. A narrowly bounded extension can be a reasonable judgment even when its future revenue is unknown. The lesson is to make the uncertainty explicit inside the decision, not to demand certainty before doing anything.

That argument is strongest when the feature is close to the product's existing purpose and can be supported responsibly. It weakens when the work changes who the customer is, what the product promises or how failures must be handled. A surprising referral channel does not settle any of those choices. Scope and support remain the product owner's responsibility.

A revenue milestone answers a different question

Kyle Nolan's 30 June 2025 ProjectionLab account reported reaching $1 million in annual recurring revenue without external funding. His timeline listed $150 monthly recurring revenue in May 2021 and $83.3 thousand in June 2025. These are founder-reported figures and chronology for ProjectionLab. They are not a revenue forecast for an importer, evidence of Soundslice conversion or proof of demand created by incorrect AI referrals.

The useful contrast is between an observed task and an account of a business developing over time. A task attempt can help identify a problem worth understanding. A revenue history can show how one founder describes a particular company's progress. Neither supplies the missing causal bridge from a new feature to sustainable revenue in another product.

Keep that bridge visible in your own decision. If the purpose of an extension is to help existing users finish an established job, judge it against that purpose. If the purpose is acquisition, identify what later behavior would support that claim. Arrivals alone leave open whether people reached the intended result or understood the rest of the offering.

Correcting expectations is a product response

A clear explanation can acknowledge the unsupported input, describe what the product currently accepts and offer an appropriate next step. It should reach the person before they repeatedly attempt an impossible action. This can be worthwhile even if the team later adds the feature, because a future possibility does not repair today's misleading instruction.

A decision against building should also have a reason that survives the immediate incident. Perhaps the requested output falls outside the product's purpose, or the maintenance obligation is disproportionate to the observed need. These are possible reasons, not findings about Soundslice. Recording them makes it easier to reconsider if stronger evidence later appears.

For custom software development, bring the actual failed task to the discussion rather than only the assistant's claim. Describe what users tried, what remains uncertain and how the proposed extension fits the product's responsibilities. Build when that argument stands on its own. Otherwise, repair the expectation and help the visitor choose an achievable next step.