Last week, we talked about how to prioritize your new product development efforts when you’re trying to get to product market fit. Once you hit that sought after milestone, your product moves into the growth stage of the product life cycle and you switch into product optimization. So it makes sense that optimization is the next scenario I’ll explore on InsideProduct. It seems like everyone is talking about product optimizationIf you’re not sure what I mean when I say product optimization, go pick five product management articles at random. If they don’t explicitly say which stage in the product life cycle they’re talking about, chances are it’s the growth stage. The activities they describe, probably continuous discovery and experimentation, are key aspects of product optimization. So to not bury the lede any more than I already have, product optimization is the act of making small changes to your product in order to improve some sort of metric, usually related to growth in terms of users, revenue or both. Prioritization in this scenario is a series of choices, similar to prioritization for new product development. Pick your goalFirst, decide what goal (i.e. outcome) you want to achieve - what results do you want your optimization efforts to result in? Are you trying to grow the number of users you have? Are you trying to increase the percentage of users that continue to use your product? Are you trying to increase the revenue your product generates? Once you know your goal, determine a good way to measure it. Be sure to pick a metric that your actions can influence and that you can see results quickly. You want a short feedback cycle so you can fairly quickly see the results of your efforts and adjust accordingly. You want to pick the goal first so you can focus your actions on achieving that goal and avoid generating a lot of seemingly good ideas that will only clog up your backlog. Contrary to what some folks believe, a big backlog is not a good thing. Prioritization is about confidence, not valueAnt Murphy points out that one reason to start with picking a specific goal is that you’ll simply have fewer things to consider. Trying to prioritize a list of 5 opportunities is much easier than a list of 50 feature ideas, which is exponentially easier than a backlog of 500+ items. So instead of generating a long list of ideas and trying to ‘prioritize by business value’, “think about outcomes and then look to gain confidence that you are solving those outcomes in the best possible way. Identify and prioritize your actionsOnce you know what you’re trying to accomplish, you can now start thinking about ways to get those results. Here are some different perspectives on how you might approach prioritizing ideas so you end up doing the best ones first. If it works for you, it’s the right modelBefore we get into some specific approaches, I wanted to share advice from Natalie Thomas, Experimentation Leader at The Good, about how to pick the right method to prioritize your experiments. Her key message: “The best prioritization model is the one that works for your team. That’s it. If it sticks, it fits.” She then described some factors to consider when picking a prioritization model: The right prioritization model is going to depend on the factors of your organization:
If your team is low trust, a system based on firm calculations that mitigate in-fighting might be best for you.
If leadership is strongly concerned with the ROI of your program and you’re still in the proof-of-concept phase for your team, then money saved or won may be more heavily weighted than other aspects.
If you are a resource-light team working to gain proof-of-concept, a prioritization method that heavily weighs the speed of results might give you the traction you need to make a case for greater investment.
If your product struggles with churn, you may want to prioritize user needs over other factors in order to build a stable of happy customers and word-of-mouth traction.
Prioritize based on factsSince the actions you identify to reach your chosen goal are experiments. It only seems reasonable to apply a scientific method when prioritizing those experiments. Michael Dubakov, founder of Fibery describes a facts-based prioritization framework his team uses for prioritization. Yes, I know I previously said don’t use frameworks, but Michael’s approach has you calculate the score based on objective facts rather than subjective rating scales. Optimizing with the help of an experiment backlogRichard Holmes with Department of Product put together a great guide for designing experiments for your product. In that guide, he echoes the benefit of deciding what goal you’re trying to achieve and then identify ideas to achieve that goal. He suggests using an experiment backlog to involve your stakeholders in identifying and prioritizing those ideas. Richard also identifies a couple of models and related questions you can use to prioritize those ideas:
Prioritization is as much a political as an analytical problemFinally, before I leave you today, I wanted to share this caveat from Rich Mironov about prioritization: Prioritization is more than an analytical/intellectual exercise. It's an organizational challenge with natural disagreements among stakeholders. Product leaders need to think about motivating the right kinds of participation and addressing the emotional issues that arise. Spreadsheets and models are necessary, but not sufficient. Thanks for ReadingThanks again for reading InsideProduct. If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email. Talk to you next week, Kent J. McDonald |
Hand-picked resources for product owners, business analysts, and product managers working in tech-enabled organizations. Check out the resources I offer below and sign up for my newsletter!
I try not to overuse click bait titles, too much. For this particular topic, however, it was just too tempting. As I mentioned in a previous newsletter, there were several reasons I went to Agile2024 after a six year hiatus. One was to get a sense of the current state of agile. There’s been a bit of chatter about the decline in agile coaching opportunities as well as trends in agile transformations in general. I certainly caught some inklings about what’s going on, but I didn’t want to rush...
I’m back from Agile2024, and it was good to be back after a 6 year hiatus. I caught up with some old friends, made some new acquaintances, and had some great discussions along the way. Some of those discussions will influence future issues of InsideProduct, and others will go down as obnoxiously long running inside jokes. If you're wondering about the latter, ask me about retractable stairs or comic sans the next time you see me. While I’m not going to talk about those topics here, I did want...
For the last few weeks, I’ve explored what prioritization looks like in a variety of different scenarios. This week finished up that series with a look at how you can go about prioritizing a bunch of stakeholder requests. This is a common scenario when you’ve already built software for your company (ie internal product) and you’re trying to optimize or maintain it. A unique aspect for internal products is that most requests for changes come from other people inside your company who may, or...