One of the common struggles that Product Managers are faced with is figuring out how to be “agile” while still managing to a vision or strategy that’s been established by the Executives or Board.  The important thing to remember is that strategy and agility are not in conflict with one another — if a strategy is properly formed, it’s a long-term view of where you’re going, and not specific enough to tie your hands when approaching the execution side of things.  But that doesn’t mean that there aren’t tensions to be found in such a situation.  Here are some thoughts on managing agility while executing against long-term plans…

Make Sure It’s Actually a Strategy

The first, and most important, thing that you need to do as a Product Manager is to push back and ensure that the strategy is actually a strategy and not just a set of tactical goals wrapped up in pretty ribbons and called a “strategy”.  Strategies are goal-oriented and look at a long-term (12+ month) view of the world and where the company wants to be in it.  It’s not about specific deliverables within a short time-frame.  “Add the ability of a user to upload a file” is not a strategy.  “Expand into the SMB market” is a strategy.  The more specific the goal is stated, and measured, the less likely it is to actually be a strategy.  Usually, we can elevate these discussions by leveraging our rule of asking the Five Whys — “Why do we want users to upload their own files?” or “Why do we want people to be able to customize their colors and logos?” are valid questions that will drive the thinking of those whom you ask toward strategic goals rather than tactical execution.

Empower Teams With The Strategy

Far too many companies hold their strategy close to the vest, almost like it was some terrible secret that can only be disclosed amongst a very small cadre of the highest echelon.  But this is entirely the opposite of how you should be using your strategy.  Every single person in your organization should be able to understand and communicate the strategy, vision, and even the reasons for the tactical decisions that are being made by the organization.  Knowing and understanding the strategy that drives the organization is important because it empowers your teams to make decisions based on an informed and shared understanding about where the organization sees itself in the future.  When we hide the strategy within a few select individuals, we limit the ability of people to make these informed decisions, and force teams to rely on an artificial and damaging authoritarian game of “hide the ball” wherein only the management or directors really know why the teams should be (or should not be) making certain decisions.  The more broadly we communicate and disseminate the company’s vision and strategy, the more independent our teams can be, and the better and more aligned their decisions will be.

Figure Out the Iterative Path

Once we understand where we want to go, then we get to engage in the most interesting part of our job — figuring out how to get there.  Each step along the way, we want to (1) confirm that the direction is still the right one, and (2) what’s the next, smallest but most functional step that we can take to get closer to the end goal?  Whether that’s a sprint-by-sprint decision, or a plan that takes a few sprints to deliver on, we need to be constantly driving the teams to figure out what each incremental step is, and fighting off scope creep.  The primary reason that we need to focus on iteration is that we should know and accept that the “plan” could change at any time, and when it does we want to be able to tell our stakeholders that we have valuable functionality that we can deliver at nearly any time.  Not only does this (1) serve our users by giving them incremental improvements to our product, but (2) it also can hold off on such randomization, because if we’ve already finished some incremental improvement, maybe we should keep going until we deliver the whole thing.  It’s far more easy to randomize a waterfall project, because all of the value is realized at the end of the project.  It’s a lot harder to randomize an agile team because each sprint delivers incremental value — pushing through one or two sprints, each of which improves on the baseline, is a lot easier to sell to stakeholders than, “Well, we’re 50% through and we’ve only got three months to go.”