Product Management Framework: A Step-by-Step Approach
Product management is a challenging endeavor, often feeling like a jigsaw puzzle with countless pieces to remember and fit together. At the heart of it, context is everything: the competitive and market landscape is in perpetual motion, and just as you think you've grasped the current state, it shifts again. Consumer pain points, needs, and expectations are not static; they evolve, sometimes subtly and at other times dramatically. Add to that the fact that business goals can pivot based on a myriad of factors, and you're in for a ride. The very nature of agile methodologies demands our constant attention and adaptation, ensuring products remain relevant and impactful.
I recall the early days of my product management career, feeling overwhelmed by the sheer volume of information and responsibilities. I remember sitting in my first product management course and being introduced to a galaxy of concepts like product discovery, customer interviews, opportunity hypothesis, and prioritization frameworks. When a classmate, equally overwhelmed, asked the instructor how all these concepts fit together, the response was a nonchalant "Well, it depends." It was a stark reminder that every situation in product management is unique, making a one-size-fits-all approach elusive.
However, amidst this complexity, it's essential to develop a framework to guide our decisions and actions. In the face of real-world challenges, the most meticulously crafted plans are likely to encounter unforeseen variables and adjustments, but having a plan is valuable because it helps you prepare, consider various options, and adapt as needed. In this blog post, I'll share a 9-step product management framework which is a great place to start.
Step 1: Understand the Business Context
Whether it’s a product feature or a whole new product, the first step in making good product decisions is to understand the broader business context, including the market and other factors that will influence the success of a product. My preferred framework is 5 C’s:
Company - This includes the company vision, other products, strengths, capabilities, and resources. We want to understand how the proposed product or feature fits with our company vision and other offerings, and how our company's skills and resources align with the product's development and go-to-market requirements.
Customers - This includes needs, preferences, behaviors, and pain points. Understanding and empathizing with our customers is essential to generating actionable insights and tailoring our product to their needs.
Competitors - We want to understand the competitive landscape, including identifying direct and indirect competitors, analyzing their strengths and weaknesses, and determining how our product can differentiate itself in the market.
Collaborators - We want to identify partners, suppliers, and any external stakeholders who contribute to our product's development or distribution. By building strong relationships with collaborators we can help streamline processes and ensure the product's success.
Context - including the broader market and industry conditions that impact our product. Factors like market trends, regulatory environment, economic conditions, and technological advancements can significantly influence how our product will be received.
Understanding the business context should be the number one priority for new product managers, or when starting in a new role. Experienced product managers need to keep an eye on how the business context changes over time.
While it may not be necessary to do a deep dive into the business context for every product feature, it is critically important to keep the business and product objectives top of mind and regularly confirm that product decisions support these objectives.
Step 2: Understand the Product
This step is particularly relevant when working on existing products, or on new products which are tied in some way to another offering.
We need a clear understanding of the product’s value proposition, target audience, existing features, integrations, key metrics, user feedback, and anything else that impacts our ability to make strategically sound product decisions.
For existing products, these things should already be somewhat understood, but look for opportunities to improve your understanding. For clean-sheet products, we can build this understanding as we go through the product discovery and development process.
Step 3: Problem Research, Validation, and Definition
This step aims to figure out what problem we want to solve and for whom, validate the problem exists (and someone cares about it), and then define it in a problem statement.
Ideas can come from anywhere, such as user interviews, customer feedback, or conversations with a stranger at a coffee shop. We then need to do further research to understand our users, narrow down on a problem we are interested in solving, and define the persona we are solving it for.
Next, we need to do additional research to validate that the problem exists, determine its impact (scope and magnitude), and find out how the problem is being solved now.
Finally, we need to capture the problem in the form of a problem statement. There are a few approaches here, but I usually use a format that looks something like this:
As [user persona],
I’m trying to [goal],
so that [expected outcome],
but [problem],
which makes me feel [emotion].
The problem is affecting [impact].
Key stakeholders impacted by this problem are [stakeholders].
Step 4: Opportunity Hypothesis
Now that we have a well-defined problem statement we can craft an opportunity hypothesis that articulates how solving the problem will meet product and business objectives. There are many problems in the world worth solving, and the opportunity hypothesis is crucial to explain how solving the problem is good for business. Below is a template that I like to use. At this stage, the proposed solution won’t be fully flushed out, and that’s okay.
For [user persona],
We have observed that [problem],
resulting in [impact].
We believe that by [proposed solution],
users will experience [value proposition].
We will know this is successful when [success metrics].
To validate this opportunity, we will [validation plan],
and expect to gather sufficient data within [timeframe].
This opportunity aligns with our overall [strategy].
The relevant business or product objectives are [business or product objectives]
Step 5: Solution Ideation
Once we have identified and validated our opportunity we can put a finer point on potential solutions. Ideas can come from anywhere, including the internal team, users, competitors, similar products, and other sources.
Ideas should be compiled from various sources and then discussed as a team to evaluate their pros, cons, and feasibility. Defining a user story is a great way to keep the discussion focused on the user's needs and behaviors.
One or more solutions can be selected for validation.
Step 6: Solution Validation
Selected solutions must be validated to ensure they address the problem effectively. We can validate solutions in several ways, including working prototypes, concierge prototypes, landing pages, etc. Generally, high-risk/high-cost solutions demand more rigorous validation than low-risk/low-cost solutions. Mock-ups, prototypes, and user feedback can be invaluable at this stage.
The results of the validation step should be fed back into the solution ideation until we have identified a solution we want to build. It’s not uncommon for teams to go through multiple rounds of validation as they narrow down the solution they want to build. This is particularly the case for machine learning and other high-risk projects.
Step 7: Feature/Product MVP Definition
Next, we need to define the feature or product minimum viable product (MVP). I like to define features using epics. My epics include a description, product, design and technical requirements, acceptance criteria, success metrics, and an estimate.
I like to define product MVPs using a Product Requirements Document (PRD). My PRDs include the problem, product purpose, user personas, success metrics, value proposition, features in, features out, designs and mockups, a press release, and an imaginary product review, among other elements.
Step 8: Feature Prioritization
Generally, features, bug fixes, and other development tasks should be prioritized based on their expected business value and estimated level of effort to build. High-value low-effort features should be prioritized over high-value high-effort features. Low-value high-effort features probably shouldn’t be built at all. Looking at reach, impact, confidence, and effort can help determine business value and estimate ROI.
One additional thing to consider is the composition of upcoming releases. Including both new features and bug fixes in each release allows customers to feel like their frustrations are being addressed and look forward to something new.
Generally, for new features, I like to use the RICE prioritization framework. In this framework, we prioritize features based on their expected reach, potential impact, the effort required, and our confidence in the estimate. We assign each component a numerical value and calculate a RICE score. Features with higher RICE scores are prioritized over those with lower scores.
Step 9: Measuring Success
Establishing and monitoring Key Performance Indicators (KPIs) is essential to measure any feature or product’s success. We need to select success metrics that serve as effective indicators of how well the feature or product is meeting its goals. For instance, using churn to track the impact on customer retention. KPIs should also be measured against a relevant benchmark. The monitoring period will depend on the type of KPI, the goals, and the level of granularity required for decision-making.
In addition to quantitative KPIs, I like to collect qualitative data from users on how they like the feature and how it is being used
If we are not getting the desired results we will need to adapt to meet our objectives. If this is the case, we will probably need to collect additional quantitative and qualitative data to understand why our feature is not performing as expected and figure out what changes to make.
