I always try to avoid the word “feature”.
It is a small language choice, but it carries a lot of baggage. “Feature” makes something sound like an extraneous add-on: a new tool or widget that can be attached to the product because it might be useful to somebody.
That framing is one reason products become crowded with semi-useful tools. Each idea can sound reasonable in isolation. Together, they create a Swiss Army knife: impressive in a demo, but not designed to do one important job exceptionally well.
Functionality belongs to a journey.
A product should help a specific person move through a meaningful sequence. They start with a problem. They take an action. They gain confidence. They reach a point where the job is done.
That journey might be simple or complex, but it should be intentional. The product is not a collection of disconnected capabilities. It is a system for moving someone from point A to point B to point C.
That is why I prefer the word functionality. It asks a better question: what does this part of the product do in service of the user's progress?
Useful is not the same as valuable.
Almost anything can be useful to someone. The harder question is whether it moves your customer closer to the outcome they came for.
For an early-stage product, this distinction matters. Every new capability adds design decisions, support burden, documentation, maintenance, and another thing for a customer to understand. Those costs are easy to ignore when building is cheap.
The discipline is not to reject new ideas. It is to test them against the path. Does this help the customer make progress? Does it remove friction between the current state and the desired one? Does it belong in the product's core job?
Words shape priorities. If we stop treating every useful idea as a feature, we have a better chance of building products that help people get where they are trying to go.