We keep building things people don't use.

What to do when you keep building things people don't use

A small town outside Bogotá, the mid twenty-tens. Erika Cardona is working for the Colombian Red Cross on community-resilience programmes aimed at women in post-conflict regions. The training the NGO has designed — financial literacy, small-enterprise skills, community leadership — is, by every measure that matters to the people who designed it, well-targeted.

It is also under-used.

Sign-ups are good. Attendance is not. Women who register for the training programmes don't show up. Women who show up to the first session don't return. The cohort the programme has been built for is doing what cohorts do when the programme isn't working — they are quietly absent.

The instinct inside the team is to adjust the training content. Simpler modules. Shorter sessions. Better trainers. Each adjustment is intelligent, well-meant, and produces no change in the attendance numbers.

Cardona's diagnostic, described later in an International Federation of Red Cross article on the programme, starts somewhere else.

She notices that almost every woman who has signed up and not attended has young children. And that childcare in the communities in question is not its own service — it is the woman herself.

The training isn't being under-used because the content is wrong. It is being under-used because the NGO has designed training that requires, as an invisible prerequisite, that the participants already have something they do not have.

Cardona's intervention is not to redesign the training. It is to build Safe Spaces for Children alongside the training centres, staffed by trained volunteers. Participation triples.

When you keep building things people don't use, the honest answer is almost never that you need a better version of the thing. It's that the thing depends on a prerequisite you have not noticed, or have assumed away, and that the prerequisite is the real product. Cardona built the prerequisite. The training didn't change. The conditions under which the training could be used changed, and the use followed.

So let's go to the office and work through it.

First read why the work is being ignored

"We keep building things people don't use."

The feeling is ignored.

The product ships. The features are intelligent. The team is talented. And the engagement numbers say what they say. Every release is greeted with the same polite indifference, and the indifference has stopped being a surprise.

Two choices. They look like the same engagement problem. The first move is different.

When the team is in love with its own ideas

Choice one: the team has fallen in love with their own ideas. The work is emotionally invested in the elegance of what's being built. The feedback loop from users has been politely ignored because it contradicts the investment.

If that's the read, make them watch. Sit the developers and designers in a room with a screen recording of a real user failing to navigate their most recent feature. No commentary. No defending the design. Just watching.

Jakob Nielsen has been clear about this for thirty years. The feedback users give you in interviews is polite. The feedback they give you by struggling in silence is not. And the silence is much harder to argue with. The goal isn't to humiliate the team. It's to break the emotional attachment long enough for the evidence to land.

When the pain simply isn't acute enough

Choice two: the problem isn't painful enough. The team has been solving real problems, just not problems users are prepared to change their workflow for. The work is well-aimed in principle and not well-aimed at anything the user is currently spending time being frustrated by.

If that's the read, ask the user what they currently do about it. If the answer is nothing, we just deal with it — kill the feature.

Teresa Torres, formalising what she calls continuous discovery, has named the test plainly. The absence of a current workaround is the clearest possible signal that the pain isn't acute. People build their own workarounds, however ugly, when the pain is real. If there is no workaround, there is no pain — and no amount of better product is going to create the pain to justify itself.

How to stop jumping to solutions too early

In-love-with-the-idea, or not-painful-enough. Same engagement problem. Two different first moves.

Three tools. The discipline is to stop the team from jumping to solutions before the problem has earned it.

Make every alternative solution visible

The first is

the Opportunity Solution Tree.

The Opportunity Solution Tree was developed by Teresa Torres and codified through her Product Talk writing and the two thousand and twenty-one book Continuous Discovery Habits. The framework draws on the deeper jobs-to-be-done tradition we covered in scenario twenty-one and the opportunity-discovery lineage that runs through the design-thinking literature. The tree is structural rather than novel — its value is forcing the team to make the discovery hierarchy visible.

