Most founders would answer “with them” without hesitation.

But when you ask them to describe the last time a real user sat beside them while they made a product decision, the room goes quiet.

There is a difference between saying you care about your users and actually building in a way that reflects their reality. One is an intention. The other is practice. And most founders, if they are honest, are building for people; designing solutions at a distance, then hoping users adapt.

The quiet trap of building for

Building for users sounds responsible. You talk to customers, run surveys, read feedback, and ship features you believe will help them.

But here is what that process quietly assumes:

• That you understand their problem well enough to solve it from a distance.
• That your interpretation of their feedback is accurate.
• That a finished product placed in their hands will fit a workflow you have never fully seen.

Those are expensive assumptions. And they are the reason many products launch to polite applause and quiet abandonment. Co‑creation and participatory design research shows consistently that when users are brought in as active partners rather than passive respondents, products come out more usable, more relevant, and more likely to stick.

Building for people keeps you in charge of the story. Building with people puts the truth in charge.

What building with really means

This is not about running a focus group or sending a five‑question Type form. It means changing when and how your users show up in the process.

At the problem stage

Before you sketch a single screen:

• Sit with five to ten people who live with the problem and ask them to walk you through their current process, step by step.
• Do not guide them toward your solution; let them show you what their actual day looks like.
• Mark the exact moments where they hesitate, copy‑paste, pick up the phone, or open a new spreadsheet.
• Let them correct your notes in real time; they should feel like co‑authors of the problem, not research subjects.

What you learn here will almost always surprise you.

At the design stage

Instead of presenting a polished interface and asking “Do you like it?”:

• Sketch two or three rough flows on paper or a whiteboard in front of them.
• Let them move the steps around: “In your actual day, would this happen before or after this?”
• Ask them to role‑play the workflow using your rough screens.
• Watch where they naturally pause, click the wrong thing, or ask a question you did not expect.

Teams that make users genuine co‑designers at this stage report discovering ideas they would never have generated alone;  because users bring real constraints, creative workarounds, and contextual knowledge that no internal session can replicate.

At the iteration stage

Building with users does not end at launch.

Share trade‑offs openly: We can automate this step or improve the report view. Which one changes your Monday more? Let their answers drive prioritisation, not internal opinions about what is technically interesting.

Stay close to the original problem as you ship. It is easy to drift into a feature factory that no longer maps to the pain that started everything. The discipline is to keep returning to that first question: Does this make the problem smaller for the person we set out to help

If you cannot explain why a feature exists in terms of the user’s Monday morning, it probably should not exist yet.

Two founders who built with the people who had the problem

Temie Giwa‑Tubosun – LifeBank, Nigeria

Temie did not start LifeBank by designing an app. She started by sitting inside the problem.

Her entry point was not a tech insight. It was a human one: watching Nigerian mothers die from entirely preventable blood shortages; blood that existed in one hospital while patients in another were bleeding out.

Before building anything, Temie and her team spent time inside hospitals. They talked to doctors already managing blood logistics through informal phone calls and personal favors. They talked to blood banks sitting on surplus. They mapped the actual handoffs, the gaps, the delays, and the trust issues between institutions.

That deep proximity to the problem is not a pitch competition or a tech trend; is what shaped LifeBank’s model: real‑time blood discovery, logistics coordination, and last‑mile delivery via motorcycle. The technology came after the workflow was understood. Today LifeBank operates across Nigeria, Kenya, Ethiopia, and Sierra Leone, delivering blood and essential medical supplies to hospitals in under 55 minutes.

Temie did not build a healthcare app for Nigerians. She built a supply chain with the people who were already trying to keep it running by hand.

Brian Chesky – Airbnb, USA

When Airbnb was struggling to grow in its early days, Brian Chesky did not commission a user research report. He flew to New York, knocked on doors, and stayed with Airbnb hosts.

He photographed their homes with them. He sat at their kitchen tables and asked what made a good guest, what made a host feel safe, and what the experience felt like from their side of the door. What he found was a product full of assumptions that did not reflect how hosts actually used it. Listings were blurry. Pricing was confusing. Trust was the real bottleneck, not features. He went back and redesigned around what he had actually seen.

Chesky later called it “doing things that don’t scale.” But the real lesson was simpler: you cannot understand a person’s experience by reading about it. You have to be in the room.

Why this matters most in African markets

In African markets, the gap between “how I think people work” and “how people actually work” is wide.

The same workflow might involve a paper register at the front desk, a WhatsApp group for team coordination, a mobile banking app for payments, a shared Excel file for management reporting, and an informal verbal process that everyone follows but nobody has written down.

No amount of desk research will give you that picture. You only get it by sitting inside the environment and letting people show you their real day.

When you build with them:

• They correct your assumptions before you build them into the product.
• They show you what cannot change due to regulation, culture, cost, or trust.
• They show you where one small fix would feel like a miracle—the quiet change nobody pitched on a stage but that transforms how hundreds of people start their morning.

That is the difference between a product that wins a pitch competition and one that quietly becomes infrastructure in clinics, schools, logistics yards, and back offices across the continent.

The founder who builds with people has a different kind of confidence

When you build for people, your confidence comes from how good the product looks.

When you build with people, your confidence comes from something harder to fake:

• You have seen their process with your own eyes.
• You have watched them use your rough version and tell you exactly what to fix.
• You have heard them say, “This is exactly what I needed,” and you know they mean it because they helped shape it.

That confidence is not arrogance. It is evidence.

For non‑technical founders especially, this is where the real edge lives. You may not write the code. But you can own the room where the problem is defined, the options are explored, and the people who live the pain help decide what comes next.

A simple build with loop to start now

You do not need a research team or a budget. You need five people and a notebook.

Start by finding five people who live with the problem; one persona, one environment. A clinic admin, a school bursar, a dispatch coordinator. Then sit with them and map their current workflow together. Do not present your solution yet. Just draw the steps out and let them correct you; let them add the parts you missed. Once the map feels real, sketch one or two rough ideas in front of them and ask which feels closer to how their actual day moves.

From there, build the smallest version that fits their real day—no‑code, manual processes behind the scenes, whatever tests the core assumption fastest. Then sit with them while they use it for the first time. Watch everything. Say nothing unless they ask. The hesitations, the wrong clicks, the moments they reach for the phone instead, those are the next brief.

End every session with one question: “What would make this easier for you tomorrow?” That answer is your next sprint.

Then repeat.

The shift that changes everything

Building with people who have the problem asks one thing from you:

Give up the fantasy of the genius founder who figures it all out alone, disappears for months, and emerges with the perfect product.

In its place, you get something better: a product shaped by reality, adopted because people recognise themselves in it, and trusted because the people who built it actually showed up.

Let AI and no‑code handle the speed. Let your users help you handle the direction.

Are you building for your users or with them? The answer to that question will show up in your retention numbers long before it shows up in your pitch deck.