A frequent way to prioritize work is to rank work items by effort and value. This falls flat for a couple reasons:

• High, medium, low value … does not reflect your confidence level. Some things have a low probability of being big winners. What’s the value in that case?
• High, medium, low value … does not reflect urgency/depreciation. The item might be extremely valuable, but it will be equally valuable in a year. Or it will lose value immediately after a particular date (like a new landing page for a Superbowl ad)
• Some efforts are amenable to incremental value delivery, and others are not. Incremental delivery lets us deliver some % of the value quickly, thereby reducing risk and extracting information to inform future efforts. We’re also free to make partial progress, and stop. What is that worth?
• In a similar vein, some items have a lot of optionality while others require a leap of faith. What is that flexibility worth? Is that reflected in Value?
• When prioritizing, it can be tempting to “project-ify” missions so that you can estimate effort. That turns the discussion into “how valuable will it be to ship this feature and how long will it take?” vs. “how valuable will it be to solve this problem and how can we incrementally fund this?” These two questions can yield very different answers (one is bounded by the particular solution)
• Value is relative to all other efforts that share dependencies. If you ask 10 product managers to rank their priorities, you’ll get high priority items from everyone. This is fine if you have ten autonomous teams. But if those teams share a resource — Ops, infrastructure, UX, for example — then you need to compare the items apples-to-apples. When you do that, you’ll get some teams that can work autonomously on low priority items. Which is fine until you realize those low priority items add complexity and overhead.
• Effort…does not reflect the cost of maintaining added complexity. Building something quickly may introduce technical debt that has longterm, non-linear costs. Or, the cost of supporting the feature may be huge (and we often ignore this effort). You could also consider this as negative value or a liability
• Effort rarely accounts for muti-tasking costs. What is the effort in the context of other work that will be occurring?
• What is information worth? When thinking about value, we frequently limit ourselves to cost savings and revenue. But information can be extremely valuable (e.g. revealing customer needs) I suggest learning more about cost-of-delay for an alternate prioritization approach.