The reason the Opportunity Solution Tree matters when you keep building things people don't use is that most we-keep-building-things-people-don't-use problems are we-kept-building-the-first-thing-we-thought-of problems in disguise. The team commits to the first solution that surfaces and never seriously considers alternatives. The tree forces the alternatives onto the page where they can be compared.

The unique insight is the branching structure. From a top-line outcome, the tree branches into customer opportunities (the pains and gains we have learned about). From each opportunity, it branches into possible solutions. Most teams discover, when they fill in the second branching honestly, that they considered exactly one solution per opportunity — the first one that came up — before committing.

What you get is a structural test for solution-space coverage. If a node has only one child solution, the team has not actually considered alternatives. The tree makes the lack of consideration visible without anyone having to accuse anyone of being unimaginative.

So. How to draw it.

Outcome. One sentence at the top. Increase weekly active users by twenty per cent.

Opportunities. Three to five pains or gains beneath, drawn from real customer evidence. Onboarding feels overwhelming. Hard to find the right feature. No reason to return next week.

Solutions. Per opportunity, three to five candidate solutions. Guided tour. Empty-state CTAs. Cmd-K search. Personalised home. Weekly digest. Streak. The structural value is the comparison — anywhere the tree has only one solution branch is where the team has been committing to the first idea.

Experiments. Per solution, what would you build and what would you measure to find out which actually moves the opportunity?

Depth before width — choose one opportunity, explore many solutions, test cheaply.

The tree is the working artefact, not the deliverable. It lives on the wall, gets updated as the team learns, and is the place the but we already considered that conversation gets settled by reference rather than from memory.

Test the solution before engineering starts

The second is

Solution Interviews.

Solution Interviews complement Problem Interviews (which we covered in scenario twenty-eight) and were formalised through the same lean-startup and customer-development tradition. Where Problem Interviews probe the customer's current pain and workflow, Solution Interviews probe whether the team's proposed solution actually addresses the pain in a way the customer would change their behaviour for. The deeper lineage runs through the concierge MVP tradition and the broader user-research practice formalised in tools like Maze, dscout, and UserTesting.

The reason Solution Interviews matter when you keep building things people don't use is that they put the candidate solution in front of users before engineering starts, not after. The disappointment surfaces while it is cheap rather than after the team has shipped.

The unique insight is the positioning between problem-validation and build. Most teams interview customers about their pain (problem validation) and then go straight to building. The middle step — testing the candidate solution — is the cheap one that gets skipped. The cost of skipping it is, typically, a feature that ships and doesn't get used.

What you get is a structural defence against shipping the wrong solution. The interview is short, cheap, and concrete. Here is what we are considering building. If we built it, would you use it? Show me when in your day you would use it. Show me what you currently do instead.

So. How to run it.

Pick. Same target segment as the eventual product. Compensate them. Schedule them inside a week.

Show. Low-fidelity sketch, wireframe, click-through prototype — whatever lets the user understand what is being proposed without the team committing to execution.

Ask. Not whether they like the solution. Walk me through what you currently do when you have this problem. The current workflow is the diagnostic; the candidate solution either fits into it or doesn't.

Watch. Where, in the user's existing workflow, would the candidate solution sit? If they can't tell you — or if it would require them to change their habits before they would use it — the candidate solution is unlikely to land.

Aggregate. Across five interviews, the candidate solution either survives or doesn't. The team that built it gets to learn this before the engineers commit a sprint to it.

Validate before you build, not after you ship

The third is

Dual-Track Agile.

Dual-Track Agile was popularised by Jeff Patton in his writing through the late two-thousands and twenty-tens — User Story Mapping (two thousand and fourteen) is the canonical reference — and traces back to the discovery and delivery split that Marty Cagan and the Silicon Valley Product Group have written about extensively. The framework runs two tracks simultaneously: a discovery track (validating problems and solutions) and a delivery track (building validated work).

