How Often Are You Wrong?

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.