Concept Testing

Concept testing puts an idea in front of the people it is for, before it is built, to find out whether it is worth building. It answers a different question from every other testing method: not whether people can use something, but whether they want it to exist.

The two get confused with expensive consequences. A team that runs usability testing and skips concept testing builds a product that is easy to use and unwanted, and finds out at launch. The usability version of failure is visible in a session; the concept version is invisible until nobody adopts it.

What to show

Fidelity should be low enough that people react to the idea rather than to the execution, and low enough that you are willing to discard it.

The polish trap is real. A concept presented at high fidelity reads as decided, and people comment on the decision rather than questioning the premise.

Asking in a way that produces information

The characteristic failure is that everyone says the concept is great and nobody uses it. Three habits prevent it.

Ask what it would replace. A concept that displaces nothing is being added to a day that is already full. "What would you stop doing if you had this?" separates genuine interest from politeness better than any rating scale.

Ask about today, first. Establish what they currently do, in detail, before showing anything. Once somebody has seen the concept, their account of the present quietly reshapes itself around it.

Ask what would stop them. In B2B the honest answers are procurement, migration effort, an integration that does not exist, and the risk of championing something that fails. These are the real obstacles and they surface only when invited.

Ratings are the weakest instrument here. "How interested are you, one to five" produces fours from people who will never adopt it, because four is the polite answer.

The signals worth trusting

Displacement. They name something they would stop doing.

Unprompted specificity. They start describing their own case in detail, correcting your example. People do not do this for ideas they find irrelevant.

Objections about implementation. "How would this handle our permissions" means they have already imagined using it.

Asking when. The strongest available signal short of money.

And the ones not to trust: general enthusiasm, "this would be useful for other teams", and any answer to a question about the future phrased as a preference.

The B2B qualification

Consumer concept testing can reach many people quickly and lean on numbers. B2B cannot, which changes the method rather than invalidating it.

Samples are small. Five to eight per role, which means a strong objection heard twice is a pattern rather than an outlier.

The person who likes it may not be the person who pays. A daily user's enthusiasm and an economic buyer's willingness to fund are separate findings, and testing only the first is how features get built that nobody will buy.

Everything takes a quarter. Stated intent and a purchase are separated by procurement, budget cycles and an evaluation. Treating a positive concept test as demand confirmed is how roadmaps get built on politeness.

A design partner is worth more than a survey. One customer willing to work through the concept in detail, repeatedly, beats twenty ratings.

In practice

A team tests a concept for automated anomaly detection in reports. Seven of eight customers say it sounds valuable, and the feature enters the roadmap.

What was not asked: what it would replace. Asked later, the answers are uncomfortable. Most of them do not currently look for anomalies at all, so nothing would be displaced; the concept adds a new thing to their week rather than removing one.

The two who do look for anomalies describe a different job. They are not hunting for surprises, they are trying to be able to say in a meeting that nothing was missed, which is a completeness check rather than a detection feature.

Seven positive reactions and one useful finding, and the finding only appeared because somebody went back and asked about displacement.

Where teams get it wrong

• Testing usability instead of desirability. Answering can they use it when the question was should we build it.
• High-fidelity concepts. The idea stops being open to question.
• Rating scales. Fours from people who will never adopt it.
• Not asking what it replaces. The single question that separates interest from politeness.
• Testing the user and not the buyer. In B2B those are different people with different answers.
• Treating a good reaction as demand. It is a reason to continue, not a decision to build.