Prioritising the Product Backlog

Louise Cantrill (Head of Consultancy at Tarigo and one of the sponsors of the Cambridge Product Management Network) writes an excellent article on the various Methods to Prioritise User Stories.

All prioritization techniques attempt to rate all the possible projects. Doing the high value / low cost projects are a no-brainer, of course. And you don't need a fancy model to tell you these big wins from the rest. It's what happens when you've done all the obvious ones - that's where it gets hard.

These techniques are supposed to make a comparison between big scary projects that are high risk, tie up lots of resources, but create new exciting opportunities versus lots of small improvements that are (relatively) quick to realise, benefit a sub-set of customers or make small, incremental improvements in consistency (for example).

All of these techniques have their advantages and will give you a ranked order of projects, based on biases that each technique injects. I have delivered my own prioritization technique - see Feature Prioritization and Roadmapping.

Whatever the results, you can view them as militant instructions or mildly useful recommendations. Nothing trumps a CEO who has just had a berating from a key customer or his dreamy conversation with a visionary at a conference!!!

1. RICE Scoring

Reach	the percentage of users or customers who will be affected by the feature, or initiative.
Impact	an assessment of the potential value or benefit that the project or feature will bring to the users or the organization.
Confidence	The team's level of certainty in the Reach and Impact estimates.
Effort	Effort quantifies the resources, time, and complexity required to implement the project or feature. It considers factors like development time, design work, testing, and any other resources needed. Effort is typically scored numerically, such as assigning a time estimate in hours or days.

RICE score for a particular concept = (Reach x Impact x Confidence) / Effort

I like this approach because: it appreciates that some features only benefits some customers. Without this, product development has a bias towards only doing features for 'squeakiest wheel', which is often the biggest customer.

2. MoSCoW Method

Must-Have	User stories that are essential for the project's success.
Should-Have	Important stories but not critical for the project's immediate success.
Could-Have	Desirable stories, but not necessary
Won't-Have	Stories that will not be included in the current iteration.

This method helps teams categorize and focus on critical user stories while allowing flexibility for less vital ones.

I like this approach because: This is great for a first-pass at prioritization: at any point in time, there are some user stories which simply NEED to get done: these could be hygiene features or simply mandated features that your biggest customer has demanded asap prior to renewal. 

3. Weighted Shortest Job First (WSJF)

This prioritization technique used in Agile and Lean software development, particularly within the context of Scaled Agile Framework (SAFe).  

WSJF is calculated using the following formula:

WSJF = (CoD + CoR) / Job Size

CoD (Cost of Delay)	This represents the business value or impact that a particular user story or feature will deliver. It measures how much financial loss or opportunity gain would be associated with delaying the implementation of that item.
CoR (Cost of the job in Progress)	This factor accounts for the ongoing cost incurred while the job is in progress. It considers aspects such as the operational costs or maintenance expenses that the organization bears until the task is completed.
Job Size	This refers to the size or effort required to complete the user story or feature. It can be measured in various ways, such as story points in Agile development.

WSJF scoring focuses on end value, the pain (which is increases over time) of waiting for the product feature as well as the effort needed

I like it because: it recognises that there is cost of NOT doing a feature: inefficiency or lost revenue (or ear-bashing from a customer) whilst the feature isn't in the product.

 

4. Kano Model

Features are categorised based on whether customers positively or negatively value the enhancement

Basic Needs (Must-Have)	The essential features that customers expect as a minimum requirement ie Hygiene Features. Without these features, customer dissatisfaction is almost guaranteed. However, fulfilling these requirements typically does not lead to increased customer satisfaction.
Performance Needs (Linear)	Features that correlate directly with customer satisfaction. As the performance of these features improves, customer satisfaction increases. These features are often explicitly stated by customers.
Excitement Needs (Delighters)	unexpected or surprising features that have the potential to delight customers. When these features are present, they can significantly boost customer satisfaction, but their absence doesn't necessarily lead to dissatisfaction. Customers often do not express these desires because they haven't experienced them before. Differentiating Features
Indifferent Needs (Neutral)	The presence or absence of these features doesn't significantly affect overall satisfaction.
Reverse Needs (Unwanted)	When present, can lead to customer dissatisfaction.

