Kalvin Brite

Business objectives help the broader team and business understand if they've achieved the intended impact but are difficult for a product team to use sprint to sprint for a few reasons: * Revenue isn't super actionable for the team: if it goes down or up, it's not immediately obvious what actions the team should take in response. * Business outcomes are often lagging metrics: length of sales cycles, churn, and expansion all impact revenue, and this takes time. It doesn't enable the team to take new actions in response to these sprint by sprint. * A complete focus on financial metrics might cause unintended behavior: We've all heard about the Wells Fargo example where they had a KR of selling eight products to every customer, which led to teams signing up customers for products without their knowledge. With business outcomes or financial metrics as the only objectives given to product teams, they could be pulled into short-term thinking to hit revenue growth instead of focusing on the customer behaviors they need to change. With so much revenue not controlled by the product team itself (sales cycle, pricing, discounting, renewals, expansions), teams should be looking at sub-metrics that are more leading and actionable. To translate business objectives to product objectives, I'm a big fan of Josh Seiden's book, Outcomes over Output as a helpful framing. In this book, he defines an outcome as a change in customer behavior that drives business results. Using this framing, teams can ask these questions to find product objectives and associated metrics: * What are the user and customer behaviors that drive business results? * How can we get people to do more of those behaviors? * How do we know we're right?

Time management is essential as a PM, and the tools I use have changed over the years as I find what works. Here are some tips: 1. Use a project management tool: A project management tool, such as Asana or Trello, can help you keep track of tasks and progress you have for yourself. I always found it hard to follow up on tasks I delegated to others until I had a specific column in my Trello board dedicated to them. 2. Make use of templates: Use templates, such as meeting agendas or project planning documents, to save time and ensure that you consistently follow best practices. I have created many templates for PMs in my team to follow for interview guides, opportunity canvases, and decision documents. This lets us quickly get to the point of the document instead of needing to wade through the many variations in layout or formatting that can be distracting. 3. Use a note-taking tool: It can help you capture ideas and essential information and keep it organized. At the end of the day, I usually wonder where I put that note on a customer quote or OKR. If it's all in one place, it's easier to find! 4. Prioritize tasks: Use a prioritization method, such as the Eisenhower Matrix, to help you prioritize and focus on the most important things. 5. Take breaks: We all know we should do it but usually don't. Take breaks to rest and recharge, and try to avoid multitasking. 6. Use time blocking: Use time blocking to schedule dedicated blocks for specific tasks or projects, and try to minimize distractions during those blocks. This is invaluable, especially as a people leader with many 1:1s and meetings. 

The best PMs define success before building a feature. To define success, teams should think through: 1. The customer problem they're solving, what does it look like when solved (for the customer and the business)? 2. How impactful is it if solved (time-saving, cost-saving, revenue-generating)? 3. How does solving this problem help the company achieve its longer-term vision/strategy? Is there a KPI or measure for the feature that helps the team know they're moving toward that strategy? Once the feature is launched, there are a few different ways to determine whether a new feature or update has been successful: * Track usage metrics: such as the number of users using the feature, the frequency with which they are using it, and any changes in retention or engagement. * Gather customer feedback: This can be done through surveys, user interviews, or tracking social media mentions of the product. * Monitor for changes in key performance indicators (KPIs): Depending on the goals of the feature or update, you can also monitor for changes in relevant KPIs, such as revenue, conversion rate, or customer satisfaction. * A/B test: If you're unsure how a new feature or update will be received, you can run an A/B test to compare the performance of the new feature or update against a control group. Lastly, a helpful question that Sean Ellis has popularized is the PMF test: ask users, “how would you feel if you could no longer use the product?” and measure the percentage who answer “very disappointed.” After benchmarking nearly a hundred startups with his customer development survey, Ellis found that the magic number was 40%. This can be a helpful tool to identify users to interview further and segment your customer base around those customers that find a lot of value in your product that you should be targeting.

