This week I facilitated a product review and thought it might be helpful to share the process I went through and my learnings and experience.
A product review is where you take the time to systematically review what’s happening with a product, use the session as a lessons learned exercise and use the insights to make ongoing improvements to not only the product but also address any cultural or other team issues.
You can use the same process to do a retrospective on a project, project review, or sunset review at the end of a project / product lifecycle.
It’s easy to assume this will happen, but it’s important for all the stakeholders to be involved in the review. After all it’s not just the engineers building the product who will have a valuable perspective. It’s also the sales people, marketing, product managers, and the leadership. The graphic at the top illustrates an important point about what each department is driven by or what they normally produce. The success of a product is having all departments not just understanding the same needs, but delivering in unison and collaboratively as opposed to in isolation.
I find when doing product reviews that you have to ensure everyone knows about the context of the product. Answering questions like:
- What is the product?
- Why was it developed?
- What are the commercials of the product? (E.g. cost of product, revenue generated)
- How long has it been in play for?
- What’s the future of the product?
Those kinds of questions help establish a baseline of knowledge from which everyone can then take part in a more informed review of the product. It also may raise important information that team members may have missed, never known about, or made assumptions about.
The structure of the conversation broadly follows addressing key headings in terms of “What went well” and “What needs more focus”. The headings I used for this review were:
- Communication – between departments, communication tools used, wider comms for awareness to business
- Collaboration – how did collaboration happen?
- Resourcing/delivery – Is the product properly resourced? Do people have the right skills? Is delivery happening against plan?
- Team effectiveness – how well are the team working together? What processes are helpful? Which aren’t?
- Leadership – what’s been the leadership for the product? Have there been conflicting demands? Who has the final say?
- Product direction – was there clarity on the development of the product?
- Tech solution – was the right tech used?
- Client engagement – how well were the clients involved in the product development? What are their thoughts on the product?
Against each heading, we had statements which we then explored further by asking what went well and what needs more focus as highlighted above. The headings need to make sense for the product review, and essentially it’s about allowing for a full discussion about the product so it can be better for the future.
In terms of facilitation, I find it best to be fluid with this kind of session. It’s less about timings and more about using the framework to have a structured discussion. What I find regularly happens is that people go off piste with their discussions. That’s fine as long as it’s focused on lessons learned. If it’s rabbit hole stuff then obviously it’s about managing that conversation and bringing back focus to the product review and the headings.
It can also be easy for key voices to continually be heard. That may not be an issue as often people have multiple points of view. As a facilitator the key is to be mindful of overall contribution and that everyone has a fair chance of being heard and being included. It can be helpful to set out ground rules at the start of the session to help establish agreed ways of interacting and contributing for the review.
The product review process naturally drives towards actions and either continuing the same things or changing them. It’s important to find a useful way to highlight the actions so people know what they should be doing differently moving forward.