As product manager and product owners, we need to forecast the likely development of our products. This creates a shared understanding of the benefits and features a product will provide thereby aligning the development team and stakeholders. But which timeframes and planning horizons should we take into account? And how far into the future should we look? Read on to find out my recommendations.
Planning Horizons and Planning Model
“Bring me that horizon,” says Jack Sparrow at the end of the movie The Curse of the Black Pearl while steering his pirate ship into the open waters. While Jack may seek freedom rather than the line that separates earth from sky, he could easily determine how far it is—there is only one physical horizon on our planet, and the distance can be calculated using a standard formula.
But in product management, there are several horizons that need to be considered—how many depends on the product planning model you use. Therefore, before determining timeframes, make sure that you have a suitable model in place like the one below, which I developed while writing my book Strategize.
In the product planning model above, the vision describes the ultimate purpose for creating the product; the product strategy states how the vision will be realised; and the product roadmap states how the strategy will be implemented. The product backlog contains the details necessary to develop the product as outlined in the roadmap including epics and user stories. A sprint goal describes the purpose of a sprint and states why it’s worthwhile to undertake the sprint.
Say I want to create an app that helps people become more aware of what, when, and how much they eat. My vision, then, would be to help people live more healthily; the strategy could be to create an app that monitors their food intake in conjunction with a smart watch or fitness band, and smart food scales. The product roadmap would communicate how the product is likely to grow, stating the benefits it should provide together with desired timeframes or dates. The product backlog might contain epics and user stories like “As Mary, I want to get an overview of my daily calorie intake,” and a sample sprint goal could be “validate that people are willing to share personal data before using the app’s main features” or “finish the dashboard so it can be released”.
Timeframes
With the right planning model in place, you can take the next step and consider appropriate timeframes. The picture below shows the planning horizons I like to work with.
Note that the planning horizon in the picture above becomes increasingly shorter from vision to sprint goal while the planning artefacts become more specific and focused. This is due to a simple but fundamental correlation: the further we look into the future, the less we can see. What’s more, take the numbers stated as recommendations and adjust them to your product. Only look as far into the future as you realistically can—without resorting to speculation or wishful thinking.
As the picture shows, I prefer to work with a big, ambitious vision like “help people eat healthily” that looks three to five years into future and thereby provides a continuity of purpose for everyone involved in developing and providing the product.
When it comes to product strategy, I like to consider the current life cycle stage. For a brand-new product, the strategy should communicate what it takes to get to launch, enter the introduction stage, and serve the early market. After launch, the product strategy should describe how to achieve product-market fit and enter the growth stage. Once that’s happened it should state how to achieve sustained growth, and so forth. This may result in a planning horizon of six to 18 months for your strategy—even though some products require longer to leave a stage. Take the Apple Watch as an example. The product was launched in April 2015, but I am not convinced that it has entered the growth stage.
Product roadmaps benefit from a twelve-months horizon in my experience (assuming the product strategy covers at least the next twelve months). Additionally, I like to include quarterly product goals on the roadmap like acquiring new users, increasing engagement, generating revenue, and removing technical debt. Shared goals create focus and alignment, and they make it easier to understand if the product is providing the desired benefits.
While a product backlog may contain outstanding work for years to come, I find such a backlog unworkable in practice. Instead, I prefer to work with a concise product backlog that is focused on the next roadmap goal, as I describe in more detail in the article “The Product Roadmap and the Product Backlog.” Such a backlog is comparatively easy to update and change—which is particularly helpful for young products.
A sprint goal, finally, should cover the next one to two weeks, guide the daily work of the development team, and set the expectation of the stakeholders.
Re-planning Cadence
While planning ahead is important, it is not enough: Things are likely to change when you manage a digital product (or if you were to sail on a pirate ship, for that matter). You should therefore regularly review your plans and revise them. The following picture shows my suggestions for reviewing and changing the vision, strategy, roadmap, and backlog.
I recommend reviewing and updating the vision when you cannot find a strategy that takes you closer to it, that is, after you’ve pivoted twice unsuccessfully.
Product strategy and product roadmap should be reviewed and adjusted at least once every three months, as a rule of thumb. (This assumes that a validated product strategy is available, that is, the strategy does not contain any big risks.) I like to combine strategy and roadmap reviews to ensure that the two plans are fully aligned and to reduce the meeting overhead.
Last but not least, you should review and change the product backlog whenever new feedback or data is available. This might be on a fortnightly or a daily basis depending on how often you test new ideas and collect the relevant data.
Note that the relationships between the elements in the picture above work in both directions: the product backlog can cause changes to the roadmap, which in turn may affect the strategy. For example, if the feedback from the customers and users indicates that the product does not adequately address their needs, or if the development progress is slow, then this may lead to product roadmap changes. Similarly, larger roadmap changes can cause product strategy adjustments. To avoid inconsistencies, keep all your planning artefacts in synch and involve the right people in the process.
Post a Comment or Ask a Question