Throughout May, I talked to four Product Leaders based in Berlin about what they think it means to be successful in Product Management as part of my Product Top Tips series. Sam Love (Chief Product Officer at wefox), Benjamin Ramhofer (Vice President of Product at Data4Life), Alexandru Dina-Gargala (Head of Product at expondo), Parth Das (Head of Product & Operations at DECA), all collaborated on May’s edition to provide top tips for the Berlin Product market.
There were a number of great tips on developing communication skills, the importance of challenging yourself, being decisive, and taking time to deliver a better result. Two consistent themes throughout all four contributions were prioritisation and people-centricity in Product Management and Delivery. I really wanted to explore these hot topics further to gain more insight into why these are so critical to great Product Management. This blog focuses on Prioritisation in Product – read on to find out more about how to prioritise features, tasks, and backlogs in Product.
Arguably, the most challenging aspect of Product Management is prioritisation. Many roles include some form of prioritisation but within Product its even more complex. Product prioritisation is the only way for you, as a Product Leader, to decide what features gets worked on. And you have an engineering team telling you that Feature A will be amazing, data analysts convinced that Feature A is completely unnecessary, whilst your users want Feature B, but your key stakeholder wants you to roll out Feature C as soon as possible. What do you action first? You have to decide.
Sam Love, Chief Product Officer at wefox, explains that “we bring value to our customers by solving their problems, not by shipping features” and that Product leaders should “challenge your roadmap and backlog; ask yourself ‘what problem am I solving and what value does it bring to my customer’. Putting your customer at the heart of product development, and prioritising their problems is key to delivering relevant and quality product.
Whilst it may be challenging, prioritisation is fundamental to successful and sustainable product management and delivery which produces high quality, relevant and timely product features and updates, that are achievable and meet user needs.
Significant challenges around prioritisation in Product Management relates to stakeholders, more specifically around communication. Failing to communicate with key stakeholders can lead to further problems around gaining stakeholder buy in, balancing stakeholder input, aligning priorities with stakeholders, and arbitrating stakeholder demands. It’s critical that stakeholders are a part of the overall product prioritisation process as it ensures that everyone knows what to expect and by when, however, it can be hard to discuss and explain your decisions around prioritisation.
Further issues tend to arise around balancing the importance of product strategy with evidence-based customer needs and aligning prioritisation with business objectives, whilst dealing with day-to-day ad-hoc businesses. Organisation and the ability to prioritise what to action are key responsibilities for Product Managers and Leaders to ensure that Product Teams are not being pulled in different directions and to enable them to get the product backlog in order.
So, when you have multiple ways to expanding or improving your Product, how do you decide what the priority is? … Prioritisation.
There are many prioritisation techniques and frameworks that Product leaders can use to ensure they are prioritising the most important and urgent features, updates, and releases for timely delivery. Below, I summarise three of the most popular product prioritisation frameworks.
The MoSCoW framework is commonly used within Agile Product Management and can help teams and stakeholders understand what is important and what is not. It’s also a really clear way to communicate to stakeholders what you are working on and why, by categorising tasks into four categories: ‘Must have’, ‘Should have’, ‘Could have’, and ‘Won’t have’.
‘Must have’ features are those that you cannot launch without. This could be because of regulations, legal requirements, safety concerns, or specific business reasoning. If you have focused on a certain feature in the marketing for a specific product, it would be misleading and problematic to launch without it.
‘Should have’ features are things that you ideally would include, but it wouldn’t be a disaster if you don’t have them. These would only be deprioritised for must have features, as explained above.
‘Could have’ features are things that would be nice to have but aren’t necessary for success. This often depends on whether you have the resources to include these features. Whilst ‘Could have’ and
‘Should have’ features may seem similar you can differentiate between them by questioning the impact on the user. The bigger the impact, the higher up the priority list it goes.
‘Won’t have’ features are things that won’t be included in this release. It doesn’t mean they are cancelled forever, they are just not a priority right now because of business targets and objectives, user needs, or resources.
Overall, the MoSCoW framework helps organise and communicate which features are priority and why they are being worked on first, which is great for general priority management and also stakeholder management. This framework is really useful because, as Benjamin Ramhofer suggests “Urgent tasks will always arise and need to be dealt with, but not at the cost of deprioritising important tasks.” This framework will help you prioritise new and existing tasks efficiently.
The RICE scoring system is another popular choice for prioritisation assessment, and is based on four areas: Reach, Impact, Confidence, and Effort.
Reach is based on how many customers will be impacted by the feature, change, or update.
Impact is about how those customers will be affected individually, usually on a numbered multiple choice scale, e.g. 0.25 = minimal impact up to 3.0 large impact.
Confidence is a percentage that is based on your intuition and gut feeling. Anything over 80% is generally understood as a high confidence score and anything below 50% is unqualified. Essentially this helps you de-prioritise features you don’t want to take a risk on.
Effort is based on information from all teams involved (design, engineering etc.). You should be aiming for tasks that are high impact, low effort, although this is rarely the case. You need to assess the time it will take all departments to do their share of the work, and then compare this to the reach, impact, and confidence scores to determine if it’s worth the effort.
Once you have your four numbers, you them multiple Reach X Impact X Confidence, and then divide by effort. The higher the number the higher the priority.
The Kano Model is a theory for Product Development and customer satisfaction which classifies customer preferences into five categories. The Kano model encourages Product leaders to think about products in relation to customers needs and satisfaction.
The model includes two self-defining aspects which are important to keep off your roadmap which are indifferent features (features customers do not care about) and dissatisfaction features (features which will actively upset customers). The other three categories are features that you should earn a spot on your roadmap: basic (threshold features), excitement features, and performance features.
Threshold features are the features that your product needs to be competitive and are features that are taken for granted or an expected part of the product (e.g. a charging port on a mobile phone). These are features that must be included. It’s important to remember that poorly executed threshold features could lead to customer dissatisfaction.
Excitement features increase customer delight and can therefore increase customer attraction and retention. If you don’t have these features, users may not miss them, but if you include and invest in great excitement features, you will exceed your customers expectations and build brand loyalty. These features might also be called “attractive” or “delighters”.
Performance features increase customer satisfaction as you invest in them. It often directly relates to functionality, such as increasing the storage size in an online app. There is usually a direct correlation between the feature and customer satisfaction.
The Kano model is often a useful framework for product teams with limited time and resources who want to ensure they prioritise the right mix of features.
Product by its very nature is user-centric, and therefore the prioritisation within product development must also stem from user needs, whilst also aligning with business vision, purpose, and goals. Products should be built with a service mindset and should delivery value to its users time and time again. As Parth Das, Head of Product & Operations at DECA explains “whenever you repeatedly buy services from the same place, the quality of service improves because the place gets to know more about you and is able to personalise the journey for you.” This improvement can be improved through effective continued prioritisation.
Both Benjamin Ramhofer and Alexandru Dina-Gargala both emphasise the importance of taking the time “to learn who your prospects and customers are and speak with them regularly”. By doing so you can truly understand your user base and can prioritise features and fixes based on this data.
Different prioritisation frameworks will suit different leaders, teams, and businesses, but conclusively, it’s important to have a set method for organising workloads. Do you have a preferred method of prioritisation? If so, I’d love to hear about it. Drop me a message in the comments with your favourite framework and how it has helped you manage product delivery.
To feature as a Product Leader in future Product Top Tips, please get in touch directly on LinkedIn, or via email at email@example.com. Alternatively follow me on LinkedIn so you don’t miss out on future top tips and Product articles.