Helper CTO Series 16 | Which Feature to Build First: A Prioritization Method for Non-Technical Decision-Makers

"Sales wants A, customer service wants B, and I want C myself — the engineer says doing all three will take six months." Six months later, all three are half-done, the budget is gone, and not one problem is actually solved. You're not bad at making decisions — you're missing a ruler every department recognizes. The following three questions are that ruler.

The Longer the Request List, the More You Need Help Sorting It

The difficulty in prioritizing isn't a lack of criteria — it's that every department's criteria are different:

• Sales cares whether it brings in more orders, and the sooner it launches, the better.
• Customer service cares whether it means fewer calls, and ideally it changes today.
• Finance cares whether it means less reconciliation, fewer errors, and finishing month-end sooner.
• Engineers care whether it touches anything currently in use, and who maintains it once it's done.

All four are right, but there's only one pool of engineering time. Without a shared ruler, the result is "whoever pushes hardest gets done first." Managing outsourcing without knowing how to code covered "focus on the purpose, not the feature" — that's the starting point for prioritization: ask what problem the request actually solves before asking whether to build it.

Two Axes: How Big the Impact, How High the Cost

Run every request through two questions. Anything you can't answer goes to the back of the line:

• How big is the impact: will it increase revenue, or how much manual work will it remove from which process? You need an actual number.
• How high is the cost: not just development time, but also whether existing data needs to change and whether it touches features currently in use.
• Ask about the worst case for cost: you can't estimate this axis accurately yourself — ask the engineer, and specifically ask "how bad is it if this goes wrong."

The two axes cross into four quadrants, and each one gets handled differently:

• High impact, low cost: do it first. These requests are rare — finding one is a win.
• High impact, high cost: break it down. Build the most painful piece first, then decide whether to continue.
• Low impact, low cost: schedule it into open slots — don't let it jump the line.
• Low impact, high cost: cross it off. Don't be polite about it, and don't wait until next month to decide.

Putting the List on the Two Axes Looks Like This

Run five common requests through it, and you'll immediately see how this ruler works:

The real value of prioritization isn't picking the winner — it's pushing back and crossing off the last two rows. Requests everyone "feels should be done" but can't explain the impact of are usually what eats up the most time.

The Third Question: Who Looks After It Once It's Done

Once the two axes are done, most people think they're finished. But there's a question almost no one asks: once this feature launches, who's responsible for checking it still works? Three things need an owner first:

• Who checks it: someone needs to actually look, every month, at whether the data is correct and whether errors are showing up.
• Who answers questions: when a customer or coworker asks how to use it or why it's different from before, who responds.
• Who fixes it: who gets called when it breaks, and how soon it needs to be resolved.

A new feature with no owner is just one more thing that can break — its cost doesn't end when it's built, you keep paying it every month. The five questions in how to tell if your engineer is telling you the truth can be applied directly to every request too.

Prioritization Isn't a One-Time Task

The request list keeps growing, business conditions keep changing, and what ranked first last month might not be needed this month. So prioritizing is a monthly routine:

• Plot every new request on the two axes as soon as it comes in — don't commit to a timeline yet.
• Revisit old requests every month, and push back anything whose impact has shrunk.
• Remove finished items, and note down what they actually cost so the next estimate is more accurate.

There's a fixed role for this. What is a Helper CTO covered it before: it acts like your company's technical lead, just not on your payroll. For how the whole outsourcing relationship should work, there's a separate article: why outsource, and how to do it right.

What Nerdtechnic Does for You on Prioritization

• Working out the "cost" axis clearly: you know the impact best; the cost needs someone who understands the technology and is on your side.
• Re-prioritizing every month: small items get done directly, and anything you want to add more of just goes on top — no renegotiating the whole contract each time.
• We look after what we build: taking over, maintaining, improving, and continuing development is the same team — we don't build it and walk away.
• We say so when something should be crossed off: we won't let a request that isn't worth doing move up the list just to take on more work.

The real skill in prioritization isn't picking what should be done — it's having the nerve to say what shouldn't.

Which new feature to build first always comes down to looking at impact, cost, and ownership together. Nerdtechnic improves and continues developing your system as your Helper CTO, re-prioritizing your list every month. The first step is a 60-minute system health check: just give us access to see the code, no production account credentials needed, and you'll get a one-page report you can actually understand within 3–5 business days. If your request list has grown too long for anyone to dare sort it, bring us the whole thing and we'll sort it with you the first time: Helper CTO: System Maintenance Plan.