AMA: HubSpot Group Product Manager, Lukas Pleva on Product Roadmap & Prioritization

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.

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.

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.

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.

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.