Lukas Pleva

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 pro ...Read More

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 dur ...Read More

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 ...Read More

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 ben ...Read More

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 mo ...Read More

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 ...Read More

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 ...Read More

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 thi ...Read More

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 ...Read More

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? R ...Read More