The People Who Build Technology Don't Always Understand the People Who Use It

A guide for founders building solo...

You're a founder who has been building something for six months. There's a pretty high chance you know exactly what it does. You know why you built it. You have probably explained the idea so many times that you can now explain it while brushing your teeth.

Now, it's the time of reckoning. You call a friend, seat them in front of your laptop or theirs, and say, “my guy check this out.” They look at the screen. They click around and stop. Then they keep asking you, in a way that starts to make you wonder why you became friends in the first place: "Okay… wait, what am I supposed to do here? Then here?… Okay."

And you are confused.

Because how could they possibly not know? You just told them. Are they dumb?

The answer to this is quite simple. You know too much.

You have been living inside the product for 6 months. They haven't. And this little difference is responsible for a lot of products in the market that make perfect sense to the person who built them and very little sense to the person who is supposed to use them.

This is particularly dangerous when you're building alone. Because when you're a solo founder, there may be nobody sitting across the table from you asking uncomfortable questions.

Nobody says: "Why are we building this?" Nobody asks: "Who actually wants this?" Nobody says: "What evidence do we have?" Nobody says: “Is this necessary?”

You can have a meeting with yourself and everyone in the meeting can agree that your idea is brilliant. It is a very efficient meeting. It is also potentially disastrous. So if you are building a product alone, I want to give you something before you build another feature.

You are the founder. You need your vision, no doubt. But you need to make room for something else there too. That is, your customer's reality.

Your idea is not the customer's problem

Let's say you wake up tomorrow with an idea. You want to build an app that helps people remember their appointments. You can already see it. A beautiful interface. An appointment log. All the cool stuff. Maybe even little animations when you successfully attend an appointment. You are excited. You start building. You tell your friend. Your friend says: "This is actually so cool." So you feel validated. You build some more and then you tell another person. They also think it's cool. Now you're really cooking.

Except there is a tiny problem. You have spent all this time validating your solution. You haven't really investigated their problem. This issue sounds small until you realise how much of a difference it makes. Your customer does not wake up thinking: "I need an application with a timer, a reading log and a social voice input." They wake up thinking something more like: "I have forgotten this appointment again. This is not good."

Those are problems. Your application is a proposed answer. And if you're building solo, this is probably one of the first things you need to learn about building products: Do not fall in love with the answer before you understand the question.

Steve Blank, who developed the Customer Development methodology, puts this idea rather bluntly: founders begin with hypotheses about customers, problems and business models, and those hypotheses have to be tested outside the building. He argues that founders should validate the problem and need before assuming that their solution is what people want.

You are not your customer

This sounds obvious. It is also one of the easiest things to forget. You might be building a product because you have the problem. That can actually be a very good place to start. You understand the frustration personally and you know what you wish existed. You may even be the first person who uses the product. But eventually, you have to ask yourself a slightly uncomfortable question: Am I building this for people like me, or am I building this for people as I imagine them?

Because those aren't necessarily the same thing.

Maybe you are a twenty-six-year-old founder who works from a laptop all day, understands technology, downloads new apps for fun and thinks figuring out a new interface is enjoyable.

Your customer who actually has that problem your app solves might be forty-seven. They might use one business application because their company requires it. They might hate learning new software. They might have no idea what your beautiful little icon means.

You might think: "They'll figure it out." Maybe. But why should they have to? They have other things to do. You are asking them to spend their time learning your product. They are asking your product to help them with something. Those are two very different relationships.

The founder knows the story. The customer sees the thing.

You know that button says "Smart Import." You know why you called it that. You know it imports files. You remember painstakingly that the feature took three weeks to build. You know it is connected to the AI system you spent another two weeks setting up. You know it is one of the most important features in the product.

The customer sees: Smart Import. And thinks: "What does that mean?" You have context. They have their screen only. This is why founders can sometimes look at a product and think it is obvious. The product is obvious to them. They have been staring at it for months. They have had conversations about it. They have designed it. They have built it. They have fixed it. They have probably complained about it. They know the entire backstory.

As a founder, always remember that your customer has none of that. They don't know what you intended. They only know what they can see. This is one reason user research and usability testing are useful. Nielsen Norman Group recommends observing real users because watching what people actually do can reveal problems and unmet needs that simply asking people questions may miss.

And you will develop a new emotion watching someone use your product for the first time. (I laughed while writing this part but I mean it). Like your friend, you might feel like insulting them, but over time you will discover that the thing you thought was obvious is not obvious at all. The thing you thought everyone would love is ignored. The thing you thought was a tiny feature becomes the reason they care.

Welcome to building for other people.

