It's pretty common at a lot of organizations I've been at for there to be more of a "gut instinct" approach to prioritization when product is first implemented at scale. There are many reasons for this, but I won't be getting into that in this article. This gut instinct approach can work for some organizations longer than others. However, at some point, there must be an implementation of some method to be used across teams and across products to understand why we are delivering items and what value they plan on bringing once they ultimately are delivered. The first step to this is to create some sort of common framework to prioritize items against one another. Here is my example of this implementation and the long-lived documentation I created to bring order to a chaotic product deliver method at Brandlive.
How do we prioritize the backlog for the Platform?
The framework here is meant as a tool to use in order to take seemingly separate and unrelated stories, issues etc.. and be able to draw some understanding of what their relative importance is to one another based on the criteria outlined below.
Brandlive has three primary focus area for our business:
Marketing focus- Helping the modern day Marketer use Brandlive to host extraordinary webinars to increase engagement and ultimately lead generation for their company or initiative.
Enterprise Customer Focus- Enabling the enterprise to host all of their video content on Brandlive and have a cohesive experience for all of their production teams to host incredible webinars and expand/scale their contracts with us.
Simplicity of User Experience (Admin and Attendee)- Brandlive needs to have the most simple and seamless experience for creating and participating in webinars as possible- efforts to decrease time to create or participate in events are included in this focus area
In addition to these core focus areas there are also a few other items that we should always consider when prioritizing items for work by the development team:
Contract- If a customer is awaiting a feature to be delivered before signing a contract with Brandlive, this should always be considered in prioritization
Sellable Feature- If a feature is something that Brandlive considers eligible for an add-on/premium feature, this should be considered in prioritization
Disruption to core user journey- These items listed below are not an exhaustive list, but a baseline to use when considering what the core use journey is:
NOTE: If there is a work around for any of these issues that is even somewhat intuitive, then that inherently will lower the priority of the issue.
Attendee User Journey
Login journey
Session watching journey
Engagement activity- chat, Q&A, surveys, quizzes, polls etc…
Unusable links or unexpected page activity on primary pages- Landing, Home, Registration
Admin User Journey
Login journey
Create event journey
Primary function on the main console nav (not sub-menus or sub-tabs)
Creation of sessions, both on-demand and live
Creation of Landing, Home, Registration, Session or Custom Pages
Agenda Module issues
Email sending
Leaderboard
Audience List(s)
User management
Complexity of the request- This generally means the impact to the engineering organization and the time it would take to implement the item. Product should always be negotiating with engineering on complexity based on customer requirements and approaches that could be taken
Volume of customers requesting- If a large majority of existing or prospecting customers are after a certain item, this shall factor into prioritization so there is inherently more weight taken into consideration for this.
As a basis for initial prioritization in the primary focus area, we should be trying always to balance the features and deliverables with equal weight to each focus area. This means an equal amount of features and improvements across each of the focus areas in each sprint and/or across each release depending on which makes most sense.
Focus Area | Weight |
Marketing | 33% |
Enterprise | 33% |
Simplicity | 33% |
In the other areas of prioritization, the following weights should be used to determine the estimated prioritization against other items:
Inputs | Weights |
Contract Value | 20% |
Sellable Feature | 15% |
Disruption to Core User Journey | 40% |
Complexity | 10% |
Volume of Requests | 15% |
Example:
Feature 1
Inputs | Weight | Value |
Contract Value | 20% | 5 |
Sellable Feature | 15% | 4 |
Disruption to Core User Journey | 40% | 2 |
Complexity | 10% | 3 |
Volume of Request | 15% | 1 |
Feature 1 Value: 2.85
Feature 2
Inputs | Weight | Value |
Contract Value | 20% | 3 |
Sellable Feature | 15% | 2 |
Disruption to Core User Journey | 40% | 4 |
Complexity | 10% | 1 |
Volume of Request | 15% | 3 |
F
eature 2 Value: 3.05
Based on this value, Feature 2 should be prioritized over Feature 1
Comments