I like it because: sometimes you need to build features that have sizzle, even if your user base has limited utility. As I write this in Autumn 2023, every company has to have an AI strategy, regardless of whether their market has a use for it. 

Conversely, Many new product managers think that adding more functionality inevitably adds to a product. NO!! When the quality of a new feature is less than the rest of the product, it detracts. When an feature is simply odd when considering the product as a portfolio of features, it detracts because it confuses the user.

5. Value vs Effort Matrix

Each feature is scored as to its effort (x-axis) and its value (y-value). My own Feature Prioritization and Roadmapping uses this technique.

High Value + Low Effort are immediate candidates. Low Value + High Effort will never be done.

What's left are all the features that require more head scratching. This technique can help, but it will absolutely NOT provide a prioritised list, but it will definitely uncover some assumptions and biases - see read my article for more commentary.

I like it because: Well, this is the one that when serious prioritisation is required, this is the tool that I pullout of the bag.

Conclusion - what do I really use??

Well kinda a blend of many of the above:

1. MoSCoW flushes out the hygiene features.
2. The time-cost of NOT having a feature is next most important
3. Ongoing investment in the Linear Features (from the Kano Model) with due regard to continuously topping up investment in Differentiating Features.
4. Use Ring Fence Development (on Page 3 of my Feature Prioritisation article) to make sure you have a reasonable balance between bug fixes, hygiene features, linear development and big innovation bets.
5. Once a year, do a product portfolio analysis (using Feature Prioritization and Roadmapping technique) to benchmark all significant future projects against each other. For product enhancements that are requested after the annual review, measure them against a couple of existing projects that have already been benchmarked.

And Why?

RICE, WSJF, Value vs Effort all require heavy-duty future predictions and detailed analysis using difficult-to-find information from other parts of the business. 

They are only really worthwhile for large products decisions whose features / technology dependencies are relatively independent of each other. 

MoSCoW and Kano use simple categorisation to drop feature requests into buckets. Ring Fence Development (on Page 3 of my Feature Prioritisation article) permits the product to move forward on a number of fronts, each effectively having their own backlog.

MoSCoW 

The tough end of product management - sunsetting or cannibalising a product

Sunsetting a product (elegantly) is far harder than creating a product. And cannibalising a existing product with a new one is the hardest of all.

New product development is easy. If it was house-building, you get to choose the brick and where you're going to put it. With sunsetting, it's like putting a wrecking ball through someone's home and expecting them to like it. 

You could say that agile / continuous delivery is the ongoing process of product replacement. True - but the replacement is only modestly different and hopefully better. The cannibalisation that I am referring to is the line-in-the-sand-never-to-return replacement.

Why so hard? An example of the unintended complexities of sunsetting a product

Once upon a time, my management team (inc. me) made a decision to terminate a product: the product had revenue and customers who loved it, but the market's requirements were increasing and the product's market position was being eroded. The investment required to bring the product back into the forefront of the market was significant and ultimately, the returns were better elsewhere in the product portfolio. 

In considering all the ramifications of no longer selling the product, I realised that one of the sales team, let's call her Elspeth, got about 50% of her commission from the sales of this product, as all leads were passed to her. As a result of the (correct) decision to close down the product, she would most probably quit and I thought she was someone that we should keep.

I went to the Head of Sales and pointed this out. He agreed and, as a result, he initiated a territory reassignment, which - and stop me if you've ever been through one of these experiences (*) - took weeks to design / approve / discuss with affected parties etc. 

In the meantime, as the product manager, I oversaw many operational decisions about the product too. I had to try and keep sales going, but approve as few contracts as possible without pissing off Elspeth too much. For example, I had to throw down lots of impediments to each sale: “There's no capacity to deliver that", "Technically, those requirements are challenging", "Ah, that customer will require new functionality that's planned for the next quarter." etc

This, of course, made Elspeth furious - she could see her targets / commission draining away. Complaints were made up and down the company about how I was obstructing every sale. Technically this wasn't true, I approved some deals in order to keep the wheels turning without making it SUPER obvious that sales and delivery was grinding to a halt. Indeed, Elspeth started to believe that I had a personal vendetta against her.

