Before you build the solution, make sure you understand the problem.

There is a temptation in technology to fall in love with what we can build.

A new technology emerges, a developer discovers a new capability, or an entrepreneur has an exciting idea.

A team gets together and starts asking: “What can we build with this?”

It sounds like innovation and sometimes, it is. But often, it is how we end up with products nobody really needs.

The truth is that technology has never been the problem. The problem is that we sometimes start with the technology instead of the people.

A great idea can still solve the wrong problem.

Imagine a company spends six months building an impressive app. It has beautiful interfaces, it is fast, and it has dozens of features. The technology behind it is sophisticated. The team is proud of what they have created. Then they launch but nobody cares.

This is not because the product is bad. It is rather because the problem it solves isn’t painful enough for anyone to change their behaviour.

We can spend months asking:”What features should we add?” without spending enough time asking:”What are people struggling with?”

There is a difference. One starts with the product, the other starts with the person.

Technology should begin with a question.

Before writing the first line of code, there should be a conversation.

Talk to the business owner who is still managing operations with spreadsheets.
Talk to the student who has completed three online courses but still doesn’t know how to get practical experience.
Talk to the employee who spends half their day looking for information that should be readily available.
Talk to the customer who has learned to tolerate a frustrating process because they don’t believe anything will change.

Ask questions and listen not just for what people say they want but for what they repeatedly struggle with because people don’t always know what solution they need.

A business owner may say, “I need another employee.”
But after asking better questions, you may discover that the real problem is poor task allocation.

A student may say, “I need another certification.”
But perhaps what they really need is practical experience and mentorship.

A customer may say, “I need a faster app.”
But the deeper problem may be that the entire process is unnecessarily complicated.

The request is not always the problem. Sometimes, it is only the symptom.

Listening is a product development skill

We often associate technology with coding, engineering, data, artificial intelligence and innovation.
But there is another skill that can determine whether any of those things matter:

Listening; to users, to businesses, to employees, to frustrations, to workarounds and to what people do when the system doesn’t work for them.

Those workarounds can tell you more about a problem than a hundred assumptions made in a boardroom.

If customers are using your product in a way you didn’t anticipate, pay attention.
If employees have created spreadsheets to compensate for a missing feature, pay attention.
If people are combining three different tools to complete one task, pay attention.
If customers keep asking the same question, pay attention.
There may be a product opportunity hiding inside the inconvenience.

The best products often begin with an uncomfortable observation.

Sometimes innovation doesn’t begin with a revolutionary idea. It begins with someone saying: “Why is this still so difficult?”

Why does this process require five phone calls?
Why does this business still keep important information in notebooks?
Why does a student have to know someone before getting practical exposure?
Why does an employee need to ask three different people before finding a document?
Why are we doing this manually when technology could make it easier?

These questions are powerful because they force us to look beyond what is normal. Something can be common but it doesn’t mean it is working.

People can become accustomed to inefficient systems.
They can learn to work around them and stop complaining. They can simply accept them as the way things are.

This is where good product builders have an opportunity. Not to create technology for the sake of technology but to notice the friction everyone else has learned to ignore.

Build for people, not applause.

There is another trap worth discussing.
Sometimes we build products that impress other technology people rather than products that genuinely help users.

A complicated feature can look impressive in a product demo. But if the average user doesn’t understand it, it isn’t necessarily good technology.

The most sophisticated solution isn’t always the best solution. Many times, the best product is the one that makes something complicated feel simple.

This is why understanding the context in which people will actually use the product is also very important.

What device do they have?
How much time do they have?
What do they already know?
What frustrates them?
What would make them trust this product?
What would make them abandon it?
What happens when the internet is poor?
What happens when the user makes a mistake?
What happens when the product becomes part of their everyday life?

These aren’t just technical questions.They are human questions. And great technology has to answer both.

The real job isn’t building technology.

Anyone with the right resources can build something.
The harder question is whether what you are building deserves to exist.

Does it solve a real problem?
For whom are you building?
How painful is that problem?
How are people solving it today?
What happens if nothing changes?
Would they actually use a better solution?
Would they pay for it?
Would they recommend it?

And perhaps the most important question:
Are we solving the problem people actually have, or the problem we assume they have?

That question can save months of development. It can save money, prevent unnecessary features and stop a team from building the wrong product altogether.
Technology is powerful. But technology without understanding can simply make the wrong thing faster.

The goal shouldn’t be to build because we can. The goal should be to build because it matters. And before we build anything worth using, we have to be willing to listen.