AMA: Splunk Director of Product Management, Subu Baskaran on Managing Mature Products

Technology can be a real competitive advantage. If your industry needs sub-second latency to monitor their systems, having a streaming architecture that delivers can make your product a no-brainer. Often, what's cutting edge today can be a drag within a decade. I have always looked at it from a customer's standpoint. For, I prioritize new product development to replace anything that is considered "legacy" when one of the following happens: 1. The overall market is shifting. Often, when a new technology comes along, it sways the market away from what customers are used to. Competing in a new era with old technology can harm the customer and the business. As an organization, when you don't embrace new technological shifts such as AI or new UI development practices, customers notice. 2. Customers are losing faith. Often, in mature products, the underlying technology may not solve customers' problems today. You start to see mature customers complaining of a lack of scale, performance, or out-of-the-box help, things that were not important five years ago. While often, one can solve such problems by optimizing the code or having better documentation for new customers who are not champions in your ecosystem, there will come a time when you have to make significant architectural changes to support these requests.

Stakeholders for mature products are typically large customers, experienced field teams (sales, engineering, support in B2B), and long-term product team members. Managing customer expectation: While there are many aspects to managing customer expectations, here are a few things that I have encountered working on mature products: 1. Hundreds of users within a large customer organization use the product daily and expect it to scale and perform to their growing needs. As PMs, it's our job to ensure the users feel heard. As the PM lead for a mature product, I often talked to customers and had transparent roadmap discussions, so they were confident we would deliver what was essential for them. 2. Users don't like change unless a new feature or enhancement radically improves their life. Remember, a problem for one customer might not even be a nuisance to many others. Managing team expectations: As a product leader, you serve the customer and the team building the product. While retaining customers is essential for business, product development teams can lose motivation to maintain a decade-old product, even one with a high ARR. I find that including senior/long-term team members in building the vision for the product is very helpful. They get a sense of belonging, have an ownership stake, and can even rally junior members for the cause. The other aspect of managing a team that has worked on a mature product is not giving in to some members' long-term biases. Even though they may have all the answers, I have found myself seeking clarity from others, which has helped me question the biases with a new perspective. Most people work with you when you question traditions or biases if you have the right intent, i.e., you are solving a real customer pain point. Even the most tenured team members come around when the stakes are high.

Mature products are used by customers across the spectrum from large enterprise customers to startups. Metrics can change based on state of business but in general I would track these metrics for a mature product: 1. Engagement: Depending on the industry, measured as Active Users, Amount of content created/consumed measured over time, Amount of data ingested/accessed (queried) 2. Business Metric: iACV: how much an existing customer has expanded their product usage to new use cases, churn (how many customers have not renewed) 3. Operational Metrics: 1. Product availability - very important if customers rely on your product to make real-time decisions, 2. Page load time: Feature-rich mature products with many active users can slow down page load performance. So measuring this becomes very important so customers don't abandon for faster, leaner products. 3. Latency: In B2b products, end-to-end latency becomes very important. Mature products often fall short in this aspect due to legacy technologies. Monitoring this metric is essential if customers rely on your product to make decisions in real time. 4. Stability: In a mature product with lots of users and endless features, the product can become unstable. For e.g. tracking dropped events can give indicate the stability of the system overall.

1. A product is mature when it is near the saturation level in its operating market, typically over 80-90% of the serviceable addressable market. 2. In a B2B Enterprise market, at least 90% of the large enterprise customers in the Fortune 100 are using the product to solve primary use cases. 3. Mature products are sustainable for a while with minor enhancements and without adding any new features since they are the best at solving the primary use case. 4. Finally, successful mature products are feature-rich and usually the incumbent that many competing startups are trying to attack using the latest technologies

There are many challenges when creating a roadmap for a mature product. But I feel it is no different from creating a roadmap for a new product. In the latter, you have so many new features to build within a given time, whereas, in the former, you need to balance new features with tech debt, customer asks, and new competition threats. E.g., in a mature product roadmap, there are always major themes, such as 1. New features 1. Customer asks 2. Market threats 2. Tech Debt 1. Lack of test coverage 2. Launch-driven product development resulting in system re-architecture 3. Enhancements 1. Customer requests to enhance existing features/functionalities 2. Features that span multiple quarters 4. Telemetry: Product teams often overlook telemetry for new features. They usually come as an afterthought when PMs are flying blind trying to understand customers' product usage statistics.

Tech debt becomes a looming issue in every quarterly planning. It manifests itself in many ways, such as: 1. Rising customer escalations due to new code causing regression issues. This happens when there isn't enough unit or integration test coverage to test all the "legacy code." 2. Launch-driven product development causes teams to "cut corners" and leverage technology that needs to be reversed, as it may not scale or work for all deployment types. A simple example would be using a cloud-native service that needs to be reversed if the product needs to be available on multiple cloud platforms. A product development team must prioritize tech debt as a percentage of new feature development, as waiting too long can cause catastrophic product failures. For example, regression bugs caused by new features can sometimes prevent user access to the product, resulting in millions of dollars in losses for the customer and the business.