Guide customers step-by-step to find the right product
How to steer a product (development) as a product owner
Source: https://blog.mindmanager.com/blog/2021/05/13/product-development-roadmap/
As a product owner you work very closely with the development team to create a product that fits perfectly to your customers’ expectations. At the beginning it is hard to know where to start and where to go to which is crucial to know, because the product owner has to lead the development team in this matter. In the following story I want to explain some helpful concepts that could make life easier for the product owner, especially in the beginning.
Vision, Strategy and Roadmap leads to the Product Backlog
On a development level in agile product management the product backlog is the north star for a team what to do and in which order. Unfortunately, a valuable backlog is not there by default. My favorite approach is to start with “Why”, that means the definition of the product vision. Obviously to ensure a vision you need a product strategy. A well-defined strategy leads to a product roadmap. And as a final step a product roadmap defines the product backlog for the development team. In the illustration below you have a non-business example to get a better idea of the differences between each level.
Multiple Dimensions of a Product Strategy
Strategy is mostly not one-dimensional which means that several criteria affect the product strategy. The formulated strategy acts as some sort of filter. This means only for the vision relevant (and for the current situation demanding) issues are addressed. Why do you need a filter? It is simply, because you cannot do everything at the same time, so you’ll need some sort of steering wheel to give direction what you want to deliver to the customer at a certain point of time. I’d like to give you a practical example:
The first dimension I call “Strategic Stories” which is a break-down of stories about the high-level product vision. To give you an idea here are some examples:
Deepen the link between the physical and the online world
Provide several options to pay the product
Improve communication between customer and company
Offer the customer paths to self-service
Personalize the customer experience
etc. etc. etc.
Hint: This generic type of dimension can be used with every product development.
The second dimension are the customer journey phases as follows:
1. Raise demand for the product
2. Plan & inform about the product
3. Buy the product
4. Use the product
5. Get help with the product
6. Bind customer to the product
Hint: This dimension fits when the product is related to selling goods or services.
Both dimensions can be combined to a matrix (see illustration below). For instance, if your strategic focus is in the intersection of “Get help with the product” (= customer journey phase) and “Deepen the link between the physical and the online world” as well as “Get help with the product” (= strategic stories) you can come up with product features that fit to them. In this case a possible feature is “Create a My Account area”. In agile product development language such product features are called “Epics”.
Another helpful dimension for me is the distinction in the following four strategic areas:
Time: The product feature has a fixed deadline (e.g. forced by law regulations)
Basic: The product feature is state-of-the-art which means competition has it and your customers are expecting it as a standard.
Value: The product feature has a quantified business value.
Innovation: The product feature is totally new on the market that implies a high risk regarding to customer acceptance and an unknown business value.
In a product organization context, you can use this classification to define where the priority of the development team is. For example, you can create the plan that in the next 6 months you focus on roughly 60% basic, 30% value and 10% time-related product features. In this scenario innovation has no vote, because it might be that it is the early stage of a product development which means that it is not the time for experiments.
Last but not least, another option is to use a business value formula to define the priority of a product features. Imagine the situation that you have a bunch of product features to implement that all feeds the product vision, but it is not clear where to start first. RICE is one common formula to do this. The formula stands for:
R means Reach as how many users or customers a product feature reaches (in %)
I means Impact as what is the concrete impact on a product KPI (in %)
C means Confidence as how sure you are about Reach and Impact (in %)
E means Effort as how much is the cost to implement the product feature (in hours, days or also more generic T-shirt sizes as XS, S, M, L, XL)
Hint: The higher the RICE value the more it is recommended to put the feature into the product roadmap.
The Product Roadmap
The product roadmap acts as a concrete near-future plan derived from the product strategy. In my personal experience the timeframe of a roadmap for agile product development should not be too long-term, because of the simple truth that our world is too complex and plans change steadily. For that reason, I use product roadmaps for the time horizon of maximum six months.
Creating a product roadmap from scratch is really hard, so it is crucial to have a well-defined product vision and a clear product strategy in the first place. Then, the product roadmap is more or less the result of the former two steps. There are lot of apps out there to visualize product features on product roadmaps, but at the end of the day a simple spreadsheet can do the job too.
The Product Backlog
The product backlog is the most short-term of all the discussed artefacts and is the closest to the implementation within the development team. There is a big misunderstanding in agile practice that a product backlog is a trash box for everything (ideas, tasks, wishes, and so on) which leads to a list of hundreds of items mostly not prioritized. If you have such a long list to discuss with your team the meetings are going to explode and time is wasted to issues that are not implemented in the near future. For that reason, the product backlog is very short-term. Personally, I prefer a backlog of maximum four sprints.
The product backlog items (PBIs) are nothing else than the more detailed issues (mostly known as User Stories = US or also called Jobs To Be Done = JTBD) derived from the epics of the product roadmap.
Feedback
Back to top