I recently had an interesting discussion with a friend about how to “measure the value of a product management team”, and it really got me thinking - what are the metrics that we can stand in front of and unambiguously say represent “success” for a product management team? It seems obvious; good product teams are successful if their products are successful. But some people might wonder if the products would have been equally successful had the “product management” just been done by the Sales team and the CEO. Are they wrong? How can we tell?
Quantitative false beard sounds fun as long as I can couple it with a matching mustache.
I haven't really heard ditching effort framed up like this. In all honesty, I've often used effort as a way to politely kill requests from high ranking folks in my different orgs who have a tendency to throw out partially baked ideas and try to push them to the top of the stack. But I could get behind what you're saying.
This is certainly a provocative post and one I disagree with mostly (while still agreeing with the principle of prioritization frameworks being problematic.)
If you have two projects that you estimate can deliver equal value, doing the one that can be done faster makes sense. Remember that the value you put on some effort is also an educated guess.
If you have a high value project that you determined is big, then obviously you have estimated how long it will take. At least roughly or relative to other things to be done. Your suggestion to split it to deliver value faster is exactly to principle behind WSJF. It is a forcing function to find the parts that can deliver the most value quickest.
Keeping mind, estimates of effort or value are not as important as the relative estimate compared to other projects under consideration.
Quantitative false beard sounds fun as long as I can couple it with a matching mustache.
I haven't really heard ditching effort framed up like this. In all honesty, I've often used effort as a way to politely kill requests from high ranking folks in my different orgs who have a tendency to throw out partially baked ideas and try to push them to the top of the stack. But I could get behind what you're saying.
This is certainly a provocative post and one I disagree with mostly (while still agreeing with the principle of prioritization frameworks being problematic.)
If you have two projects that you estimate can deliver equal value, doing the one that can be done faster makes sense. Remember that the value you put on some effort is also an educated guess.
If you have a high value project that you determined is big, then obviously you have estimated how long it will take. At least roughly or relative to other things to be done. Your suggestion to split it to deliver value faster is exactly to principle behind WSJF. It is a forcing function to find the parts that can deliver the most value quickest.
Keeping mind, estimates of effort or value are not as important as the relative estimate compared to other projects under consideration.