The Complete Product Management Framework

In partnership with

TL;DR - The product management cycle, in a nutshell, involves identifying user problems, generating ideas, detailing product specifications, validating with market research, prototyping, developing the product iteratively, rigorously testing, launching with marketing strategies, reviewing post-launch performance, and then deciding whether to retire the product or iterate based on feedback—ensuring a structured approach to meet customer needs and achieve business goals.

Recently, I was asked about our approach to Product Management and the software development process. What systems are essential for creating a repeatable workflow? Who is responsible for each phase, and who should participate? How do we generate and prioritize ideas? How do we ensure the process remains effective? Writing out the entire flow made me realize it was my first time documenting it on a single page. I believe this could be beneficial for others, so I'm sharing it here. This overview primarily targets new Product Managers, as these concepts are foundational. Experienced PMs will likely be familiar with these steps, but I hope they find some valuable insights too. I want to clarify that this isn't the definitive product development flow—there are various alternatives and specific adjustments needed based on industry or context. Thus, this is not an exhaustive review but rather a high-level framework. This framework applies to a single program or feature, with additional mechanisms for longer-term strategic investments. Different organizations may also have varying sequences or groupings of activities, which is perfectly acceptable. The key is to establish strong mechanisms for each activity: define ownership, set objectives and output expectations, and regularly review and enhance your processes. Below is a summary of the 10 steps.

There’s a reason 400,000 professionals read this daily.

Join The AI Report, trusted by 400,000+ professionals at Google, Microsoft, and OpenAI. Get daily insights, tools, and strategies to master practical AI skills that drive results.

Sign up now for free and work smarter, not harder.

Step 1: Product and Feature Ideas

What should we create for our customers? There are numerous strategies you can implement to generate ideas for new products, platform-level offerings for multiple users, enhancements to existing products, reworking current products, or fixing bugs. These ideas can be integrated into your annual/quarterly planning cycles or pitched as new initiatives requiring additional resources. We have established various mechanisms to support this cycle: annual strategy planning, quarterly prioritization sessions, bi-weekly status updates, and sprint planning. We also communicate these opportunities with stakeholders including customers (especially in B2B), internal and external partners, suppliers, and leadership. For new product opportunities, the key questions are: What valuable experience can we deliver to customers? And what experience can we offer our suppliers or other key stakeholders? Value varies by organization and may differ across industries or growth stages. Generally, I recommend using long-term free cash flow as the best measure of incremental value. This includes both immediate transactional value (such as advertising) and ongoing value from subscriptions or engagement opportunities. Long-term free cash flow drives growth and aligns with investor interests without sacrificing long-term benefits for short-term gains.

Here are several mechanisms to consider when generating new ideas:

Direct Customer Feedback

This refers to explicit signals aimed at providing insights on a product.

1. Usability Studies: Conduct sessions with around 10 customers early in development to gather feedback on specific flows and designs. Use prototypes or mocks if necessary; customers will provide valuable suggestions.

2. Customer Focus Groups/Diaries: Explore customer behaviors by understanding why they prefer certain features or stop using products. This step aims to identify top issues rather than achieving statistical significance.

3. Customer Surveys: After identifying key issues from focus groups/diaries, use surveys to quantify these issues and prioritize opportunities.

4. Customer/App Store Reviews: Customers who leave reviews often do so out of frustration; while not ideal for identifying top issues, they can yield valuable insights into potential improvements.

5. Panel/Beta Apps: Gather early feedback on complex features from engaged customers willing to test new developments; take this data with caution due to potential biases.

6. Explicit Customer Feedback Mechanisms: Integrate feedback options directly into the product experience—ranging from simple thumbs up/down options to detailed feedback forms.

Indirect Customer Feedback

This consists of implicit signals indicating customer resonance with a product.

In addition to soliciting direct feedback from customers, consider what resonates with them outside your organization:

7. Customer Behavioral Data: Analyze metrics like retention rates and conversion rates over time to understand customer experiences with existing products.

8. Customer Service Insights: Customer service teams can provide valuable information about common pain points and bugs in existing products.

9. Data Aggregators: Use data aggregators that track app behavior to gain insights into trends over time; focus on relative changes rather than absolute figures.

10. Team Ideas: Encourage team members to pitch ideas through a one-page document evaluated in bi-annual sessions; this promotes participation in the idea generation process based on data-backed proposals.

Step 2: Working Backwards Document

Once you have identified your primary product or feature concepts, the next step is to elaborate on the minimum lovable customer experience, both in the short and long term. This includes outlining the business strategy, logging, data collection, metrics approach, potential risks, and strategies for risk mitigation. All of this information can be compiled into what is known as a working backwards document. This document should clearly define the comprehensive customer experience we aim to provide, the reasons customers will appreciate the product, how they will utilize it, and where they can access it.

The depth of this documentation may vary, typically in relation to the level of investment involved. For instance, if the investment is substantial—such as involving multiple two-pizza teams over a period exceeding six months (a two-pizza team is defined as a group of about 6-8 engineers along with a product manager and a software development manager)—the output would include a fully developed Press Release and accompanying Frequently Asked Questions (PRFAQ). While much has been discussed regarding Amazon’s PRFAQ format, at its core, the Press Release is usually limited to one page and describes the anticipated experience at launch, why it will appeal to customers, how they will interact with it, and how they can access it. The FAQs typically span three to five pages, ensuring that the entire document remains under six pages; however, an appendix may include User Interface mockups or other pertinent information.

It is crucial to document the customer experience and key business decisions early in the software development process. This documentation facilitates communication of the strategy to stakeholders and team members alike. It also allows for articulation of customer flow and discussion of critical decisions before development begins. An Amazon executive once remarked, “We always start with a PRFAQ before one line of code is written. This allows us to align on the experience and debate key issues before placing it in front of the customer.”

As previously mentioned, you can initiate this process with ‘pitch documents’ or similar formats to avoid requiring team members to draft extensive documents before engaging in discussions. If your idea pertains to a feature of an existing product, you may proceed directly to step 5 to elaborate on use cases and convert them into technical specifications.

Step 3: Prioritization

While I have designated prioritization as the third step, it is important to note that this process occurs throughout the entire product development cycle. I emphasize it here because once you have established your key product ideas—most of which will be supported by working backwards documents—you will possess the necessary information to make informed investment decisions for the upcoming year, quarter, month, or sprint. Decisions regarding features or sub-features may evolve as you gather more data throughout the process.

Metrics for Effective Prioritization

To enhance the prioritization process, it is highly beneficial to utilize a metric or set of metrics that align with teams across the organization. There is a diverse array of prioritization metrics available, but typically, at least three key types should be considered:

1. Customer or Business Impact: This can be assessed through various lenses, such as financial metrics (e.g., revenue growth or profit), engagement metrics (e.g., increased visits or repeat visits, dwell time), customer satisfaction ratings, or a decrease in complaints. It’s essential to balance the precision of measuring customer value against the simplicity of having a unified metric across the company. I personally advocate for the latter approach, as teams tend to improve their ability to estimate the impact of a single metric over time.

2. Time to Implementation: Prioritizing high-value initiatives that can be brought to market quickly is crucial. When evaluating time to market, consider whether a preliminary version of the experience could be presented to customers to gauge product value sooner. This assessment should take into account the overall cost of creating the product; if costs are significant, it’s wise to seek opportunities for early testing before committing fully to development.

3. Risks: Identify any internal or external factors that could hinder your progress. Assess how likely these scenarios are and whether there are aspects of the experience where the team may lack expertise—such as in Machine Learning—that could pose challenges.

Step 4: Breakdown of customer stories

Utilizing the working backwards document, you can outline all the functionalities that customers and stakeholders expect from the product. This should be framed from the perspective of those who will benefit from the product's value. For instance, we developed a product that offers expert articles on various items (e.g., from publishers like Wirecutter) for customers seeking product reviews beyond just user feedback. One implementation of this was integrated into Amazon’s search results; for example, when a customer searched for “best TVs,” we would present a widget within the search interface to highlight relevant articles.

Customer Stories Example

One customer story could be articulated as follows: “As a customer, I want to see expert articles on products I’m interested in when I search for them. I would like to view the product, its star rating, the publisher of the review, and concise excerpts from the article to help me decide whether to engage further.” This approach also allowed us to design various product interfaces for users. Another use case might be, “As a customer, I want to see the top three articles related to my search query.”

It is essential to consider all stakeholders involved with this product. In this scenario, publishers are a significant stakeholder. A corresponding use case could be, “As a publisher, I want my brand prominently displayed to customers.” Additionally, a partner team might express their needs with a statement like, “As the Search team, we require a ranked set of article widgets delivered through our API within X milliseconds.” Other departments such as Legal, Finance, PR, and Operations should also be included as stakeholders to develop comprehensive use cases.

Prioritizing Use Cases

After identifying all use cases, you can prioritize them to establish the Minimum Lovable Product (MLP). Some organizations refer to this initial version as the Minimum Viable Product (MVP), but at Amazon, we debated this extensively and concluded that the minimum standard should be a product that customers genuinely love. Consequently, discussions revolve around which features should be included in the MLP, focusing on essential P0 features.

