Lukas Pleva

One of the benefits of working with a mature product is that you likely have access to a large pool of existing users from whom you can solicit feedback. In contrast, new and emerging products often have a much smaller user base, especially in the early stages or if you’re still working on finding product-market fit. With that said, here are two of my favorite methods for gathering feedback: Built-in, In-App CSAT/NPS Widget Many of the products I've worked on invite users to provide feedback during their use. This can take the form of a persistent 'Feedback' button that's always visible or a more dynamic pop-up or slide-out that appears under certain conditions (for instance, after the user has performed a key action or been using the product for several minutes). Keep in mind that the implementation of this mechanism can affect the type of feedback you receive. For example, if you add a feedback button that users need to discover on their own (versus actively prompting a random selection of users for their opinion), you may find that the majority of respondents are those who absolutely love or hate your product. After receiving in-app feedback, you can reach out to the user to ask if they’d be open to a more detailed chat, either in person or virtually. Mining Support Tickets Unless your product is perfect (which, let’s be honest, no product is), there will likely be some volume of support tickets. These tickets are a goldmine of information about the challenges your users encounter, whether it’s due to a bug, incomplete documentation, or a misalignment between the product team's intentions and customer expectations of how the product should be used. Depending on the volume of support tickets, you might encounter a high noise-to-signal ratio, or you might need to use a third-party tool to assist with sorting and categorizing to uncover overarching trends.

There are countless product management prioritization frameworks available, such as RICE (Reach, Impact, Confidence, Effort) and MoSCoW (Must have, Should have, Could have, Won't have). That being said, my favorite is a simple, four-lens model that my very first HubSpot manager taught me. * The Market lens - How differentiated will our offering be compared to other solutions in the market that are solving a similar problem? * The Business lens - Will prioritizing this initiative allow us to make progress against our higher-level business objectives? * The Custom lens - How big of a need is there for this feature? Are 80% of our customers asking for it, or is it solving a more niche problem? * The Technical lens - What's the overall level of effort? To what extent will this create or reduce tech debt? While it won't always work out this way, in general, you should prioritize features that strongly align with several (or, ideally, all) of these lenses.

Most roadmaps indeed focus on both. The balance of prioritizing prospects versus existing customers will depend on the business objectives your product roadmap is designed to support. For instance, if the business leadership team is leaning on you to improve customer retention or promote edition upgrades, it might be necessary to prioritize existing users. On the other hand, if the goal is net-new user acquisition (in other words, the aim is to build a larger customer base), it might be more beneficial to focus on prospects.

It depends on who the other team is and what I expect them to do with the information. * If it's another team that I depend on to execute my goals, I'll share more details. It's important for them to have a good understanding of what exactly my team's building, why, when it's shipping (estimated), and what I need from them. * By contrast, if I don't have a dependency on the other team, I'll keep it more high-level and focus more on the business and customer impact than the nitty-gritty details. That said, regardless of the target audience, remember that "clear is kind." We're all busy professionals. Even in the scenario where I share a more detailed roadmap, I put the most crucial information at the top to make it easy to scan.

I'm a big fan of publicly available roadmaps. They provide current and prospective customers with insight into where you plan to focus and serve as a great resource for Sales and Customer Success teams. Compared to internal roadmaps, the publicly available ones tend to have: * Less specificity about when a particular feature is shipping (e.g., 'second half of this year' vs. June/July) * Less detail on how the feature will work or how you plan to measure success * Fewer technical specifics, focusing more on what problems you're solving or what use cases you're enabling.

This is a gross over-generalization, but in my experience, there are two kinds of product development cultures: * Sales-led, where you build what you sell. * Product-led, where you sell what you build. The former is especially common in organizations that serve large enterprise clients. In those situations, you often find yourself building capabilities needed to close a specific deal or to fulfill a promise included in a particular contract (e.g., 'by the end of the next fiscal year, we'll build this capability'). One way to regain autonomy in this type of environment is to stay on top of market trends affecting your industry and to anticipate the problems and pain points your sales team will encounter in future prospect conversations. Show your sales leadership team how solving that problem will be a rising tide that lifts all boats, benefiting many existing and potential clients, not just 'the big fish.' Ultimately, though, if this type of culture is ingrained in the company's DNA, you'll need to have a candid conversation with yourself about which environment will allow you to do your best work.

Creating a product roadmap is fraught with challenges, regardless of whether you’re working on a new/growing or a mature product. That said, when dealing with mature products, it’s especially important to consider: * Change Management: A mature product likely has a large, established user base accustomed to how the product functions – including its supported use cases, quirks, etc. This presents a challenge when considering significant changes, like overhauling the user interface or significantly modifying key user flows. In such cases, you'll need to invest considerably more in change management: How do you ensure your users are aware of the impending changes, understand what these changes mean for them, and feel comfortable with the new experience? These considerations affect everything from the rollout pace (which will likely need to be more gradual) to having to devise a legacy strategy (for instance, with APIs and platforms, ensuring that your customers' products don’t suddenly stop functioning). * Tech Debt Management: Generally, mature products tend to accumulate more tech debt than newer products. This should be a key consideration while developing your roadmap. For newer products, only a small percentage of your roadmap might be dedicated to technical maintenance, with the bulk of your development efforts focusing on new functionality. However, with mature products, this percentage might need to be higher.

I tend to focus on two groups of indicators. First, did we deliver a delightful user experience that added value to the customer? My go-to for answering this is Google’s HEART framework: Happiness, Engagement, Adoption, Retention, and Task Success. * For Happiness, I look at metrics like user CSAT or NPS. * For Engagement, I consider metrics such as average session length. * For Adoption, I focus on key activation metrics (e.g., inviting a friend to join, publishing a first post, etc.). * For Retention, I monitor our churn rate. * For Task Success, I evaluate key activities we want users to complete and monitor their completion rates. Note that it’s not necessary to measure every single metric in every category for each project. Secondly, did we add value to the business? Ideally, your product benefits not only your customers but also your organization. The specific metrics to consider will depend on your goals, but here are some examples: * Did we help the business acquire new customers? * Did we increase conversion from a free version of the product to the paid version? * Did we enhance overall 'stickiness', leading to lower churn and increased customer lifetime value? * Did we drive more cross-sell or up-sell, resulting in higher revenue per customer?"

The unsatisfying, but honest, answer is “it depends.” As a general principle, addressing tech debt should be a continuous consideration. Without it, you put your product’s long term security, reliability, and scalability (both in terms of handling new users but also in terms of being able to quickly implement changes and updates) at risk. That said, how often you’ll need to spend development calories on addressing tech debt is contingent on a variety of factors: * Overall technical architecture of your product * Past decisions (did former teams cut corners? How often, and how much?) * Your company’s overall willingness to prioritize maintenance and tech debt vs. new feature development

It’s common to assume that mature products have a static, well-defined persona. However, product teams should aim to continuously challenge and pressure-test that assumption. Specifically: * We should continuously validate whether our long-held assumptions about user demographics, behaviors, needs, and pain points remain valid. Markets inevitably change, and user preferences evolve. Is our ideal customer who loved and raved about our product two years ago still the same one who’s doing so today? * Relatedly, we should always be on the lookout for new personas that need to be accounted for in our planning and development process. Remember, there are job roles today that didn’t exist two years ago. Are there new types of users with expectations and needs we haven’t previously accounted for but now need to consider?