Before you build more, find the people with the problem

Let me teach you a little marketing tactic. First question to ask is: Who actually experiences the problem I am solving?

And if you are building software for restaurants, don't start with: "Restaurants."

Which restaurants? Small restaurants? Large chains? Restaurants with delivery? Restaurants with five employees? Restaurants that take orders through WhatsApp? Restaurants that already use POS software? Restaurants in Lagos? Restaurants in London? Restaurants whose biggest problem is inventory? Restaurants whose biggest problem is getting customers?

The more specific you become, the easier it becomes to understand the person you are actually building for. And you don't need a giant market research department to begin.

You can talk to people. Yes. People. Terrifying, I know. But if you are building something for humans, you eventually need to meet some humans.

Stop asking "Would you use this?”

Please. I'm begging. Do not walk up to someone and say: "I have this amazing app idea. Would you use it?" They will probably say yes. Not necessarily because they are lying. They may genuinely like your idea. Or they may like you. They may want to encourage you. They may not want to be rude. They might have even started imagining a version of your product that is much better than the one you will eventually build. And most importantly, liking an idea is not the same as changing your behaviour for it. We see this all the time as product marketers.

Instead, ask about what already happened before. Ask:

• "Tell me about the last time you had this problem."
• "What did you do?"
• "What are you using right now?"
• "How often does this happen?"
• "What is the most annoying part?"
• "Have you tried anything else?"
• "Why did you stop using it?"
• "What happens if you don't solve it?"
• "How much time does this take you?"
• "Have you ever paid for a solution?"

From experience, I've learned not to disclose your idea while asking all of these questions… at least not at the beginning.

These questions are boring. That is good. Because boring questions can produce very interesting answers. If someone says: "Yeah, I'd definitely use an app that helps me manage my invoices." That tells you something. If they say: "Last Tuesday I spent three hours going through WhatsApp messages because a customer couldn't find the invoice I sent them six months ago, so I made a spreadsheet to track every invoice." That tells you much more. Now you have behaviour. You have a situation. You have pain. You have a workaround. You have evidence that the problem exists. That is much more useful than "sounds cool."

Go looking for the workaround

One of my favourite questions for a founder to ask is: "What are you doing today?" Because if your product doesn't exist yet, people are still doing something. They're not sitting around waiting for you to create it.

Maybe they're doing it badly. Maybe manually. Maybe expensively. Maybe with three different tools. Maybe with a notebook. Maybe with WhatsApp. Maybe with Excel. Maybe with a sticky note on their wall. Maybe they have hired someone. Maybe they have created a ridiculous system that makes sense only to them.

These workarounds are gold. Because a workaround is evidence that someone is trying to solve a problem.

Imagine you want to build a tool for freelancers to track payments. You ask someone how they do it. They tell you: "I have a Google Sheet, then I check my bank statement, then I message clients on WhatsApp if they're late." Now you're learning something. You can ask: "How often do you do that?" "How long does it take?" "What happens when you miss one?" "Why didn't you keep using it?"

Suddenly you're not designing from your imagination anymore. You're designing from someone's actual life.

Find the people who have the problem badly

Not everybody with a problem is a customer. I say it again: Not… Everybody… With… A… Problem… Is… A… Customer.

Someone might say: "Yeah, it would be nice if that were easier." And then continue living exactly as they are. That's different from: "I hate doing this every week. I've tried three things and none of them work." You must notice the difference between the two. The second person has given you something important. Evidence of pain. And pain comes in different forms:

• It can cost money.
• It can cost time.
• It can create stress or embarrassment.
• It can make someone look incompetent.
• It can make something unnecessarily difficult.
• It can prevent someone from doing something they really want to do.
• It can simply annoy them every single Tuesday.

You need to find a problem that matters enough for someone to do something about it. How important is this problem in their actual life?

You don't need everyone

This is another place where founders get themselves into trouble. You have an idea for a product. You ask: "Who is my target audience?" And the answer somehow becomes: "Everyone." Everyone who uses a phone. Everyone who reads. Everyone who owns a business. Please. Everyone is a very large group. And when you try to build for everyone, you end up making decisions for nobody in particular.

You don't need everyone to care before your product can make it in the market. You need the right people to care enough. Maybe your first ten customers all have something in common that you didn't expect. Maybe they're all freelancers. Maybe they're all mothers. That pattern gives you somewhere to look.

Ask what "better" actually means

This is where your product can start taking shape. Imagine you're building a budgeting app. You think: "People need AI-powered financial insights." Sounds impressive. Then you talk to customers. And they say: "I don't know where my money goes." That is different. You ask more questions. They say: "I get paid, I pay my bills, I buy things throughout the month and then somehow I'm broke before payday." Now you understand the situation better.

