by Gary Worthington, More Than Monkeys

You are running a B2B SaaS, and your backlog is full of “must have” requests that all sound urgent if you read them quickly enough. Sales wants whatever closes the next deal, Customer Success wants whatever stops churn, and someone important has emailed you three times with “quick win?” in the subject line, as if you can just pop a new workflow out between stand-up and lunch.

Engineering, meanwhile, would like one week where scope does not appear out of nowhere like a jump scare.

This is normal. It is also how B2B products quietly become bespoke workflow engines for a handful of loud customers, where onboarding is painful, support is constant, and every new feature makes the product harder to explain. If you want a roadmap that builds a scalable product, not a museum of one-off exceptions, you need a prioritisation approach that is boring, consistent, and just a little bit rude to bad requests.

Here’s a practical system that works especially well when money is tight.

The uncomfortable truth about “feature requests”

Most feature requests are not actually feature requests. They are a customer asking you to copy their internal process into your product, complete with all the quirks, workarounds, and the one spreadsheet that only Steve understands. Sometimes that is the right call, particularly if you are building a category product and you keep seeing the same problem across your market, but usually it is not.

The fastest way to kill a B2B SaaS is to say yes to everything, ship a thousand edge cases, and then act surprised when onboarding hurts, support never stops, and your product feels like it was designed by committee. Prioritisation is how you avoid that fate.

The rule of thumb for low-runway decisions

When cash is constrained, the roadmap is not a democratic process. It is a survival plan, so you prioritise work that does one of these things, in roughly this order.

First, it protects money by reducing churn risk, keeping renewals on track, or meeting contract obligations. Second, it creates money by unblocking new deals, expansions, or pricing power. Third, it creates evidence by proving a bet about activation, retention, or usage. Fourth, it reduces cost by cutting support load, manual ops, and reliability incidents. Everything else goes into the “nice” pile, which you are allowed to keep, but not allowed to worship.

If a request does not map to one of those first four, it is not urgent. It is merely enthusiastic.

Turn feature requests into outcome requests

This one change solves half the problem, because it forces the right conversation.

Every request gets rewritten as an outcome, not a solution. Instead of “we need bulk export to CSV with custom columns”, you capture who is feeling the pain (and how many accounts it affects), what outcome they want (saving time, reducing errors, meeting compliance), what it is worth (ARR at risk, ARR unlocked, or a measurable usage improvement), and when it matters (renewal date, go-live date, procurement deadline).

If you cannot fill those in, the request is not ready to prioritise. It goes into “needs discovery” and stops consuming your roadmap like a black hole. It also improves your customer conversations, because people will usually tell you what the real pain is if you ask, and it is often not “CSV export”.

Use a scoring model that rewards small, valuable work

You do not need twelve frameworks and a spreadsheet that looks like it was designed by a hedge fund. For B2B SaaS, a WSJF-style model with an “ops tax” penalty works well because it balances value, urgency, and effort without pretending you can predict the future perfectly.

Score each request from 1 to 5, then keep it simple.

For cost of delay, look at:

• Impact (£): the ARR at risk or ARR unlocked.
• Urgency: renewal timing, contractual dates, go-live, compliance deadlines.
• Leverage: whether it unlocks other work, improves the platform, or enables upsell tiers.

For cost to deliver, look at:

• Effort: your t-shirt size turned into a number, because none of us have time for theatre.
• Ops tax: the ongoing support burden, complexity, infra cost, and future maintenance.

Then use a basic formula:

(Impact + Urgency + Leverage) / (Effort + OpsTax)

You are not trying to be mathematically pure. You are trying to be consistent, because consistency is what prevents roadmap decisions being made by whoever spoke last.

Why the ops tax matters

Low-runway startups love “quick wins” that quietly create permanent work. If a feature increases configuration complexity, support tickets, or edge cases, it needs to earn its keep every month, not just look good in a sales demo. The ops tax makes that cost visible, so you stop optimising for short-term applause and start optimising for a product you can actually run.

Create a “deal and renewal” fast lane, with strict entry rules

Some work genuinely should jump the queue in B2B, but if you do not define what qualifies, everything becomes a fast lane request and you are back where you started.

A request enters the fast lane only if it meets two or more of these criteria:

• There is a renewal within 90 days and you have credible churn risk.
• There is a new deal that is committed (or in contracting) and genuinely blocked on this work.
• There is an expansion attached with clear value, such as seats, modules, or tier upgrades.
• There is a contractual obligation already signed.

If it does not meet the criteria, it goes through normal scoring. This is the bit where you upset someone, and that is fine, because it is still cheaper than building the wrong thing.

Run a weekly 30-minute triage, not a monthly meltdown

The goal is a small, frequent decision loop, not a monthly meeting where everyone shows up with feelings and a slide deck.

Keep the attendees tight: Product, an engineering lead, and one voice from Sales or Customer Success (one voice, not a crowd). The agenda is equally tight: rewrite new requests as outcomes, score quickly, decide Now / Next / Later / Never, and for anything that is “Now”, define a success metric and the smallest releasable slice.

If the meeting runs long, you are doing discovery in the meeting. Do it outside. Triage is for decisions.

The one-page template that keeps everyone honest

If a request cannot be captured in this format, it is not ready for the roadmap. It is ready for a conversation.

• Request title:
• Customer(s):
• Segment: size, plan, industry
• Problem statement: one sentence, no therapy
• Outcome metric: what changes, how it is measured
• £ value: ARR at risk or unlocked, or a reasonable proxy
• Deadline: renewal, go-live, procurement
• Workaround exists?: yes or no
• Evidence: calls, tickets, usage data
• Effort: S/M/L
• Ops tax: L/M/H
• Score:
• Decision: Now / Next / Later / Never

This removes ambiguity and stops strong opinions winning by default.

The anti-Frankenstein rule

Here’s the guardrail that saves you from slow death by customisation.

If a feature request is only valuable to one customer, it must be paid for in one of these ways: it becomes part of a priced tier or add-on, it unblocks significant ARR now, or it creates a capability you can sell repeatedly.

If it does not meet that bar, you are building bespoke software. That is a perfectly respectable business model, but it is not a scalable SaaS one, and pretending otherwise is how you end up with a product that looks like it was stitched together in a lightning storm.

What to do tomorrow morning

If you want to implement this without a big process overhaul, do five things.

Pick one measurable goal for the next 4 to 6 weeks, such as activation, retention, time to value, renewals secured, or support volume reduced. Take your top 10 requests and rewrite them as outcomes, and if you cannot, book discovery calls and stop pretending you understand the problem. Score them using the simple WSJF-style formula, then make a Now / Next / Later cut and commit to “Now” properly, not in that vague “we’ll see” way that means nobody does anything.

Finally, ship smaller slices, because most roadmap pain comes from trying to do “the full feature” instead of “the smallest useful release”.

That is it. You will still get feature requests. You will just be in control of them, which is a much nicer way to run a company than letting the backlog lead the strategy. The backlog is enthusiastic, but it is not known for its judgement.

Gary Worthington is a software engineer, delivery consultant, and fractional CTO who helps teams move fast, learn faster, and scale when it matters. He writes about modern engineering, product thinking, and helping teams ship things that matter.

Through his consultancy, More Than Monkeys, Gary helps startups and scaleups improve how they build software — from tech strategy and agile delivery to product validation and team development.

Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.

Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance