When scaling bebop pre- and post-acquisition by Google, we developed an approach to Product Review Meetings that made them productive discussion forums. This series details what we learned.

One of the most frustrating yet common experiences as a PM or product leader is what I call the “swoop and poop.”

It’s when you’ve been driving a project or new strategy, and seemingly out of nowhere, someone with influence in the company swoops in and metaphorically “poops” all over your work – raising questions or pointing out issues that halt or even reverse all the progress to date.

On the one hand, it’s important to have a culture where it’s okay to ask difficult questions in the spirit of getting to the best answers for customers and the business. But when these get surfaced late in the game, it’s painful and demoralizing for the team driving the work.

The solution is not to avoid the questions, but rather to suss them out and address them as early as possible.

When scaling bebop both pre- and post-acquisition by Google, we created a Product Review Meeting (PRM) cadence that helped surface difficult questions early in the project lifecycle. This enabled the team driving the project to address misalignment and adjust early on – while the cost of big changes in direction was still relatively low.

In this blog, I introduce the overall PRM cadence. In subsequent blogs, I will deep dive on each type of PRM meeting and what makes for a successful instance of the meeting at that stage.

Define the Project Lifecycle

Before you can start adding PRMs to your process, it’s important to align on the “lifecycle” any major project goes through from concept all the way through shipped.

I find it valuable to map project definition and development against the key stages of a human-centered design approach. This has a lot of implications (and if you want to read more on design thinking, there are many good articles such as this one and this one). But at a high level, the critical implication for the project lifecycle is that each (major) project undergoes a series of iterative cycles during which divergence is a valuable part of the process before converging on a path forward.

More specifically, there are three divergent cycles to consider for a given project:

1. Problem context: This is all about “designing the right thing.” It includes empathizing with the user through deep research to identify what problems exist for them (diverge). Then it requires narrowing to define which problem(s) to solve now (converge).
2. Solution context: This is about “designing and building the thing right.” It starts with ideating on potential solutions given the problem you’ve decided to solve (diverge). Then teams can prototype, test and build to deliver the solution (converge).
3. Learning: Projects don’t stop once they get shipped. There is an ongoing need to “launch and iterate.” Measuring and monitoring post-launch drives new learnings and thus new problems to solve (diverge). As you identify new problems worth solving (converge), you go back to step 2 to drive new solutions.

Map Different PRMs to Different Stages

One of the most important evolutions we made to PRMs – a change that proved necessary to make them an effective discussion forum – was to define different types of PRMs for the different stages of the project.

The most frustrating and unproductive product reviews I’ve seen usually become that way because there is misalignment between the type of feedback being provided and where the team thinks they are in the project lifecycle. For example, getting feedback on what problem to solve when you’ve already started ideating and narrowing solutions is really difficult.

So we created PRMs #1 - 4 mapped against the project lifecycle:

• PRM #1 is about aligning on the problem to solve
• PRM #2 is about exploring critical user journeys and low-fidelity UX
• PRM #3 is about finalizing higher fidelity, dev-ready designs
• PRM #4 is about reviewing metrics post-launch to identify (still) unmet needs

We actually named each meeting based on whether it was a PRM #1, #2, #3, or #4. This helped guide attendees on what type of feedback the team was seeking given the stage of the project.

It’s worth noting that you do not need to run every project through this exact sequence of meetings. Instead, adjust the PRM cadence based on the size and shape of the project.

For example, if it’s a straightforward and well-understood problem, you may combine PRM #1 and PRM #2 into a single meeting, or perhaps skip PRM #2 and go straight from PRM #1 to PRM #3. However, if it’s an entirely new strategic direction or product line, it may make sense to do multiple PRM #1 meetings just to align on the problem context.

The key is to be clear about where you are in the project lifecycle during each review meeting.

Reframe “Success” for Project Owners

Another critical piece of making PRMs successful was to reframe success criteria for the presenter from “aligning on answers” to “identifying questions that still need answers.”

Early in my career, I thought success was convincing others in the room of my point of view. I felt the need to leave each meeting I ran with clarity on the decisions we had reached.

Over time, I began to realize that success was rooting out feedback, skepticism, and insights from others as early as possible. I needed to understand the concerns being raised – or in some cases not being explicitly voiced – so I could take them into account going forward.

Sometimes, this meant I would change my perspective. Other times, it meant I would think deeply about the feedback and conclude that my initial perspective was sound, but something was missing in how I was explaining it. Either way, the feedback made my thinking stronger.

This evolution in the definition of success makes PRMs much more effective. It relieves the pressure to leave each meeting having answered or resolved all disagreements. Presenters don’t need to build consensus during the meeting. Rather, they need to understand what questions are being raised and align on the next steps to address those questions – a much easier task than providing answers on the spot.

This provides an overview of the PRM cadence and best practices that we evolved to over the course of scaling bebop, getting acquired by Google, and then operating as a product area within Google Cloud. I’ve also seen it work well at other fast-paced software companies.

In subsequent blogs, I will deep dive into effective tactics for each type of PRM meeting.

‍