To aid in feature prioritization, usability testing can provide valuable insights into what customers deem critical versus merely desirable. This data-driven approach ensures that the development process aligns closely with customer needs and expectations.

Step 5: Business Requirements Document

The purpose of the business requirements document (BRD) is to provide a more detailed analysis than the working backwards document and serve as a crucial input for the technical design phase. This document should encompass several key elements:

1. Purpose of the Product: Clearly articulate why this product is being developed, including the reasons customers will appreciate it and the underlying business case.

2. In-Depth Customer Experience Analysis: Provide a comprehensive overview of the customer journey, including detailed customer flows and mockups for each step based on the previously identified P0 features. This will help define the intended functionalities and outcomes for customers, as well as clarify what the product will not deliver.

3. Handling Exceptions and Errors: Outline how exceptions and errors will be managed within the system to ensure a smooth customer experience.

4. Experimentation Strategy: Detail the strategy for conducting experiments, including design elements and critical considerations such as ensuring an equitable distribution between treatment and control groups.

This document will be the primary reference for the technical team as they develop the technical design. It is essential for aligning all stakeholders on project objectives and ensuring that everyone understands both the business needs and customer expectations.

Automate Prospecting Local Businesses With Our AI BDR

Struggling to identify local prospects? Our AI BDR Ava taps into a database of 200M+ local Google businesses and does fully autonomous outreach—so you can focus on closing deals, not chasing leads.

Ava operates within the Artisan platform, which consolidates every tool you need for outbound:

• 300M+ High-Quality B2B Prospects

• Automated Lead Enrichment With 10+ Data Sources Included

• Full Email Deliverability Management

• Personalization Waterfall using LinkedIn, Twitter, Web Scraping & More

Book a demo and supercharge your sales team

Step 6: Technical Design and Tech Breakdown

Engaging the technical team throughout the entire product development cycle is crucial. If their involvement begins at Step 6, there is a significant chance that the Minimum Lovable Product (MLP) will be improved due to their insights. The technical team can provide valuable input regarding the feasibility of features, potential risks, and critical questions about why customers will value the product. While Product Management is responsible for completing steps 1 through 5 and jointly managing steps 8 through 10, the technical team will take charge of steps 6 and 7.

Developing the Technical Design

At this stage, it is essential for the Product Manager to establish a timeline for the final technical design. The team should draft the design documents, review them with senior engineers, and collaborate with partner teams as needed. This process should also include a testing plan and allocate time for addressing any critical bugs that arise.

Discussions around Operational and Engineering Excellence are vital at this point. The technical team must allocate time for several key activities:

• Documentation: Ensuring that all aspects of the project are well-documented.

• Latency Testing: Evaluating how quickly the system responds under various conditions.

• Security and Privacy: Implementing measures to protect user data and comply with regulations.

• Resiliency Efforts: Focusing on system availability, conducting load testing, and chaos testing to ensure stability under high traffic.

• Operational Metrics Logging: Tracking metrics to assess customer experience and identify failure points.

A critical consideration for the team is determining how much work should be completed upfront before initiating experiments. Certain foundational components—such as security, privacy, availability, and operational metrics—are non-negotiable. Resiliency efforts are especially important for products expected to handle high traffic; however, if a product fails to pass initial experiments, some of this work may not be utilized.

Step 7: Technical Implementation and Testing

In this step, which is primarily managed by the technical team, the Product Manager (PM) must work closely with the Software Development Manager and relevant engineers to ensure alignment on data flows, testing strategies, and experimentation methods. This phase includes comprehensive technical testing to validate that services return accurate data, user experiences render correctly across platforms, and services maintain the expected levels of availability and latency. Effective communication and regular check-ins between the PM and technical team are essential to identify and address any challenges promptly, ultimately contributing to a successful product implementation that meets customer expectations.

Step 8: Customer Flow and User Acceptance Testing (UAT)

In parallel with Step 7, the Product Manager (PM) leads the efforts on customer flow and User Acceptance Testing (UAT). This typically involves conducting a "bug bash," where team members thoroughly navigate the entire user experience by clicking through every element to ensure that the flow functions as intended—not only confirming that the sequence is correct but also assessing latency and fallback experiences. Participants aim to identify any potential issues by attempting to break the experience and retracing their steps as a customer would. Once all issues are documented, they can be prioritized based on their frequency and severity, allowing the team to distinguish between critical fixes needed before experimentation and those that can be addressed after testing but prior to the production launch.

Step 9: Final Fixes and experimentation setup

