Jacqueline Porter

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: * Top Level Business Objective: Increase enterprise ARR by 20% * Product Key Result: Deliver paid feature X to help compete and close 3 sales pipeline deals * Product Key Result: Implement use case documentation for paid features to support Field Team

Both product lifecycles require a strong long-term vision in order to effectively motivate the team and attract users. Without a strong vision, the 0 to 1 product would not be able to focus on goals/exit criteria for launch while the mature product would get stuck in a routine problem-solving approach with the existing base.

Love this question! Planning for product vision is usually done in 3 horizons: 10 years, 3 years, and 1 year. The 10-year vision is your guiding, north-star approach that will help guide all other investments overtime. The 3-year vision is a little more actionable and will help shape what the execution plan needs to be. 1 year vision is execution based on what can be accomplished in that current year.

I am a firm believer that what you need to grow and what you need to scale are two different things - including leadership, team processes, and strategy. This means that I have found it easier to start with a small seed group to build your framework for operating. This has a couple of advantages, including reducing biases for certain processes and ensuring multiple perspectives are included from the beginning.

A well-rounded product team requires three main features: * Diverse composition * Top talent in the domain * Rigorous product management processes Diverse talent can be accomplished by hiring with a specific schedule of product manager you want to hire. This can mean location diversity gender diversity, and racial diversity, but the bottom line is you want to have a population in your team that is representative of your customers. If you don’t have a product team that reflects your customers, you’re likely not going to be building a product that will be used and loved by your end users. Top talent in the domain is usually accomplished by looking at your competitors looking at your aspiration products and recruiting from those specific companies. It can also mean finding thought leaders in the area people who are producing contact on YouTube for Twitter, and our respected in the domain. Lastly, the processes. A product team can be completely rock stars when it comes to all of their domain knowledge, their ability to think about problems specifically, but if they don’t have a way to work together, then all of those skills are wasted. An example would be how do you release product? How do you update your customers and how do you think about the market? All of those questions need to have an answer so that your product managers are producing the way it is that you want to deliver product in the same way.

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: 1. Have a published single-source-of-truth charter where current status and archived information live. This repository can be a word document, google sheet, or even a static website. You will want to add "pins" to any relevant documents or links at the top for easy access. 2. Determine a regular cadence for team syncs 3. Provide continual async updates and link back to the SSOT (number 1) so people who are unable to attend syncs can reference the materials later 4. Overcommunicate and overshare the goals and results of the cross-functional work 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. 

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 a great question about how to pave the way for two things: product strategy and product management execution. I can see this being applicable to not only first Product hires at start-ups, but new product areas a company has never pursued before. There are a few mechanisms/processes I would establish as a first priority: 1. Establish a feedback loop with the top customers, internal users, and market analysts (product mgt execution) 2. Identify the top 1 or 2 business metrics you are looking to influence (product strategy) 3. Create a cadence for a roadmap to release notes that can be published publicly for internal and external audiences (product mgt execution) 4. Review the existing competitive landscape and understand your product market fit (product strategy) 

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. 

I typically start from what are the annual business targets set by the company to answer this question. Oftentimes, the sales organization, CEO, and professional services organizations have targets around expansion, new logo acquisition, and win rate which will help portion out what the backlog needs to be to support the business goals. In absence of these targets set by leadership, I would use a RICE framework (https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/) to establish what is the highest value driver for the business. That way I am not really focused on driving whitespace or greenfield, rather on what will drive the most business results in total.