Stop Asking What to Build. Ask What's Broken.

One of the easiest mistakes to make in Product Management is starting with the solution.

You have an idea.

It sounds useful.

You can already imagine the app, the features, the colours, maybe even the logo.
And suddenly, you're spending hours designing something before asking the most important question:
Does this problem actually need solving?

I've caught myself thinking about products this way too.

While working on projects such as Civora, a community-focused alert and reporting concept; Cura.io, a healthcare and community-support platform concept; and PoultryLink, an agriculture marketplace connecting different players in the poultry ecosystem, I've worked through very different problem spaces.

And one thing keeps becoming clearer:
Good product ideas don't begin with features. They begin with problems worth understanding.

1. Start with a problem, not a product

Instead of saying:
"I want to build an app for farmers."

Try asking:
"What makes it difficult for farmers to get what they need, sell what they produce or connect with the right buyers?"

That's a much better starting point.

When I was working on PoultryLink, for example, the problem space wasn't simply "farmers need an app."

It involved several groups: farmers, buyers, suppliers and logistics providers.

That immediately creates better product questions:

• How do farmers currently find buyers?
• How do buyers find suitable suppliers?
• How is delivery handled?
• Where does the process break down?
• What happens when the people involved are far apart?
• What happens when internet access isn't reliable?

Those questions are more useful than jumping straight into features.

The same principle applies to Civora.

Instead of starting with:
"Let's build a community-alert app."

You can start with:
"What happens when someone notices a problem in their community and wants it addressed?"

Now you have something to investigate.

Who do they report it to?

• Do they know who is responsible?
• What do they currently do?
• What happens after they report it?

The product comes later.

The problem comes first.

2. Go where people already talk about the problem

Once you've identified a problem space, look for evidence that the problem actually exists.

Depending on what you're researching, that could mean:

• App Store and Google Play reviews
• Reddit discussions
• X posts
• Facebook groups
• YouTube comments
• Product reviews
• Online communities
• Customer-support complaints
• Published news reports quoting the people affected

For Civora, much of my early evidence came from that last category: publicly available reports in which residents described their own experiences. Some described refuse heaps that had stayed in their neighbourhood for months despite repeated complaints. Others described badly damaged roads that had been a problem for well over a decade. Others described blocked drainage contributing to flooding, while officials pointed to weak enforcement and too few collection facilities.

What mattered was not any single story. It was the pattern: people could see the problem, discuss it constantly and still had no simple way to record it, see whether their neighbours were affected or follow what happened next.

That gap, rather than any feature idea, is what made the problem worth investigating.

For PoultryLink, by contrast, you might investigate conversations around finding reliable buyers, sourcing poultry supplies, transportation and the difficulties of selling or purchasing poultry products.

You're not searching for people to agree with your idea.
You're looking for patterns.

But there's an important warning here: Complaints are evidence, not proof.

The loudest people online aren't necessarily representative of everyone experiencing the problem.

• Someone can write a 500-word complaint about a product and still happily continue using it.
• Someone else might never complain publicly but experience the same problem every week.

So don't confuse:
"People are talking about this"

with:
"People desperately need this solved."

Civora is a good illustration. Published reports told me where to look. They could not tell me how badly residents need a fix, or whether they would use an app to get one.
Online research is a great discovery tool, but it doesn't finish the research.

3. Look at what people do instead

When people have a problem, they rarely sit around waiting for your product. They improvise;

• They use WhatsApp.
• They make spreadsheets.
• They call someone.
• They visit an office.
• They ask friends.
• They combine several tools to get one thing done.

Those workarounds can be more revealing than the complaint itself.

In the Civora research, complaints were travelling through community WhatsApp groups, social media, phone calls, letters, meetings and personal contacts. Each channel works a little, but together they make reports easy to lose, easy to duplicate and hard to follow up.

The most telling example was a community that reportedly pooled its own money to fund a road project after years of calls and letters went unanswered. When people pay out of their own pockets to fix a shared problem, the problem clearly matters to them. It doesn't prove they would pay for software, but it is a strong signal about how much the problem weighs.

Now take PoultryLink.
If the problem you're investigating is difficulty connecting poultry farmers with buyers, don't stop at:
"Farmers need better access to buyers."

Ask:

How are they finding buyers right now?

• Are they relying on personal contacts?
• WhatsApp groups?
• Middlemen?
• Social media?
• Local markets?
• Existing platforms?

And what happens when those methods fail?

That's where product discovery becomes interesting.

You might discover that the biggest problem isn't finding a buyer at all. It could be trust, logistics, information, payment or something else entirely.

The point isn't to assume the answer.

It's to find out.

4. Get specific about who has the problem

"Everyone" is usually a sign that you haven't narrowed your user down enough.

Cura.io is a good example of why this matters.

"People who need healthcare" is far too broad.

Even within a healthcare-support product, there can be very different users:

• someone seeking healthcare support
• someone raising funds for a medical need
• someone willing to contribute
• a healthcare professional
• a community member offering support

They may all interact with the same ecosystem, but their problems aren't identical.

If I were researching Cura.io first, I would start with the person raising funds for a medical need. They feel the pain most directly, they set the whole process in motion and everyone else in the ecosystem depends on what happens to them.

The same applies to PoultryLink.
"Farmers" isn't one user.
A small-scale poultry farmer, a commercial farm, a buyer purchasing in bulk, a supplier and a logistics provider can all experience different problems.

Civora followed the same logic. Rather than targeting "communities" in general, I narrowed the starting point to adults living in organised residential communities, with community managers as a secondary group.

So ask:
Who experiences this problem most often?
Who experiences it most painfully?
Who is already trying to solve it?
Who can actually take action?

The more specific your user is, the more specific your research can become.

