The Low Hanging Fruit Paradox
What Software Product Management Taught Me About Prioritization
With all the new incredible tech (mainly AI-powered) that floods healthcare, there are a lot of conversations about how health systems should prioritize their technology projects. It’s a real problem. Software companies, that need to continuously make hard decisions on what capabilities to develop next, face a very similar challenge with their Product Backlogs.
The Product Backlog is a concept that makes sense: put all the stuff you want to add to the product, prioritize it, and then start implementing from the top. From time to time your needs change and you have to re-prioritize the backlog, but the development team always knows the next thing they are working on.
Methods for prioritizing the backlog are some of the most important product management tools. Saying “no” and staying hyper focused is what success is all about.
One of the methods for prioritizing a backlog with the Product Management team is this:
-After gathering the most needed capabilities (based on inputs from customers, the sales and marketing teams, the product vision…), you end up with a list of product features on a whiteboard.
-Each team member gets 10 votes.
-The team members decide how they split their votes between the features. They can put everything on one feature, or split it between features.
-You sum up the votes and get your prioritized backlog. Ta da!
The problem with this method: some of the features are smaller and some are giant ambitious projects (think: “fix this annoying little user flow” vs “develop a new user interface”). Low hanging fruit features are mixed with strategic and ambitious features. And who wants to waste their precious voting power on stupid small stuff?!
The result: the amazing low hanging fruit are never prioritized high enough to make it to the top.
Every product manager will tell you that the most suprisingly important features they added in their career were the low hanging fruit that took the developers 2 days to implement and were business game changers. Every product manager can remember the big “strategic” projects that were meaningless by the time they were ready.
A solution for this problem that my team utilized back in my Product Management days: while the big ticket items were prioritized with key decision makers a few times a year, each Technical Product Manager also had their own separate “low hanging fruit” backlog. They made sure the developers dedicated some resources to that backlog. The executives gave up some control: the Technical Product Managers didn’t prioritize the low-hanging fruit backlogs with the entire Product team or with the executives. The Technical Product Managers only had to keep their backlog transparent and update everyone about it so there were no conflicts. The Technical Product Managers had autonomy — they understood their areas of the product best, and were close to the end-users.
The low hanging fruit features were some of our best product capabilities. They had real impact on our users, and they were often what users raved about.
As health systems work on structuring how they prioritize their big tech projects (“Hospital at Home”, “AI fixes healthcare” etc.), I wish some time was spent on developing a simple framework for autonomy on the “low hanging fruit” backlogs. We may find that these low hanging fruit, the capabilities that no c-suite executive sponsor would spend their precious voting power on, are the real game changers.