Product planning is just as important in an agile context as in a traditional setting. Unfortunately, some product owners focus so much on the product details that the strategic planning aspects are neglected. But discovering the right user stories and UX design is difficult, if we haven’t thought about the product strategy; and choosing the right strategy is hard if we haven't got a vision of what we want to achieve. This post discusses a systematic product planning approach that balances vision, strategy, and tactics.
The Three Planning Levels
Agile product planning comprises three levels: vision, product strategy, and tactics. The vision is the overarching goal, the product strategy the path to the vision, and the tactics are the steps along the way, as the following diagram illustrates:
The level of detail increases, as we move down from the vision to the tactics: Whereas the vision is typically captured by a brief statement, the strategy communicates different aspects including the market or market segment targeted, the product price and the channels, and the product’s unique selling points (USP’s). The tactics go further by describing the product details employing, for instance, user stories, design sketches, scenarios, and storyboards.
Product planning starts with creating a vision: an overarching, shared goal that guides people. A sample vision from my own company is: “Grow Pichler Consulting without increasing headcount.” This vision may not sound mega exciting but it is very helpful for my team and me: It guides our work and focuses our efforts. Note that the sample vision doesn’t mention a specific product or service. It rather states a business goal. How the goal is realised is captured in the product strategy.
The Product Strategy
The product strategy is the path chosen to realise the vision. Without a strategy, making the right decisions about the product details is difficult: the functionality, the design, and the non-functional properties the product should exhibit. Having a strategy in place also prevents me from getting lost in the details.
I find it helpful to capture the target group, the needs addressed, the key features of the product, and the desired business benefits in the product strategy. But you may want to add the product price, the channels, the main competitors, and other important business model elements to characterise your strategy more comprehensively. As the strategy is a path to the vision, it may turn out to be wrong. This is particularly likely when a new product is created. Changing the strategy is also called a pivot.
The Product Tactics
The product tactics describe the product details: the product functionality, the user interaction, and the user interface design. Great techniques to capture these aspects are epics and ready stories, scenarios, design sketches and mock-ups, constraint stories, and sprint goals. New product features are best delivered incrementally so we can learn from the feedback we collect. I use blog posts, for instance, to create the material for my e-learning course. This allows me to learn from the feedback I receive, and to validate my strategy and the product details.
Product Planning Tools
I like to use the product planning tools listed in the table below:
|Vision||Vision statement on the Product Vision Board|
|Strategy||Product Vision Board, Strategy Canvas and ERRC Grid, Business Model Canvas, and GO Product Roadmap|
|Tactics||Product backlog, product canvas, story maps, scenarios, and storyboards|
To capture the vision and the core product strategy I like to employ the Product Vision Board and the GO product roadmap. The Strategy Canvas and ERRC Grid help ensure that the product is adequately differentiated and stands out from the crow. The Business Model Canvas or the extended version of the Vision Board are great to describe the business model, including revenue sources and channels.
To capture the details, I use the Product Canvas. The canvas allows me to work with personas, epics, scenarios and storyboards, design sketches and mock-ups, constraint stories, sprint goals, and ready stories. For an incremental product update, a product backlog may be sufficient to capture the product details.