Managing Mature Products

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.

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.

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?

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.