Product Management as described in books Inspired and Empowered from Marty Cagan gives a consolidated perspective about the Product Discovery and the Product Delivery. Indeed, Agile frameworks like Scrum and Kanban cover for some part Product Discovery but the main focus is Product Delivery. On the contrary, Design Thinking concentrates on Product Discovery.
- The 4 dimensions of Product: Value, Usability, Feasibility and Business viability
- Product Management activities: Product Discovery and Product Delivery
- Product Strategic Context
- What’s next? Learn about other frameworks around Product Development like Lean Startup, Story Mapping, Impact Mapping and Agile
- Do you want to learn more about Product Management? Here are some valuable references
Note that there is a continuity in Product Management between Product Discovery and Product Delivery. In fact, the representation with phases is for simplification. It is true that the first phase is about Product Discovery. But after that, both are interconnected and going all together, even if, as time goes the balance move from discovery to delivery.
The 4 dimensions of Product: Value, Usability, Feasibility and Business viability
First thing that Marty Cagan adds when explaining Product Management is coming from Design Thinking and Product Design. Surely, Agile is by nature driven by value, risk management and learning. But Product Design and Design Thinking are more explicit about the types of values and risks to focus on. This makes it possible to have a better holistic understanding of what is at stake with the product. Furthermore, Agile and Design Thinking both tackle problems upfront and before significantly investing, ideally before building anything.
The 4 dimensions of a product and related risks to have in mind all product life long
Value
Will customers buy the product? Features of the product bring the value. In addition, marketing may help to attract and acquire users and customers but this does not replace a product delivering value to customers.
Usability
Will users figure out how to use the product? This is User Interaction. Traditionally, User Experience, aka UX, falls in this area. This concerns not only the features but also all the Customer Journey related to the product. Of course there is some connection with value, as part of the value is how the user perceives the experience when interacting with and using the product.
Feasibility
Will the team be able to build the product? Technology is the enabler of the features. Truly, the team needs to validate feasibility of key elements of the solution at the beginning, during discovery, with other risks and assumptions, not later. Confirmation is about current technologies the team has or is currently exploring. In addition, it is also about expected time and skills to design and build the product.
Business Viability
This principle covers at the same time the capacity to generate profit with the product and monetize its features, but also to make sure that the product is compliant with all the company aspects: legal, finance, sales and marketing, just to mention some of them. Similarly, there is an need to address this dimension of the product, at the beginning during the Product Discovery phase.
Product Management activities: Product Discovery and Product Delivery
Product Discovery
So, Product Discovery aims at splitting quickly and cheaply the good ideas from the poor and bad ones. The result is a first level of validation of ideas to become features aka user stories. As we have seen above, the exploration in this activity covers the 4 dimensions of the product and related risks:
Will the user buy this (or choose to use it)?
Can the user figure out how to use this?
Then, can our engineers build this?
At last, can our stakeholders support this?
Product Discovery process and tools are mostly the same as Design Thinking. Indeed, Product Discovery uses prototypes of all forms rather than the product to run quick and cheap experiments to learn, confirm assumptions and mitigate risks. Surely, the challenge here is profitable innovation and risk management.
Product Delivery
Product Delivery is about designing, building and delivering high-quality products to generate revenue in compliance with the business. Clearly, the challenge here is execution. Indeed, Innovation is useless if you cannot turn it into a product and then generate revenue with it.
Continuous Product Discovery and Delivery
As we have reviewed above, Product Discovery and Product Delivery are not sequential activities. It is true that the first phase is more about discovery either with a Design Thinking phase or a Design Sprint. But after this phase, it is critical that both happen in parallel and within the same team. Truly, you do not want to recreate a mini-waterfall between Product Discovery and Product Delivery.
Dual-Track Agile to address both Discovery and Delivery
This is what the market calls Dual-Track Agile: 2 activities with interconnected processes that a same team delivers at the same time. There are 2 backlogs: one with ideas, assumptions and risks to discover, and one with features, aka user stories, to deliver. But it is the same team covering both.
Staggered Sprints
Actually, having 2 teams with one focusing on Product Discovery and the other one focusing on Product Delivery is an anti-pattern and a common misunderstanding of Dual Track Agile. Furthermore, the name of this anti-pattern is Staggered Sprints and it has all the drawback of waterfall in comparison with Agile, nevertheless this time between the Discovery Team with UX Designers and the Delivery Team with BA and developers:
- Handoff from Discovery to Delivery teams generating extra effort and misunderstanding.
- Lost of common shared vision about the context and the vision.
- Slow down and lost of relevance with decision making.
So, the same team should carry both Product Discovery and Delivery. With for a given time period of a number of sprints.
One team and two activities: Product Discovery and Product Delivery
- Some team members working on Product Discovery, most likely with Kanban as the unknown nature of items makes them difficult to size and changes priorities by the flow as the team learns. This sub-team should have UX skills but it is valuable for other team members to contribute.
- Other team members working on Product Delivery usually in Scrum. Except if the environment is instable (high-variability of production activity) as in this case Kanban will be also the relevant Agile framework. The core of this sub-team are developers. Of course, the product manager and the designers help daily on delivery to clarify intention of features. At last, note that there is also learning generated by this team. Indeed, learning continues when in production with the live data captured. Furthermore, low risk tests can be performed in production for instance implementing a new or modified feature on a part of the customers. In other words, A/B testing.
Product Strategic Context
We have covered the dimensions of a Product and the phases of Product Management. Yet, Product Management requires in addition a frame for the team to contribute to it efficiently. This is what Marty Cagan calls the Product Strategic Context.
Company Strategic Context
The first part of this context is actually inherited from the company and is an input for the Product Manager to elaborate his or her Product Strategic Context.
Company Mission
In a nutshell, this is the purpose of the company. Surely, it should be a simple statement and it is supposed to last for a long time period, if not for the lifetime of the company. Everyone in the company should know and understand the Company Mission.
Company Objectives
These objectives come from the company strategy and are what the company focus on. Surely, they should be outcomes, business results, not outputs such as delivering an initiative.
Company Scorecard
Company Scorecard or Dashboard consolidates Key Performance Indicators (KPIs) supporting an understanding of the big picture and health of the business.
Product Strategic Context
The Product Manager builds the Product Strategic Context consistently with the Company Strategic Context. It consists of several elements.
Product Vision
The Product Vision is the way the Product Team delivers the Company’s Mission by developing products and services to their customers. Furthermore, it is consistent with the Company Vision.
The mission may provide the purpose, but it’s the vision that begins to make this tangible.
The Product Vision should be ambitious, appealing and inspiring. For instance:
To provide access to the world’s information in one click, Google’s Vision
Create economic opportunity for every member of the global workforce, LinkedIn’s Vision
Spread ideas, TED’s Vision
To accelerate the world’s transition to sustainable energy, Tesla’s Vision
The Product Vision describes a long term future the Product Team aims at creating, and how this future will improve the lives of their customers. The time frame is usually:
- Between 2 to 5 years for a software company.
- Longer, between 5 to 10 years for a hardware company.
Product Principles
The Product Principles is complementary to the Product Vision as it explains the values and beliefs that the Product Team will refer to, to take decisions regarding the Product. This is the epitome of the product you want to create.
Team Topology
The Team Topology is how teams organize to discover, design and build the product. In other words, it is their scope of responsibility, their focus and the problem they solve. In addition, it comes with the big picture on how they relate to each others when co-working on the same product.
Product Strategy
Marty Cagan describes the Product Strategy as connecting the Company Objectives with the Product Vision to generate the Product Team objectives and channel their actions. Like all Strategies, Product strategy focuses on key areas, means and people, to reach a lever effect.
The Product Roadmap supports these Product Objectives and enforces focus. It structures and visually displays the path how the Product Team is going to deliver the Product Vision.
The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there.
Product Team artifacts to support Product Management
Product Roadmap
Typical Product Roadmaps are usually about outputs and features, not outcomes and business impact. This switch of paradigm is key in the Product Team that Marty Cagan describes.
There are several issues with Output-based Product Roadmaps:
- Firstly, many of the ideas in the Product Roadmap will not work and will be replaced by others.
- Secondly, whatever disclaimer you use, a roadmap is generally understood as commitment. Truly, some items should be committed because there is an important deadline to reach as dictated by the environment. To illustrate, a deadline for meeting a compliance requirement that will result, if not done, in a financial penalty and an impact on the company image. But this is not the case for other items that are delivered to maximize value and learning.
- Thirdly, roadmaps are like Scrum Backlogs, they are emergent. It takes several iterations to transform and idea in features then impact on the business. In addition, Product Team needs Product Discovery before being able to commit.
Legitimate expectations from the management on roadmaps should still be addressed:
- Make sure that the Product Team is working on the most valuable items or is dealing with the biggest risks or assumptions.
- Ensure that people in charge of planning actions from contributors outside the Product Team like marketing, sales force and partners have the necessary visibility.
Outcome-based Product Roadmap
The pre-requisites for Outcome-based Product Roadmap are:
- Firstly, that the Product Team has the necessary business context as described above and built by the Product Manager: Product Vision, Principles and Strategy.
- Secondly, that the Product Team is empowered. We develop this aspect in the post about the comparison between Product Team and Feature Team. In a nutshell, the team is empowered on a defined scope to solve a problem, not just to deliver features.
OKRs
The Objectives and Key Results (OKRs) is a tool based on objectives enabling focus and alignment at all levels of a company. Clearly, this is why transparency is the rule all over the company with OKRs. Furthermore, they should be in limited number: typically one to three objectives, with for each, one to five key results.
- The Objectives are qualitative. The Management of the organization down to the Product Manager defines them.
- The Key Results on the contrary are quantitative, measurable and with a target. Similarly as above, the Key Results should be outcome-based as business results, not output-based. Definitively for empowered Product Team, that’s the team that defines them as they are in charge of solving a problem and defining a solution. Surely, they are the more experts to set them and they are the KRs owners. As a result, they will feel accountable to achieve their objectives.
At last, the Product Team defines or revises their OKRs quarterly. In addition, they update and review progress on their OKRs on weekly basis.
What’s next? Learn about other frameworks around Product Development like Lean Startup, Story Mapping, Impact Mapping and Agile
- To learn more about other frameworks supporting Product Development like Lean Startup, Story Mapping and Impact Mapping check my other post.
- In addition, you can review my posts introducing Agile and Agile at Scale.
- At last, learn more about innovation with all my posts about Digital and the disruptive technologies.
Do you want to learn more about Product Management? Here are some valuable references
Web references:
- Dual track sprint:
- Jeff Patton’s post on Dual Track Development.
- Desirée Sy’s post on Dual track sprint. She introduced the concept of Dual track sprint.
- Jeff Gothelf’s and Josh Seiden’s post on how to integrate Agile and LeanUx and on the difference between Dual Track Sprints and Staggered Sprints.
- Alex Ballarín’s post from UX Collective on Staggered Sprints.
Product Management books:
- Marty Cargan:
- The Product Book from Josh Anon, Carlos González de Villaumbrosia