When your customers struggle to explain what you sell

Riley Brown says Codex has become harder for him to explain in his videos. An explanation that once fitted in a short sentence now needs qualifications about products and ways of working. That interests me as a commercial problem: a product can become more capable while asking more of the person trying to explain it.

For a software company, I would take that concern into a customer conversation. What can the person who has just seen your demonstration explain to a colleague afterwards? They may have understood each feature while you were showing it. They still need a way to describe what the product would help them do, and where they would begin.

At Leapwork, I implemented a MEDDICC- and Command of the Message-based playbook across the commercial organisation, including Product, Marketing and Sales Engineering. That work gives me a particular interest in the explanation shared across those teams. If they each describe the product through their own responsibilities, the customer can end up having to assemble the connection.

I would ask the customer to describe the piece of work they would try first. Then I would listen to the explanation they would give the colleague doing it with them. Where do they hesitate? Which product distinctions do they have to explain before they can describe the useful result? Those questions can reveal something a successful demonstration leaves unresolved.

Imagine a sales manager considering an AI product to help prepare proposals after customer meetings. This is a hypothetical example. The manager needs to explain which information goes in, what the team will get back and what the salesperson still has to check. A colleague should be able to recognise the assignment from that explanation.

Now suppose the manager also has to explain which workspace to open, which agent can use the meeting material and whether the result can be edited in the place where the team normally works. Some of those distinctions may be necessary. Each one also gives the colleague another decision to make before they can try the product.

I would want to understand why those choices sit with the customer. Perhaps different permissions genuinely require different routes. Perhaps the company has added capabilities through separate products and has left customers to understand how they fit together. The response should follow the reason. A shorter product description will do little for someone who still cannot work out where to start.

Bring the customer's explanation back to the people responsible for the product and its commercial presentation. Work through the actual assignment together. Marketing may need a more specific description of who the product helps. Sales may be demonstrating too many possibilities before understanding the customer's work. Product may need to choose a sensible starting point for that work. Several of those things can be true at once.

There is another possibility worth taking seriously: the customer has understood the product and cannot see a useful enough reason to change. In that case, improving the explanation may help us learn why. It should leave room for the answer that our proposed use is not important to them. Repeating the pitch more clearly would miss what they are telling us.

The question becomes more difficult with a capable AI product because it can do many different things. An experienced user may value that breadth and want control over the setup. Someone arriving with a particular task may want the product to make more of those choices for them. I would examine those two journeys separately before deciding that either needs fewer features.

For the proposal task, a starting point organised around the assignment could help the team choose. The product would still need to explain which meeting material it can use and where the draft will appear. Those details belong where the person makes the relevant decision. Making the first sentence easy to repeat does not excuse a misleading account of what the product can do.

I would then watch someone attempt the task. If they can explain the purpose but stop at a choice between workspaces, we have found a different problem from an unclear description of the benefit. If they complete the task and struggle to see why the result is useful, the product team has something else to investigate. Those observations give the teams a more precise discussion than a general instruction to simplify.

Riley's post concerns his ability to describe products in content. It does not establish that a particular product change reduced adoption or sales. I think it gives commercial leaders a useful question to pursue: how much of our own product organisation are we asking a customer to understand before they can get value from it?

For the next release, put the customer's first task beside the new capability. Have someone outside the product team explain how they would begin, then let them try. Pay attention to the decisions they cannot make with the information in front of them. That gives Product, Marketing and Sales a concrete choice to resolve before asking the customer to explain it to anyone else.