As Product Managers, we often talk about agility and Agile methodologies from the perspective of how we prioritize and execute the work that needs to be done, but how do we as Product Managers actually make ourselves more agile and responsive to change? As I’ve noted elsewhere on this blog, Agile methods and agility in general are more than just development values and processes – they are indications of a kind of culture that accepts the unknown and is willing and able to respond as new information is discovered. And we as Product Managers are often a key part of that culture, so we should strive to be as agile in our own practices as possible — to demonstrate and model this behavior for others to learn from!
What Does an “Agile Product Manager” Look Like?
I won’t rehash the Agile Manifesto here, as I hope everyone reading this blog is familiar with it by now. But from that manifesto, we can pull out some key features that define what an agile Product Manager might look like:
Collaborative
First and foremost, an agile Product Manager is collaborative — they are actively and intimately involved in everything that’s going on in the organization, to the extent necessary to ensure that things are running smoothly and that nobody is left in the dark. They seek out teams who might otherwise be operating independently, and ensure that everyone in the organization understands, acknowledges, and is working toward the same common goals. A collaborative Product Manager ensures that they’re available to anyone in the company, at any time, for questions, suggestions, or feedback on anything related to the product. If a developer reads some marketing collateral that they think mis-states a capability, they should feel comfortable talking to the Product Manager about it. If a services team member has an idea for a new feature that would make it easier for them to satisfy and delight their customers, they should feel comfortable talking to the Product Manager about it. If the CEO has a concern about the progress being made toward a strategic goal, they should feel comfortable talking to the Product Manager about it. Used in this context, “collaboration” is all about enabling people to achieve against the organization’s goals and to feel included in the larger organization — the hub of which is the Product Manager.
Cooperative
I separate out collaboration and cooperation based on a very fine point of distinction — but to me a very important one. In everything they do, a Product Manager must be collaborative — ensuring that the people who are affected by decisions, changes, or strategy feel included in those decisions and understand why they’re being made. But in many situations, a Product Manager must actually get their hands dirty, and work side-by-side with someone in order to get things done — and this is where cooperation comes into play. An agile Product Manager is willing to roll their sleeves up and get down into the weeds when someone needs their help. They must be willing to sit down with a developer and work through a particularly troublesome user story or use case. They must be willing to sit down with the Marketing team and review and revise collateral and positioning statements. They must be willing to sit in a room with Sales and answer specific questions posed by a prospect about the product. There are times when we have to be more than just “supportive” and actually get our hands dirty — and when we do, we establish a great deal of trust and respect with those other teams that we can use later to help drive our strategic and tactical goals.
Flexible
Of all the values upon which Agile development and corporate agility are based, the Product Manager probably most needs to embody flexibility. This usually shows up as flexibility in priority and in planing, but also applies to flexibility in just what the job is, how it works, and when and where we make our impact on the company. A Product Manager should never say, “That’s not my job,” but rather “Let me figure out who can help you with that,” or “I’ll see what we can do to get that done.” The blessing and the curse of Product Management having such a variable role in the organization is that we’re often asked to do things that are well outside our wheelhouse — but if we’ve taken the time and effort to build up a bank of social capital in the organization, there’s almost nothing that we can’t get done if we set our mind to it, and put our name on the line for others to get it done. We need to be willing to accept some responsibility for things that might be outside our direct control — because we’re more likely to know who and how to get something done than any other team in the organization. We should welcome challenging and interesting ideas and request, even if they fall out through prioritization — this builds our social capital in a way that “That’s not my job.” never will.
Future-Focused
Most teams in the organization exist in the here-and-now. Development teams build what they’ve committed to in the iteration that they’re in. Sales teams focus on the current deal, and if they’re really good, the next deal as well. Marketing teams are often focused on the next piece of collateral or the next industry event. Services teams focus on the clients they’ve been assigned, and ensuring their satisfaction. But the particular power that’s held by Product Management is that we aren’t beholden to a single focus. We aren’t limited in sight and scope to what’s right in front of us. And we’re exposed every day to all the other teams who are trying to manage the day-to-day and balance it with the strategy as they understand it. This provides Product Management with a unique perspective within the organization, and it’s our duty to leverage that perspective in a way that encourages, educates, and empowers those around us. We have to always ask how our backlogs further the future vision of the company and the product; we have to always ask whether our product is moving us forward; we have to always ask how well people understand why we’re building what we’re building, who the product is for, and where we’ll be in 6, 9, 12, or 24 months. The biggest failure I’ve seen in Product Management teams is a loss of this focus on the future — a shift to the same day-to-day vision that most other teams have. And it kills the product. Every. Single. Time.
These are four of the qualities that an agile Product Manager should have — feel free to suggest any others that come to mind in the comments!
