Team quarterly plans

At Trustpilot, we are 550+ people across 7 different offices all over the world. When we set OKR's for a product team it's often hard for the entire organisation to understand why we are focusing on one area and not another.

I do a lot of stakeholder management, leadership meetings and tour our offices every quarter to do product all-hands. I talk a lot about why we focus on the areas we do. But again and again, we started to get questions later in the quarter "why this, and not that?".

I have also been struggling with the responsibility of setting the OKR's, is that with the me as a manager or the product team?

We have combined that answer to these two problems into one solution, the Team Quarterly Plan.

Scope

In the past I have asked teams to achieve an OKR defined by me, it was often a bit of a conflict as the team thought something else was more important but they had a hard time discussing it with me as I (and the rest of the management team) had a more holistic knowledge of the company's business issues but also lacked the deep product knowledge that the product teams have.

I hated dictating a direction and was often unsure if we were right as our product and customer knowledge is a lot lower then the product managers.

We are now changing away from dictating an OKR to setting a scope.

The scope is very simple, I use my knowledge about what's holistically most important for Trustpilot within the context of the team and ask the team to look into that area. An example could be:

"We need a more productive sales force".

If you give that scope to the team that is responsible for driving upgrades from our Free product to a paid product they know much more about how to set OKR's than I do as a VP.

Team Quarterly Plan

With a given scope the team goes back and starts to look into the scope and use all their knowledge about the product and it's customers to develop an OKR that makes sense.

When you choose an OKR you need to choose something that has a significant impact on your company. A product team at Trustpilot is roughly 6 people, the OKR defines what they are trying to achieve in the next 3 months. This adds up to 1.5 man years of work where success is defined by the OKR. If the impact from the OKR is very small, the ROI for sure turns negative.

The team documents the expected impact and ROI together with the OKR in what we call a Team Quarterly Plan. The plan should give the answer to why we are focusing on this area. Its written in a way so everybody around the company can read the plan and be convinced that the team is working on an impactful thing.

The Team Quarterly Plan is not a business plan, but much more a back of the envelope calculation and formulation of the impact of achieving the OKR we set up to achieve.

But what are you going to do?

In the plan, we also add a section where we describe what we right now know we are going to test and deliver to achieve the OKR in the upcoming quarter. This is not a roadmap, not a promise of what's to come, it's solely a description of what kind of things we expect that's needed to achieve our goal. It's also only a captured state of what we knew when we wrote the plan, it is not updated during the quarter.

The finished plan

The finished plan should cover the following::

Business why, the business impact on Trustpilot as a business including data
The goal: objective and key results
Discovery, what ideas do we have that can help us achieve our goals, describe each idea.
Delivery: What delivery do we already know is needed in the quarter?

Don’t write a long plan, the why should be maximum two pages long, and the goal in form of an OKR is always short. The discovery and delivery parts should be as short and easy to read as possible, would be great to illustrate it if you already have mockups are drawings. Remember to tell people that the content in these sections are ideas for directions, not final decisions.

The decision is with the product manager

By implementing this we move the decision of focus and responsibility for a good strong "why" from the VP team to the individual product manager. If the product manager comes back and tells us that he can't do a valuable goal within the scope we gave him, we are obligated to change to scope.