Making Software: the blessing and the curse

Picture this… You bring together a group of smart people who knows the domain, to kick-off an ideation session for a new product you’d like to launch.

How much time would it take to have enough options that could easily occupy something like in the range of 6 to 12 months worth of work? Half an hour, tops?!

Now, combine that with the fact that we are talking about a software product, meaning that changing is fairly easy, particularly if compared to a hardware product. Such a blessing, isn't it!? In principle, absolutely! But what about in practice? It might be a whole different story…

Afterwards, ideas are cheap. And execution is everything!

For as cliché as that might sound, there’s a lot of truth to that. And perhaps if you want to be a bit more precise and further elaborate on it, here’s an alternative…

There’s always a lot we could do. But it’s not about that. It’s about what we SHOULD do, meaning what will actually create value.

So the real question is how to sort it out, and act upon signals as opposed to noise. Talking about cliché, much easier said than done.

And that’s precisely why what should be such a blessing from the skies of being so easy to change in software, might become rather a curse.

After all, if it’s so easy, we might as well just act upon pretty much anything that comes our way. Or at least that’s the risk!

I think you get the general idea by now… The next sensible question, then, is how to solve for that. How to figure out how we get that trade-off right, of leveraging the easy to change in software while not risking overdoing it and ending up in a situation, of a product with a bunch of features no one really uses (or rarely does so). Some industry benchmarks have estimated that risk to be as high as about half of features fitting in that category (of never or rarely used).

Not a situation any of us would like to be in, I hope you agree with me… The challenge is real, and in fact having too many features creates cascading effects which would turn that blessing of being easy to change considerably less so – in other words, making the product so much more complex than it should be and thus changing is more complicated, taking longer.

That just further aggravates the whole problem.

So, what now!?

Should we just accept our faith and let the chips fall where they may!? Should we just embrace reality and deal with it as it comes our way!?...

I guess that’s an option, and practically speaking we will alway have to do that (take reality for what it is, not for what we would like it to be). But there’s higher hopes than that. We can actually do something about it, and it all starts by being humble…

How not to let the blessing derail to a curse requires

Here we are… humbling ourselves, accepting that reality might turn to be “uglier” than we think is acceptable. We want to do it while not falling as sort of victims of our own circumstances – put it other words, to be humble is not accepting everything as they come our way, but rather having the humility to accept a fundamental truth…

We are wrong. Much more than we’d like to admit (that we ought to accept as a reality).

To turn that ship around basically then requires us to develop mechanisms to figure out fast how wrong we were (technically, we could also be right, but as explained here, to me is important to approach it from a scientific method standpoint, and hypothesis are to be proven wrong).

That’s like the overarching mindset we should have…

Assume we will be (often) wrong.

And it’s logical accompanying attitude to deal with it, can only be…

We are better off validating fast if / when that’s the case.

That’s the model. That’s how we can have a better chance and continue building up on the blessing of easy change in software, while protecting it from the risk of turning it into a curse.

And that’s precisely why I put so much emphasis on flow as part of ideas I regularly share over here. It’s not about some sort of obsession I have on the theme (at least not the key reason).

Ultimately, flow enables efficacy. It does so because it allow us to validate faster that we were wrong. And iteratively do so until we get something right. You couple that with proper lifecycle management to regularly check and get rid of stuff that over time turn to be not useful (anymore), you are better set for success in keeping a (software) product which is sharp and fit-for-purpose, and still easier to change.

That sounds like the closest to magic I can think of with my product management hat. That because it help us get closer to the goal of product development (in the words of Jeff Patton): “maximize impact while minimizing output”. Or like the agile manifesto has it:

Simplicity – the art of maximizing the amount of work not done – is essential.

simplicity in an image

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.