Feature prioritization in enterprise SaaS
A framework to help in backlog prioritization in the Enterprise SaaS world
Feature prioritization is essential to plan out the “dev” roadmap. It helps answer the broad question “what are we going to do over the next 6 months?”, and the very specific question “ what are we developing next sprint”.
Features come from different sources
Some of the sources of new features
- Customer requests are features that originate from the customer
- Compliance requests are an outcome of the laws of the land that your customer operates in
- Tech debt is internal facing. These may manifest, in the worst case, as issues that the customer is facing from time to time
- Strategic are initiatives that unlock the long term value and align with the company OKRs
- Bugs, while not features strictly speaking, are also backlog items that need to be prioritized
Priority of features depends upon the sources.
- Compliance features are typically high priority (P0). You may be launching in a new geo, and the timeline for the launch is depended upon when the compliance feature can be delivered.
- Tech debt features depend. If you are already seeing system-level performance issues that you’re firefighting on an ongoing basis, or you see these issues cropping up in the near term for whatever reason e.g. scaling, then you better make this a high priority (P0), and get it done asap. There could be other cases where the cost is bearable, and in such cases you could lower the priority and wait for a more appropriate moment to fix it.
- Strategic features are strategic because they unlock significant value, and therefore it is good practice to prioritize these very highly (P0). Because there is no real pressure to push on these, and the fact that you typically have many fires to fight and noisy customers, Strategic features tend to get pushed out. Get your process to a place where you are on the front foot and attacking Strategic features at highest priority (P0).
- Customer requests are more nuanced to deal with. Prioritizing these will typically be a function of a) How important is the customer who is requesting? b) What stage is the project in ? If it is a pilot/launch, then there is an inherent pressure to impress the customer at this early stage (get things off to a good start) c) Does this feature have impact on other customers? d) Does it directly align with the company’s Objectives (OKRs)/North star metric?
- Bugs always leave a set bandwidth in every sprint for unplanned Bugs that will come along and need to be worked on (Sev 1s) or planned ones that are pulled in at the start of the sprint
A Framework for prioritization in Enterprise SaaS
Effective priority = f (Customer importance, Project stage, North star metric alignment and Cross-customer relevance)
Now, what you will notice is that the presented approach translates fairly well to the popular RICE (Reach Impact Confidence and Effort) framework.
The “Customer Importance” and “Cross customer relevance” delivers “Reach” and “North star metric alignment” delivers “Impact”.
The “C= Confidence”, is less relevant in the Enterprise world as you typically deliver what the customer requests, under the assumption that the customer knows their business better. “E=Effort”is the same in both the consumer and Enterprise worlds. If two features deliver equal value while one is easier to develop, then it does logically follow that the lower effort feature should be prioritized.
Below is an example of a prioritization exercise.
Take for example the feature “Integrate with OEM X Telematics cloud”. While this feature doesn’t have any customers clamoring for it to be delivered, it is one that aligns highly with the N Star Metric (Total vehicles on platform) and has cross customer relevance. This in itself means the impact of this feature is high and therefore deserves a “P0” effective priority.
Now consider that you don’t have enough Bandwidth to pull the feature discussed above into the next sprint because you have other competing P0 priorities that actually have customer commitments that hinge on them. What you should do then is to pull it in as soon as Bandwidth opens up in subsequent sprints.
Conclusion
References:
