While we have made great strides in challenging late integration, lack of collaboration and the obvious need for automation, we still have a ways to go when it comes to ideation, and the dangerous amount of certainty we have when it comes to products and people.

Assume Delivery is a Constant

I once had a physics teacher who often said, “Assume acceleration is a constant,” just before he took us into the land of big thinking. Before we stepped too far into the land of complex learning, he tried to reduce the number of variables so we could focus on the more complex aspects ahead. I use this same idea when working with product teams by helping them to work towards delivery as the constant.

Of course delivery is never a constant, but it is tangible and often deterministic. Eco-systems where teams build and sustain adaptive eco-systems with well structured code, high levels of automation, rich collaboration and strong visualizations tend to do well with delivery, and often learn to deliver more than ever before. Thoughtful and aware teams (and programs) quickly realize that as product delivery becomes a constant, product discovery looms large on the horizon, and it is a land that’s messy, clumsy, non-linear and non-deterministic. Best practices rarely help.

Product Arrogance

So, for a minute, assume you’ve made delivery a constant. How sure are you that you are producing the right thing? How do you decide what is your next best investment, and how do you validate your choice? As a tool to help you, I offer of the idea of product arrogance. Inspired by Nassim Taleb‘s use of Epistemic Arrogance in The Black Swan, or “the difference between what you know and what you think you know,” Product Arrogance is simply defined as “The difference between what people really need and what you think they need.”

Now, while you are still assuming delivery is a constant (which is no small challenge on its own), ask yourself, “How wrong are you?” as it relates to the product ideas you are chasing. Or examine the flip side, “How sure are you that you are building the right thing?” What makes you sure, and what makes you unsure, are areas of thinking and learning that confront teams when they’ve worked hard to smooth out delivery. It does not matter if they are using Scrum, Kanabn or NonBan

The Myth of Certainty and the Measures of Realities

Many teams I coach talk about a “definition of done,” one of many emergent ideas from the agile community that has helped people learn to deliver. Work deemed done, in the form of working product in a meaningful environment, improves measures and learning, but sometimes induces a false sense of certainty and a dangerous level of confidence that success is near.

Unfortunately, products are only done when they are in use. Watching users in the wild often teaches teams that what they were certain about. “I am sure people will need to …” is not what people need. It may be that one person’s arrogance, or fear of “not being a good product owner,” is the issue. It could also be the simply fact that the product ideas were right and the market changed the game. When this happens, shedding arrogance and embracing evidence is your best tool for building less of the wrong thing (which allows you to learn fast and spend less).

Embracing Wrongness

Product development, which goes far beyond product delivery alone, is an act of being wrong often. Like science, ideas are tools for learning and need to be viewed with less certainty than an automated test. Where people are involved, as opposed to code, automation is more difficult. People are beautifully chaotic and take unexpected journeys into interesting and uncharted territories. Being ready to be wrong is one way to be ready to learn, and product learning something we all need to practice, and practice and practice.

If you have practical experiences to share, please chime in so we can collaboratively learn from being wrong collectively.

Join the Discussion

    • Lyle Kantrovich

      Great heavy-hitting short article David. You baked four big ideas into one succinct post (and nicely outlined them with clear headings too).

      People usually forget if a project/product was on-time or on-budget, but they usually DO remember whether it was a “good” product – whether it sold, was effective, if customers loved it or hated it or just didn’t notice it. Projects are temporal, products are what matter over time. (For example see the pyramids in Egypt…do we know or care if they were on time or on budget? How about the Macintosh? How about Microsoft Bob?)

      It’s all about the product (and therefore, it’s users)…and a lot less about the project. The idea of assuming delivery is constant is a great eye opener.

      Not trying to stir the pot, but I’ve long thought that Agile evolved out of the needs of IT departments, not the businesses or markets they serve. It largely solves the problem of “how do we deliver” (yes, this is a gross over-simplification on my part*)…your post kind of says “and then what”…and I love that.

      *There’s a lot more to agile and lean philosophies today that are more product and business focused…but I’m sure someone will take issue with my over-simplification. Just keep in mind I’m talking about the motives for starting the agile revolution. Agile clearly has been a huge step forward in many ways. David’s post is about looking forward, not backwards.

    • Robin Goldsmith

      Thank you for being another, and I fear also too- lonely, voice advocating first getting right what I call the REAL business requirements deliverable _whats_ that provide value when met by some product/system/software _how_ rather than charging prematurely to build what turns out to be the wrong thing. Unfortunately, people have so little self-awareness and so many defense mechanisms preventing them from seeing things objectively that they practically never recognize their problem is their approach. Instead, they keep blaming false issue and continuing to suffer the same predictable problems. For more, see my book, Discovering REAL Business Requirements for Software Project Success.

    + 84 = 86