Discovery Is Incomplete Until Operations Can Survive the Product

Product discovery has a blind spot. We spend a lot of time asking whether customers want something, whether they can use it and whether engineering can build it. We spend far less time asking whether the company can operate it once customers actually arrive.

That omission is becoming harder to defend. AI products are receiving deeper access to calendars, inboxes and payment methods. Autonomous services are moving from controlled trials towards wider availability while still learning from difficult real-world conditions. Even relatively conventional products can reveal their real value only when tested inside a busy restaurant or another operational environment.

The common pattern is that the product does not end at the interface. It creates work elsewhere in the business.

A feature can perform well in a usability test and still produce an unacceptable number of support cases. An AI assistant can complete the expected task while creating a review burden that removes the promised efficiency. A new pricing model can improve conversion while making invoices harder to explain and revenue harder to reconcile. A self-service flow can reduce sales involvement but increase fraud checks, cancellations or manual corrections.

None of these are edge cases to clean up after launch. They are part of the product.

When I review discovery work, I therefore want to see operational evidence alongside customer evidence. If a team expects meaningful adoption, what happens to ticket volume? Which exceptions require a person? Can finance explain the transaction? Can customer success diagnose a poor outcome? Can the company stop or correct the service without engineering performing an emergency intervention?

This is not an argument for involving every department in every product decision. That would make discovery slow and political. It is an argument for testing the operational consequence most likely to challenge the business case.

The test can be small. Run a limited release and have support classify every contact it produces. Ask finance to reconcile a realistic set of transactions. Let customer success investigate an intentionally incomplete AI output. Put the product into the actual environment instead of demonstrating it in a clean meeting room. The purpose is not to collect approval. It is to learn where the operating model breaks.

This also changes how I look at ROI. A business case that counts additional revenue or saved user time but ignores new internal work is not optimistic; it is incomplete. The cost of a product includes the exceptions it creates. With AI, that may include model monitoring, human review, security investigation and handling customers who challenge an output. With a physical service, it may include local interventions, weather-related disruption and recovery procedures. With a growth feature, it may simply be the extra workload pushed into support.

Teams should define an operational threshold before expanding availability. For example, the product may need to keep manual reviews within an agreed range, allow most incidents to be diagnosed without engineering, or produce transactions that finance can reconcile using the existing process. The exact threshold depends on the product. What matters is agreeing it before enthusiasm and early adoption make restraint unpopular.

This gives product managers a clearer responsibility as well. They are not accountable for personally running support, security or finance. They are accountable for understanding whether their product makes those functions stronger or quietly depends on them absorbing unlimited complexity.

Building faster will not solve this. More infrastructure will not solve it either. A smaller model, a larger model or another automated system watching the first one may change the technical equation, but it does not remove the operational one.

I consider a product discovered only when we have evidence of three things: customers value it, we can deliver it and the organization can live with its success. The third condition is usually the least exciting. It is also the one that determines whether growth becomes a result or a recurring incident.