The launch note went out on a Thursday. By the next Tuesday the usage line was flat, support had a handful of confused tickets, and the squad had already pulled the next item forward. Nobody in the room could name a person outside the building who had wanted the thing.
This is a familiar week for anyone who funds product work. A team argues the roadmap in a meeting, picks the idea the loudest stakeholder can describe, and builds it. The customer hears about it when it is already live. The retrospective then blames adoption, as if a person were obliged to be grateful for something they never requested.
Laura Klein, writing for the Nielsen Norman Group, says too many organisations still skip user research before they build new products and features. She has spent years watching teams find the time to build the wrong thing, then pay someone to repair it. She describes the result as the bad, unresearched and unwanted feature. Users, she notes, generally know what they do not want, and it is the thing you built without talking to them. Shipping work that misses the need wastes the calendar and annoys the people you meant to help. It also takes longer, because you build, you discover the miss, and you build again.
Ask about the job
The excuse Klein is tired of hearing is that people do not know what they want. Users can tell you the problem they need solved and what they are trying to get done. They are rarely the right authors of your solution. In her account, user research is the work of understanding needs, motivations and problems, and then deciding what to make. A list of requested features, built in the order they arrived, is how a team ships something that sits unused. Design thinking training changes the order of that week.
The team brings one live offer they are about to fund. They sit with a person who would have to live with it, and they ask about the last time that person tried to get the job done. They write the need as a situation, with a person and a constraint, before anyone names a solution. Then they make something rough enough to show, and they show it while the roadmap can still change. A wall of sticky notes about an idea the sponsor already loves is a different meeting. It feels busy. The customer is still absent.
The room we book
Collective Campus builds high-performance teams for the AI world. The design thinking workshop is the room for that sequence. We use your challenge, a person who actually has it, and a decision the sponsor can defend on Monday. How to get users into the work while you are still shaping the service is in how to design a service with its users. How a learning lead chooses a programme that starts from a live problem is in human-centred design training for corporate teams.
Before you book
Bring the offer you are about to fund, and the name of a customer who has not seen it. If you cannot name that person, the day will decorate a decision the meeting already made. Send me the offer in one sentence and the name of someone who uses the current service. We will shape the workshop around the conversation you have been postponing.