I've found it helpful to craft a ~3-year product strategy that articulates the market and trends, the challenges/opportunities, and the product's path forward with coherent actions to address those challenges. This frames the product's direction and how it will impact the company and customers you serve. From there, determine the % allocation of your teams' capacity across investment buckets. Agree with your team on how you'll spend your time across these to achieve your product strategy: 1. Innovation: bold changes to make leaps and bounds towards the customer journey vision. E.g., new features, the overhaul of existing features, and integrations with partners. 2. Iteration: incremental changes to the existing product to deliver additional customer & business value. E.g., conversion funnel optimizations, A/B testing, and minor fixes that provide an incremental lift of a KPI. 3. Operation: The cost of managing a modern SaaS product. E.g., Security/data privacy, performance/uptime, tech debt/upgrades, and bug fixes. Next, you can consider the opportunities/ideas that may fall into each of these buckets to create a stack rank for each based on the Impact it can have. Again, a simple scoring framework can help, like RICE (detailed below). While prioritizing within each bucket, consider the following: 1. Align with the product vision and goals: Ensure that the features being considered align with the product's long-term vision and goals and that they support growth initiatives. This is often the first filter when prioritizing items. You can take additional steps to determine Impact and Effort if an opportunity is aligned. 2. Evaluate customer needs and feedback: Regularly gather customer feedback and analyze data to understand their needs and priorities. Is this opportunity impactful to these customers by solving a significant problem? How many customers might this opportunity affect? 3. Consider the cost-benefit of each feature: Evaluate the resources and time required to develop and implement each feature and weigh that against the potential benefits. A helpful framework for this is RICE, where R is the Reach (# of customers), I is Impact (degree of Impact on these customers), C is confidence (how much evidence have we gathered to support our assumptions), E is the Effort (how much effort and time might it take to develop this solution?). You take R*I*C divided by E to provide a numerical score. 4. Balance short-term and long-term benefits: Consider the Impact of each feature on both immediate and future product success. 5. Collaborate with cross-functional teams: Work closely with design, engineering, and marketing teams to ensure that all relevant perspectives are taken into account when making decisions.

It's essential to regularly evaluate and address tech debt as it can significantly impact a mature product's overall health and sustainability. If left unaddressed, it can build up and require a massive focus from the team that can disrupt existing customers or prevent you from adding new customers to the product until addressed (this is something I've run into before, and it's no fun!). Here's how I approach it: 1. Regular technical reviews: I schedule regular technical reviews with my development team to identify any technical debt that has accumulated and determine the best way to address it. We typically have a staff-level engineer or dedicated architect who can provide regular guidance and reviews as we build to ensure we consider the larger technical vision and the scale we need to deliver. 2. Budget for tech debt: I allocate a budget specifically for addressing tech debt and ensure that it is included in our development plan. I use three buckets at the team level to align what percentage of our overall capacity to devote to each: Innovation (new features, new products), Iteration (incremental enhancements), and Operation (tech debt, bug fixes, etc.). 3. Incorporate tech debt into prioritization: Once you have the target capacity allocation across the big three buckets, you can incorporate tech debt into the product backlog and prioritize it alongside new features and enhancements. This helps ensure that you take a proactive approach to reduce tech debt and improve the product's codebase. In conclusion, considering tech debt is an ongoing process when working on a mature product. By regularly evaluating and addressing it, you can ensure that your product remains healthy, scalable, and sustainable over time.

At Contentful, we are organized into three Product Lines (Core Platform, Apps, Ecosystem) that each own a specific set of products for a set of customers. Within each Product Line, we have a 2-5 year product vision that gets revised 2x a year with each PL leader (eng and product). From this strategy, we decide the level of investment to make across each PL, and the teams needed to achieve this vision. We then create charters for each team that provides direction to the team (PM, Designer, Engineers) on what they own, the objective they should achieve, the customer problems and outcomes to achieve. I oversee 2 product lines, each composed of several product teams that own parts of these PLs. As an example, in the Ecosystem PL, we have an Integration team, Developer Experience team, Marketplace team, and Extensibility team. Each of these teams have a PM, Designer, and Engineers. When organizing product teams, it's essential to set the charter/mission of the team, what they own, and the problem they are solving for customers. This creates focus and gives the team something to own and optimize over time. A helpful book on organizing product teams is Team Topologies.

As a product manager, it's essential to consider the perspectives and expertise of all team members, including engineers. However, it's also important to remember that as the product manager, you are responsible for representing the needs and interests of the target users and ensuring that the product meets their needs. Here are a few strategies you can use to push back against engineers who believe they know what to build because they "are" the target user: 1. Gather data: Use data, such as customer feedback and usage metrics, to back up your perspective on what the target users need. This can help to provide a more objective view of the situation. 2. Emphasize the importance of user research: Make it clear that user research is a crucial part of the product development process and that the insights and perspectives of the target users should be given weight. It's too easy to assume we know what customers want if we have been on the customer side before or identify with their needs. This is a common trap that all of us have to work against actively. 3. Encourage collaboration: Encourage engineers to work closely with you and other team members (design, research) to better understand the needs and perspectives of the target users by participating in interviews and surveys. I've found it helpful to record user interviews and share snippets of the recordings and the transcripts with the entire product team to foster customer-first thinking. 4. Communicate your perspective: Share your perspective on the needs and interests of the target users, and explain how the proposed feature or update aligns with or deviates from those needs. Centering the conversation on the customer, their context, and their problem helps to shift conversations back to the actual customer. Ultimately, it's important to foster open and respectful communication with your engineering team and to work collaboratively to find solutions that meet the target users' needs while also considering the product's technical constraints and capabilities.

Here are a few tips for nailing the self-serve experience for an API product: 1. Make it easy to get started: Make sure that it's easy for developers to sign up for an API key and get started using the API. This might involve providing clear documentation, simple onboarding flows, and access to sample code and other resources. 2. Offer robust documentation: Provide comprehensive and easy-to-understand documentation for your API, including details on how to make requests, what data is available, and how to troubleshoot any issues that may arise. 3. Keep it up to date: Regularly update your API documentation and other resources to keep them current and accurate. This can help to ensure that users have the most up-to-date information and can make the most of your API. 4. Provide clear pricing and usage limits: Make it clear to developers how much your API costs and any usage limits or restrictions that may apply. This will help them to understand the potential costs of using your API and plan accordingly. 5. Offer support and community resources: Provide support and community resources to help developers get the most out of your API. This might include a developer forum, an FAQ section, or access to support staff who can help with any questions or issues. 6. Monitor and respond to developer feedback: Pay attention to developer feedback and use it to improve the self-serve experience. This might involve updating documentation, adding new features, or fixing bugs based on developer feedback.

I've found informal mentors to be very helpful throughout my career. These have often been colleagues and peers I work with at a given company where I will buy them a coffee and chat about their career, experience, and problems I may be encountering to get their take. If they give advice or suggest something (a book, a conversation with someone from their network, etc.) I follow up with them to let them know how their recommendation or connection helped me with my problem. This creates a positive reinforcement loop where they feel good about helping me (I took their advice, learned something, and let them know it made a difference), and they, in turn, make themselves available to help me again in the future. There are often many people in your organization you can learn from if you take the time to get to know them. If you cannot find these informal mentors, or you'd like something more formal: 1. Network: Attend industry events, join professional organizations, and reach out to people in your network to see if anyone is interested in mentoring you. 2. Ask your company: Many companies have mentorship programs or can help you connect with a mentor within the organization. Ask your manager or HR if any internal mentorship opportunities are available. 3. Use online resources: Several online resources, such as LinkedIn or mentorship platforms, can help you find a mentor. You can search for potential mentors based on their industry experience or areas of expertise. 4. Consider a paid mentor: If you're having trouble finding a mentor, you might consider paying for mentorship services. Several professionals offer paid mentorship services or coaching and can help you with your professional development. It's important to do your research and choose a mentor who has the experience and expertise that aligns with your goals and needs. Don't be afraid to reach out to multiple people to find the right fit.

I look for candidates who demonstrate curiosity and structured thinking during product interviews. Curiosity is an essential trait for PMs because it helps them stay up to date on industry trends and understand the needs and motivations of their users. In interviews, I screen for candidates who are curious about the product and its users and who can ask thoughtful questions and delve deeper into the problem space. Structured thinking is also vital for PMs because it helps them break down complex problems into smaller, more manageable parts and approach problem-solving logically. I look for candidates who can approach problems in a structured way, using frameworks or models to guide their thinking and analysis. To assess for curiosity and structured thinking, an interviewer might ask the candidate to describe a problem they faced in a previous role and how they approached solving it. This would show how the candidate demonstrates curiosity and structured thinking in practice.