← Articles
Daily columnWritten fresh this morning

Test the Deal-Breaker Before You Build the Delight

Test the Deal-Breaker Before You Build the Delight

9 November 2026

Today's argument

Product teams should identify and test the single condition that can disqualify a product before investing in features that increase its average appeal.

Product teams are trained to look for accumulated value. Add enough useful features, remove enough friction and the product should become more attractive. That logic is built into roadmaps, prioritization models and most product reviews.

Customers do not always evaluate products that way. One serious weakness can cancel out ten strengths.

Recent product coverage makes this visible. A basic device can be compelling precisely because it avoids unnecessary additions. A technically versatile appliance can still lose the reviewer on one feature. Parents looking for safer phones are not comparing long lists of capabilities; they are looking for assurance on a specific concern. At the same time, product publications are paying more attention to churned customers, noisy dashboards and the need for smaller experiments.

I see one pattern across these developments: teams spend too much time measuring average appeal and too little time finding the customer’s veto condition.

A veto condition is not simply a missing feature. It is something that makes the rest of the proposition irrelevant for a particular customer or buying situation. An expense platform may save finance teams hours, but it will not pass procurement without the required access controls. A reporting product may be easier to use, but one unreliable export can make it unsuitable for board reporting. An AI assistant may produce good drafts, but a legal team may reject it if employees cannot tell which information leaves the company environment.

The mistake is to treat these objections as items in a backlog alongside ordinary improvements. They are not equivalent. Better navigation might raise satisfaction. A missing compliance requirement can prevent adoption entirely.

This matters more now that teams can produce prototypes and features faster. Cheap building makes it tempting to demonstrate breadth. A team can show five workflows, several integrations and a polished interface before it has tested the condition that determines whether the product can be used at all. The demo looks like progress because there is a lot to see. The underlying commercial risk remains untouched.

I would therefore add a simple question to strategy and roadmap reviews: what is the most likely reason the intended customer cannot or will not use this product, even if the main promise is true?

The answer should be specific enough to test. “Customers may not trust it” is too vague. “Finance administrators will not enable automatic reconciliation without a reversible approval step” gives the team something concrete to investigate. So does “operations managers will abandon the workflow if exceptions require a support ticket.”

This also changes experiment design. Teams usually test whether customers understand the proposition, complete the flow or express interest. Those are useful signals, but they tend to confirm upside. A good early experiment should also try to expose the veto. Give users the difficult exception. Put the product into the procurement conversation. Ask churned customers to identify the moment when the product stopped being a viable option, not merely what they disliked.

I would not fold the result into one broad satisfaction score. Aggregate metrics hide disqualification. If most users are happy while a strategically important segment cannot complete a critical task, the average can look healthy while growth stalls. The veto condition deserves its own measure and an explicit owner until the team has reduced the risk.

This is not an argument for building every requirement a customer names. Some veto conditions belong to segments the company should not serve. That is still a valuable conclusion. The team can narrow the target market deliberately instead of carrying an untested assumption through months of delivery.

Strong product strategy is not only a clear statement of the value we intend to create. It is also a clear view of what can nullify that value. I want teams to find that condition while the product is still cheap to change, not after a polished launch proves that customers can admire a product without choosing it.

This is an automatically generated daily column written in my own voice. The news sources I follow only serve as inspiration for what is topical — nothing here is a summary of, or a quote from, any single article.

Inspired by what was in the air at: lennysnewsletter.com, techcrunch.com, tpgblog.com, mindtheproduct.com, romanpichler.com

  • product-strategy
  • experimentation
  • customer-retention
  • product-measurement