I've worked with enough startups to notice a pattern.
Whenever growth slows down, the first instinct is almost always the same.
"We need another feature."
The logic seems obvious.
More features make the product more valuable.
More value attracts more users.
More users means more growth.
Except that's rarely what happens.
Instead, the product becomes more complicated.
Navigation gets messier.
The onboarding takes longer.
New users have more things to understand before they experience any value.
Ironically, every new feature that was supposed to improve the product makes it slightly harder to use.
The problem isn't that the feature was poorly designed.
The problem is that nobody stopped to ask whether it needed to exist in the first place.
Building feels like progress
One reason this happens is simple.
Building things is fun.
Founders love imagining new possibilities.
Developers love solving technical problems.
Shipping creates momentum.
Everyone feels productive.
Questioning whether something should be built doesn't create the same excitement. It feels like slowing the team down.
But there's a difference between slowing down and being intentional.
Spending thirty minutes deciding whether something is worth building can save weeks of engineering time later.
I've seen teams spend months polishing features that hardly anyone used.
Not because they built them badly.
Because they were solving a problem that wasn't important enough to solve.
Having a vision isn't enough
Founders often have a clear vision for where they want the company to go.
That's essential.
But a vision doesn't automatically answer questions like:
- What problem are we solving next?
- Why is this the most important problem right now?
- Who actually experiences it?
- How do we know it exists?
- Is there a simpler way to solve it?
Those are product questions.
Someone on the team needs to own them.
In larger companies, that's often shared between product managers and product designers.
A PM helps define what should be built.
A product designer explores how that problem can be solved in a way that's useful, usable and valuable for the people using the product.
Smaller startups rarely have both roles.
Sometimes the founder owns both.
Sometimes the designer does.
The title doesn't matter.
What matters is that someone owns the quality of product decisions.
Otherwise the roadmap slowly fills with assumptions disguised as features.
Before the next sprint, ask four questions
Before your team commits to building something, answer these four questions.
- Who is this feature for?
- What real problem does it solve?
- What evidence do we have that this problem actually exists?
- What's the smallest version we can build that creates value and helps us learn?
If you can't clearly describe the people it's serving, you're probably building for everyone.
Describe the pain, not the feature.
People don't care about features.
They care about problems disappearing.
Customer interviews.
Support conversations.
Usage data.
Repeated requests.
Anything stronger than "I think users would like this."
You don't need to bet months of engineering time on an assumption.
You can often learn the same thing with a much simpler experiment.
Better products aren't built by adding more
They're built by making better decisions.
That doesn't mean saying no to every idea.
It means earning the right to build it.
The teams that consistently create products people love aren't necessarily the ones shipping the fastest.
They're the ones spending just enough time making sure they're moving in the right direction.
Because the most expensive feature you'll ever build isn't the one that takes the longest.
It's the one nobody needed.
