Features are the last step, not the first

Why features come first

Features are easy to picture and easy to discuss. They give everyone something to react to, and they look good on a roadmap. Problems, by contrast, are vague and uncomfortable. They require admitting what isn’t working, for whom and why. So teams skip ahead, and the result is predictable: long arguments about solutions, because nobody agreed on what the solution was supposed to solve.

Goal, problem, then options

My order is the reverse. First the goal: what should be different for the business or the user if this succeeds? Then the problem: what stands in the way today, and how do we know? Only then do we look at solutions, and not one but several. Placing three possible solutions side by side, each judged against the same problem, changes the conversation completely. It stops being about who proposed what and becomes about which option serves the goal best.

Often the winning option is not a new feature at all. It is a change to an existing flow, a clearer message or a step removed rather than added.

Features as the last step

Seen this way, a feature is simply the final form a decision takes. It is the last step of a chain that starts with the goal, not the first. Teams that work in this order build less, argue less and ship things that people actually use, because every feature has a reason behind it that everyone can name.

A habit worth building

It takes discipline to stop a meeting and ask what problem a feature solves, especially when everyone is enthusiastic. But I have never regretted asking. The best products I have worked on were not the ones with the most features. They were the ones where every feature had earned its place.