As a SaaS product manager, your challenge is picking the right things to develop at the right time. Development resources are scarce, time is limited, and stakes are high, so how do you set development priorities for the coming sprints?
For me, the following four criteria have been a lifesaver when it comes to determining sprint priorities:
- Product Vision,
- Impact,
- Urgency,
- Effort.
I leave it up to you what scale you want to use, but I would opt for:
- Top
- High
- Medium
- Low
- Ignore
Before digging deeper into these four topics, I would like to mention that I believe setting priorities should be based on a healthy mix of quantitative and non-quantitative topics. If we only focus on things we can quantify (decrease in cost, growth in MRR and margin), many great things would never happen. Non-quantitative doesn’t mean it is only built on a gut feeling, but it could be constructed based on a vision that is hard to quantify.
Product Vision
If there is anything that should be the priority of your SaaS development, it’s the Product Vision you set out. You should ensure full support for your product vision from management and, whenever possible, be the product advocate promoting the vision to all stakeholders.
Any feature requests that are not in line with your Product Vision should be scrutinized and will often fall in the category of:
- Good idea, but we are not going to do it. (As it’s not in line with the product vision).
The opposite happens when ideas that pop up align with your product vision.
As a Product Manager, having a strong product vision to guide you will make your life much easier and help you make tough decisions quickly.
Impact
Impact is not a single-dimensioned factor. When I look at the impact, I take into consideration things like:
Impact on the User or Customer:
- By answering the question: What’s in for the customer?
- How easy will it be for a user to adopt the new feature?
- How many do you expect will adopt the new feature and why, or perhaps sometimes easier to answer why not?
Impact on your business:
- Once you know the value it brings to your customer, you can answer the question: What’s in it for our company?
- Do we achieve a cost reduction or an increase in margin, MRR or customers?
Marketing:
- Will this new idea be a real differentiator builder, setting us apart from the competition? Can we introduce it easily within current marketing content, or do we need to add or change things?
Again, you see a mix of quantitive and non-quantitative topics, which means that not all impacts are equal.
Urgency
Urgency speaks for itself. Do we need it now, can it wait, or is it a nice to have? If your stakeholders claim they need it now, ask them why.
- And what if we postpone until x date?
- Would that still be feasible?
In other words, don’t let your stakeholder’s agenda determine the Urgency without taking a helicopter view and asking the right questions.
Effort
After having led the development of a SaaS service for some time, you, as a Product Manager, should be able to get a first sense of how a feature request fits in the current architecture. That enables you to make an educated guess on the needed effort.
Depending on the topic, you might consult the team or your lead engineer to validate that first estimation; it continues to be an estimation and is only there for you to be able to set priorities!
Later, when preparing the items for the sprint, the team will further distil the feature request and estimate the needed story points. Don’t be surprised when the initial estimation and final story points don’t add up. This improves when your development team becomes more senior.
We are focused on the development team’s efforts, but as a SaaS Product Manager, you don’t just have a development team to run; you need to create marketing materials, set pricing, introduce new services, and so on. Please consider these items when you look at the required effort.
Swimming lanes
If you treat all items in your backlog equally by validating with the above four metrics, some items will never make it to your development sprint. And that can cause unwanted effects. Instead, I propose you create swimming lanes. I previously used the following swimming lanes:
- Bugs,
- Features,
- Refactoring.
When filling the sprint, we would look at all three swimming lanes and decide which items would go in the next sprint. This resulted in more balanced sprints and higher development team satisfaction as they saw progress in all three swimming lanes. I suggest you create swimming lanes with topics relevant to the state of your application.
The fifth element
While filling the sprint based on set priorities, I have often rearranged the sequence of items based on the team’s feedback. They would mention that from a development perspective, developing Feature B before Feature A would make more sense and save development time. As a Product Manager, you should be open to and promote this kind of feedback, as it can save valuable time and increase product quality.