When will it be ready?
This is somewhat a natural question to be asked in any delivery context, but it's also a sign of lack of trust and confidence. In a recent beautiful (mess) post, John Cutler explains the risk of being obsessed with predictability. I couldn't agree more with him. But there are nuances that I thought it would be worthwhile to explore here.
The implied underlying reasoning of Cutler's post is that often it doesn't matter much whether we shipped something on time, but rather whether we accomplished the necessary outcome (and one that hopefully also drives business results, or impact). As already shared here in other posts, the way I like to visualize what good product delivery looks like is this:
There's no real original idea here of mine, and in fact, I have written a post where I make the case that this is a generalized common pattern that is underneath several leading practices of how you figure out what to do, where to focus on, and how that maps back to what truly matters in the end (business results or impact). The sketch is just me making sense – and I do actively use that quite regularly in my day job, by the way.
The storyline goes more or less like this:
A product is only worth investing in if it is driving business results, which we can define as (having an) impact. We only create value with a product if there's value being captured back from the market (or indirectly, if we talk about an internal product). And we can drive that by creating a theory of what kind of behavior change we need to go after so that we can unlock that dynamic of value created and captured back.
We call that an outcome—a measurable change in user behavior. That's the sweet spot of product management, that's what product should focus on: driving clarity from the top by understanding the mapping down until we come up with our hypothesis of what we could deliver as an output, to nudge the change in behavior, the outcome we are after, and hopefully our theory is right, and the impact will also be there, eventually.
Operational excellence, or flow, is therefore an enabler of that dynamic. But we aren't done when we ship something; in fact, with digital products, we are never really done (unless there is a deliberate decision to shut a product off). And that whole thing playing out around the different levels is what makes things complex and challenging.
Now, once we acknowledge that, particularly the part of operational excellence in delivering designed output, one could argue that it is more or less natural to expect commitment. That's perhaps where the trap of predictability that John Cutler talks about comes into play. But maybe the workaround is not to frame it as an expectation of predictability but rather of speed, in terms of learning as fast as possible. That's what I mostly mean by flow (and the pursuit of operational excellence).
To put it quite bluntly…
How trustworthy can we say a team is if the thing that is in principle (again, although in some contexts, there will be nuances like dependencies and whatnot…) under the control of the team working on something is too often falling behind (against the promises made by the team themselves) or taking too much time?!
In my humble opinion, we already have to accept way too much uncertainty in the upper levels of that dynamic, not being able to put a finger on whether the thing we are working on will change behavior in the way we thought it could, and then not knowing whether that outcome will drive the impact we ultimately need. That's too much to take in. To also have to accept that there will be a lot of uncertainty about the shipping of the work defined would be to settle for mediocrity (if not worse than that).
I know it sounds very opinionated – but that's how I view it as a general matter. It's about taking responsibility for what you can control.
Now, surely this is much easier said than done. It's simple yet hard to get right. It takes having a holistic approach towards products, like gardening, when you are as much about setting the right environmental conditions for flourishing as about what you are planting strictly speaking. So for products, that means things such as managing the complexities, improving processes, and not only falling into the build new features trap (which is often linked to the "when will it be ready?" question, by the way).
Once you get your head around that, you start understanding that there are more insightful alternative questions that will sound something like:
Have we accomplished our goal? And how do we know we are making enough progress (learning included) towards that?
To wrap it up, a few takeaway bullets from my perspective:
The risk of a focus on building and output predictability is real. It takes reframing to understand that we are never (apart from a divestiture scenario) really done with (digital) products, and that the focus has to be on the outcomes (changes in user behavior) that we believe will drive the business results or impact (what truly matters in the end).
A key enabler, though, is to be able to ship and learn faster, technically taking the responsibility to build trust and confidence by demonstrating that you can do what you said you would do, more often than not by the time you said you could do it as well.
That can only be accomplished if you take a more holistic approach to product development. One that recognizes all the underlying factors that can affect the ability to deliver fast and sustainably in the long run, "gardening" the environment around the product itself (technically) as well as the delivery processes.
by Rodrigo Sperb, feel free to connect (I only refuse invites from people clearly with an agenda to ‘coldly’ sell something to me), happy to engage and interact.