Finding Purpose in the Product Review meeting
Depending on your tech org culture, the product review can take many shapes and sizes. Without the mindful guidance from tech leaders, the meeting can easily sway from being a safe haven for valuable product and design feedback to a dreaded, high-stakes evaluation period. I recently started a new job as a product manager at a fantastic company called Teachable. Based on my past PM experiences, I’ve been asked to test drive a product review session with the team, something the company hasn’t done before. This has led me to researching and holding multiple conversations with other colleagues to validate and refine my interpretations of the product review. My documented thoughts and conclusions can hopefully serve as guidance to other PMs, designers and engineers who are deciding on whether to bring the product review into their team.
What is a product review?
To put it simply in my own words, a product review is a weekly or bi-weekly recurring meeting for tech members to get together and share early stages of prioritized projects with their fellow pods/squads in order to gather feedback and validate ideas. Applicable for any MVP, iteration or enhancement.
Length: These meetings should take no longer than one hour.
Attendees: Product managers, designers, tech leads, Product & Engineering Leadership (engineers optional)
NOTE: This is not to be confused with the sprint review defined in the Scrum Dictionary, a design critique, nor the external-facing product reviews in e-commerce.
How is this done in practice?
- Product reviews are generally done after quarterly (or monthly) planning has identified the priority projects/problems for the near future and before designs have been finalized for dev work.
- Product teams submit their projects that they’ll be presenting in advance to the designated facilitator.
- Post its are given to all members to write down any notes as the team cycles through presenting pods/squads.
- For new projects, the product pod’s triad (PM, Designer, Tech Lead) present the problem, hypothesis and approach to solving the problem.
- Supporting artifacts for these reviews include one-pager product briefs, low-fi design mockups and prototypes, research and data, customer feedback, financial performance and more.
- It helps guide audience feedback when the pod/squad has prepared questions.
- Much like a design critique, the review is not for bashing someone else’s work or doing any problem solving or decision-making on behalf of the product pod/squad presenting.
- Tips to audience members: empathize with your presenters, be clear and specific with your feedback, ask clarifying questions, talk about what you think works and where things get confusing, and (if you must) suggest alternative solutions with a grain of salt.
- If the presenting pod/squad decides that they have sufficient feedback to revisit their approach, the team can move onto the next pod.
- After feedback and questions, the team moves onto the next presenting pod/squad. Words of appreciation and praise to the presenters are strongly encouraged.
Why the product review?
I like to think of the product review as the necessary counterpart to sprint demos. To avoid your product/engineering leaders and peers from realizing for the first time what your team is currently building or has already finished (very common) at a demo, the product review is an agile planning checkpoint before the train leaves the station. The review is a standardized way for product teams to share the context behind the problems they’re prioritizing (WHAT and WHY) along with their directional thinking and approach to solving these problems (HOW).
The product review is an agile planning checkpoint before the train leaves the station.
The review should at least involve the executing product teams (represented by the triad of PM, Designer, Tech Lead) and PED Leadership. Additionally, the review extends the helpful feedback beyond just the designs and to the overall approach and strategy to solving the customer problem — ensuring that product messaging is clear and coherent — before communicating these projects with wider audiences (i.e. stakeholders, exec sponsors). This reduces questions further down the road that can potentially disrupt or slow down the product team. Done right (and fully acknowledging the degree of vulnerability required of the sharing teams), the product reviews help to ensure Leadership buy-in and support, tap into peer knowledge, highlight cross-team dependencies, discuss unknowns and risks, and reinforce team camaraderie and support.
Adapting to your team’s culture and needs
Like conducting backlog grooming, there is no definitely exact way to run a product review. Ultimately, the product review is a mechanism to help product teams walk out with increased knowledge, additional perspectives and checked biases in order to build better solutions for meaningful customer problems. If any part (or the entire forum in general) is making things difficult or adding additional work and stress to your teams, I’d suggest making some adjustments that fit with how your tech org likes to interact and operate with one another, or to hold off on product reviews entirely. Product reviews should be a casual, safe place for all attendees and presenters — a time to check our egos and biases and empathize with one another and the customer.
It’s fair to say that product reviews are not for all companies, and there are certainly other agile practices out there to provide transparency, solicit feedback and gain alignment. If the product review is new to you and your team gives it a shot, please don’t hesitate to let me know how it goes. I’d love to hear what works and doesn’t work for other teams. Good luck and happy building!
Did you like this post? Follow me now to see more stores like this. I constantly seek to learn, so comments and feedback always welcome.
