How to drive consensus and exceed OKRs as a product team
The OKPS (objective – key result – problem – solution) visualization helps PMs focus their product teams on the right work, drive consensus cross functionally, and exceed product OKRs.
Solving problems for PMs
Many of the PMs I have managed and mentored find resistance in building consensus. Cross-functional and executive consensus tend to be the toughest to crack. Cross-functionally, it is common for sales or marketing to be unhappy with historical feature delivery and communicated roadmap items. Upwards, it is common for executives have their own ideas of what to build.
Building consensus within the core product team is a tougher nut to crack than initially appears, as well. Most successful PMs are able to drive verbal consensus amongst their product team. Shared context, bringing members along, and joint decision-making help PMs drive verbal & tacit agreement. The catch is: while the PM spends the majority of their time driving consensus, the rest of the team executing the product ideas is usually only participating in this process as a portion of their job. Designers have to make designs, and engineers have to code. This can lead to occasional gaps in understanding, resulting in team confusion.
So, the non-PM members of the product team need to be continually reminded of the shared context the team agreed on. That includes the focus area now, the metric to move, the user problem the team is solving, what has been shipped, how those have moved metrics, and what needs to be shipped. If PMs can effectively share this information, it helps the team develop a mental mind map as rich as the PM’s. It also gives the team clear items to verbalize, as they evangelize the product team’s vision when the PM is not around. But communicating such a long list of information without being repetitive, and respecting product team member’s time, is hard.
Enter the OKPS, objective – key result – problem – solution, tree.
An example OKPS
There are four basic components to the OKPS I have seen used in practice most often. The first two components are OKRs. Start with the objectives and line up their key results. After that, the magic starts to happen. Product teams engage in discovery to draw out the key user or technical problems that are the root causes of the OKRs. Then, they brainstorm and source solutions to the problems.
Let’s dig into why this is so magical.
Benefits of OKPS
Focus on the right work
OKPS is a great companion visualization to OKRs. OKPS forces data-driven product teams to link features to metrics. The linking function drives the team to focus on the right work. The team does not ship features that do not link back to the OKRs they had set out. There cannot be a floating solution on the board. They have to be able to link it back to an objective and key result. This helps the team actually achieve OKRs and move metrics.
The visualization also forces a level of discipline in assessing work. The team has to decide which OKR a potential feature might potentially influence. This is tougher than it sounds. It is very different from how most product teams are used to working. In the early stages of OKPS, it is likely the team will even misplace features. That is actually a great learning benefit of the OKPS. It helps the team build a shared understanding of what types features move what types of metrics. Then they can make even better OKRs the next time around.
Being user-centric
While OKRs are very powerful, they lack a focus on the user. What do Amazon and Google have in common? They both put user, or customer, centricity first. It is a core value at each of these multi-trillion-dollar market caps. The best product teams also are user-centric. In fact, not being user-centric is one of the easiest pitfalls of product teams. Bringing the product team back to the voice of the user is the sign of a stellar product manager. That is why OKPS is a vital tool in the tool belt of developing PMs.
OKPS forces product teams to put user problems against OKRs, and, actually, between OKRs and proposed solutions. This helps the product team not just be user-centric, but entirely focused on solving user problems. Solving user problems actually turns out to be the easiest “growth hack” for any product team. When their features do not solve a core user problem, they have a great candidate for not moving metrics as well.
Set the discussion for the product team
Heading back to our original example at the top, OKPS helps PMs bring context back to the product team. This is one of the hardest challenges for PMs. But with the OKPS, in one working image, the PM can quickly set context for what the team is working on and why without having to be repetitive. The OKPS can be continually updated for the status of items. OKPSR is a variation of the OKPS I have pictured above where you show the results of each solution to see if you have reached your KR. If you have, you can green out that part of the tree, as the example team has for their first set of OKRs.
Imagine your typical product team meeting. Discussion can begin with the tree. It will show the template for the discussion. From there, the team can focus on the what has been shipped and what has to be done from design and engineering. Analytics can report on what has shipped. Design can comment on what is to be spec’d. Engineering can comment on what is to be built. The OKPS provided an exhaustive tree to visualize the work and topics.
OKPS also helps drive in-team alignment. PMs often find particularly missionary team members within their own product team who have had to “disagree and commit.” The team member may not think a solution should be shipped. But they understand why the team is trying, because they have the context. They also know the team will come back to measure the result. They know they will have their opportunity to resurface their idea if they can articulate it in the context of a user problem and OKR.
Drive consensus cross-functionally
As Product Managers, we recurrently have to present a compelling reason for why we are building what we are building. The OKPS provides external stakeholders what, and why, the team is building. It provides the terms for the discussion. Stakeholders can argue their un-included item would result in a greater increase in a key result. Great, the product team would be happy to update then. Or, stakeholders can argue that the team is missing a key problem. Great, the product team would be happy to learn that and build to solve it.
As long as OKRs are publicly communicated and committed, arguments become productive instead destructive. Arguments are just discussions on how to achieve OKRs. Nothing is personal. If something is not built, let’s get it into the next OKRs. Or if it does not move an OKR we can get everyone to agree to, then maybe it really does not need to be built.
Implementing OKPS For You
The OKPS is a tool. You would not want your expert contractor using a hammer as his tool for every job. You also do not want to only use the OKPS as the tool for your job. Instead, you want to take the principles of OKPS, and benefits it tries to drive, and bring those to your product team. It may mean one step towards OKPS. Or it may mean something like an opportunity solution tree (I love Teresa Torres’ explanation). Pick and choose what of these principles make sense for your situation. Maybe to start it’s a simple tree. Try it on for a few weeks. If it works, try more.
Conclusion
More and more companies and product teams are switching to OKR driven development. This can be a terrific forcing function for product teams to focus on shipping things that move metrics. But, that same forcing function can also be very tough on product teams. It can be difficult to, in advance of shipping a feature, understand what metrics it will move. Let alone, how much it will move the metrics. This is even more difficult for teams that are new to working in OKR driven development.
The OKPS tree presents a solution to many of these difficulties that product teams face with OKR driven development. It solves problems for product managers. It helps the product team focus on the right work, be user-centric, have focused discussions, and drive consensus cross-functionally.
