Recently I spoke with a team of very frustrated Scrum developers. They were frustrated because they felt like all they were doing for the past year was chasing features and that the product manager really had no clue where they were heading or what they were really trying to accomplish. When I spoke to the product manager (product owner in Scrum lingo), he explained that he thought the whole idea of Agile methods like Scrum was to remain flexible and “agile” and that he didn’t think he was supposed to worry about or lock in a longer-term direction.

This is not the first time I’ve seen this confusion, and I fear that creating an effective product strategy may have become an unintended casualty of the move to Agile methods. So I thought it would be useful to discuss what a product strategy is, why it is critically important to do, and how it is actually completely compatible with an Agile philosophy.

First, a product strategy is meant to describe the vision of what you are trying to accomplish. Usually the timeframe is between two and five years out. It is a visionary work and meant to be persuasive. It is definitely not a spec in any sense.

Sometimes the product strategy is articulated in the form of a web page on a project Wiki, sometimes it’s a white paper, sometimes it’s a PowerPoint deck, and sometimes it’s in the form of a video of you evangelizing the vision. Partly the medium depends on how many people you need to communicate your product strategy to, and whether you can do so in person or whether it must be self-contained. In any case, it should be clear, compelling and inspiring. How will things be better when this product or service reaches its potential? It’s not about the specific features or functionality that may or may not be built, but rather the benefits of having this product. What problems will be solved with this product? Why will users love this product? How will the world be better once this vision is reality?

Second, the product strategy is the bridge between the business strategy and the product roadmap. The product strategy must support the business strategy, and the product roadmap is what describes your current plan of how you will get from where you are today, to the vision described in your product strategy.

Make sure you don’t confuse the business strategy with the product strategy. The business strategy might be something like “expand our e-commerce offering to allow buyers in Europe and Asia.” The product strategy might then describe the eventual e-commerce offering that has the necessary language support, currency conversions, payment methods, shipping and fulfillment methods, customs controls, etc. that you would need to support this business strategy.

Third, coming up with a good product strategy is one of the most important things a product manager (or very often, the director of product management) does. It’s not easy but without it you have little hope of actually ending up with something worthwhile. It’s like the old saying that if you don’t know where you’re going, any path will do.

We come up with a product strategy by first gaining a deep understanding of our target users, the market, and the underlying technologies. There will be brainstorming and lots of debate. You should actively involve your lead designers and lead engineers in this discussion, as well as key stakeholders. The product strategy is something that you will discuss and review actively with your management. Your executive team should care deeply about this product strategy.

Many product managers make the mistake of believing that the product strategy must come down from above, and in some cases it does, especially if you’re in a startup with a founder serving as the product visionary. But if not, you need to propose the product strategy and offer it up to your management for their review. This is a great opportunity for you to step up. But defining and building features without a well thought out product strategy is very likely a waste of time and money.

Fourth, it is essential to understand that the product strategy does not lock you into any particular features or sequencing. Features and sequencing are represented in the product roadmap (the backlog in Scrum lingo). You can, and absolutely should, adjust the roadmap constantly based on what you learn from your users, the market, your analytics, and the ever-changing technologies we build upon.

Finally, I have found that creating a set of product principles that accompany the product strategy will help you and the product team to make the many decisions and trade-offs that arise when you actually define the features and the user experience. The product principles go along with and support the product strategy. You can read more about product principles at http://www.svpg.com/blog/files/product_manifesto.html.
Hopefully you can see that the notion of having a vision of what you are trying to accomplish is not in any sense inconsistent with the principles of Agile methods. I argue in fact that Agile methods, applied properly, will help you make your product strategy a reality significantly faster than conventional methods.

If you don’t have a product strategy for your product, I strongly suggest you take a breath, step back and ask yourself what you’re trying to accomplish? In three years or so, what do you want this product to be? How will you measure or recognize this state? Then share this vision with your management and with your product team – especially your engineers. They want to know where the product is heading too. It will help keep them motivated, they will have some faith that you as product manager are not just shooting from the hip, and also the strategy is important because it helps the engineers anticipate future capabilities and requirements which may impact the choices they make on technology and architecture.