By simplification principle, maybe we should invert the value problem!?

Note: on a very personal note, although she doesn’t even read this, but who kwows maybe some day she might, and I’m just so proud of her that feel like shouting from the mountain top… January 31st is a special day for me. My first daughter, Isabela, was born, which also means all of sudden I became a dad, 13 years ago. This kid, and the two others who followed her, has taught me so much I can’t even properly articulate. I am a better man for having them in my life, so I’m a big advocate for it (although ultimately your life you own business, obviously). Kids rock! Not because life becomes easier with them, quite on the contrary, it’s almost precisely for the opposite – it becomes harder but at the same time so much brighter that you have no other way than keep going because all will make sense and be worthwhile (both in the end, but also on ongoing basis). Thank you, my sweet Isabela, for being part of my life for this last 13 years – and I hope for many, many and many more! Dad loves you.

I am not entirely sure how to transition and follow the above note, so I guess I should just jump straight in…

We know the deal. Products are means to solve problems (or framed more positively, to somehow add value), and hopefully they do that in a way that is sustainable – the least thing we want is to create bigger problems (or not be adding enough value) while trying to solve one.

It can happen, that’s the reason we should keep our options open to either pivot out, or sometimes completely let something go – in other words, do proper lifecycle management. There’s no shame for as long as we are learning along the way.

We humans love to try to represent complex concepts in a simplified manner, or in a more concrete fashion, thus a lot of what we are typically after when trying to assess the sustainability question around a product is to get a sense of “return on investment” (ROI). That is to ask ourselves questions like…

Was it all worth the trouble? Did we accomplish enough for all the effort we put in? We took some risks by somehow putting our “capital” (here defined rather broadly) behind this thing, did we get enough benefit back?

This are considerably easier questions to answer on retrospect. The real challenge though is that we can't quite always know how to anser that upfront (which would be the ideal), and honestly I’m being kind by saying “not always” (it’s more like just in rather controlled situations we can properly put a finger on it).

To be clear, I still advocate for the discipline of trying to understand value upfront, I just accept the probabilistic nature of it and that I can be wrong, and by a lot! So I advocate for it to then forget about it on a practical level, knowing that what will make a bigger difference is focusing on accelerating the learnings with the smart combination of flow and right-sizing.

It recently has hit me – “right-sizing” can be seen as just a mechanism to keep the investment part of the ROI conundrum in check!

I like giving credit were due, the insight came up after reading this piece on feature price from

Mike Veerman

. I got myself thinking about the practical utility of trying to answer that question and the implications of having that insight for meaningful conversations.

I eventually realized this may be a way to think about it – there’s a simplification principle on problem-solving, that essentially states that instead of trying to solve the tough problem directly (here by focusing on the value side of the equation), we can simplify it by addressing a simpler related problem (of similar nature).

I would like to suggest there’s a lot of practical utility to use that approach to reason about the balance of the two sides of the ROI equation… For example, if we are yet so unsure about the value we could unlock, that immediately should lead us to be much more conscious on what to put in as an investment (just like we would do for a financial investment, for instance).

That best news is that (the “cost side*”, the efforts we put int…) is much more on our direct control, on an ongoing basis. It’s really a no brainer, once you really think about it. That can lead into much more insightful questions in contrast to the ones we typically tend to try to answer upfront…

I also realized that a lot of this overarching thinking, on a pragmatic level, maps back to one of the alternative I’ve articulated in the previous post on trying to determine value: contrast to invest.

It’s about keeping regularly in check, under the uncertainty of the value side of the equation, whether indeed is “all worth the trouble”... Does it even make sense to continue investing on it, or even to consider doing it on the first place, if we the contrast to invest with what we know now doesn’t seem to “add up”.

Or better yet – we can use the logic of “enabling contraints” (which in literature would be precisely the way to go about managing complexity) to frame even more empowering question such as:

If all we are willing to invest now is ‘X’ week(s) worth of effort, what’s the ‘X’ week’s effort version of attempting to solve this problem? Or at least to make sufficient progress, so that we can learn something meaningful to better understand if we should proceed moving forward or not?

It’s important to counter the risk of incurring on “sunk cost fallacy” by just keep going without sufficient signals just while we are at it anyway. We can largely do that by having clear success criteria at any stage we put a level of ambition behind attempting something (the ‘X’ week's version question).

I hope you can see how’s that considerably simpler than the typical scenario where we too easily get ourselves into a kind of rabbit hole of wrestling with the whole value x cost conundrum. It’s always simpler to focus on what we can more easily control, ultimately.

* I do want to make sure what I am alluding to here is deeper than the often use rough idea of estimation, or using relative story points, and stuff like that. I personally like to ground myself on a much more concrete level by talking about how many pieces of broke down work (maybe in your context you may call them stories, or tasks – whatever is the tactical level item that flow through your development processes). I then like to use throughput-based forecasting (e.g., using Monte Carlo simulations) to give it all a much more robust statistical basis, as well as embrace the probabilistic nature of the problem of trying to project “costs" (or efforts, in this case).

By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.