A Diagram Representing Product Management Activities: As a Tool for Dialogue and Action
I am sharing a diagram that attempts to represent the overall picture of key product management activities and the mutual influence between each activity. The diagram is below.
Product Management Activities Diagram
Download PDF version↓
About this diagram
This is a diagram that attempts to represent the overall picture of key product management activities and the mutual influence between each activity. There is
no single, uniform process for product management that exists, but I have attempted to represent the activities that tend to be performed in many product companies as one possible form. I especially hope this will be useful for product teams (including product managers) and product leaders.
Background of creating the diagram
This diagram was drawn starting from the realization that I could not find a suitable diagram to use when I wanted to talk about the "overall picture of product management activities."
However, in the process of drawing this diagram and explaining it, I realized that there are things I am emphasizing in particular. My own failures and the challenges of product organizations I have heard about from various people were brought to mind.
Product teams (even product managers) have ended up with a division of labor that does not involve discovery.
Activities called "Discovery" have become nothing more than defining requirements for items written on a request list, rather than exploring strategic opportunities or exploring what should be built.
Product teams (product managers, engineers, designers, etc.) are building products based only on hearsay without ever touching primary information.
Without verifying "whether the problem actually exists" or "whether there is value and demand," they plunge into the process of "building the product" and mass-produce things that are not used.
After product delivery, they do not perform evaluation of outcomes and leave it as built and forgotten.
Key product management activities are being carried out under excessive role segmentation, process segmentation, and one-way processes.
The relationship between the product team (even the product manager) and the Go-to-Market team (marketing, sales, customer success, etc.) has become minimal .
Although a roadmap exists, it is not calculated backwards from a "future vision to aim for" in terms of vision and customer value, but has become a pile-up of immediate requests.
Product teams (even product managers) do not understand business strategy or Go-to-Market strategy, and their awareness of how the product contributes to the business has become low.
The product strategy is not presented..
The leader responsible for formulating both business strategy and product strategy is biased toward one perspective over the other.
When the leader formulating business strategy and the leader formulating product strategy are different, they are not collaborating with a healthy sense of tension and cooperation, resulting in a strategy that lacks high standards.
The strategy is not based on insights gained from exploration, resulting in armchair theory.
The product vision is not presented.. Or, the product vision has become something that does not help with decision-making or boosting team morale.
Of course, even if the situation is as described above, if the product and business are successful, approaching the envisioned goal, and the people involved are happy (and if these conditions seem likely to continue), there is no problem at all. Also, there are many cases where the "activities" are not the essence of the problem. However, if the states described above could be the cause hindering that success, I hope this diagram can be of some help.
When using this diagram in product coaching, I do not use it for one-way explanations, but rather as a "catalyst for dialogue and action". It starts with conversations like "We aren't spending enough time here" or "We should really focus our efforts here now," and develops into concrete actions such as "Let's reallocate our energy for better results." Differences in interpretation, or even misreadings, can become triggers for discussion and action.
Also, I received a lot of feedback from many people when releasing this diagram. The points of empathy and discomfort vary from person to person, and the strong convictions born from their experiences came through, for which I felt respect. And I felt that "the fact that it became a trigger to hear such thoughts is the significance of this diagram's existence."
I believe that if product professionals who see this diagram can "What do you think of this diagram?" "This part is different. Shouldn't it be like this for us?" "This part is important, isn't it?" and engage in dialogue, and further, if that dialogue leads to actions for results, the probability of product success will increase even more. It can also be used by product leaders to share their own thoughts and serve as a starting point for dialogue. In other words, I hope you will use this diagram not for self-study alone, but as a catalyst for dialogue and the actions that follow.
Also, as a slight aside, I feel that with the rise of AI, the time has come to unbundle the stereotypical job definitions of "product managers" (and many other product-related roles) and re-focus on "what should essentially be done". I hope this can also serve as material for that discussion.
Examples of dialogue scenes and content
-
Dialogue within the product team
While mapping our own activities to those in the diagram, discuss the balance of energy distribution as a team.
Discuss "where to trust and delegate to each other" and "where to work together."
-
Dialogue between Product Manager and Manager/Mentor
Create a shared understanding and common language for the big picture of product creation, and engage in dialogue to broaden perspectives.
Discuss the hopes and expectations regarding "the scope one wants to (or wants them to) become capable of," "the scope one wants to (or wants them to) focus on," and "the scope one wants to (or wants them to) bleed into."
-
Dialogue between roles involved in product creation
Dialogue regarding bottlenecks for product success.
Discuss "where to trust and delegate to each other," "where to bleed into each other's work," and "where to eliminate boundaries."
How to read the diagram and points to note
The large text (e.g., "Product Discovery," "Product Strategy") indicates the names of activity areas, and the smaller text around them (e.g., "Turn insight into strategy," "Grow talent") indicates the content of those activities. Activity areas that are colored (i.e., not in black text) are those where product teams (cross-functional teams including product managers, engineers, designers, etc.) tend to be more directly involved. Product leaders (CEO/CPO/VPoP/Senior PM/CTO/Business Head, etc.) are strongly involved in all activities within the diagram. Product teams also need to deeply understand the activities written in black text and be strongly aware of their mutual influence on and contribution to their own daily activities.
The arrows indicate 'influencing/being influenced' (e.g., insights gained from Product Discovery influence Product Strategy). Of course, there is mutual influence between all activities, but this diagram only shows the major ones.
Furthermore, this does not mean that work is divided between arrows and passed along as a process. Who is responsible for which activity and how the process is designed must be considered in context. At the same time, because the side effects of excessive division and fragmentation are significant, it is also necessary to devise ways to avoid them.
Also, these activities do not mean a one-way process with a strict sequence. Each activity is often carried out in parallel, and they are constantly revisited through mutual feedback.
Overview of activities in the diagram
The loop of the four activities at the bottom (Product Discovery, Product Definition, Product Delivery, Product Evaluation) is the fundamental set of activities that product teams, including product managers, engage in daily.
We explore and discover ideas that should be built and have value and business viability (problems to solve and their solutions) (Product Discovery), define them for construction (Product Definition), shape them into a form that can provide value, and prepare them for deployment to customers and users (Product Delivery). We launch to the market while coordinating releases with Product Go-to-Market activities, and promote adoption of the product to generate profit. Then, we evaluate and learn from the information obtained from the market, and apply it to subsequent activities (Product Evaluation).
If you are a beginner product manager, it is recommended that you first focus on mastering each of these four activities by experiencing them end-to-end, even if it is just for a very small project.
And that series of activities is heavily influenced by Product Strategy and Business Strategy, which are primarily formulated under the leadership of product leaders (CEO/CPO/VPoP/Senior PM/CTO/Business Head, etc.). In other words, Strategy provides clear direction for other activities. At the same time, those Strategies also take insights gained from the four activities mentioned above and Product Go-to-Market activities as important inputs. Note that Product Strategy and Business Strategy are updated as nearly integrated entities while responding to each other.
And Product Strategy is responsible for realizing the Product Vision, that is, 'the world created through that product.' In other words, a good Product Vision leads to a bold Product Strategy.
Even if you are not a product leader, the product team needs to at least actively understand this area. If you are a product manager, you will likely become involved in its formulation as you become a middle or senior manager.
Further explanation of activities in the diagram
Product Discovery Loop
Product Discovery is the activity of exploring and discovering the problems to be solved and their solutions and is an important activity that serves as the starting point for many other activities. By deeply understanding the market, domain, customers, users, data, and the background information associated with them, and by engaging with a large amount of primary information, we derive insights and hypotheses (deciding what to build by taking what is written in request tickets at face value is not Product Discovery). We explore and discover hypotheses for ideas that are valuable to customers and users, have demand at a scale that ensures business viability, align with strategy, and are technically feasible.
Also, rather than going through the large loop of four relatively time-consuming and costly activities, we obsess over running only this Product Discovery loop with minimal lead time, verifying/falsifying hypotheses about value and demand as early as possible to find "what should be built with a high probability of success."
Product Discovery includes both broad Product Discovery that seeks "problems to be solved" leading to Product Strategy (or Business Strategy), and limited Product Discovery that identifies the problems to be solved and their solutions in order to perform Product Definition. It is important to perform both of these intentionally as an organization. While the former can sometimes take up to three months, the latter is often a matter of days or weeks.
While Product Discovery is fundamentally performed temporarily and intensively for specific purposes (discovering new businesses, formulating strategies, deciding on solutions), it is not limited to temporary activities; it is also an activity that the product team, led by product leaders and product managers, performs continuously. Product managers should be engaging with primary information at least once a week. Innovative strategies and ideas are born from individuals and teams that possess cumulative insights..
Also, when you are lost in formulating a Product Strategy or Product Vision, returning to this Product Discovery activity and re-engaging with primary information while forming hypotheses is an experience that many have had that clears the path ahead.
*Product Discovery practices, frameworks, and keywords:
User/customer interviews (exploratory, validation), fieldwork (user observation, business ethnography research, Contextual Inquiry, apprenticeship), expert interviews, Jobs-to-Be-Done, Double Diamond, hypothesis list, hypothesis map, Value Proposition Canvas, Lean Canvas, Opportunity-Solution Tree, Opportunity Backlog, Kano model, persona, empathy map, business flow diagram, Customer Journey Map, Experience Map, User Story Map, Storyboard, pretotype, prototype (rapid, high-fidelity), concierge MVP, Wizard of Oz MVP, smoke test, guerrilla test
Product Definition and Product Delivery loops
Once "what should be built with a high probability of success" is found through Product Discovery, it is detailed in Product Definition with the goal of bringing it to market in earnest. We re-articulate "who will be in what state for it to be a success," which often tends to slip out of the minds of stakeholders, express as a story the state where "the target audience enjoys the value and is successful," establish metrics to measure the success that the solution will create, and define requirements (functional requirements, non-functional requirements), UI, and architecture.
At the same time, we prioritize multiple "things to build" and map them out in the form of a product backlog, roadmap, or release plan. This becomes a short-term milestone and goal setting for the team, creating a good rhythm. It also serves as a tool for dialogue with internal stakeholders.
To be frank, this Product Definition area is an area with little added value from the perspective of customers and users, and one should always pay attention to whether the workload in this area is excessive relative to the effects obtained (such as whether it is an appropriate investment in the efficiency and quality of related activities or our future productivity) and be constantly mindful.
*Product Definition practices, frameworks, and keywords:
PRD, MRD, Press Release & FAQ (PR/FAQ), product backlog, short-to-medium-term feature roadmap, release plan, User Story Map, user story, JTBD statement, wireframe, mockup, information architecture, functional/non-functional requirements, data flow, event storming, customer/user hearing, customer/user testing
Product Delivery is the activity of actually "making value deliverable." We run design, coding, testing, and deployment with the shortest possible lead time. It is desirable to be in a state where deployments happen multiple times a day and deployment and release are managed separately using mechanisms like feature toggles.
Also, in order to make evidence-based judgments in the next Product Evaluation, it is essential to make each feature measurable. Product observability also increases the speed of preventing failures that cause loss to customers/users and investigating their causes.
Furthermore, the loop between Product Definition and Product Delivery is carried out without being excessively fragmented into stages, moving back and forth within the product team on a daily (or even minute-by-minute or hourly) basis Also, in this loop, it is necessary to
avoid getting trapped in activities that are only about building things, and instead obtain feedback from the market, customers, and users as early as possible, and devise ways to avoid building things that have no value (such as minimal scoping and early customer/user testing).
Product Evaluation
After release, it is converted into clear "learning from the market" through Product Evaluation. Each metric is constantly visualized on dashboards and the like, and kept in a state where it can be analyzed. Release results are analyzed from both quantitative data (product metrics, business metrics) and qualitative information (customer/user voices, situations, etc.), and evaluated focusing on the definition of success metrics determined in advance. The learning obtained is shared within the team, with other teams, and with stakeholders, while being centrally managed within the organization. Then, that learning is fed into the ongoing Product Discovery loop.
The Pair of Product Strategy and Business Strategy
As indicated by the bidirectional arrows drawn in parallel, Product Strategy and Business Strategy are updated while responding to each other. Just because you are a "product" team, "product" manager, or "product" leader does not mean you do not need to be involved in Business Strategy. In particular, as you move into roles that are relatively closer to management, it becomes necessary to formulate a Product Strategy based on corporate strategy and the improvement of corporate value.
While the two represent a correspondence between "winning moves from a business value perspective" and "winning moves from a customer value perspective," the activities for formulating them will likely have many overlapping parts without being clearly separated (for example, self-awareness of strengths and advantages, understanding the competitive environment, identifying opportunities and threats, and market evaluation, which are conveniently placed under Business Strategy, will also be carefully considered from a product perspective).
Product Strategy
In Product Strategy, while keeping an eye on the long-term Product Vision (~5 years), guidelines for the medium term (about 3 months to 1 year) are clearly indicated. That strategy must be aligned with corporate strategy.
Areas of medium-term focus and the success state of those customers are depicted as a story, and success metrics are set. Also, we always assume what the product portfolio will look like at each stage of the medium to long term (6 months later/1 year later/2 years later, etc.) to maximize value. And to realize that, we build an organization and culture where the strengths of existing good product teams continue to be fully utilized, and an ideal investment portfolio can be realized.
However, in the very early stages of a product or during periods of pivot consideration where large possibilities are being intensively explored, the Product Strategy may be reviewed on a weekly basis depending on the learning obtained.
As an important point, Product Strategy is never something created only at a desk, but something generated based on insights obtained from Product Discovery, Product Evaluation, and Product Go-to-Market.
And the most important strategic initiative across all activities is to promote the growth of people and teams.
*Product Strategy practices, frameworks, and keywords:
Medium-to-long-term product portfolio planning, medium-to-long-term Product Strategy roadmap, STP, TAM-SAM-SOM, JTBD-Based Segmentation, OKR, competitive map, SWOT/cross-SWOT, 5 forces analysis, competency matrix, 3 Horizons, press release & FAQ, scenario planning, One Metric That Matters
Product Vision
Product Vision is one of the most important elements in product creation, indicating "what kind of world we will create" while looking at a long-term (up to 5 years) time axis. It is also an element that attracts people inside and outside the organization. Also, the vision needs to be useful for decision-making. If you cannot draw a good Product Strategy, it may be a sign that there is a problem with the Product Vision.
If there is Problem-Founder Fit, it is often drawn starting from what is inherent in the founder from the very beginning. While the vision may be solid from the beginning in that way, there are also cases where it is not stable or clear in the early stages (this is likely to happen when creating a second pillar product within the company). In that case, rather than forcing yourself to draw a plausible vision right now, it is better for the product leader to thoroughly re-touch primary information and increase the time spent gaining inspiration. Also, a vision that was solid in the early stages may need to be updated as the product grows and the environment changes.
Product Vision should not only be a concise 1-2 line statement, but should depict the future world in a story format rich in scenes, emotions, and characters, and also clearly indicate the essential and major challenges that must be solved to realize it. It should also draw milestones that can be thought of at that time for the realization of the vision, and show that the vision is not a dream story. Also, by setting "metrics that can be said to indicate the realization status of the Vision", it will become the North Star for the team, and you will be able to avoid losing sight of the long-term direction in daily activities. Also, depending on the product, by setting
product principles (e.g., Chromium's Core Principles), the concept that should be the axis of the product becomes clear, which is useful for a wide range of decision-making from the strategy level to the functional specification level.
*Product Vision practices, frameworks, and keywords:
Vision statement, elevator pitch, vision novel, concept movie, North Star Metric, product principles, one-pager, backcasting, future perspective, flywheel, vision type
Product Go-to-Market
Simply releasing a product does not mean value reaches the customers or users.Value becomes a reality by creating demand, enabling marketing and sales teams, channels, and partners, and supporting the success of customers and users. Then, as the product gains traction in the market, revenue increases.Go-to-Market teams (such as marketing, sales, and customer success) must work closely with the product team to plan and manage market deployment (releases and launches). Releases and launches must never be driven solely by the product team's ego.
Furthermore, Go-to-Market teams are in daily contact with existing and prospective customers and users, making them a powerful unit that gathers extensive and specific market trends and customer/user feedback, and they likely possess deep knowledge of these areas. We often obtain information that serves as the starting point for Product Discovery from the Go-to-Market team, who act as the voice of the market, or conduct Product Discovery together. In that sense, the trust and closeness between the Go-to-Market team and the product team are crucial.
Questions as Seeds for Dialogue
When engaging in dialogue, please try using the following questions. They are not listed in order of importance, so please choose a few that interest your team and discuss them. And remember,
everything is for the sake of outcomes (customer/user success, business success, realization of vision, and the happiness of the team and individuals). Having all of these done well does not equate to 'outcomes'. Use these strictly to gain hints to increase the probability of success when aiming for further outcomes. Never let the means and the ends become swapped.
Overall
Who is responsible for the results of the product strategy and the entire product portfolio? If someone is, who is the right person for the job?
Who is responsible for the results of each product's success? If someone is, who is the right person for the job?
Is the product team cross-functional and collaborating on a daily basis for the success of the product? What can be gained by increasing the level of collaboration?
Is the product team working together (in some activities, relying on each other as professionals) to tackle Discovery, Definition, Delivery, and Evaluation as a whole? What can each person do to step beyond their current roles?
Does the product team, including the product manager, understand the business strategy and Go-to-Market, and are they proactive in contributing to them? Who would be best to talk to in order to understand them better than you do now?
Is the product team, including the product manager, stepping into the business team (business owners or BizDev) and Go-to-Market team (sales or CS) to collaborate closely? To ensure good collaboration, do you understand the other party's work goals and beliefs?
Are the respective activities parallel, constantly providing feedback, and moving back and forth as needed? Which bottlenecks can be addressed to shorten the lead time to creating value compared to now?
Around Product Vision
Does a product vision exist? Is that vision still functioning today?
If you were to create (or recreate) it, who could draft it? Who has had the most passion for the product throughout its history? Can you talk to that person?
What is the 'core problem' you need to 'solve', and for 'whom'?
If you were to express the world your product will create in the future as a story rich in scenes, emotions, and characters, what would it be? What would the world look like at the intermediate stages of 1 year, 3 years, and 5 years from now?
Can you try prototyping your company's product as it appears in that story right now?
If you have no idea what kind of vision to set, what kind of primary information could you encounter to gain inspiration?
When has a vision been useful for decision-making? Regarding difficult past decisions, what kind of vision would have been helpful?
Can everyone in the product organization talk about the vision? Is it known outside the product organization as well? What is missing to make it resonate with that person in the company?
Around Product Strategy
Does a product strategy exist? Is it useful for daily decision-making?
Is the product strategy being considered and decided only on paper? What primary information should be touched upon in discovery to guide the strategy?
Do you have a deep understanding of business strategy and corporate strategy for strategy formulation? Does that strategy improve corporate value? Who should you talk to to deepen understanding and discussion in that area?
In a word, what is the theme to focus on in the next 3-6 months? What are the things you will 'not do'? If you were to strictly prioritize the strategy items, what would the order be? What is the opportunity cost if you narrow it down to the top 3? Is that loss unacceptable?
If you were to secure a full day of thinking time to create or review the strategy, when could you secure it? What date? Which meetings or tasks could you reschedule to free up time?
What will the product's feature set look like in 1 year, 3 years, and 5 years? Within limited resources, what should you focus on most to bridge the gap?
Can competitors develop a similar strategy? If they were to adopt a similar strategy, what are the strengths or capabilities of your company and product that would serve as differentiators?
If the strategy you envisioned turns out to be wrong, what are the conditions for a pivot?
What are the unacceptable risks? What are the acceptable risks?
What segments are possible if you segment by demographics/firmographics? What segments are possible if you segment based on jobs (JTBD)?
What are the leading indicators that represent product success? If you had to narrow it down to one most important leading indicator that aligns with your current strategy, which one would it be? What lagging indicators are you tracking? Are the indicators you are tracking becoming vanity metrics? Is it unlikely that your actions will be distorted by excessively pursuing those indicators?
What will the organization look like in 1 year, 3 years, and 5 years? If you continue to invest in the current talent/teams, will there be enough 'good leaders' and 'good teams' growing at each phase?
What kind of culture is good for business, product, and people alike?
Are the product strategy and business strategy providing feedback to each other? Are there conflicting interests that both sides should understand in order to provide feedback to each other? What is the common goal that aligns beyond those interests?
Around Product Discovery
Are you organizationally executing both discovery for strategy formulation and discovery for product definition (i.e., solution definition)?
If you don't have enough time for discovery, are there any tasks or meetings you can temporarily stop or delegate to someone else? (It would be great if the team could say, 'I'll help you with that work so you can spend time on discovery!')
To discover the problems that need solving, are you continuously exposed not only to secondary information (messages from sales/CS teams, feature requests from customers, etc.) but also to primary information (customers/users themselves, their actual work/field, their bosses/executives, purchasing decision-makers, competitors, domain experts, opinion leaders, etc.)?
Who currently has the most primary information within the company? How would it be best to involve that person?
Are the various issues and hypotheses organized and managed?
How can we prove the 'existence of the problem,' the 'value of the solution,' and the 'demand' for it without writing production code?
Around Product Definition
Is the work we call 'product discovery' within the company stopping at this 'product definition' work (defining requirements and specifications)? Who should we involve to branch out into exploration? What can we do to gain the trust needed to get them involved?
For that feature, what 'state' would 'whom' be in for it to be a success? If you were to name 'whom' by their real name, who would it be?
What is the 'ideal story when it is released and accepted by the market, customers, and users'?
What happens if you assign a strict priority to the things that should be built (assigning unique, sequential numbers in order of priority)?
What are the success metrics for each backlog item? How do they relate to the current key strategic metrics?
Are the people who should be responsible for strategy and discovery taking up too much time with just this product definition? What would a pie chart of their average weekly work distribution look like? Who should you rely on or ask for help from to share the workload?
Around Product Delivery
What are some ideas for improving delivery lead time? What are some reform ideas to shorten it dramatically?
Are the people who should be responsible for strategy and discovery spending too much time on delivery management (project management)?
Are environments like automated testing and CI/CD in place? Is the system's observability high? Can feature usage be measured?
Are there mechanisms in place, such as feature toggles, to realize releases that take Go-to-Market into account?
Around Product Evaluation
Whose help can we enlist to visualize product usage and make it constantly viewable?
Are delivered features being evaluated both quantitatively and qualitatively? Is the achievement status of the defined success metrics being checked? What are the mechanisms and systems to ensure this is executed?
Are the key metrics for the entire product and business being checked regularly, not just by delivery unit? Who can lead that?
Are there too many metrics to look at? What is the opportunity loss if you narrow it down to the top 3 metrics? Is that really unacceptable?
Are there any important metrics you are overlooking? If you were to explain the connection between your current key metrics and your strategy/vision, what would it look like?
Are leading, coincident, and lagging indicators intentionally distinguished?
Are the learnings gained from the market through the launch being applied to discovery and strategy? If you were to apply the learnings from the various evaluations of this quarter to the next strategy, what kind of strategic ideas would you have?
Frequently Asked Questions
Q. I often see diagrams in the world that define the product management loop as just 'Product Delivery' and 'Product Discovery.' Why does this diagram include 'Product Definition' and 'Product Evaluation'?
I see and hear about the following issues often, so I am attempting to clarify that these are distinct and important activities by intentionally breaking them down.
Work called 'discovery' within the company is nothing more than 'definition' of requirements, rather than the 'exploration' of value or opportunities.
Product evaluation is not being conducted after product delivery.
I was hesitant, wondering if 'breaking them down would encourage excessive fragmentation,' but this is how I have it for now.
Q. I think Business Strategy should be positioned above Product Strategy (and Product Vision).
As you say, in reality, there are many cases where Business Strategy comes above rather than in parallel. However, I have placed them in parallel here to reflect cases where product managers and product teams exert influence to raise the level of business strategy, where product leaders and product managers dissolve the boundaries between product and business, and real-world examples where ideas born from Product Vision create powerful businesses.
Q. I would like to know more concrete and detailed activities and deliverables for each activity.
I apologize for not having delved that far yet. For now, I hope you can get hints from the various keywords in this article (by asking an AI or searching). I am considering providing more concrete and detailed examples of activities and deliverables upon request.
Q. Is it okay to redistribute this within my company?
Actually, please do! The license is CC BY-SA.
Feedback
Thank you for reading this long, long text to the end. If you have any feedback, please send it to X: @ykmc09.
Acknowledgments
This diagram was provided to clients and brushed up daily during that process. I am grateful to all the clients who always engage in good discussions with me.
-
Before publishing this note, I received feedback from the following individuals (in Japanese alphabetical order). I gained many insights from their diverse and constructive feedback, which I was able to incorporate into improvements. While there was much feedback I could not fully reflect, I will use it as a reference for future improvements and additional posts. Thank you very much.