The reason Dual-Track Agile matters when you keep building things people don't use is that the workflow makes it impossible to validate while the team is building. Most teams default to a single-track workflow — the engineers build whatever the product team has next, and validation happens (when it happens) after the build has shipped. The structural problem is that the workflow doesn't have a place for test the solution before commitment.

The unique insight is the parallel-track structure. Discovery and delivery don't take turns; they happen simultaneously. The discovery track is one or two weeks ahead of the delivery track. By the time engineering starts on a feature, that feature has been through Solution Interviews and validated against the Opportunity Solution Tree. The team isn't validating after they ship; they're validating before they build.

What you get when the workflow is dual-track is a structural mechanism for keeping the team out of building things people don't use. The discovery track does the testing; the delivery track only gets work that has already been tested.

So. How to organise it.

Discovery. Interview customers. Frame opportunities. Prototype solutions. Test assumptions. The track for figuring out what to build — product, design, research — running Concept Testing and Solution Interviews on candidate features.

Delivery. Plan sprint. Build. Ship. Measure in production. The track for actually building it — engineering — taking on features that have passed discovery.

Handoffs. A feature only crosses from discovery to delivery when discovery has produced sufficient evidence that the feature will be used. The team agrees what sufficient evidence means in advance — usage signal from prototype, qualitative interview saturation, quantitative test result.

Discovery always runs one cycle ahead of delivery. The temptation under deadline pressure is to skip discovery on the easy features — that's exactly how teams accumulate the unused-features problem the workflow is supposed to prevent.

The framework is the structural solution to the build-things-people-don't-use problem. Every feature has a discovery record before it has a delivery commitment.

A precedent: the tool was fine, the theory of uptake was not

That's the toolkit. One more story before we close.

The Cardona story we opened with showed the discipline of recognising that the thing the team kept building wasn't being used because it depended on a prerequisite the team hadn't noticed. The story we close with shows the same move at a different scale — a founder who realised the tool she had built was a tool for a job nobody in the room was incentivised to do.

Los Angeles, two thousand and fourteen onwards. Melissa Hanna co-founds Mahmee in two thousand and fourteen with her mother, a nurse, as a maternal and infant health platform aimed at closing the gaps that open up in the days and weeks after an American mother leaves the hospital — a period the US healthcare system is structurally bad at.

The original product is software. A care-coordination platform for existing providers, designed to reduce information loss between obstetricians, paediatricians, lactation consultants, and the mother herself. It is the right problem.

It is not the right product.

The diagnostic Hanna describes in subsequent podcast appearances is structural. Providers pilot the platform. They tell Mahmee it is valuable. They do not integrate it into their workflow in any durable way. Because the integration cost, in staff time, is real — and the incentive to absorb that cost is not.

The mothers who need the coordination are not the ones buying the software. The providers who would buy the software have no incentive to do the integration work the software requires. The product is sitting in the gap between two parties — the people who need the outcome, and the people who would have to do the work to deliver it — neither of whom is structurally positioned to pay for it.

Hanna's decision, taken as the team works through successive funding rounds, is to stop trying to sell the software to providers and start delivering the care directly. Mahmee staffs the coordination layer the company had been building tools for. They charge mothers and payers for the outcome rather than charging providers for the tool.

So.

Cardona at the Colombian Red Cross built the prerequisite the training depended on, and the training was used. Hanna at Mahmee replaced the tool with the job, and the job got done. Two different cuts at the same diagnosis — the team kept building things people didn't use because the team had been building against an unstated dependency or selling against an unstated incentive.

When you keep building things people don't use, there is a version of the problem where the product is right and the sales process is wrong. There is another version, less comfortable, where the product is a tool for a job that nobody in the room is incentivised to do.

Cardona built the prerequisite. Hanna stopped selling the tool. She hired the people who would do the job and sold the job.

The tool was fine. The theory of who would pick it up and run with it was not.

So. Your Next Move from this playbook.

How many alternative solutions have you actually considered for the opportunity you're about to commit to — or have you been defending the first idea since the start?