A feature is a response to a problem, and the problem is always more interesting. When you start with the feature you commit to a shape before understanding the friction, and that shape becomes load-bearing before anyone confirms it’s solving the right thing. Starting with the problem keeps options open longer. Sometimes the right answer isn’t a feature at all, and [[Do less]] at the product level often looks like removing the request from the backlog rather than building it.
Stakeholders usually arrive with features already defined, so the work is translating that back into a real human need before anything gets scoped, which is why [[Keep user experience discussions at the product level]] matters: the problem only becomes visible at the level above the interface. [[Focus on outcome, not output]] is where this becomes practical: the outcome is the friction removed, not the feature shipped. Holding that distinction in the room is what prevents [[Building a boring task list]] of things that felt important but changed nothing.