Seems like they reinvent the wheel feeling innovative when this has already been solved for 15 years or so. If you assign costs/estimations before prioritisation and ordering the whole issue goes away because PMs can just take the cost into account when planning. Importantly: It is rare that the mismatch of cost vs. value really leads to misplanning because real life is more nuanced and has also more factors. There are milestones and higher level objectives that some things play into and others don't. There is team availability and work dependencies/blockers. A PM knows all of these factors and balances them ad hoc without the need for an extra level of "value estimations" and more process. There is ONE important exception: This could be a really good framework for deciding what items that have been deferred multiple times because it never fit into a milestone/initiative to purge or finally really commit to doing.
To be fair, this article should also include the situation where engineers are delaying customer value by insisting they must first invent a custom abstract all-purpose meta-framework before implementing any user features.
The product vs engineering framing here didn’t sit well with me. For a deep dive I would recommend Don Reinertsen’s Principles of Product Development Flow (2009).
Seems like they reinvent the wheel feeling innovative when this has already been solved for 15 years or so. If you assign costs/estimations before prioritisation and ordering the whole issue goes away because PMs can just take the cost into account when planning. Importantly: It is rare that the mismatch of cost vs. value really leads to misplanning because real life is more nuanced and has also more factors. There are milestones and higher level objectives that some things play into and others don't. There is team availability and work dependencies/blockers. A PM knows all of these factors and balances them ad hoc without the need for an extra level of "value estimations" and more process. There is ONE important exception: This could be a really good framework for deciding what items that have been deferred multiple times because it never fit into a milestone/initiative to purge or finally really commit to doing.
To be fair, this article should also include the situation where engineers are delaying customer value by insisting they must first invent a custom abstract all-purpose meta-framework before implementing any user features.
The product vs engineering framing here didn’t sit well with me. For a deep dive I would recommend Don Reinertsen’s Principles of Product Development Flow (2009).