What does a large company pay for when it skips the customer?

I ask for a conversation with a user before the build. The team says there is no time. The Nielsen Norman Group keeps a list of the lines founders, leaders and product managers still use, and that time line is the oldest. The people who use it often found the time to build the wrong thing, and then the time to pay for a repair.

Excuses that protect a decision already made

Time has a cousin. The engineers are waiting on the designs, so research has to wait. On the group's account, those engineers usually have technical debt they could clear while someone sits with a customer. A few conversations can happen before a feature exists, and they cost less than the meeting in which everyone argues about what to build next. A research department can be expensive. Building the wrong feature twice costs more.

Then comes the claim that users do not know what they want. The group treats the old faster-horses story as a dodge. Users can describe the problem and the job they need done. They do not know your constraints, and they do not owe you a business model. Turning the problem into a product is the team's work. Study the need and the behaviour. Teams that gave people exactly what they asked for, and then watched them stay away, had collected an order form.

An A/B test can tell you which of two built versions moved a metric. It cannot tell you why, and it cannot start before something exists. The group notes that firms who test every small change often see a string of tests with no significant effect, because neither version came from a customer problem. Fear does the rest of the damage. If a founder treats the first product as a personal idea, talk to people before that idea is fully built, while a change is still cheap.

What the large company actually pays for

The harder pattern shows up in larger companies, and it survives every rebuttal of the polite excuses. The group's account of the incentive is plain. Inside many of these firms, shipping something that helps the user brings no real benefit to the team that did it. The firm rewards teams for shipping new features quickly, and for chasing the trend that is current. By the time the feature reaches users and fails to help them, the firm has promoted the people who drove it, or those people have moved on to the next launch. The pay packet follows the launch. A miss after launch rarely costs the sponsor.

If the budget cannot change when the finding says you are wrong, skip the study. Research you will ignore is a cost with no decision attached. A handful of the right conversations can show the repeated problem. You do not need the whole user base on a call.

Design thinking that survives the board pack keeps a problem honest once a committee is in the room. Someone still has to speak to a customer before that committee falls in love with the feature. CX maps that operators will actually use help when the map came from those conversations.

Collective Campus runs customer experience work with the people who have to change the service after a finding. The session can put a real customer in the week. It will not repair a bonus plan that pays for the launch and looks away from use.

What to ask before you book another study

Ask these of the study you are about to commission.

1. Which decision can this research change, and who has the authority to make that change?
2. Are we asking about the problem and the behaviour, or collecting feature requests the roadmap already lists?
3. If the finding says stop, does anyone in the room gain from stopping?
4. Who spoke to a customer this month, and what did the team change afterwards?

If nobody gains from stopping, another round of interviews will decorate the roadmap you already printed. Change what the launch bonus pays for. Until you do, the skipped conversation is the customer research habit your firm has chosen.