Eventually the territory reassignment plan was all agreed, Elspeth had some new turf carved out for her. She was given some commission for the sunset product sales that she should have won. And finally, we could implement the sunset plan - a plan that had plenty of moving parts in itself: letting existing customers know, properly killing deals in the pipeline, changing the website, redoing sales & budget forecasts, internal comms, etc.  What a lot of stress. And Elspeth finally forgave me!

(*) Territory realignments are painful because: 

• What happens to deals where the customer is just about to sign? 
• What about that tacit knowledge of the customer's business and relationship that the sales team has generated?
• What do you do with commission for deals have been initiated by one sales gal but closed by another? Does credit go to the initiator or the closer or both - and in what ratio? 

This becomes harder when sales revenue is recurring as in SaaS businesses.

Other scenarios: 

• What about pilot or pathfinder deals - deals that prove a concept with the expectation that future business would result? 
• When the SaaS revenue is highly variable or seasonal?

Easy cannibalisation 

Swapping out an old product with a new product is easy if the new product is bigger and better in every way and cheaper than the existing product. If the product is more immature, has less functionality (at go-to-market), has a different pricing structure than the old product - what a surprise - you may encounter market resistance. 

• "You haven't finished the product that you sold me X years ago." 
• "I can't run my business without features X, Y and Z." 
• "What? How much more? Are you mad or am I hard of hearing?"

What about internal resistance? Yes, there can be no shortage of that either. If you change the price / pricing structure, it can destroy existing deals in the pipeline (sales, account management & customer support hate you) if the price is more expensive. If the price is cheaper, then sales, account management and finance hate you, as revenue plunges.

Some recommendations from someone that has gone through hell:

1. Make sure you have the big picture justifications absolutely nailed and bombproof.
1. Expressions like "Trust me, it's hard" and "It's been decided - it's very complex" will undermine (product) management in the mid-term, never mind the long-term.
2. Understand your customer base - and the outliers. Handle the outliers with great care - the customers themselves and the internal teams that support them.
3. Do NOT assume that you will convert every existing customer to the new product.
1. List out the customers that are most likely to flee and make sure that EVERYONE understands that these accounts are at risk and assume that you'll lose some. 100% conversion is simply naïve.
2. Make sure that execs are fully onboard if these customers threaten to flee - and they are briefed when they get calls from furious customers (and colleagues).
3. If it is obvious that the outlier customers might flee, then is the company OK with it? (I mean really???)
4. Make sure that someone (it may not be product management) has done the analysis of which colleagues might leave (that the company actually needs).
1. This is super difficult, as some of the reasoning behind sunsetting a product might be associated with technology and skills sets. 
2. There is an implicit assumption that colleagues will blindly follow an executive decision. The very people that you want to retain for their business knowledge may flee because their product / technology has been jettisoned. 
5. If you think that product managers should communicate (and they should!), then DOUBLE OVER-COMMUNICATE when sunsetting a product.
1. Herein lies the hard part of sunsetting a product - a decision to cull a product may require a rapid execution in order that the process doesn't spiral out of control. However, the very people that you need to consult to make a competent decision may be sufficiently ill-informed to advise you.

Finally, best wishes - bridging the chasm between old and new products, especially if it involves repricing is the toughest job in product management!

Product Management for Corporate Glue AND Lubricating Oil

Product Managers have a fascinating, all-encompassing role. They can be called many things, CEO of the product, Janitor, Super User. See Product Manager is a janitor basically.

All other business functions are well understood: 

• Engineering develops the product
• QA assures that the product 
• Sales converts a product into justifiable business value for each customer
• Marketing communicates the product proposition to a market of similar users / buyers

etc

But what do Product Managers do? 

• Product managers are frequently the glue that keeps the rest of the business functions inside a technology organisation stuck together. They fill in the cracks in between all these business functions.
• And they are the corporate 'oil' that lubricates other business functions within the company, making each function more efficient and in better harmony with each other.

Example

The next version of the product is coming. It's in Engineering. Product Management has defined the requirements of the product and during the build cycle, it assists with dilemmas and issue resolution.

