How do I prioritise features when everything feels important?

When you are close to an idea, every feature feels essential, because you can see how each one makes the whole thing better. That is exactly why gut feel fails at prioritising: everything feels like a must-have. What you need is a method that takes the emotion out and sorts the list by something more honest than how important each part feels.

Step by step

1. Write every feature on its own lineGet the whole list out of your head and onto a page, one feature per line, however long it runs. You cannot prioritise what you cannot see all at once, and keeping the list in your head is what makes everything feel equally urgent and equally essential. Include the small and obvious ones too, because those are often the ones that quietly turn out to be must-haves. The act of writing the full list already starts to reveal that some items are clearly weightier than others, and seeing them side by side takes some of the heat out of the decision, which is exactly what you want when everything currently feels like it has to be built at once.
2. Split by the core-action test firstGo through each line and ask one question: if this were missing, would the core action still work and still be worth using. The ones that fail this test, where the idea genuinely breaks without them, are your first tier, the true must-haves. Everything that passes, where the idea survives without it, drops to a second group to be sorted later. This single cut usually shrinks the must-have list dramatically, because most features are improvements, not necessities. It can be uncomfortable to move a feature you love into the second group, but that discomfort is exactly the sign the test is working rather than your preferences.
3. Sort the rest by value against effortFor the features that are not strictly essential, weigh two things: how much each genuinely helps a user, and how much it costs to build. The best next things are high value and low effort. The worst are low value and high effort. This comparison, even done roughly, exposes the features that feel important but cost a lot while adding little, which are the ones quietly worth dropping or deferring.
4. Respect the dependenciesSome features cannot be built until another exists first; you cannot have order history before you have orders. Mark these dependencies, because they override preference, a feature you want early may have to wait for the thing it depends on. Sorting out the forced order now prevents the frustration of committing to build something only to discover it needs a prerequisite you had scheduled for later.
5. Commit to the order and hold the lineTurn the result into a plain ordered list: build first, build next, build later, maybe never. Then protect it, because the pull to jump ahead to an exciting later feature is constant and always feels justified in the moment. When a new idea appears, run it through the same test rather than letting it queue-jump on enthusiasm alone. A priority order is only useful if you actually follow it when the temptation to reshuffle arrives, and the value of having done the sorting is precisely that it gives you something honest to point back to when a shiny new feature tries to leap to the front.