How to prioritise what features to build

Deciding what to build and when is the most difficult task for any product/engineering team. There are always multiple competing interests that appear at different times, pulling you in every direction.

Without an understanding of how to prioritise, you can easily switch contexts too often, damaging productivity and making everything feel manic.

Despite this, it is it possible to define some prioritisation rules. These are mine:

Critical problems waking up your team
Your team are the first of two crucial stakeholders. It sounds obvious, but without team members you can’t deliver your service! Stress and fatigue caused by outages have a knock-on effect on your customers because product quality suffers. Engineers must be on call for their own code and systems, but if there are too many out of hours incidents and the trend is not towards a reduction in volume, they will eventually leave. Being woken up (or interrupted out of hours) has a huge impact on quality of life which has to be addressed quickly.
Critical problems breaking service for your customers
Customers are the second of the two crucial stakeholders that determine prioritisation. Your business only survives because customers generate revenue but without your team, you cannot service your customers. As such, customers come second. But any critical issue that is breaking a core service for your customers must be solved quickly. This can range from a complete outage to a major bug that is preventing functionality from working. These types of issues should be parachuted into the current development cycle and fixed first. It’s much easier to keep existing customers happier than to sign up new ones.
Bugs and improvements requested by or affecting existing customers
Linked to #2, keeping existing customers happy is the best way to build a sustainable business. This is especially the case with SaaS, where accounts often grow and revenue can be increased without anywhere near the cost of acquiring a new customer. Existing customers also know what they want to see in the product because they’re actually using it. You don’t necessarily have to agree with them and it may not be appropriate to build everything every customer asks for, but bugs and smaller improvements help to improve retention. SaaS revenue compounds.
Innovation
Since it has never been easier to start a business, differentiation is crucial to standing out amongst the inevitable competition. Products have to continually evolve because what is differentiating today is just a standard feature tomorrow. This means having a unique perspective of the market and what customers want from it. Building solutions to interesting problems helps attract the best team. It makes customers want to stay with you because they see the product evolve. And it makes you stand out from competitors. You can’t stay ahead just by copying.
What lost deals or prospects are asking for
Having a unique position in the market isn’t sufficient if you don’t offer the key features everyone is asking for. Understanding why customers are not buying and/or what they are asking your sales team for will give you a good insight into what you should be building. Sometimes you can commit to delivering requests as part of a deal (or with a chargeable services element on top). I’d also argue there’s a place for a whole product team dedicated just to building requests that come out of the sales and marketing discovery process.
What your competitors are doing
This is often linked to #5 if competitors are defining the market. You need to ensure you cover at least the core functionality for buyers who have a simple checklist, but then this is where #4 comes in to make your offering stand out. However, it is the lowest priority to simply copy what competitors are doing because by definition doing so will mean you’re always behind.

Whether you agree with the ordering above or not, the important thing is to have a set of rules which can be applied to inbound requests.

You’re going to get input from your team, customers, investors, board members, friends, competitors and more. Technical debt, refactoring and rearchitecting also have to be considered (maybe it comes under #1 in extreme circumstances, but it can probably be considered as part of a project that fits into one of the normal priorities).

Things will also change over time.

Only one thing can be top. Unless there is a single, ordered list of numbered priorities, nothing is the priority.