Maybe they don't need an AI financial analyst. Maybe they need a very simple way to see where their money went. The customer doesn't care that you can build a sophisticated model. They care that they stop wondering where ₦200,000 disappeared to. (honestly, if it was me, I'd care too).

But this is why product decisions should eventually connect back to customer outcomes. Harvard Business Review has made a similar argument before in its work on "jobs to be done": companies can collect plenty of customer information and still miss the underlying reason people choose one solution over another.

Understanding the job a customer is trying to accomplish helps connect product development to what actually matters to them. Your customer may ask for a feature. But underneath that feature is often a desired outcome. Your job is to find it.

Your customer is not your product designer

Now, before I make you go interview twenty people and then build exactly what they tell you, let me stop myself. Customers are not always good at designing the solution. They know their lives. They know their problems. That's about all of it. That doesn't mean they know the best technology to solve it. If you ask: "What should we build?" you may get: "An app." "AI." "A dashboard." "A WhatsApp bot." "A button here."

Interesting. But don't immediately start coding. Ask why.

If someone says they need dark mode. Why? "Because I use the product at night and the white screen hurts my eyes." Now you know something. The feature request was dark mode. The need was comfortable nighttime use. You have more freedom than you thought. Maybe dark mode is the right answer. Maybe it isn't. The customer gave you the problem. You still have to design the solution.

Watch people use the thing

Eventually, you need to stop talking about the product and put it in front of someone. This is where things get very interesting. Give someone the prototype you built. Don't explain everything. Don't sit there saying: "Okay, this button is for..." If you do so, you're cheating. Let them use it. And watch how they use it. Where do they click? What do they ignore? What do they try to do that your product doesn't allow? What do they do completely differently from what you expected?

You may feel an overwhelming urge to rescue them. Don't. Your customer will not always have you sitting beside them whispering: "No no, click the little thing on the left." If your product needs you there to explain how it works, that is useful information.

Nielsen Norman Group recommends early and repeated testing with real users to uncover usability problems, and distinguishes this from simply asking users for opinions about a design.

The person struggling with your prototype is not failing your test. Your prototype is being tested.

Keep talking to customers after you launch

Customer research isn't a pre-launch ceremony. You don't interview ten people, launch the product and announce: "Okay, my work here is done."

Your customers are going to keep teaching you. They will tell you where they get confused, what they expected, what they love, what they hate, what they don't use, what they hacked around, what they wish existed, why they left, and why they came back.

Customer support is research. Reviews are research. Churn interviews are research. Sales calls are research. Usability tests are research. Watching someone use your product is research.

The entire business can become a learning system if you pay attention.

But what if customers disagree? They will. One person wants dark mode. Another doesn't care. One person wants AI. Another thinks AI is unnecessary. One wants a cheaper plan. Another wants more features. One says your onboarding is too long. Another says it isn't detailed enough.

Congratulations. You have customers. Now you have to think.

Your job is not to make every customer happy individually. Your job is to identify patterns and make decisions. Maybe one request belongs to a niche. Maybe another is a loud opinion from one person. Maybe five people are describing the same problem in completely different words. That's where your judgement matters. Remember that customer research gives you evidence. It does not remove the need for thinking.

Marketing is already happening

If you have been thinking: "I'll deal with marketing when the product is finished," I have bad news. You have already been doing marketing. You just didn't call it that.

When you decided who the product is for, that's marketing. When you figured out what problem matters most to them, that's marketing. When you tried to understand how they describe the problem, that's marketing. When you decided which benefit to communicate, that's marketing. When you figured out why they should choose you instead of what they're using now, that's marketing. When you decided what your product should be known for, that's marketing. It's all marketing and more marketing.

Marketing isn't the Instagram post you make after the product is finished. That post is one tiny piece of it.

Your job is not to be right

I think this is probably the hardest lesson for a founder. You believed in your idea enough to start. That belief is useful. You need some stubbornness to build anything. But there is a difference between being committed to the mission and being committed to every assumption you made about it. You can say: "I believe this problem matters," and still say: "I was wrong about how people solve it." It's not a win-lose situation.

Steve Blank describes the process as having "strong beliefs" that are validated or modified by evidence gathered outside the building. I like that. Strong beliefs. Loose enough hands to change them.

And finally, as a founder, you need to be willing to leave the comfortable little room in your head where your product makes perfect sense and go find out what happens when another person touches it. Because the person who builds the technology will always know something the person using it doesn't. They can't know more about the product than you. You can't know more about their problems than them.