One pattern I've noticed in teams without a dedicated product designer is that they often jump straight from a problem to a solution.
A meeting ends with:
"Let's add a dashboard."
Or:
"We should send push notifications."
Or:
"Let's add AI."
Nobody asks whether those are actually the best ways to solve the problem.
The first idea quietly becomes the roadmap.
Every solution is an assumption
Imagine your team notices that new users aren't completing their profile.
The ticket becomes:
"Send a push notification reminding users to complete their profile."
It sounds reasonable.
But the notification isn't the problem.
It's someone's proposed solution.
The real problem is that users aren't completing their profile.
Maybe a push notification helps.
Maybe simplifying the onboarding flow would work better.
Maybe users don't understand why completing their profile matters.
Maybe the profile asks for too much information.
Until you explore the problem, you don't really know.
The cost of skipping exploration
When teams move directly to implementation, they unintentionally narrow their options.
Engineering spends time building the first idea.
Marketing prepares the announcement.
Everyone becomes invested in making that solution work.
But nobody stopped to ask:
"Is this actually the best way to solve the problem?"
Sometimes it is.
Many times it isn't.
By the time you find out, you've already spent weeks building it.
This is where product design creates value
A lot of people think product designers make interfaces look good.
That's certainly part of the job.
But the bigger contribution happens before Figma is even opened.
A good product designer helps the team answer questions like:
- What problem are we actually solving?
- Who is experiencing it?
- Why does it happen?
- What evidence do we have?
- What are three different ways we could solve it?
- What are the trade-offs of each approach?
- Which assumption should we validate before we invest engineering time?
Notice that none of those questions are about colours or buttons.
They're about making better product decisions.
Better decisions come from better evidence
Even designers don't know the right solution from the start.
Their first idea is just another assumption.
The difference is that they're trained to reduce uncertainty before development begins.
That means looking at analytics.
Talking to users.
Running usability tests.
Building lightweight prototypes.
Comparing alternatives.
The goal isn't to prove they're right.
It's to reduce the risk that the team builds the wrong thing.
You don't need perfect certainty
Startups don't have unlimited time.
You can't research forever.
A good rule of thumb is to keep learning until you stop hearing new things.
When the same insights appear again and again, you're no longer collecting opinions.
You're starting to see patterns.
That's usually a good sign that you're ready to make a decision.
The next time your team writes a ticket...
Instead of writing:
"Send a push notification reminding users to complete their profile."
Write:
"New users aren't completing their profile after signing up, and increasing profile completion is important because it's a key activation step."
One describes an implementation.
The other describes a problem.
That small change encourages the team to explore instead of assume.
Sometimes you'll still end up with a push notification.
Sometimes you'll discover a much simpler, cheaper, or more effective solution.
You won't know until you ask the question.
Because great products aren't built by falling in love with the first idea.
They're built by staying loyal to the problem until the evidence points to the right solution.
