Product management: how do you chose what feature should be added next?
This is the delicate art of trade-offs, balancing the speed of development with the market potential of a new request
This is guest post, written by my friend Sonia Bramwell, who is the most talented project manager and product manager that I’ve worked with during my career. She sent me the following in an email, but it was so good, I felt I had to share it, and I now do so with her permission. The subject was how to prioritize the roadmap, that is, how to decide what features will be added next, versus what features can be postponed till later. Every startup has limited money, and therefore limited development talent, and therefore limited time, and so the art of deciding what comes next is often the very thing that decides whether a startup will succeed or fail.
This is from Sonia’s email:
Hi, Lawrence! I strive to balance — and help the leadership balance — 3 main factors for every roadmap initiative:
Monetization potential
The greater the monetization potential of an initiative, and the more directly it can be monetized (and the more precisely this can be measured), the higher its "bottom line" impact, hence, its priority. Some ideas have revenue potential that is easy to estimate. Other ideas have revenue potential that is difficult to estimate. Even when two ideas seem to have equal revenue potential, I’d prioritize the idea where our revenue estimate is more confident. Or to put that differently, if two ideas both might increase sales by 20%, but we only have confidence about our revenue estimate for one of those ideas, then we go with the idea about which we are confident.
Percent of users who will benefit
How much of our user base will benefit from a given improvement or feature? The greater the % of the user base, or the number of distinct user groups, that benefits from its release, the higher its priority. Also, when different customers pay different amounts for our services, then we also need to ask, which customers benefit from some new feature or service? If our most lucrative users are asking for a feature, then that gets more priority than a feature request that comes from our least lucrative users.
Level Of Effort
Last but not least: the initiative's LOE (level of effort for implementation teams, aka, all development when factoring in Design, software development, changes to Operations, changes to customer service, changes to Sales, etc, how much needs to change, and how much needs to be done, to fully implement a new feature for customers). With LOE, we're looking for an inverse relationship with the initiative: all else being comparable, if 2 separate initiatives have significantly divergent LOEs, the one with the lower LOE gets priority, expediting time to market and freeing up developer resources so they can get to work on the next feature. This is also the single most "missed" dimension in so many organizations: When relative LOEs of roadmap milestones isn't given sufficient consideration, missed market opportunities and cost overheads often result. Lastly, what makes LOE so important to consider is the same factor that makes it so difficult to: in order to provide even a rough LOE, Biz (led by Product) needs to spend sufficient time to roughly define the initiative's business goals/high level requirements. But, if the organization collaboratively invests in this definition exercise, at least for core initiatives on an ongoing basis (even quarterly), the "ROI" on this investment isn't just a LOE for each, but an actual head start of the requirements themselves, which enables the software developers to hit the ground running when the (previously discovered/defined) initiative is "up to bat".