Early in my career, I spent a lot of time thinking about who our users were.
Were they enterprise customers or SMBs?
Were they recruiters or hiring managers?
How large was their company?
Those segments were useful, but after a while, I noticed something interesting.
Two customers from the same company, with the same job title, could use the product in completely different ways.
Why?
Because they were trying to solve different problems.
That realization changed how I thought about segmentation.
Sometimes the most meaningful way to understand users isn’t by looking at who they are. It’s by understanding what they’re trying to accomplish.
The Same User Doesn’t Always Have the Same Problem
Imagine you’re building a project management tool.
One team uses it to organize daily work.
Another uses it to collaborate with external clients.
A third only needs it for quarterly planning.
On paper, they may all look like similar customers.
But their expectations, priorities, and workflows are completely different because the problems they’re trying to solve are different.
If you build the same experience for all three, you’ll probably satisfy none of them particularly well.
Problems Drive Behavior
One thing I’ve learned is that people rarely adopt products because they like features.
They adopt products because they need help solving a problem.
Think about a navigation app.
One user wants the fastest route home.
Another wants to avoid toll roads.
Someone else is looking for nearby charging stations.
They’re using the same product, but for different reasons.
Those reasons influence which features they use, what they value, and whether they continue using the product.
Understanding the problem often explains user behavior better than demographics ever can.
Features Make More Sense in Context
I’ve seen teams debate feature requests by asking questions like:
“How many customers asked for this?”
That’s useful.
But another question often leads to better decisions:
“Which problem does this solve?”
Sometimes five different feature requests are actually different attempts to solve the same underlying problem.
If you focus only on the requested features, you end up building more and more functionality.
If you focus on the problem, you often discover a much simpler solution.
Product Decisions Become Clearer
Problem-based segmentation also makes prioritization easier.
Imagine your analytics show that customers struggle with reporting.
A closer look reveals something interesting.
Some users need reports for compliance.
Others want quick operational insights.
A third group simply wants to share information with clients.
Instead of building one complicated reporting feature, you can design solutions that address the specific problem each group is trying to solve.
The product becomes simpler because it’s designed around real needs instead of assumptions.
Customer Interviews Become More Valuable
One mistake I made early on was asking customers what features they wanted.
The answers were helpful, but they rarely explained the bigger picture.
Over time, I started asking different questions.
What were you trying to accomplish?
What happened before you opened the product?
What made this task difficult?
Those conversations often uncovered problems we hadn’t considered.
Customers are usually much better at describing their challenges than designing the solution.
That’s why understanding the problem is often more valuable than collecting feature requests.
Problems Change Over Time
Another reason I like problem-based segmentation is that it evolves naturally.
The same customer may use your product differently six months later.
A startup might initially need speed.
As the business grows, reliability and collaboration become more important.
The customer hasn’t changed.
The problem has.
Good segmentation should evolve alongside those changing needs instead of placing users into fixed categories.
Build Around the Problem, Not the Persona
Personas still have value.
They help teams visualize who they’re designing for.
But personas alone rarely explain why customers behave the way they do.
Problems provide that missing context.
When product discussions shift from “Who is this customer?” to “What problem are they trying to solve?”, conversations become much more focused.
Features become easier to prioritize.
Research becomes more meaningful.
And products become more useful.
Final Thought
I’ve come to believe that the best products aren’t built around customer profiles.
They’re built around customer problems.
Two users may have the same title, work in the same industry, and use the same product every day.
But if they’re trying to solve different problems, they deserve different experiences.
As Product Managers, understanding those problems gives us a much stronger foundation than demographics ever will.
Because in the end, customers don’t choose products that understand who they are.
They choose products that understand what they’re trying to achieve.
Leave a Reply