One of the constant challenges for a product-based agile development team is to map what they are doing ‘right now’ to what the product is supposed to shape up to in say, 2-3 years from now.
It’s not about teams not knowing what they are working on but more about the fact that they may stay too focused on their day-to-day tasks, invariably undermining the sensitivity of the impact of their ‘present’ work in the big picture. The decisions or the choices made during execution today can have a big future impact, especially when the product is evolving.
Let’s take a real life example.
I was part of an agile team that was trying to introduce a text translation service for site content. The decision was made and a third-party machine translation tool was used. However, the product roadmap eventually mentioned that, in the future, users should be able to correct and provide their own contextual translation, which meant that the translation capability should have artificial intelligence so that it can learn on its own, based on feedback.
Given this development, the choice made was not apt and therefore required a fair degree of re-work because the big picture was not linked to what the agile team was tasked with in the sprint.
One can argue that teams can make a conscious effort to get this information, but the point is that why can’t these ‘long-term’ goals be captured in the existing agile tools and dashboards?
The agile teams execute well-defined and specific tasks in a development cycle but does that mean it must come at the cost of being indifferent to the product evolution? No, I don’t think so.
From what I know, there is no quick tool or framework that either advocates or recommends this information to the agile team, in their day-to-day functioning, but can such a view be created in the existing view? Worth a try? Let’s see how can we do it.
Explore our Popular Business Management Courses
We will start with the most common artifact in agile – product backlog.
According to the SCRUM Institute, a product backlog is the list of things that needs to be done in a project. These things can include either enhancements and/or bugs. A numbered list isn’t helpful unless the team knows what the priority structure of the items are. This is where the Product Owner comes in who has the overall responsibility to work with the stakeholders to get clear requirements, resolve inter-dependencies, and get a prioritized list for the product backlog items.
upGrad’s Exclusive Product Management Webinar for you –
How to craft GTM Strategy for a Product?
It is possible that during this process, a larger and dependent work item is further broken down into small parts so that it is easy to develop for the team. These product backlog items are broken down into smaller chunks and executed in sprint cycles ranging from two to four weeks, answering the ‘how’ component of product development.
On the other hand, product backlog items are also mapped to the “true north” of the product often termed as the product vision. This is the desired state of the product that is often achieved through multiple version releases and links closely to what the target audience or customers want and the value it brings to them.
This chain of elements linking the agile team to customers (including product backlogs and vision) can be represented as:
Distant link between an agile team and what the customer needs…
With the lack of a view that clearly links sprints with the product vision, product owners often run into the risk of focusing too much on the ‘how’ part and lose sight of the larger and important goal of the ‘what,’ which can lead to misguided prioritization.
The approach I discuss here is to create a simple yet powerful view that links both the components. This is known as the Product Vision Matrix (PVM). The objective is to link the vision of the product to granular development items. This matrix becomes a key factor in analyzing the progress of the team with respect to product development. It also serves as a product dashboard for the senior management of the organization and keeps them posted about the attainability of the product goals.
As the name suggests, PVM is a matrix where the columns represent the dimensions (from micro to macro) that are being captured. Let’s understand PVM with the help of a food ordering app where the vision is to provide a food experience to the users, and the starting point is food ordering. The sample matrix looks like this:
Top Essential Management Skills to Learn in 2022
|Product version||Big Rock Item||Feature||Sprint ID||Development Status|
|1.0 Beta||Ordering||Location-based||1.0_1||Development Complete|
|Cuisine-based||1.0_2||In Progress (Design)|
|Reviews||External ratings||1.0_1||Design Complete|
|Loyalty/Rewards||First order discounts||1.0_2||In Progress|
|1.0 Production||Ordering||Food truck orders||1.0_3||Planned|
|Orders from distant vendors (pack and deliver)||1.0_3||Planned|
|Loyalty/Rewards||Location-based real-time offers||1.0_4||Planned|
|2.0 Production||Ordering||Real-time tracking||2.0_1||YTB|
|3.0 Beta||Food Experiences||Food tours||TBD||YTB|
|Reviews||Reviews to be provided to external sites||TBD||YTB|
The Product Vision Matrix can have the following fields:
- Product version: This is the product version that is the official release milestone and is often what the customer receives.
- Big Rock Item: This is the category or theme that a feature belongs too. These items can also be the long-term product need areas of the product vision.
- Feature: This is the product feature that is being developed. The feature can belong to one or multiple themes (big rock items).
- Sprint ID: This is the sprint number in which a feature is being developed.
- Development status: This field denotes the progress of development (Planned, Design Complete, Development Complete, Tested, and Released).
Our Top Management Articles
Note that the structure of the matrix is indicative here. One can be more creative in identifying the columns that can capture the product vision.
The advantage of this approach is the clear visibility each team member has on the overall product goals. For an evolving product, team members should have a better understanding of the bigger picture. This not only allows them to contribute effectively but also enables them to take more accountability. The result is a more focused and adaptive team that always has a finger on the pulse of their customers and recognizes the difference their sprints can make in contributing to the vision and eventual success of the product.
Study Product Management Courses online from the World’s top Universities. Earn Masters, Executive PGP, or Advanced Certificate Programs to fast-track your career.
Featured Program for you: Design Thinking Certification Program from Duke CE
What is meant by product backlogs?
When a product is being developed or managed, it becomes a sort of project to manage. A product backlog is a list of all the things that needs to be done in order to complete the project. However, this can be extremely complicated, as managing a product involves several hundred activities that need to be done. Each activity will need to be performed by a different person in the cross functional team, and thus, it may not be easy for a product developer to understand which activities must be prioritized over others. That is where the product manager comes in.
What is meant by product vision?
The product vision is simply what the product must look like in terms of design as well as features so that it can bring value to the intended customers. Usually, this happens through multiple version releases or sprints, as it is impossible to get a product right from the beginning itself. A product vision helps product managers and their cross functional teams focused on the final, desired version of the product and prevents them from getting too overwhelmed with the operational or technical aspects of product development. The product vision matrix is a powerful tool that can help product managers balance the “how’s” with the “what’s”.
What is the ideal career path for a product manager?
A product manager can choose several paths, depending on their interests. For instance, if they enjoy the technical aspects of product management, they can go on to head technology teams that are responsible for developing, maintaining and extending new products. If the business aspect of product management excites them more, they can go on to head the business strategy function of the organisation, responsible for working with cross functional teams to deliver successful strategies at various stages of the product cycles of all the products the organisation sells. They can even go on to becoming the CEO of organisations or start their own business.