The Concept Car Problem

This vehicle had both side doors open and an interior arranged like a small living room. It was the most photographed thing in the hall and you cannot buy it. Every technology company has one of these, and most of them do not realise it: the version of the product that appears in the keynote, the launch video and the sales deck, which is meaningfully ahead of the version a customer receives. The gap is not always dishonest. It is always expensive.

What is the concept car problem in software?

It is the distance between the demo and the default. The demo has clean data, a configured account, the integration already connected and someone who knows the shortcuts. The default is an empty account, an import that half worked, and a person who has twenty minutes before their next meeting. Both are real. Only one of them is what the buyer gets on Tuesday.

The concept version is not a lie in the way people fear. Nobody at that stand claimed the vehicle was in production. The problem in software is that there is no equivalent signal. A screenshot looks like a screenshot whether the feature ships next week or next year, so the audience has no way to tell which one they are looking at.

Three ways to show a product, and what each one is for.

Version	Audience	Legitimate use	Risk if unlabelled
Shipped product	Buyers in a trial	Product pages, demos, pricing	None
Current release cycle	Buyers close to signing	Sales conversations, changelog	Timeline slips become broken promises
Roadmap or vision	Category and investors	Keynotes, category pieces	Buyers assume it exists today
Idealised demo data	Nobody, ideally	Internal testing	Cold start feels broken by comparison

Why does the gap cost more than it seems to?

Because it is discovered at the exact moment the buyer is most fragile. The trial or the first month of onboarding is when confidence is being built, and a feature that does not exist as advertised converts an enthusiastic new customer into a suspicious one in a single session. Recovering from that costs more attention than the original sale did.

It also poisons the parts that were true. Once someone finds one overstated capability they audit everything else, and things you genuinely do well now have to be re-proven. I have watched this happen on accounts we inherited, where the marketing had run ahead of the product for long enough that the sales team no longer believed their own materials.

There is an internal cost as well. Support and customer success absorb the difference, quietly, forever. A gap created in one launch becomes a permanent tax on a team that had no say in creating it.

Is showing the future ever the right move?

Yes, and category creation is one of the few cases where it is close to necessary. If nobody knows the category exists, a vision piece has real work to do. But that is a different asset from the product page, with a different audience and a different job, and it should look different enough that nobody confuses the two.

The other legitimate case is enterprise sales with a long procurement cycle. If the contract signs in nine months and ships in twelve, the roadmap is genuinely part of what is being bought. The requirement there is that it is written down as a roadmap, with dates, in the contract, rather than implied by a screenshot.

How do you keep marketing and product honest with each other?

Label the horizon. Three buckets: shipped, in the current release cycle, on the roadmap. Anything in the second or third bucket that appears in public gets marked. This is a five-minute convention that removes most of the risk, and the reason it is rare is that it makes marketing look less impressive in the short term.

Then put someone from delivery in the review. In our own process, work goes through an automated publish gate before it goes out, and 44 content pages on one account sit behind that gate specifically so that nothing ships claiming something the product does not do. A validator is cheaper than a retraction, and it does not get tired or political.

The last piece is a rule about demo environments. When we build demos for named enterprise deals, they use the prospect’s own data rather than an idealised set, which is more expensive to prepare and removes the argument entirely. A demo with their data closes better anyway.

A screenshot looks like a screenshot whether the feature ships next week or next year. That is the whole problem.

What should a buyer do about this?

Ask one question in every demo: is this in the release I would get today, and if not, when. It is a polite question and the answer, including how comfortably it is answered, tells you most of what you need to know about the company you are about to depend on.

Then ask to see the thing from an empty account. Anyone confident in their product will show you the cold start. Anyone who has been living in a concept car will find a reason not to.

Related: how positioning fails in an aisle, the demo that needed no explanation and why we gate everything before it ships.