Why it's important to run regular stakeholder reviews, and a helpful structure
The Importance of Reviews
Regular reviews are vital to successful product teams. Reviews are often undervalued, but they are vital to ensuring the team can deliver high-quality software aligned with customer needs and the organisation’s strategy.
Without regular stakeholder engagement, team drift is inevitable. Symptoms of team drift include:
- Unproductive meetings, which are often rescheduled or cancelled
- Lack of team clarity of purpose, leading to duplication of effort or rework
- Unresolved interpersonal conflict
- Lack of context, so the team doesn't understand what success looks like
- Poor stakeholder engagement, leading to loss of reputation or purpose
A regular, well-structured review can help to avoid team drift.
Why Bother?
In a world of already-stacked calendars, how do you justify taking more time from people's days?
In short, the payback is huge.
As well as preventing team drift, reviews enable teams to:
- Stay aligned with the company mission
- Remain focused on delivering the best outcomes for their customers
- Ensure stakeholders are bought in to the work of the team
Why Is It Hard?
Teams sometimes struggle with reviews for a variety of reasons.
Workflow
Teams that follow Scrum will generally do a Sprint Review at the end of every sprint. Teams following other frameworks, such as Kanban, may not understand the value of regular reviews. I have seen such teams struggle without a regular review ceremony to punctuate their progress. It can feel like the team is making endless effort but little headway. Adding a regular review enables the team to observe and celebrate its progress.
Confidence
If a team is drifting, it is often unsure of its direction, or suffering from a lack of psychological safety. If there’s a lack of psychological safety in the organisation, and the team is constantly criticised or belittled by stakeholders, then the team is likely to withdraw and become nervous about drawing stakeholder attention. This ironically only makes things worse.
If there’s a lack of psychological safety within the team, the leadership of the team will need to invest time in building trust and creating an environment where people feel it is safe to express themselves.
You can do this by focusing on:
- performance over personality
- role-modelling vulnerability
- enabling constructive and respectful conflict
Stakeholder Engagement
The counterpoint to confidence is when stakeholders are not sufficiently engaged with the team and reviews don’t happen because of a perceived lack of interest or support.
If the problem lies with stakeholders, team leadership should work with them by:
- asking for feedback
- gaining the stakeholders' perspective on the team's value
- listening to their concerns without judgement
They can then work with the stakeholders to re-engage them with the progress of the team, and to ensure that concerns can be shared without stakeholders getting frustrated or the team feeling threatened.
Structure
Holding reviews is no guarantee that you are having good reviews. It’s important to have a cohesive structure that engages the attendees to the review.
How to Conduct Effective Reviews
A well-structured review enables stakeholders and the team to inspect the work being done and to ensure the team remains aligned and focused on its mission. By presenting information and asking appropriate questions, the team builds confidence in itself and with its stakeholders around the solutions it is creating.
Preparation
It’s worth putting in the time to prepare for each review.
As well as ensuring that you know who is speaking, try to anticipate some of the questions and challenges that will come up. Be prepared to mediate discussion, and to prevent ‘accidental influence’ where team members may react to stakeholder feedback by pivoting immediately to address concerns. The better course of action may be to complete the work they are doing before accounting for the issues raised. It can be useful to invoke the mantra to ‘stop starting, start finishing.’ It’s good to let discussions unfold but beware getting lost in the weeds. If things are getting too detailed or off-track, be ready to schedule a follow-up meeting with the interested parties and move on.
Create an agenda with running order. I follow the PROUD acronym for structuring my agenda (Progress Review, Outcomes, Updates, Demos). This creates a compelling structure for the meeting, enables you to notify who will be speaking in advance, and ensure you invite the most interested parties.
Let's step through each of the elements in turn.
1. Progress Review
This is where most reviews begin and end, but it should just be the beginning. Giving an update on the work that it has been doing since the last review enables the team to set context and reiterate the problems that it is solving for the organisation. This sets the scene for the rest of the review, which will culminate in the demonstration of completed work.
The Progress Review includes the value-adding activities of the team since the last review. It could include a summary of a recent design workshop, a discussion of some of the challenges the team has encountered, a consideration of some functionality the team is developing but is not yet ready to demo, or even an update on work being done to clarify dependencies with another team.
Invite stakeholders to interrogate the work that has been done, encouraging open dialogue between them and the team.
Sample Questions to Ask
- What have you learned?
- What surprised you?
- How does this help the team accomplish its goals?
- How can the stakeholders help?
What to Watch Out For
- Accidental influence
- Debates disappearing into the weeds
2. Outcomes
Next, the team shares data on the performance of the software it has released. The Product Manager leads this section of the meeting. They update the stakeholders on the customer outcomes that have resulted from the most recently released functionality. This could be based on usage data, e.g. a user conversion metric, or it could be qualitative feedback on something like ease of use. The important thing is that it’s clear that data is informing the team as to how they measure up against the hypothesis they had when they decided to prioritise and release this particular increment of software. This should also inform debates about upcoming work for the team.
Usage data is reviewed with stakeholders and inspected. If the underlying hypothesis is not proven, i.e. the functionality has not had the desired impact, this is a chance for the team and stakeholders to discuss this, understand what has happened, and create fresh hypotheses or formulate new possibilities for the product. The facilitator should watch out for stakeholders playing politics or the intrusion of unfounded opinions. The data should speak for itself as the outcomes of the software delivered are measured against the hypotheses created when the work was formulated.
Sample Questions to Ask
- Is the marketing message and spend correctly targeted?
- What is driving adoption in some customers?
- How do we get/remain on target?
- Why did(n't) we meet our expectations?
- What else does the data tell us?
What to Watch Out For
- Opinions overruling data
- Politics interrupting honest interrogation of the data
3. Updates
It’s easy to confuse the idea of Updates with the Progress Review. However, the scope of Updates is significantly wider. The purpose of this section of the review is to ensure that the team remains aligned with the desired customer outcomes of the organisation and its strategy.
The team provides updates on what it has learned from its customer and market research. If the team is getting feedback that it needs to reset its priorities, this can be debated with the stakeholders. For their part, the stakeholders can share any strategic updates from the organisation that may impact the team
This should be a reasonably open debate (watch out for the timebox!). Where the team has feedback to share, this is presented to the stakeholders.
Sample Questions to Ask
- Have the companies priorities changed?
- Have we learned something that suggests we should pivot?
- Is the organisation on track to meet its wider objectives?
- Do our core assumptions still hold?
- Which of our hypotheses should we test next?
- Are there company pivots happening that may impact the team?
What to Watch Out For
- Irrelevant information impacting the team
4. Demos
Finishing up, the team presents any completed work it has ready. This may or may not have been released to production. By demonstrating the work and functionality they’ve built, team members build credibility and confidence with stakeholders. It’s always fun to show working software, and it also gives them a chance to restate their driving hypothesis.
It also gives customers and stakeholders the opportunity to provide early feedback. Quite often, a usability or accessibility issue will be raised here, giving the team the chance to review the functionality before it is released. As with the Progress Review section, it’s important to listen to stakeholder feedback, but not to uncritically respond to it.
The team members that built or is building the functionality presents it to the stakeholders, confirming the hypotheses being tested, when the software was/will be released, and next steps.
Sample Questions to Ask
- Who is this for?
- What are we trying to learn?
- How does this address our most important concerns?
- How confident are we of problem-solution fit?
What to Watch Out For
- Off-topic feedback
- Misunderstandings of the hypothesis the team is testing
Running the Review
I suggest the following ground rules for running a good review.
Credit Where Credit Is Due
The people who do the work present their work. This gives the team members valuable exposure and a chance to hone their communication and presentation skills.
Go Broad...
Teams should welcome a broad audience to their reviews. As well as having people further up the chain of command, it’s useful to pull in people from across the organisation. Cast your net wide. Include Support, Customer Service Managers (CSMs), Product Marketing, and other software development teams impacted by your work.
...But Not Too Far
However, it’s important to make sure that the people attending have a reason to be there. There is no benefit to presenteeism or disengaged attendees. Beyond the immediate blast radius, you can invite guest attendees for occasional reviews, especially where the team is working on something of interest to them. It can also be worth inviting customers on occasion, especially where the team is working on something that a particular customer has highlighted as being of keen interest. It’s a good idea to record the reviews and share the video widely afterward, so that more distant stakeholders can catch up with the team’s progress at their leisure.
Cadence
I like to have fortnightly reviews, but this may not be feasible for all teams. The team should decide on its best review cadence. The cadence is less important than them happening regularly and having the correct focus. Keep them regularly scheduled for months ahead so that people reserve their time and routinely attend. Moving meetings or last-minute scheduling should be avoided at all costs.
Conversation Over Presentation
The review should be a conversation, not a presentation. While some presentation is required and the team needs to prepare accordingly, you want to avoid Death by Powerpoint. Team members should practice their presentations in advance, but frame them so that they are inviting comment and questions.
Queries and challenges from attendees are not just welcomed, but encouraged. The facilitator for the meeting should invite questions from stakeholders. Observe people’s body language and if you see someone react to anything in the presentation, ask them about it. Don’t lose sight of the review’s timeboxes. The meeting needs to remain focused so that it is a valuable use of people’s time. I find that 45 to 60 minutes is usually the ideal amount of time, encouraging the team to focus on highlights and have a debate without getting bogged down in details.
In Summary
| Good Review | Bad Review |
|---|---|
| Agenda with timeboxes | No agenda |
| Presentation inviting conversation | Death by Powerpoint |
| Multiple presenters, single facilitator | Single presenter |
| Customer value foregrounded | Internal/team focus only |
| Opportunity for alignment | No discussion of wider concerns |
| High psychological safety | Discussion limited by fear |
| Regular cadence, scheduled well in advance | Irregular, chaotic scheduling |
Conclusion
As well as giving you the chance to gather feedback, a well-structured review can energise the team and ensure that the team remains focused on the right outcomes.
Regular reviews keep the team connected to their stakeholders. By following the PROUD formula, they can maximise the use of the time, building credibility and relationships that will power their progress over time.