5. Ask the uncomfortable question: Will anyone pay?

This is one of the biggest things beginners forget.

A problem can be real, frequent and frustrating and still not be a viable business.

People complain about plenty of things they wouldn't spend money to fix.

So eventually, you need to ask:

Who pays to solve this problem?

It might be the user.

It might be another business.

It might be an organisation.

It might be a partner or sponsor.

Or there may not be an obvious payer yet.

That's useful information too.

For example, if farmers genuinely struggle to connect with buyers, you've identified a potentially valuable problem.

But another question remains:

• Would farmers actually pay for a solution
• Would buyers pay?
• Could suppliers participate?

Could another part of the ecosystem pay for the value being created?

Civora raises the same question and I treat it as open. Issue-reporting platforms already exist, so reporting alone isn't the value. Whether residents, community managers or future partner organisations would fund a more specific offering is something desk research can't answer.

Finding a problem is only one part of product discovery.

You also need to understand the value exchange around it.

6. Talk to actual people

Online research is a great starting point.
It shouldn't necessarily be the finish line.
Eventually, talk to people who actually experience the problem.
And the questions you ask matter.

Don't start with:
"Would you use an app that solves this?"
Try:

• Tell me about the last time this happened.

• What did you do?

• Who did you contact?

• How long did it take?

• What was frustrating?

• What did you use instead?

• Have you ever paid for a solution?

For Civora, for example, asking someone whether they'd like a community-alert platform isn't as useful as understanding what they actually did the last time they encountered a community issue.

• Did they report it?

• Who did they report it to?

• How?

• Did they receive a response?

• If they didn't report it, why?

• Those answers tell you about behaviour.

And behaviour is much more useful than:
"That's a great idea!"

I'll be honest about where Civora stands: my research so far has been desk-based, so conversations with residents and community representatives are the next step, not something already behind me.

But how do you find these people?
Start with your existing network.

Ask friends, classmates, colleagues, community members or people connected to the industry you're researching if they have experienced the problem.

You can also reach out through relevant online communities.

The important thing is to find people who actually fit your target user, rather than simply collecting opinions from whoever is available.

And remember: five relevant conversations can teach you more than fifty conversations with the wrong people.


7. Don't fall in love with your solution
This is probably the hardest part.
You've created the screens.
You've chosen the name.
You've imagined the launch.
Now you desperately want your research to confirm that your idea is good.

Don't.
Let the research change the product.

Maybe users don't need your favourite feature.

Maybe the problem belongs to a different group.

Maybe people already have a good workaround.

Maybe the problem is real but nobody wants to pay for solving it.

Maybe the problem you thought was the biggest isn't actually the biggest.

That's not failure.

That's product discovery.

As a Product Manager, your job isn't to prove that your original idea was right.

It's to understand what is actually worth building.



A simple problem-validation framework

Before moving from research into solution design, write down:

Problem: What exactly is going wrong?

User: Who experiences it?

Frequency: How often does it happen?

Current behaviour: How do they solve it today?

Pain: What does it cost them in time, money, effort, risk or frustration?

Evidence: What have you actually observed or heard?

Payer: Who would potentially pay?

Opportunity: Why could solving this be valuable?

If you can't answer several of these questions, you probably aren't ready to build yet.

And that's okay.

You have more research to do.

What happens after you find the problem?
Don't immediately build the app.
Test the problem first.

• Have conversations

Talk to people who genuinely experience the problem and look for repeated patterns.

• Create a simple landing page

Explain the proposed solution and measure an actual action.
An email signup, demo request or other meaningful commitment tells you more than someone simply clicking "I like this."
And even those signals aren't proof that people will eventually pay.
They're just another piece of evidence.

• Run a manual pilot

Before building software, manually provide the service to a small group.

If you're testing a marketplace, for example, you might manually connect buyers and sellers before building the marketplace itself.

With Civora, that could mean running a pilot in one or two residential communities before building anything more.

• Test your riskiest assumption

If your biggest assumption is:
"People will pay."
Test that.

If it's:
"Organisations will respond."
Test that.

If it's:
"Farmers will use this regularly."
Test that.

Don't try to validate everything simultaneously.

Find the assumption that could kill the product and test that first.

• Don't give yourself a seven-day deadline

I initially liked the idea of turning product discovery into a seven-day challenge.
But honestly, real research doesn't always work that neatly.
You might spend several days finding the right people to interview.

Someone might cancel.

You might discover that your original user group was wrong.

You might need another week to investigate a new direction.

That's normal.

So instead of treating this like a strict seven-day deadline, give yourself a two-week discovery sprint.

Week 1: Understand the problem

• Define the problem you're investigating.
• Find existing conversations.
• Identify recurring complaints.
• Look for current workarounds.
• Narrow your target user.

Week 2: Test your assumptions

• Speak to relevant users.
• Document what they actually do.
• Identify your biggest assumption.
• Test it through conversations, a landing page or a manual pilot.
• Decide whether you need to continue, change direction or investigate further.

The goal isn't to prove your idea is amazing.

The goal is to know more than you knew two weeks ago.


Your product idea can wait.

If you have a product idea sitting in your Notes app right now, don't open Figma yet.

Write down the problem instead.

Ask:

• Who has this problem?
• How do they currently deal with it?
• How often does it happen?
• What does it cost them?
• What evidence do I have?
• Who would pay to solve it?
• What's the biggest assumption I haven't tested?

You might discover that your original idea needs to change.

That's a good outcome.

Because discovering that something needs to change before you build it is much cheaper than discovering it after you've spent months building it.

Don't start with "What should I build?"

Start with:
"What's broken, who is affected, how are they coping today and is solving it valuable enough for someone to act, or pay?"

That's where better products begin.