Due to the unique role that Product Managers play in most organizations, we’re often capable of being the strongest influences on the overall culture of the product development organization and of the company in general. And while there are many companies out there who are truly only interested in giving lip service to the concept of agility, there are others who actually want to be better, who want to embrace the concepts of agility — and it’s up to us as leaders to influence that and contribute where we can. While there are a lot of different behaviors that we can engage in which are likely to increase the adoption of agile practices across our organization, in my experience there are three key things that we should focus on if we want to broaden the success of agile adoption in our companies…
Create a Shared Vision
One of the defining characteristics of a successful agile environment is that the people involved in any effort are strongly aligned toward a shared understanding of the objective that they’re trying to reach together. And, as Product Managers, one of the most effective things that we can do to instill an agile culture is to establish a shared vision among the team members, and work with them over time to ensure that their efforts map to that vision. Most waterfall approaches are narrowly tailored toward micromanagement — we dictate what needs to be done, when it needs to be done, the order it needs to be done in, and apply complex change control to “ensure” that everything goes according to “plan”. In contrast, an effective agile approach doesn’t focus so much on the “how” but rather on the “what” and the “why” — and trusts that people will generally do the right things at the right time to achieve the right result so long as we allow them to do so. Perhaps the single biggest predictor of the success of a truly agile Product Manager is how well they can create and advocate for a shared vision amongst their team and their related stakeholders.
Focus on Outcomes
If we’ve got a shared vision on one end of the success spectrum, the other side of agile success lies in focusing on outcomes. Vision is great, and obviously necessary — but if we have a vision with no execution, we’re just treading water. But when we focus on outcomes, we need to be careful that we’re not falling into bad, old, waterfall-oriented micromanagement. We need to remain focused on the outcome — defining it, checking against it, and ensuring that each iterative step toward our shared vision delivers some amount of customer-facing value. However the team chooses to get there, whatever steps they take between committing to deliver and actually delivering — that’s entirely up to them. We do not dictate how people solve the problems what we put before them; we may set boundaries within which they have flexibility, but if we’re intimately engaged every single step of the way, we’re not trusting the team to do what’s right. We review the outcomes, we assess the quality of the work that was done, and we help to define the next iterative step toward the vision based on those outcomes.
Accept Uncertainty
While sharing vision and focusing on outcomes are two key behaviors that we can model as agile Product Managers, there is one key capability that enables us to be successful in both of these efforts — accepting uncertainty. The fundamental flaw of waterfall approaches is that every aspect is designed to create a false sense of certainty — from the detailed, time-consuming creation of “big, up-front requirements” (BUFRs) to heavy-handed change management techniques. All of these aspects make people feel like things are more predictable, better established, and more likely to result in the desired outcome, but they come at the cost of time and effort that’s wasted creating this facade of success. Perhaps the most important component of agile is a firm rejection of this false sense of certainty, of safety — and an acceptance that we simply can’t know everything ahead of time. As Product Managers trying to create and reinforce an agile culture, we absolutely must accept that we won’t know everything, that there’s no guaranteed path to success, and that iteration requires that we take small steps toward success and check ourselves every step of the way. Agile drives out uncertainty not by creating a false sense of security and predictability, but by accepting that we can’t be certain about anything other than what we’re currently working on — and even then, certainty comes in small, iterative steps toward our envisioned future and not by creating some security blanket crutch of business requirements.