I totally agree that “shipping” — i.e. building and delivering features for release — should not be the default mindset.

Building new capabilities is an investment, and there must be structured decisions made within the context of a strategy (or set of strategies) and roadmap on what is important and what is not. That framework will define the significant items to invest in.

So prioritization is not just a relative to other things, but aligned/constrained by the guidelines laid out by product objectives/strategy etc.

As for the heuristic (some financial measure as you give in the article), an apples-to-apples across initiatives involving $$$ is not always possible. e.g. the economic basis you mention has significant error-bars associated with it, at this very early stage.

At the strategy/roadmap level, we know with high confidence things that are big, medium, small impact etc. but given the targets (the customers, their needs, market trends, technology adoption etc.) are in flux, it’s often unclear to me what additional learning will significantly change the picture.

i.e. we’ve done a lot of analysis already to go from:

business objectives ==> product objectives ==> product strategy ==>(strategic) product roadmap ==>release plan ==>prioritized backlog.

I’m not saying there is never a case to learn more before making certain build decisions, but that learning and those decisions for larger investments should be made well before the feature prioritization exercises are performed.