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.
The Vision
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:
Level | Sample Tools |
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, 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.
Post a Comment or Ask a Question
6 Comments
Hi Roman,
I like this breakdown approach which defines clearly the boundaries and interdependencies between the strategic and tactical sides of product management and planning.
However, I have a current situation in a project for which I would be grateful to get your opinion. This project consists of the replacement of a legacy tool developed from scratch and maintained for many years internally within the company. To replace the tool two alternatives are mainly possible: choose and configure an out-of-the-box tool from the market or redevelop a new tool internally. From your perspective, the fact to choose between both approaches, is it part of the product strategy or part of the tactical approach? Personally, I’m more of the opinion that it is a tactical decision based on some strategic aspects. An example is if the strategy of the company is to keep total flexibility … So to resume the product strategy will not in this case state that we choose alternative 1 or alternative 2 but will state some requirements which will lead to a tactical decision that alternative x is better than alternative y. Hope I’m clear enough and would be grateful to get your advice on this.
Regards,
Stephane
Thanks for sharing your feedback and question Stephane. The decision make-vs-buy has a strategic and tactical aspect. The former relates to understanding how the product is currently used and if it should be replaced like for like. You might be better off unbundling some of its features into a new product or creating one or more product variants. Please take a look at the following article, in which I share my advice for successfully re-writing a digital product: https://www.romanpichler.com/blog/tips-for-rewriting-a-digital-product/
This an outstanding breakdown and approach to product planning! An approach that I will definitely employ and add to my Product Owner toolkit. Thank you!
Thanks you for yoru feedback Michael!
Thank you for providing all these resources and knowledge. I am truly grateful!!!
You’re welcome Jamie!