As a "product-guy founder” turned professional product executive, I’ve been able to see just how pervasive misalignment of product teams and leadership teams can be. I think about these situations a lot because I can think from the founder’s perspective as well as the product manager’s. I try to think about how I would structure my own company’s product organization to avoid these kinds of costly misalignments.
For founders, nothing creates more anxiety than feeling like you hired the wrong product person, especially the critical first product hire. For PMs, being out of sync with higher-ups makes your job much less enjoyable.
The core of almost all misalignments between product managers and founders or executive leadership teams (ELTs) is a disconnect between the company objectives and the opportunities in the product to drive those objectives. Fortunately, product strategy methodology has developed ways to better align company objectives or outcomes with product outcomes that can be driven by product managers. These practices should become more widespread and I want to share some tips that I will likely use the next time I launch another startup.
OKRs are a Good Start
In some sense, product-ELT misalignment should be less of a problem than ever. Many companies make use of, in one way or another, the Objectives and Key Results (OKR) framework for clearly defining and communicating company goals across the organization.
OKRs are designed to articulate in a clear way what the company needs to achieve in order to move forward. The objectives should be concrete and clearly defined, and the key results should logically indicate a success state of the objective and be numerically measurable to know if or how much the company has succeeded in reaching the objective. The point is to make it easy for the entire company to know what’s most important for the organization right now, and to align their work to achieving those objectives.
But even with OKRs product teams and executive teams can find themselves misaligned about what features or areas of the product the company should invest in. As software companies become increasingly “product-led,” this is obviously a big problem. And it usually comes down to a lack of a shared understanding of the opportunities to drive business outcomes from the product.
Map Product Outcomes to Business Outcomes
The simplest way to align the goals that a product manager can control (product outcomes) to the goals the business needs to achieve (business outcomes) is to map them. A company-wide goal like increasing revenue can be mapped to product outcomes like increasing the percentage of users who switch to a paid tier of the product, or increasing the number of paid features customers use. These are outcomes product managers can control to contribute to the company-wide goal of increasing revenue.
The harder part is figuring out which product outcome to focus on, because there must be an opportunity available to act on in order to drive the outcome. This is where things get complicated.
If you break down almost any product outcome you can think up (increase sign-ups, decrease returns, increase renewals, etc.) you will quickly realize that all product outcomes are essentially actions or behavior you want users to do with the product. But how do you get someone to do something you want? Unless it’s a loved one, you will almost certainly need some benefit to them taking the action. For software products, this likely means you need to solve some problem for the user or fulfill some need. That means our opportunities to get users to take the actions we want and drive our desired product outcomes are limited to the set of problems we can solve for them.
Features and products that don’t solve a problem for the user will not see the traction you need to achieve your outcome. And this is where product-ELT misalignment can rear its ugly head. If company leadership and product teams don’t agree on what needs are most important to users, they are not going to agree on what the product roadmap should be.
The clear solution here is that PMs and the ELT need to share and exchange what they know about customer needs and how they believe they map to product outcomes, and ultimately business outcomes. But how?
Use Opportunity Solution Trees to Share Understanding of the Customer
Many of you reading this have already recognized the elements of the book Continuous Discovery Habits I’ve been dropping so far, and won’t be surprised that my recommendation is to use an Opportunity Solution Tree (OST) to communicate the needs and pain points of customers to others. If you didn’t recognize terms like outcome mapping, pick up a copy of the book ASAP!
OSTs provide the full picture of how product teams can create value and contribute to company goals. They map needs and pain points of customers to product outcomes that in turn map to company goals and OKRs. They guide the ideas of potential features that could be added to the roadmap and help the selection of those ideas. My advice to founders and ELTs is to use OSTs to communicate the opportunities you see to drive outcomes to your product teams, especially new or first product hires.
Oftentimes as founders, we feel an intuitive sense of what the customers of our company need that can be hard to articulate. In reality, what you know about your customers is not just intuition but a result of all the time you’ve spent with them: talking to them, pitching them, closing contracts with them. It’s important to remember that your PMs may not have all this understanding of the customer that you’ve accumulated. You need to document and communicate what you understand about customers to your product team.
Delibr’s OST feature is probably the best tool I’ve seen for maintaining OSTs. It’s great visually, but also does an excellent job of storing notes and documentation. Each node in the OST (outcomes, opportunities, solutions, and experiments) can be opened like a document with all notes, links, and other information right there in the node. The templates are fantastic for guiding documentation or scoping, so that, for example, a solution idea on the OST can contain all the requirements, scoping, user journeys, etc, for that feature.
You can start by simply jotting down a few notes about the pain points you believe are most common for your customers, these will be the opportunities on your OST. Try to provide as much context about them as possible. In Delibr, you can add notes directly to an opportunity node that the PM can reference as needed. If you don’t have recordings of interviews or sales calls that you’ve done, be sure to include notes about where this feedback came from.
From here, you should share the notes with your PM or product team, but then hash out product outcomes together with them. You’ll still do most of the driving here, since you will know more about the product than they do. But it’s important to give them a voice in identifying the product outcomes they will ultimately be responsible for delivering. Work together and discuss how different outcomes can tie back to the business outcomes you’ve set for the company.
Finally, sketch a few solution ideas with the team. If possible, go through the normal brainstorming process described in Continuous Discovery Habits. Discuss each idea and assumptions that jump out as you sketch each solution. This gets the PM involved in shaping solution ideas, so that you are not just assigning them stuff to work on. But the goal is still a few potential projects the PM or product team can start on right away. That helps get them going while they also start developing their own deeper understanding of customers.
You should explain why you think a certain opportunity or feature is a better candidate than another, but it’s important that the PM still does the work of learning more about the pain points you believe you’ve confirmed, by doing interviews, mapping out assumptions about solutions, and running tests on those assumptions (experiments). Founders don’t always make it to this level of customer discovery, but these are absolutely the things product managers should be doing.
Stay Aligned
The OST you come up with together with your PM is a starting point that transfers what you know about the customer to the PM. It starts everyone off with a shared understanding of the opportunities for the company to drive outcomes. It should remain as a focal point for the product roadmap as your PM learns more about customers than even you did.
As the objectives of the business change, the OST ensures alignment between ELT and Product. PMs use what they know about customers to come up with projects that tie back to product outcomes that contribute to the company’s OKRs. ELTs can follow the reasoning of the PM of what to prioritize against an opportunity space tree that contains what the company knows about customers. In this way, OSTs are not just a great way to get a new PM started, but to ensure ongoing alignment and impact.
Build your Opportunity Solution Tree in Delibr!
Let us help you!
Book intro meetingPRD, story map, decisions & Jira issues in 1 epic doc
Manage your user stories in Delibr, integrate directly with Jira
Put your user stories on a story map
Check out Delibr's best practice epic template
Epic kanban board: a powerful overview of your epics
.png)
