The 4 Principles of LinkedIn’s Product Review Meetings

Product Review Template

Settings

Explore

The 4 Principles of LinkedIn’s Product Review Meetings

How the LinkedIn SVP of Product re-designed Google's famous product strategy meeting

Deep Nishar

At LinkedIn, I had the privilege of serving as the SVP of Products and User Experience. My primary professional objective was to build insanely brilliant and simple products that change people’s lives. And when I joined LinkedIn in 2009, I brought some of the best practices from Google, including one I eventually put my own spin on: the Google Product Strategy Session (GPS).

If it was a Tuesday afternoon at Google, several teams would likely be sitting on couches outside a large conference room, waiting their turn to pitch an idea or propose a product plan to Eric, Larry and Sergey. If you were slotted towards the end of the afternoon, there would sometimes only be five minutes to present a 15 minute deck. Teams would sometimes walk out of the room without a clear and conclusive understanding of next steps and action items. This necessitated a debrief with a senior product executive who could translate the founder’s comments for the team.

As a ritual, the GPS had a lot of positive impact on the team. It gave every product team exposure to the founders’ thinking about their product area and was an excellent learning tool. However, it could also feel ambiguous, rushed and inconclusive at times. When I got to LinkedIn, I was ready to deploy my own version of the GPS, with two specific improvements: inclusivity and closure.

The four core principles of LinkedIn product reviews

At LinkedIn, we held two 30-minute product review meetings and a 10-minute follow up meeting the following week for each product review from the previous week. Each session was attended by my product leadership team which included

Allen Blue⁠

Adam Nash⁠

Christina Allen⁠

DJ Patil⁠

Elliot Shmukler⁠

Joff Redfern⁠

and

Steve Johnson⁠

as well as the key team members working on the project being reviewed. In a typical product review meeting, we’d talk about everything from product concepts, upcoming product launches to user insights from previously launched products.

We intentionally crafted this meeting around a set of four core principles:

The right set of attendees: Hear directly from the team members who do the work.

Listen first, opine second: Only speak if you have something material to add to the discussion.

“The

Talking Stick⁠

: “ Orderly feedback. No spectators.

Return for the Follow up: Avoid feedback black holes.

Since first developing the product review process at LinkedIn, the tools we used to run it have evolved to be more collaborative and remote friendly (Coda, Slack, and Zoom weren’t available in 2009!). I recently partnered with the Coda team to build a template that you can copy and use to run your own product reviews.

⁠

Copy this doc

⁠

1. The right set of attendees: Hear directly from the team members who do the work.

The first step is to have the right attendees for each review. We understood the need to interact with the key team members actually working on the project — the engineers, designers, PMs, or sales people. We asked them to present, not their managers.

Here’s a very simple example of what a signup list would look like:

Topic

Date & Time

Reviewers

Working team

Scribe

Company page editor launch review

Thu, Sep 30, 10:30 AM

Group chat UX review

Thu, Sep 30, 11:30 AM

Video meeting scheduler - stats review

Thu, Oct 7, 1:00 PM

No results from filter

⁠

By default, product managers tend to do most of the talking during the product review. After all, one of their primary functions is to act as a communication hub for the product area they are working on. However, engineers and designers often bring crucial context to the conversation, so I like to encourage them to present along with the PMs. Similarly, the sales team typically understands customer needs by virtue of their daily interactions with customers so it’s often helpful to include them in the presentation, especially for enterprise products.

We also define the role each person will play in the review. The clarity that comes to a meeting when each attendee understands the purpose of the meeting and the role they play is quite amazing:

Reviewer

Learn more

Working team

Learn more

Scribe

Learn more

⁠

A note about reviewers. In our meetings, reviewers were fixed and limited to the product leadership team. We also had standing invitations for Reid Hoffman (the co-founder), Jeff Weiner (CEO), and Kevin Scott (the Head of Engineering). You’re welcome to adapt both roles and meeting stages to fit your own workflow.

When we started this process, one of our challenges was making sure that everyone in the room understood their role. As we rebuilt this process here in Coda, we came up with a fun idea — this template will actually send a pre-meeting personalized Slack message to each attendee describing their role and the expectations:

⁠

⁠

2. Listen first, opine second: Only speak if you have something material to add to the discussion.

The second key principle ensures that the working team feels heard and empowered. In my experience, this happens only if you practice active listening.

At the beginning of the product review, the working team presents updates on the product topic at hand: customer insights, current performance, upcoming launches, etc. During the presentation, it’s tempting for reviewers to interrupt when they have questions, but this can quickly derail the meeting. We found that active listening often encouraged more thoughtful and intentional questions after the presentation.

To encourage this, no questions were allowed during the presentation (except for occasional clarifying questions). Instead, reviewers wrote questions down and addressed them afterwards. At LinkedIn, we did this in a very low-tech way. We made sure the room always had tons of post-it note pads and pens, and people would use them to track questions during the presentation.

When re-thinking this experience with Coda, I opted for something a bit more digital: the table below allows each reviewer to add their questions / feedback during the presentation. It includes a “+1” button so others can just express their agreement and not have to repeat the same question or feedback. Here’s an example:

⁠

Add feedback

⁠

From

Question/Feedback

Notes

Lola Tseudonym

Are you planning on refreshing the brand colors?

Open

What percentage of our customers use this feature?

Open

Buck Dubois

I love the attention to the details of this use case!

Open

Did you explore a simpler onboarding flow?

Open

⁠

3. “The Talking Stick”: Orderly feedback. No spectators.

Meetings often have a

HIPPO⁠

problem, where the highest ranked person in the room has the most influence. And we’ve all been in meetings where one person does all the talking while everyone else listens. LinkedIn’s product reviews were designed to be the inverse. Requiring everyone to participate keeps the meetings inclusive, enabling everyone’s voice to be heard.

After the presentation is over, reviewers provide feedback using a technique inspired by the

talking stick ritual⁠

, which has been used by indigenous tribes for hundreds of years. The idea is simple — only the person with the talking stick is allowed to speak. After the person speaks, they pass the stick to someone else until everyone has the chance to speak. Remember, no spectators! I love this ritual because it ensures that each person gets to speak and encourages empathetic listening from the rest of the group. We also time bounded each person’s feedback so they could focus on their most important comments.

⁠

⁠

If someone has nothing material to add or if they agree with what has already been suggested, they can +1 a previous comment and cede their time to the next person. As each person speaks, the scribe takes notes and captures feedback. As the “boss” in the meeting, I always gave my commentary last. This prevented my opinion from biasing the rest of the discussion and allowed a broader spectrum of feedback from the group.

4. Return for the follow up: Avoid feedback black holes.

It’s far too easy to close a meeting with a list of action items just to forget about them the next day. I call this the feedback black hole. Instead, feedback should lead to conclusive decisions and closure.

Following the review, the scribe categorized the feedback and the working team decided on next steps for each piece of feedback. They then returned the following week for a follow-up meeting to present the action plan to the reviewers.

Often the plan included taking action on the feedback: tweaking a design, gathering more data, etc. Once in a while the plan was, “we heard you but we’ve decided to not take any action at this time.” Either way, the follow-up meeting was an important forcing function to ensure that the feedback didn’t end up in a black hole and we attained closure.

The Slack channel for the project can then get this final plan, ensuring that the entire team is on the same page.

A template to run product reviews

This template is designed to ensure that your product meetings are inclusive and conclusive:

Copy doc if you haven’t already 👉

copy this doc

⁠

Schedule the

Product Review Calendar⁠

. Pop open an individual row to assign roles, link to the review page (see below), and send out a Slack reminder. You can also adjust the

Settings⁠

as you customize this for your team.

Duplicate the

Product Review Template⁠

for each review, and run your meeting from that page. This is where the working team will present their plans, the reviewers will provide feedback, and the group will discuss with the proverbial talking stick.

Connect this doc with Slack. Finally, be sure to connect this doc to Slack so the entire team (including the meeting attendees) will automatically receive reminders before each meeting, as well as the conclusions and next steps.

If you would like to try this technique and need help implementing it, the Coda team has graciously offered to help. Click this button to get assistance:

⁠

Connect with a Rituals Architect

⁠