The difference between successful teams and leaders and those less so boils down to humility. Specifically, it’s being humble enough to admit they don’t know the answer up front. That simple admission changes the dynamic of the team immediately. It levels the playing field by letting everyone else admit that they’re not confident in their assertions either. Without a single keystroke from an HR database administrator, job titles become far less meaningful. It opens up the team mindset to experimentation in an effort to figure out which direction best solves their business and customer needs.
Most importantly, it centers the team’s conversation around a more important question than, “What should we build?” Instead, the team starts to focus on this question: “How will we know if we’re right?” With that seemingly simple shift, the team is now discussing customers, their needs, behaviors and transactions with the business. They’re discussing what changes they’d like to see in customer behavior and they begin digging into the root causes for the current set of behaviors. The conversation morphs from one focused on output (features, functionality, colors, workflows, etc) to one of outcomes the team has determined as success for the project. It is those outcomes that can then be used as filters for the feature conversation focusing the team around only those ideas that achieve their desired outcomes.
By declaring that we don’t know how to solve the problem up front we completely change the way the team operates. This is not something we’re trained nor incentivized to say. In fact, there are people on our teams in roles paid to “know the answer” to these business problems. This simple step therefore is not an easy one but it’s critical if the team is to truly become a collaborative structure capable of pushing the boundaries of the company’s current product development efforts.
[Jeff]
Bingo. This “seemingly simple” change is, in actuality, a substantially different lens by which to examine business/product problems. The impacts are substantial; in addition to being a potential threat to those who are “paid to know the answers,” it also tends to undermine traditional planning concepts (such as product roadmaps) that provide the illusion of certainty to stakeholders.
In a nutshell, this shift is a stark acknowledgement of the inherent uncertainty in building software. The uncertainty was always there; we’re finally embracing it. But business leaders have a strong desire (sometimes justifiably) for certainty. Admitting we aren’t certain can be deeply disturbing to the business, especially in enterprise settings.