Before Adding Another Feature, Ask What Problem We're Actually Solving

"Can we just add this?"

Five words capable of changing an entire sprint. The request usually sounds simple. Add another filter. Add another button. Add another status. Add another tab. Add another feature because a competitor has it.

And sometimes, adding it is absolutely the right decision.

But before opening Figma, writing a ticket, or asking engineering for an estimate, there's one question worth asking:
What problem are we actually trying to solve?

It sounds obvious. In practice, we skip it surprisingly often.

Features are solutions. Not problems.

Imagine someone says:
"We need a new dashboard."

That's already a solution. Maybe the actual problem is that managers can't see which projects are delayed. Maybe existing reports are too difficult to understand. Maybe the information already exists, but nobody knows where to find it. Those are three different problems. And they probably shouldn't produce the exact same solution.

If we jump directly from request to feature, we risk spending weeks building something that technically works but doesn't actually improve anything.

The fastest way to build the wrong thing is to skip the question behind the request.

"But the stakeholder asked for it."

Fair.

Stakeholders usually understand their business better than we do. But understanding a business problem doesn't always mean knowing the best product solution immediately. That's where product collaboration becomes useful.

Instead of saying:
"No, we shouldn't build this."

Try:
"What are we trying to improve by adding this?"

Suddenly, the conversation changes. Maybe the requested feature is still the answer. Great. Now we understand why. Or maybe there's a smaller solution that achieves the same outcome without adding another layer of complexity to the product. Also great.

Every "small feature" eventually needs somewhere to live.

One new button doesn't feel dangerous. Neither does one additional filter. Or one extra setting. The problem appears after dozens of perfectly reasonable small requests accumulate. Eventually, navigation gets crowded. Screens become longer. Settings multiply. Users need more explanation. Designers create more states. Developers maintain more logic. QA gets more scenarios. And everyone wonders why a product that used to feel simple suddenly feels complicated. Nobody intentionally designed it that way. Complexity arrived one reasonable request at a time.

Before adding something, try asking this

What user or business problem does this solve?

Who actually needs it?

How often will they use it?

Can the existing experience solve the same problem?

What new complexity are we introducing by adding it?

And my personal favorite:

What happens if we don't build it?
If nobody can clearly answer that last question, maybe we don't need to rush.

Sometimes good product design means designing less.

Product teams are often measured by what they ship. New features are visible. Things we intentionally don't build are not. But deciding not to add unnecessary complexity is also product work. A good product isn't the one with the most features. It's the one where the right features work together clearly enough that people don't have to think too hard about using them.

So before adding another feature, ask about the problem.

Figma can wait five minutes.