AMA: Head of Product, VP, Deepti Srivastava on Managing Mature Products

Any product metric (for products at any stage) should ideally be tied to business goals and to user goals. So if the business goals are focussed on revenue growth, then making sure that product goals and outcomes, measured via metrics, are also contributing to those overall business goals. That being said, the top product metrics that I believe are important to move forward for mature products are: * increasing user retention * reducing user/revenue churn * removing user friction (in product engagement) User friction related metrics are always important to keep an eye on as they can be an early indicator of churn and revenue loss.

There are multiple definitions out there for "mature products", but it ultimately depends on the product and business leaders in a company to define that as they know their products and services the best. Generally speaking though, we'd consider products to be mature when they meet the following criteria: * broad adoption in market (adopted by most/all applicable verticals and industries) * feature set is broad, and there is narrow differentiation from competition in the market based on features * a new feature or update will not unlock a new vertical or a significant portion of the market * growth becomes incremental (and feature requests also become incremental rather than fundamental)

Persona research for any product tends to be a mixture of broad market research and more targeted UX research via surveys, CSAT, in-person events etc. Usually for mature products, I would approach persona research in the following ways: 1. Validating that the ICP that was originally set for the product, still aligns with the majority of current customers. 2. Periodic UX research interviews to get qualitative feedback from the ICP candidates to compliment the quantitative feedback gathered by other means 3. Broad market research (using 3rd party research where available and applicable) of personas that use similar or competitor products. If a gap is identified, then following up with UX research targeting the newly identified persona to understand what it would take for them to adopt the product / unlock that market segment. This is important for growth of mature products.

The biggest challenge with product roadmaps for any type of product is managing competing priorities. The trade-off triumvirate of time, scope and resources is always present. For mature products, the competing priorities usually end up being competing feature requests from important customers that pull the engineering team in different directions. Having a clear framework for managing the different feature requests and prioritizing feature development so it doesn't compromise product quality, delivery timelines, and eng team focus and velocity is extremely important. For mature products, the most important job of the product manager / GM / leader is to have clarity themselves on the top business goals and related product priorities, and to communicate those clearly to their teams so they can have alignment on the roadmap.

First, any new feature or update should have pre-defined success criteria/metrics that are set before launch. That helps in objectively assessing the success or failure of the feature/update. The bigger/more requested a feature, the more important it becomes to validate that it was successful with metrics. As a general rule, I don't ascribe to the "launch first and we'll figure out what to measure after" approach as that can lead to measuring vanity metrics instead of user or business outcomes. Generally speaking, the top metrics to measure for any new feature/update are: * adoption (of new feature) * retention (users continue to use that feature after n weeks/months) * engagement (did users start using the product more because of this feature) There could be other metrics in addition to the above depending on what the feature is and what additional outcomes are expected.

Tech debt is an ongoing input into the product roadmap process, especially for mature products that may have a higher probability of tech debt in the code base. I usually have the following inputs to my roadmap process: * business goals and strategic product priorities * user friction (eg: adoption blockers etc.) * market and sales priorities (eg: is delivery of a feature important to win against a competitor in this cycle) * internal priorities (eg: technical debt, infrastructure upgrades etc.) The relative priority of tech debt depends on how severe it is vs. new feature development, and how much it is hindering user workflows. For example, if tech debt is making it increasing challenging to maintain the product, or it is affecting reliability, availability or security of the product, or it is making it hard for devops to run production services, those merit adding tech debt removal at a higher priority in the product roadmap. There have been times when, as a team, we have decided to completely halt new feature development for a quarter, to get the tech debt and related issues under control.

Any prioritization exercise needs to start with first having clarity yourself as the Product Manager on the top business goals and related product priorities, and then to communicate those clearly to your teams so everyone is on the same page on features and growth initiatives and their relative priorities. Also, having a clear framework for managing competing efforts so it doesn't compromise on existing product quality, delivery timelines for new projects, and eng team focus and velocity is extremely important. In addition, when managing different competing initiatives like features for mature products and separate growth projects, I advocate for separating the two initiatives into separate sub teams. This makes the roles and responsibilities very clear to all parties and avoids confusion and thrashing within the team. It also avoids burdening a team to do multiple things, which leads to loss of focus and lack of clarity on delivery schedules and timelines.

The short answer is -- gather user feedback all the time through multiple channels. Ideally, anytime the user interacts with the product, you should have the ability to either get direct feedback or indirect feedback via workflow monitoring. Generally speaking, the following metrics should be continuously monitored from user interactions with the product so you have an understanding of the baselines and can quickly flag deviations from those baselines: * user engagement * user friction (drop off in the common workflows) * user churn Direct feedback can be gathered via: * in-product CSAT * periodic user surveys of the current customer base * in-person at conferences, customer sessions, customer advisory boards, webinars etc.