Objectives and Key Results are meant to encourage cross-functional alignment and collaboration. In product management, it is essential to think of OKRs as a method for prioritizing scope that will help drive the top business KPIs, so that your product roadmap has a built-in mechanism for considering how to help the business succeed.
The below example is one I have seen work well:
Many product organizations focus on delivery, Net Promoter Score, and user counts. One metric that I think is important to always consider is your availability and consistency of user experience in the performance of the application (latency). Using Error Budgets and thinking about uptime critically as a Product Manager helps put into tangible terms the cost to the user when your offering does not meet a performance or uptime standard. If you are offering mission-critical software, it is essential to be responsive and reliable. Lack of responsiveness and reliability can erode your base over time.
Engineering and Product are two sides of a smooth sailing R&D engine. I have seen a number of ways to split the accountability across these groups:
These three are my three favorite metrics for ensuring you are delivering the right things. Some metrics that don't seem to work very well:
- Number of tickets closed in a time period
- Number of items in a release notes/change log
Both of these can result in perverse incentives, where people are adding issues to close them or including irrelevant items in a changelog or release notes to get more credit for delivery.
This is a great question. I am a fan of actually being ambitious and setting unrealistic targets or stretch goals and seeing where we end up in the first couple of reporting periods. To get a dose of realism, you can always reference analyst reports and right-size your total available market vs. serviceable market and current penetration into the new market. I don't advise setting realistic targets when entering new markets because that can lead to complacency instead of innovation. You can also leverage a range, and use a moderate case and best case target achievement. For example, if you are offering an existing product with 1M marketing analyst users to a new persona like project managers, you would want to evaluate what is the total presence of project managers in your customer base or industry. If you see that you only have 2K project managers in the current user base, but there are over 3M project managers in the industries you are serving, you can set an incremental goal somewhere between 2K and 3M, but you wouldn't want to set a 3M project manager user target right out of the gate since you have no idea how many of those users are actually servicable.
The worst KPIs are vanity metrics that have no ties back to actual adoption or business metrics. I once had a product manager commit to hitting a number of emails a notification system was supposed to send in a 30-day period. Without context, this seems like a great metric to track for volume, except the total count of emails tells you nothing about how many people are getting value, if they are getting value, if they are recurring users, or if the emails are contributing to user satisfaction. This can certainly be a metric in the toolkit, but not a KPI for a product line.
Oftentimes as a Product leader, I am tasked with cross-functional work across Go-to-market, R&D, and finance. One of the most critical aspects of cross-functional is to drive clarity. This can be done by following three practices:
Point 4 is one to belabor. This overcommunication creates a sense of focus, collaboration, and clarity on purpose and intent. By using consistent communication, people feel like they understand how they can contribute and where they can support.
Well, I often incorporate multiple sensing mechanisms into the roadmap - the field and sales team are definitely an important lever to drive revenue, which really is why product managers exist.
So, a tactic I use is to show how much of my engineering capacity is dedicated to enabling revenue, technical debt, and long-term vision. The long-term vision is often a "big bet" that is about making a splash in the market or analyst review. Oftentimes, sales and the field are supportive of carving out time for long-term bets because analyst ratings, whitepapers, and affirmations of the product in the market are great supports for the sales cycle.
I love this question - the audience is everything! I typically have 3 pre-prepared altitudes for my product roadmap which correspond to a specific persona and time horizon
1. Annual Thematic Roadmap with Big Boulder Features - Executives and Buyers of Product: This roadmap has a conceptual, initiative-based view. So, it features connected narratives of multiple features for what the themes of the roadmap will deliver for a buyer or an executive interested in the ROI of the roadmap.
2. Quarterly Feature Review - Field Teams/End users: For internal teams that sell the solution and are working with technical personas, I have a quarter by a quarter snapshot of the features that are most relevant for the day-to-day work of the end-user. So, I like to think of these as Rocks - smaller more tangible features that can be used.
3. Community contributor monthly roadmap - Internal technical teams/Community members that will contribute to the roadmap: This is the most granular and technically informed roadmap that shows what the team is working on in the current month and how users can potentially contribute to the roadmap. This is what typically is considered a sprint review and has minor, iterative deliverables to enable adjacent product teams to the core features being delivered that month.
I will use a community page, release notes, and internal handbooks to publish these different POVs for the organization and others to consume readily.
This is certainly a tricky one! I like to think of a roadmap being made up of four sensing mechanisms:
1. External stakeholders - investors, board members
2. Market landscape - competitors, analyst reviews or reports, and prospects
3. Internal stakeholders - CEO, leadership, cross-functional teams
4. Customers - install base or existing paying and free users
When you are able to attribute the sources of your roadmap features transparently, it becomes a trade-off conversation with executives - rather than a top-down mandate. Being able to show that certain bodies of work have been sourced from competitors or analyst reports which show that you may be lagging behind, for example, is a great dialogue to have when it comes to prioritizing the input from the executives.
If the feature request should get done because you have applied a RICE score or some other type of validation, sequencing behind the most impactful items will be a great way to accommodate the request while delivering the most impact.
Since I have joined GitLab, where our product roadmaps are publicly accessible (https://about.gitlab.com/direction/), I don't think I will ever go back to internal roadmaps. A public roadmap as a number of benefits:
1. You keep everyone internal to the company aligned and up to date on what the product organization is building
2. You can encourage contribution (if you use open source) from the community or customers to help build your roadmap - delivering on a dual fly wheel mechanism
3. Reduces external and field team confusion on what the business is delivering.
If you use disclaimers and set expectations that planning is ambitious and can change, then public roadmaps really have minimal negative consequences.
Keep in mind, security fixes or issues that contain sensitive data are confidential and have regulatory/meaningful business risks, so these types of planned work should be discussed in general terms without compromising the safety of the company.