tl;dr:

Your product team will need to keep its work visible to stakeholders outside the team. If your product team is doing both discovery and delivery, you’ll need to review both those things. If you’re new to dual-tracking, use this recipe as a starting point.

Stakeholder Product Review Recipe

Purpose: Keep your product’s health, your discovery work, and your development work visible to the whole organization.

In Scrum, sometimes this is called a Sprint Demo. Some teams call this meeting a Showcase. You might know this as the thing your team needs to do every few weeks to keep your work visible to the whole organization.

There are lots of others in the organization who are likely interested in what you’re working on, and what you’ve accomplished. You’ll need to make this work visible to them. Unlike your team, these others probably don’t know the details of what you chose to build, nor where they fit into the big picture. So, you’ll need to plan on connecting what you accomplished and learned back to the product. This is also an excellent opportunity to learn from them, and to get their support.

Do use this review to show the outcome of your efforts. Stakeholders should care about that.

Don’t use this meeting as a place for stakeholders to criticize your team’s planning or the way your team works. That’s your team’s responsibility to manage.

Who: Invite everyone who’s interested.

This is a big public review. Anyone interested is welcome. Make sure your whole team is there. Seeing others’ reactions to what they’ve done, either positive or negative, helps remind them that what they’re doing matters.

Some organizations combine multiple product teams’ reviews into one larger stakeholder review. This cuts down on the number of meetings stakeholders need to attend routinely.

How long: plan for 30-90 minutes. This review should be faster, and at a higher level than your teams’ product reviews.

Bring food. I promise everyone will like what you have to say when they’re loaded up with carbohydrates. Even bad news goes down easier with sweets.

1.     Review your current product’s health

If your team is responsible for an existing product or product area, you’ll need to review how that product is doing. If you don’t currently have something in production that users are using, skip this part. Hopefully you’ll get something shipped soon.

When reviewing your product or product area’s health, make sure you connect what your focusing on to the metrics that matter for the organization.

Discuss your product’s Key Metrics, or KPIs:

  • What 2-4 metrics are you currently paying attention to about your product or product area and what are their values?
  • How do those metrics connect to those that impact the business such as revenue, cost savings, or retention?
  • How do they compare to what you expected? To the last cycle? To last month? To last year?
  • What should you celebrate? What should you be watching out for?

Discuss any subjective data on your product:

  • Quotes from customers about your current product that came from discovery work, customer surveys, or customer support

2.     Review discovery work

Reviewing discovery is critical. The best time to get feedback from stakeholders is before you’ve invested lots of time building something. If you’re showing real lessons learned from putting software in front of customers and users, they’ll value learning what their customers actually think. Often, the only thing that trumps an executive opinion is a cold, hard fact.

  • Discuss each opportunity you’ve taken up briefly: whom it’s for, why we’re building it, and the outcomes you expect if it’s successful. Make sure you tie that opportunity back to the value proposition for your organization.
  • Discuss your hypothesis at the beginning of the cycle and how it changed during the cycle:
    • What were you wrong about? And, what tests lead you to believe you were?
    • What were surprising new facts that changed your hypotheses?
    • What parts of your hypotheses were strengthened?
  • Discuss and show the work you’ve done to understand the problem and the solution. This may include things like proto-personas, story maps, or UI design.
  • Discuss and show prototypes and experiments you’ve run. Discuss what your customers and users are saying about your solution. If you have experiments that you deployed to a limited set of users, discuss any data you were able to get from measuring their use.

Notice that you’re not explicitly discussing the time budgeted for discovery or reflecting on your learning velocity. Your team owns the quality of its planning and its work. You’ll certainly answer questions and share how you did thing when asked. But, their no need to open yourselves up to micromanagement.

3.     Review delivery work

It’s been my experience that stakeholders are focused on what and when you’ll release to customers and users. They should be because it’s not until after you release a viable solution that you’ll be able to observe real outcomes and get real value. They’ll be interested in progress made toward that goal.

Review the delivery work you’ve completed at a solution-by-solution level. Think of the solution as the big rock that’s more relevant to stakeholders. The feature or capability that you’ll release. Some using story jargon may think of this as an epic.

For each solution:

  • Review the solution’s target customers, users, and outcomes. It’s good to remember why we’re building this and what success means.
  • Discuss and show the results of stories built for each solution. Stakeholders will offer feedback. Hopefully if they had a chance to give feedback when you were doing discovery work, the feedback at this point will be “Yup, that still looks good.”
  • Discuss the stories holistically. If you’re using a development strategy like the Mona Lisa strategy explained in User Story Mapping Chapter 4, you’ll need to explain to them why the software looks incomplete at this point. Remember that they may want to see a square inch of a complete portrait, and not the software equivalent of a sketch of the whole canvas.
  • Share with them your progress toward getting this solution releasable. How much work is left? What have you learned while building the solution that will affect its successful delivery?

Be prepared to write stories for new opportunities, or for changes you’ll need to make.

It’s possible that others in the room unfamiliar with what you’re building and why, will suggest things that aren’t a good idea. Respectfully and gently remind them of the target audience and outcome for the solution, and why what they’re suggesting might be a great idea, but doesn’t support the outcome you’re currently focused on.

Notice that you didn’t discuss your team’s development velocity and how that relates to what you’d planned on. Keeping your commitments is your team’s responsibility. Use your team’s review and planning meetings to discuss how you’ll meet those commitments.

Keep your work visible to everyone in your company. Help them be excited about what you’re doing and learning.