QA is shaping up to receive the product, but this new version is more sophisticated than the previous version. The QA team need to understand the common use cases / user flows in order to write system / regression tests. They rely on Product Management for guidance.

Marketing is familiar with existing positioning, but this latest release opens up new markets and positioning. They rely on Product Management for guidance: what are the USPs? what are the best use cases? how should it be positioned and to whom? 

Sales may not be able to help for lots of reasons - they want to sell the existing products, not ones that aren't on the price list yet. The rest of the company is dependent on the Sales team selling the existing product in suitable volumes in order to pay the salary bill each month - you really want them sticking to the knitting and selling what's in the warehouse now, not yet-to-be-proven products still on the production line.

Additionally, they have had limited exposure to it: feature and functions aren't well understood yet, positioning isn't developed, use cases and case studies are embryonic at best

Account Management and Support want to know what's different about the new product and how can it be positioned to existing customers and how can they benefit most from it. Is it as good as the existing product? Can existing customers try it before they buy it etc? What the known limitations?

So, often it is the product manager / marketer that goes prospecting for beta customers and manages the beta programme(s) to their successful (hopefully!) conclusions. See the The challenge of beta programmes and Product Launch vs Release vs General Availability vs Deployment.

As a result, it is Product Management who is at the heart of technology product company, acting as its glue and the oil - and that's not contradictory!

See also How everyone else views the first-in-post product manager

ChatGPT for product management

With the release of OpenAI’s ChatGPT at the very end of November last year, there has been an explosion of enthusiasm. Here’s their trajectory to a million users!

(Thanks to Azeem Azhar of Exponential View)

Initially, the response was ‘Look at this cool poem that ChatGPT wrote.’ Thankfully more considered use cases are now developing.

So here are my thoughts on how ChatGPT can help Product Managers:

Broad Use Cases	Use Cases for Product Management
Summarisation of a long body of text	Summarising large amount of texts for requirements analysis chatGPT is surprisingly competent at summarising text eg for condensing a whole list of free-form product requests from customers into a couple of pithy themes.
And the inverse, extrapolation of short body of text.	Writing product descriptions for product marketing. a. Reinterpreting features to benefits b. Rewriting product marketing copy for particular audiences
Variation of an existing body of text	Wearing your product marketing hat, you have written some descriptive words, but they need some help or the body of text needs to be shorter to fit into a text box on the website or on your PowerPoint.
Initial research into a topic or industry	As Product Managers, we spend a lot of time trying to make sense of a market / customer / technology / product / service. I can see myself using chatGPT as a great start to understanding the four walls of a market. Market research: what do I need to know about XYZ? What’s new and important in the XYZ sector? Who has the competitive advantage and why in XYZ sector? It’s great a high-level summaries, but not good enough for the details that matter.

As always the devil is in the details, but at least it gives the Product Management some boundaries and some structure to start with. And you would never submit the output from ChatGPT as your completed, best thoughts, BUT it does provide a start and save on that first half hour / blank canvas problem / writer's block when you’re wondering where to start from.

ChatGPT for managers

One great advantage is that it can create consistency when you have review or compare work from multiple teams. By getting your teams to start with ChatGPT's output, then at least all the teams have started from the same point with their use case (not using a template).

What it won't do effectively?

Some have claimed that it could be used to write product requirements. Nope – well, not to a meaningful level and certainly not good enough to give to a developer.

Cute Use Cases

• There’s one elegant use case of writing a Value Model Canvas.
• I Interviewed ChatGPT for a PM role, and it almost got the job

Side Notes on OpenAI

• Who are their investors - it's always useful to know where the money flows. 
• Y Combinator
• Peter Thiel (founder of Paypal)
• Reid Hoffman Foundation (founder of LinkedIn)
• Khosla Ventures 
• Elon Musk did invest, but has now sold off his stake
• Microsoft Ventures ($1bn investment in 2019 + MS has built a supercomputer in Azure to support OpenAI ML research)

OpenAI have more complex corporate structure than most: there is for-profit corporation OpenAI LP and its parent company, the non-profit OpenAI Inc. AND in 2019, OpenAI transitioned from non-profit to "capped" for-profit, with profit cap set to 100X on any investment. (Source: Wikipedia)