At this stage, the Product Manager (PM) should have a comprehensive list of prioritized bug fixes along with a detailed experimentation plan. This step focuses on allocating time to implement any final modifications before initiating experimentation. It is crucial to discuss the methodology and rationale for conducting experiments. Generally, running experiments is beneficial because they provide insights that reflect the "will of the customer," allowing customers to influence product development based on their perceived value. Additionally, experiments facilitate incremental attribution, meaning that they measure the impact of changes in a way that accurately assigns credit for customer behavior. While experiments are considered the gold standard for assessing incremental customer actions, it’s important to recognize that they come with costs—sometimes significant ones—and achieving statistically significant and accurate results can be complex. Various biases can affect outcomes, such as triggering issues, customer preferences, or experience-related biases like latency problems in either treatment or control groups. Therefore, consulting with statisticians is essential to ensure the validity of results. In some scenarios, experimentation may not be necessary—such as when a product has already been launched in multiple countries or when you are focused on improving performance metrics like latency.

Step 10: Experimentation, Customer Feedback, and Analysis

In addition to conducting experiments, it’s essential to gather further customer feedback. While the experiment results should indicate whether customers prefer the new experience over the control—assuming proper metrics are in place—logging and analyzing every metric can be both challenging and costly. For instance, in an experiment conducted in the Amazon app that required users to sign in, all metrics suggested a positive outcome; however, customer feedback revealed that users disliked the new experience despite their willingness to comply for access. This discrepancy led to the decision not to launch the new experience. Documenting both experiment results and customer feedback is crucial, as the true failure would be not learning from the process. Even if a new experience isn’t launched, understanding customer preferences provides valuable insights for future product features and programs. As you build your product development cycle, consider key questions that can guide your experimentation efforts, ensuring that you remain focused on customer needs and continuously improve your offerings.

Who owns each step in the process? 

To clarify ownership of each step in the process, a RASCI framework can be developed. This framework specifies who is Responsible for each step, designating a single individual who has the authority to assign tasks and deadlines to others. The person Accountable for a task is responsible for ensuring its completion; in my teams, the roles of Responsible and Accountable often fall to the same individual, although this can be a point of contention since RASCI theory suggests these roles should be separate. It's important to use your judgment based on the specific situation. Supportive individuals contribute to completing tasks, and since each step involves multiple tasks, several people may fulfill this role. Those Consulted are experts—such as Principal Engineers or Senior Designers—who provide feedback before a task is finalized. Lastly, individuals Informed about a task or decision are stakeholders who need to understand the outcomes and adjust their processes accordingly. Typically, I assign an R/A to each step, allowing that individual to determine who else should be involved in completing the task.

What recurring mechanisms do you use to keep the process on track? 

To ensure the process remains on track after Step 6, we establish a working backwards timeline that outlines each key step in the implementation, including significant milestones such as major technical epics (aggregations of features and services that fulfill essential requirements), stakeholder reviews, testing phases, and experimentation. We then distribute a bi-weekly or monthly newsletter to all key stakeholders, providing updates on the status of each milestone. Given that we manage multiple products simultaneously, we also implement a portfolio tracking mechanism that allows the team to identify risks associated with any product at any stage. We conduct bi-weekly roadmap reviews to assess the status of each product and surface any potential risks. If necessary, we schedule follow-up meetings to collaboratively address these risks and ensure projects remain on schedule. Additionally, the technical team engages in parallel processes—such as bi-weekly sprint planning, retrospectives, and daily stand-ups—to facilitate the successful completion of Step 7.

What potential pitfalls could you encounter and how do you mitigate these risks?

Throughout the product development process, various risks can arise, and I want to highlight three common pitfalls along with strategies to mitigate them.

First, not treating data as a product can lead to significant issues. It's essential to recognize three critical types of data: customer data, which tracks engagement; output data, such as financial metrics; and technical operational data that monitors service performance. Product Managers should approach data with the same rigor as the customer experience by defining success criteria and determining the necessary metrics upfront. This includes allocating time for logging data, building aggregation pipelines, and creating dashboards to visualize metrics. By prioritizing data management, teams can avoid confusion when problems arise post-launch.

Second, underestimating coordination costs is a frequent challenge. Teams often struggle to accurately estimate the time required to complete tasks, leading to delays. This risk is amplified when a product depends on inputs from other teams. To mitigate this, it's crucial to identify potential bottlenecks early and maintain open communication channels for quick issue escalation. Ensuring that all parties have complete information can minimize downtime and align expectations.

Lastly, cultures that are averse to bad news can create significant obstacles. A culture where team members feel uncomfortable sharing negative updates can lead to a lack of transparency, often described as a "watermelon" status—green on the outside but red on the inside. To counteract this tendency, leadership must foster an environment that rewards openness about challenges and reinforces the importance of addressing issues head-on. By consistently modeling this behavior and supporting team members in problem-solving, leaders can help build a culture that values honest communication and proactive risk management.