How do you decide what to build next when everything feels important?
A 3-step framework for getting ruthless about priorities, before it costs you a quarter.
"If everything is a priority, nothing is. The founders who build the best products aren't the ones who do the most. They're the ones who stop the most."
A founder I worked with last year had a backlog of forty-three items, every one marked urgent. The team was shipping every two weeks. Velocity looked great. The product was doing a lot of things. It just wasn't doing anything well enough to matter.
He didn't have an execution problem. He had a prioritisation problem. Six months of engineering had been spread so thinly across the roadmap that the product's core — the single thing that got users in the door, had been left to rot while the team built edge cases for users who hadn't signed up yet.
Here's the way I think about it. Three steps. The same questions any experienced product leader would ask, written down so you can actually run them this Tuesday afternoon.
STEP 01
Choose One Thing That Matters Right Now
This sounds obvious. It almost never is. Every founder can tell me three to five things their product needs to do better. What almost none of them can tell me is which one of those things — if solved — would change the trajectory of the business in the next ninety days.
The question isn't "what's important?" Everything on your backlog is important, or it wouldn't be there. The question is: what is the single goal your product needs to serve right now, given where you actually are?
The Goal Test
Before you prioritise a single feature, you must answer: are we trying to sell our first product, push upsells, attract more users, improve retention, or validate the idea? Each goal calls for a completely different product strategy. If you can't name your single goal in one sentence, you don't have a goal. You have a mood.
Look at Facebook. Users don't love ads, never have. But revenue has been their goal since 2012. Every product decision: the algorithmic feed, the deep demographic targeting, the push notifications — was made in service of that goal, even at a cost to user experience. That's not ruthlessness. That's clarity.
STEP 02
Apply 80/20: Find the Behaviour That Drives the Goal
Once you have your goal, the next question is mechanical: what part of user behaviour actually drives it? This isn't about opinions. It's about the data you already have, or the signal you can get quickly.
If your goal is revenue, where do users convert? If it's retention, where do they drop off? If it's validation, which single feature — if someone used it — would prove they care enough to pay?
→ IN PRACTICE
In most products, 20% of the features drive 80% of the outcomes that matter. The job isn't to build more. It's to find that 20%, double down, and cut everything else from the priority queue.
Here's a concrete example. Suppose you built a 30-day free trial. Sensible model. But what if your product is something people only need twice a year — accountants at tax time, event planners before a launch? They exhaust the trial, don't convert, and come back next year for another free trial. The model is broken. Not the product.
Switch it. Give them 5 uses instead of 30 days. Now you're measuring behaviour, not time. That's an 80/20 insight — it didn't require a new feature. It required looking honestly at the data and letting it tell you what to change.
STEP 03
Let the Signal Decide, And Know What Counts as Signal
When a power user sends a long feature request, it feels like signal. When three enterprise prospects ask for the same thing in the same week, it feels like signal. When the team votes unanimously that something would "really move the needle," it feels like signal.
Most of it isn't. Here's how to tell the difference.
Real signal comes from users who have demonstrated they will pay — in money, in time, in genuine workflow change — for the problem to be solved. Loud opinions are not signal. Enthusiastic opinions are not signal. Investor opinions are especially dangerous: they have money, but not your users' problems.
THE ONE TEST
Before adding any feature to your next sprint, ask the room: 'What concrete, costs-something signal tells us this is the right thing to build right now?' Not a survey. Not a thumbs-up from a design partner. What evidence exists that real users, in real pain, have already tried to solve this and failed? If the room goes quiet, you just saved yourself a sprint.
Prioritisation Is a Daily Discipline, Not a Sprint Ceremony
Before every sprint, ask one question: does this thing, built right now, directly move the goal that matters this quarter?
- If yes, build it.
- If maybe, get more signal first.
- If no, even if the feature is genuinely good, even if users would like it, put it on a holding list and come back when the goal changes.
Startups don't drown because they stop building. They drown because they can't stop.
A question I'd genuinely like to hear your answer to: what's the hardest feature you ever had to say no to, and what happened because you did?
Reply, or send me a note. I read everything.
P.S. If you want the one-page checklist I walk founders through before every sprint planning session, it's a free download.
→ Grab the Priority Signal Checklist
Interested in learning more about x-enabler?
Leave a comment!