Product management foundations
This year I invested in a Reforge membership, which, at > €2,000 per year is not a small one. Needless to say, I had high expectations.
So far, those expectations have been met and slightly exceeded.
I started off by taking the ‘Product Management Foundations’ course. Having finished it, I want to share my key takeaways.
Note that this post only covers the surface of this course. If you want to dig deeper and also access all the Reforge templates and the wonderful Slack community, you may consider becoming a member yourself.
This course covers the core of product management by focusing on features and breaking down the process into 4 phases: feature opportunity validation, feature design, feature development, and feature launch & iteration.
Note: It’s very SaaS-focused program. If you are, like me, working in different context, you need to think about these lessons contextually.
Step 1: Feature opportunity validation
The first step to building great features is opportunity validation. Before starting any design & development work, PMs need decide what to build and critically validate whether an opportunity will bring value to the user and the business.
An opportunity must fulfill 3 criteria to be worth pursuing:
1. Strategic fit
It needs to align with the company’s strategy and goals. Think of this like a chain:
Mission & vision
Company strategy
Product strategy
Team goals
2. User value
It needs to solve a relevant problem for the target user(s). Think about:
Who is the user?
What’s the problem we’re trying to solve for them?
Why is that problem important for the user?
What does success look like for the user, and how will we measure it?
3. Business value
It needs to create value for the company. Consider:
What does success look like for the business?
How does success for this project tie to the team and product goals?
Who are the key stakeholders and how do you align with them?
Great PMs validate each component of each opportunity and communicates this to build alignment across the company.
This should be captured in the PRD (Product Requirements Document) at the start of the project. The PRD should describe all aspects of a new idea required or desired to make its realization a success. The structure of the PRD will depend on your needs. This template can help with inspiration.
How to validate an opportunity
Conduct a manager briefing: gather strategic info about the project from your manager and align on expectations.
Refine the user value by talking to users to gain insights into how they think and feel.
Refine the business value by doing a funnel analysis:
Define a funnel by connecting a start and end point, then fill in the key steps in between
Calculate the problem magnitude by setting a baseline and identifying the largest problem areas
Evaluate business value by leveraging proxy metrics to create (directionally correct) estimates
Communicate the opportunity and learnings back to stakeholders. This can be done through a review meeting where the goal is to stress-test your hypotheses, get feedback and buy-in on the direction.
Step 2: Feature design
The second step is feature design which is the journey from problem to solution. It’s the process of defining how we want to solve the user problem that our feature is intended to solve.
We can think of this journey in 3 steps
1. Constrained divergence
The first step is to define constraints, brainstorm ideas within those constraints and then cluster the ideas that emerge.
2. Iterative convergence
Once we have a set of clustered solution ideas, we need to prioritize them and test the top ideas by building simple prototypes and picking the top one based on the test results.
3. Approval & alignment
Once we have converged on a final prototype, approval is needed from the key stakeholders and the PM should align with the core team before creating the final design and moving into the development phase. This can be done through a design review meeting followed by a project kickoff. In between, it’s important to make sure the PRD is kept up to date.
Step 3: Feature development
Once a feature is designed, it has to be developed. The feature development phase can be separated in 4 parts.
1. Cross-functional dependency management
PMs need to track and be on top of all activities requiring support from another team before a feature can be launched.
Hence, the first step is to know who your counterparts are. This will vary for every company but generally we can divide counterparts into:
Engineering, Product, Design (EPD): develops or improves products
Go-To-Market (GTM): gets products into hands of users / customers
General & Admin (G&A): HR, Finance, Legal etc.
Operations (Ops): support users / customers when they have questions
PMs don’t do any development so their key responsibilities in this phase are:
Defining milestones
Running the execution cycle
Managing risk
2. Preparation
Prep work will depend on the feature your developing and the structure of your team & org.
Generally, it involves a version of the following:
Defining milestones: separating a project into smaller chunks of work to complete sequentially (owned by PM)
Writing technical specs: outlining what needs to be developed (owned by technical lead)
Estimation: evaluating the project in terms of required resources against business impact (owned by technical lead)
Staffing: allocating resources to project (owned by engineering manager)
How to define good milestones
Great milestones help identify risks early, ensure value delivery, and allow for effective sequencing of work.
Evaluating risk: When defining milestones, evaluate risk by thinking about whether users can find the feature (discoverability risk), use it (usability risk), and whether it actually solves the user problem (utility risk). Setting milestones that mitigate these risks helps ensure that value is generated for the business.
Delivering value: Think about when users and the business can expect value from the project. The milestones PMs set will for example determine if the feature is launched incrementally or only to a sub-segment of users at first.
Categorizing dependencies: Categorize all dependencies (should be captured in the PRD) in order to sequence work effectively into a realistic plan.
There are 5 categories of dependencies:
Input-output: one task has to be completed before another one can begin.
Integrations: work that can be done in parallel but needs to come together at the end.
Third-party requirements: when utilizing a third-party partner, requirements from their end need to be taken into account.
Resources: availability of talent, teams, or tools over certain periods of time.
Important dates: holidays, important meetings, related launch dates etc.
3. Execution
Once the prep work is done, development begins. PMs can see this in 3 sub-phases:
Kickoff: align on context, priorities, staff assignment and commitments.
Building: development work during which the PMs role is to eliminate bottlenecks to keep the project on track, manage risk by proactively dealing with product or strategy changes, and communicate with stakeholders effectively.
Retro: reflect on the work done and what can be improved for next time.
When it comes to stakeholder communication, PM should not simply relay info but intelligently route it. That entails evaluating 3 things before passing the info along:
Importance: does it impact the team’s focus or pace?
Correctness: does it represent fact or opinion?
Resolution: can it be resolved without the help of the team? If not, what potential solutions exist to resolve it?
4. Risk management
Risk management is the final core responsibility PMs need to master and it needs to be done throughout the feature development phase.
Managing risk entails dealing with changes and making decisions based on that. A lot can change, from delivery dates to scope to strategy. PMs need to be able to play both good offense and defense. To be good at offense, regular check-ins are important to diagnose changes early and understanding the tradeoffs between scope, time and resources is key to make good decisions. As such, good defense means knowing when to push back and when to make those tradeoff decisions.
Step 4: Feature launch & iteration
The final step is to launch what has been developed and to iterate based on learnings.
1. Launch coordination
When coordinating the launch, PMs should think about launch learnings and launch readiness.
On the one hand, to generate the right learnings, the feature launch should answer the following:
Did the feature create value for the business and users?
Is anything preventing the feature from achieving its goals?
One way to go about this is to launch the feature in stages, i.e., rolling our the partial or complete feature to a user population that can be increased over time. Doing this allows you to balance risk and learning.
On the other hand, to ensure launch readiness, PMs should work with a launch master checklist detailing out all the tasks that need to be completed (and by whom) to ensure a successful launch.
2. Performance evaluation
Performance evaluation ties back to the feature opportunity validation stage where we defined the user value and business value goals.
PMs need to track those goals, measure the impact, and make iteration decisions according to the results.
Optimize: delivers some value but has room for improvement
Redesign: missed the mark
Roll back: created problems and negatively impacted downstream metrics
Move on: doing exactly what was expected, additional changes aren’t worth the effort
3. Post-launch communication
The results then need to communicated with the different stakeholder audiences:
Team that worked on the feature
Cross-functional leaders and teams affiliated with the project
Individuals across the broader company
Users impacted by the feature
The key of post-launch communications is to close the loop while informing collective learning and improving iteration decisions.
The project retrospective is the primary tools for PMs to communicate this with the two first audiences. In this meeting, you want to set the context, present the performance and walk through the iteration plan and the rational behind it.
If the project went well, PMs should communicate about it throughout the company. This can be done via Slack or whatever platform your company uses.
If users are impacted by the feature, external communications are also needed. Here PMs should align with the customer-facing teams to ensure users are informed (via in-product notifications, emails or other channels).
Conclusion
It’s been a very helpful course where I have been able to get a holistic overview of a PMs responsibilities, best practices, as well as valuable tips and mental models to apply to my own work at EVBox.
What I like about Reforge is that the programs are created by industry experts based on their experience. This makes the programs very practical in nature and easy to follow along while maintaining a high level of detail.
The Reforge platform is also very nicely built as you would expect for the membership price you pay and the Slack community can be very useful to get ideas from peers across the world. Highly recommended! I’m now looking forward to taking the Advanced course and joining the next live cohort.
