AMA: HubSpot Product Lead, Katherine Man on Platform Product Management

I’ve held roles as both platform and non-platform product managers and I’d say being a platform product manager is definitely the most challenging but rewarding. The most challenging part is your solutions are more abstract and less obvious. Instead of building solutions directly for customers, you’re buildings tools for customers to build the solutions themselves. Does your head hurt yet? Let me give an example. Let’s say you’re trying to let customers customize the way their HubSpot UI looks. While you could try to build all the customization requests you get, no two customers want the same thing and it’d be impossible for our product teams to keep up with that demand. Instead, you build tools for external developers and admin users to configure the UI in the way they need. But how do you figure out which tools? Here is the usual process for regular product management: 1. Collect customer use cases 2. Identify a pattern 3. Build a solution that solves for the majority of use cases. Here is the process for platform product management with an extra step: 1. Collect customer use cases 2. Identify a pattern 3. Identify a pattern across solutions 4. Build a solution that solves for the majority of use cases. Still confused? Let me make the customization example even more specific. Let’s say you notice that a lot of customers want to display their HubSpot data in a table format on the CRM record page. Taking a non-platform approach, you’d build out every single table request that customers make. But this isn’t scalable. Instead, you build a configurable table component that customers can populate with their own data and then display. Believe me, I struggled for a long time with this adjustment in thinking but I promise if you choose to pursue it, you’ll love the wider impact that you’re able to have on customers!

Platform product management works with many of the same departments as other product teams along with a few additional stakeholders on the developer side: * Product marketing: Helps with messaging new features to both internal teams and external customers. Often you collaborate on release notices together. * Go-to-market: Collaborate on pricing and packaging of features, creating enablement materials for internal teams, understanding the broader market, and advising on how to position features in the market. * Sales/Customer Success/Support: Partner closely with internal enablement teams to make sure both customers and prospects understand what the new features do as well as troubleshoot any issues. Will also be able to provide you with customer feedback faster than customer satisfaction surveys. Additional developer-facing teams: * Solution architects/Technical consultants: Since your features are more technical, in addition to the enablement teams mentioned above, you might also work closely with internal solution architects and technical consultants who help customers and prospects understand your more technical features. They often have a deep understanding of customer needs and build demos, which makes them convenient early adopters to test your features. * Technical doc writers: If you’re releasing features to developers, you’ll need to work with technical doc writers to create developer documentation. Developers often rank having clear documentation as one of the most critical components of a successful platform. * Developer Relations: To engage with the developer community, you can work with this team to hear feedback directly from developers and publicize your features at events.

It’s true that platform teams serve many different types of users. I like to define the platform mission as “building tools for customers, developers, and internal teams to extend the product in a self-service way.” While you do need to understand different personas, at the end of the day, all of your users are still united in trying to solve for the end customer. With that lens in mind, user feedback is still driving priorities. The only difference is it’s coming from multiple sources: * Customers: For simpler solutions that can be solved in the product UI, you can gather feedback directly from customers and deduce what they’re trying to do. Often you’re able to provide a solution that will solve for the majority of use cases and customers can build the solutions themselves. * Developers: For more complex solutions that are often unique to the customer, it’s not possible to offer a general solution in the UI since it wouldn’t make sense to the rest of your customers. That’s where developers come into play. Developers are like business partners who help build solutions for customers. They’re often a great source of knowledge of customer needs and can help inform your product roadmap. * Internal teams: Internal teams are another key stakeholder since they will often ask you to build something their team needs. Unlike external customers, you cannot dodge them and will need to give them an answer or they’ll harass you on Slack :) In this case, you can still ask for a business case (combination of customer feedback and data) to understand the priority. So in the end, you’re once again prioritizing based on customer feedback. Once you’ve gathered customer feedback across all three sources (customers, developers, internal teams), you then can prioritize your roadmap and determine what solutions to build for the highest impact.

Alignment can be a challenge for platform product managers since you usually have more than the average number of internal stakeholders and increased cross-team dependencies to get your work done. At best you have the potential to have a large scale impact, at worst your projects get blocked by another team. That’s why it’s critical to gain alignment across the broader platform. When striving for cross-team alignment, I always tell my teams to think in ‘spheres of influence:’ * Start with your immediate team: Work with your team to prioritize your product roadmap based on customer feedback and data. Make sure your team is bought into the work before circulating too broadly. * Expand to your larger product area: Most teams do quarterly planning, so once you and your team know your quarterly roadmap, I highly recommend circulating it to your broader product area, which includes teams that you partner with closely. You want to identify any cross-team dependencies as early as possible and get the work prioritized on their roadmaps if necessary. Since you usually partner closely with these teams and you’re probably also doing work that their teams need, the hope is that you can negotiate getting onto each other’s roadmaps. * Expand to the entire product organization: Since platform work has a broad impact, you usually want to let the wider product organization know what you’re working on as well. This can help you identify early unintentional impact you may have on their teams or even better, ways they can benefit from your work. Usually you have a good sense of your key internal stakeholders so you may be able to limit alignment to a few key teams outside of your product area, but it never hurts to let the broader organization know what you’re working on.

Platform metrics will vary depending on who your users are (internal vs. external) and the project specifically. They are different from normal product management in that the focus tends to be on scaling rather than generated revenue since it can be difficult to measure that direct impact. Here are some metrics that my teams focus on: * Adoption/usage: Since customers are building with your tools, adoption/usage is usually the main metric you track. How many customers have built a solution? Are their end users using the solution? You need to be patient with platform work since adoption will take longer than usual and need to be measured over several quarters as opposed to within a single quarter. While the beginning may be slow, you'll ideally see a drastic uptick after customers find your tools and start building with them. * Customer NPS: Customer NPS becomes a really important measurement since you’re able to measure how customers feel about the tools you released by comparing satisfaction surveys before and after releasing your tools. Since a lot of your users will be internal, you will be able to get a lot of more in-depth, direct feedback. * Associated revenue (monthly recurring revenue, customer dollar retention, deals won): Measuring direct impact on revenue can be difficult since customers are building their own solutions instead of you giving them one. Instead, we measure a lot of associated revenue meaning, “did we win a bigger deal size because the customer is interested in using some of the features we built?” “Do customers with a higher customer dollar retention tend to use our features?” While platform work requires quite a bit of patience, there's no other satisfaction like seeing customers delighting their own customers and teams with what you've enabled them to build.