Feature prioritisation is the problem nobody warns you about before you start a SaaS business. You spend months validating the idea, building the first version and getting a handful of paying customers, and then suddenly you have a list of forty things people want and time to build about three of them. I have gone through this exact scramble on four different products now, and the honest truth is that most founders prioritise badly because they are answering the wrong question.
The wrong question is "what does the customer want." Nearly everything on your backlog is something a customer wants. That is not a useful filter. The right question is "what happens to the business if we do not build this," and that single change in framing is what actually makes prioritisation possible.
Why Feature Prioritisation Breaks Down When You Are Bootstrapping
Funded startups can afford to be wrong about priorities for a while because they have a pile of cash buying them time to recover. You do not have that luxury when you are bootstrapping. Every week spent building the wrong feature is a week you cannot get back, and it is a week your competitors spent building something a customer actually needed.
The other problem is that bootstrapped founders tend to be the ones talking to customers, reading the support tickets and writing the code. That closeness is usually an advantage, but it makes you emotionally attached to requests in a way a product manager sitting two steps removed from the customer never would be. The loudest customer starts to feel like the whole market, and it rarely is.
The Framework I Actually Use
Forget elaborate scoring matrices with weighted columns for impact, effort, confidence and reach. I have tried them. They look rigorous and they fall apart within a month because everyone starts gaming the numbers to justify the feature they already wanted to build. What I use instead is three plain questions, asked in order, and I will not move to the next feature until I have honest answers to all three.
Does it move a real number
Every feature request has to connect to a number that actually matters to the business, not a number that sounds good in a pitch. Will it reduce churn. Will it let you charge more. Will it remove a blocker stopping a deal from closing. Will it cut support tickets. If you cannot draw a line from the feature to one of the metrics I cover in the SaaS metrics that actually matter when you are bootstrapped, it goes to the bottom of the list, no matter how interesting it is to build.
Who is actually asking for it
One customer asking for something is a data point. Five customers asking for the same thing independently, without prompting, is a pattern. There is a world of difference between the two, and conflating them is how founders end up building bespoke features for their single loudest account while the rest of the customer base quietly looks elsewhere. I learned this properly at CampSuite, where one large site kept requesting a reporting feature that, when I actually checked, nobody else had ever asked for once.
What happens if you build nothing
This is the question people skip and it is the most useful one. If you do absolutely nothing about a request for the next six months, what actually happens? Sometimes the honest answer is nothing at all, the customer grumbles and carries on using the product anyway. Sometimes the answer is that customers churn, deals stall or your support team drowns. Only the second category deserves a place near the top of your roadmap.
The Loudest Customer Is Not Always Right
Bootstrapped founders are terrified of losing a customer, and that fear quietly distorts every prioritisation decision if you let it. A demanding customer who threatens to leave unless you build their pet feature is not automatically your most valuable customer. Sometimes they are, and you should move fast. Often they are your most expensive customer to serve, generating a disproportionate amount of noise relative to the revenue they bring in.
Before building anything for a single account, weigh what that account is actually worth against what the feature will cost you in development time and ongoing maintenance. I have turned down requests from customers paying four figures a month because the build would have taken three weeks better spent on something twenty other customers needed. Not a comfortable call, but the right one.
Saying No Without Losing the Customer
The good news is that saying no rarely costs you the customer if you say it properly. What actually loses customers is silence, where a request goes into a black hole and nobody ever hears back. Reply to every request, explain honestly why it is not happening right now, and where possible offer a workaround using what already exists in the product.
I keep a public list of what we are working on and what we are deliberately not doing yet, with a short reason for each. It takes five minutes to update and stops the same conversation happening over email every week. Customers do not need everything they ask for built. They need to feel heard, and a clear no with a reason attached does that better than a vague "we will look into it" that never gets revisited.
Running This Across More Than One Business
This gets harder once you are running more than one business at the same time, and harder again once you sit on a board rather than run the product day to day. In my non executive roles I see founders approve a roadmap because it sounds impressive in a board pack rather than because anyone tested whether it moves a real number. The three questions above work just as well from a board seat as a developer's desk, which is exactly what I dig into in what a non executive director actually does.
The businesses that get this right are not the ones with the cleverest prioritisation spreadsheet. They are the ones with a founder disciplined enough to say no to good ideas so there is room left for the ones that actually matter. That discipline is a muscle, and it gets stronger every time you practise it.
Build Fewer Things, Better
If there is one thing I would tell a founder starting out, it is that your backlog is not a promise, it is a list of options. Nobody is entitled to have their idea built just because they wrote it on a card. Ask whether it moves a real number, whether more than one customer is genuinely asking for it, and what actually happens if you leave it alone. Most of the time you will find the answer is build less than you think and ship it properly, rather than building everything half heartedly and wondering why nothing moves the needle.
This is the same thinking that runs through The 28 Day Startup, the book I am writing on getting a business off the ground without wasting months on the wrong things. If you want a second opinion on your own roadmap, it is exactly the kind of conversation I have with clients through product development consulting.
