The Product Catalogue: A set of artifacts for product development
Why product development
In the early 00’s we did agile transformations.
The idea was to make the teams work more efficiently by introducing some structure through artifacts, ceremonies and by empowering the teams by removing primarily top-down bureaucracy.
Agile was a major improvement, but bigger organizations quickly realized that many agile teams working in the same organization required more structure than just a backlog to ensure that the teams were value-driven from a business perspective.
I have seen many different solutions to solve that problem.
Some organizations invest 2-3 days every quarter doing big room planning, other organizations create a waterfall portfolio process/PMO on top of their agile organization. Some organizations run SAFE and other frameworks to ensure a clear direction.
I do not believe that there is a right or wrong when it comes to how to do this right. I believe that different tools work in different organizations as culture, people and trust play a major role in what will work.
I like to keep things as simple and agile as possible.
The Product Catalogue is a set of artifacts for product development that includes all the things an agile product team needs to know what success looks like and to be truly value-driven.
What’s in the product catalog
The product catalog is a set of artifacts that I have been developing on-going over the many years I have been working with product development and agile transformations.
With these artifacts in place, the team is ready to start working as a truly agile team using agile methodologies like Scrum, Kanban, etc.
Product Vision (deep-dive into product vision)
The product vision reflects where the product is heading long-term.
- What are the major problems we are trying to solve?
- Why are we here?
- What does the world look like when we are done?
Product visions can look very different. I prefer that the product vision is very overall, so simple that everyone can understand it. Therefore I often end up with a drawing.
Sometimes a product vision can be hard to understand for stakeholders. It can be beneficial to have an as-is drawing and communicate that when you present the product vision for the stakeholders.
The product vision is crucial to ensure that the team knows where we are going long-term and essential to communicate clearly to stakeholders what we are trying to archive.
The product vision should be revised every quarter. If there are major changes to the product vision, the team should stop and do another product discovery sprint with the key stakeholders.
It all starts with a product vision, and until we have a clear vision for how we can create the value we need, we should not do anything.
Product Roadmap
The product roadmap shows the long-term path to success.
- What do we need to deliver in which order?
- When do we expect to deliver which increments and deliverables?
- In which order will the different epics and features be delivered?
The roadmap shows the major epics, features, and when the team expects to deliver them. The product roadmaps cover the period it takes to deliver the product vision.
The roadmap is clear for the months to come but gets more “blurry” the further it goes into the future.
It is crucial to understand that the roadmap is not a plan! It is a declaration of intent that we expect will change every quarter.
As the team delivers sprint after sprint, they will learn and get a better understanding of what they need to deliver and how to do it. The team will also identify opportunities to create more value, and the team (and the product manager/owner) must have the mandate to make these calls.
The product manager/owner is the owner of the roadmap, but both the team and stakeholders should be major contributors to the roadmap, and adding 3 months to the product development because of some opportunity that was identified should be a mutual decision between the team, stakeholders and maybe even leadership. Budget, scope, and time will also always play a role in these kinds of decisions.
The roadmap should be updated and communicated broadly every quarter, especially if there are major changes to the roadmap and thereby the expectations to the product team.
Product OKR’s
The product OKR’s shows the medium-term path to success.
- What do we plan to deliver in the next period (quarter)
- What are the objectives we want to archive (the why)
- What are the key results we need to do (the how)
- When do we expect to deliver which increments and deliverables?
- In which order will the different epics and features be delivered?
From a responsibility perspective, the stakeholders/customer lead is responsible for defining the objectives while the team is responsible for defining the key results.
I generally recommend strong team collaboration when creating both the objectives and key results. That could be a shared workshop with the full team (including team and relevant stakeholders) facilitated by strong Scrum Masters.
I wrote a deeper post about OKR’s. You can read it here
Product Value Proposition
The product value proposition is about ensuring that we harvest the value we expected from the product we develop and will help make sure that developing the product is actually a good value-creating idea.
The product value proposition should be created before we establish the product team, but as with all the other product artifacts it is a living document, that should be updated at least every quarter or every time the teams see new opportunities within their product.
The product value proposition should be owned by the customer lead/stakeholder and it basically links the product to the customer’s needs.
There are many different templates and standards on how to do a Product Value Proposition. Here is an example but they are just templates.
The quality is about asking the right questions and provide at good answer for the questions.
Here are some questions you should ask about the product.
- What does the product do?
- How does the product work?
- What features does that product have?
- What does the product “feel like” and behave?
Here are some questions you should ask about the value and stakeholder
- Why would people want to buy this product?
- What are the rational reasons for developing this product?
- Are there any hidden needs that this product will solve?
- Why would people not want to buy/use this product?
- Why should people buy this product and not continue to do what they do today?
- How are people currently dealing with the problems that this product solves?
Many mistakes can be avoided with a good product value proposition, and lack of product value propositions has shut good business down in the past.
Therefore spending a day or at least a few hours on developing a product value proposition is very much time well spent, and the artifact will help to ensure transparency and alignment both in and outside the product team.
I will write a deeper piece about it later when I find time for it.
Product Lifecycle
This is usually the hardest artifact to get started in a new organization, and especially with senior engineers and tech people 🙂
The purpose of the product lifecycle artifact is to think and plan the product’s lifecycle from birth the death.
In the good old days (80/90’s) we expected that our features and code would live forever. At that time engineers and CPU time were both rare and expensive.
Today features and code can be created to live for a very short period of time (a few years), to be replaced by something else because that’s where the value is, and that is something that we should consider when we develop the product and features today.
In other words, we should see developing tech products like software exactly the same way as we develop other products, and with the consumers and their needs in mind.
I like to use this artifact and especially the facilitation of creating it, to make the product team and stakeholders think and reflect about the phases of the product’s life is, and what the product requires in those phases to be a success.
That knowledge can be very useful when it comes to decisions about architecture, technology, how we develop and grow the product, how we maintain the product, and not least how we sunset the product in the future.