Katherine Man

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!

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.

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.

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

The ideal product manager to engineer ratio can vary from company to company and even team to team, but it usually depends on the company size, product complexity, the skill level of the engineers, and the role scope of the product manager. A general rule of thumb is 1 product manager for every 5-10 engineers. * 1:5 - This is common in startups or small teams where the product manager may need to be in the details. * 1:10 - As the team and company grows, a product manager may manage larger engineering teams. Sometimes it's one large team or multiple engineering teams. Since product managers don't have time to be in the details for every project, they are expected to work at a higher level on setting product vision and direction rather than detailed product requirements. It is common for senior product managers to manage multiple teams. * 1:7 - This is the sweet spot where a product manager can still get into the details of a project while also having a lot of impact with a team of this size.

Success metrics should be discussed early with engineers to ensure alignment with the product or feature's goals. By setting these metrics early, it helps prioritize what features to build and define how success will be measured. While it's fine for the metrics to change as new learnings come up, it's important to involve engineers early and often. Many times engineers will also help pull the success metrics data so they need to understand why it's important.

Product managers should partner closely with engineers on building a product roadmap so that everyone is bought into the roadmap and avoids the need for slipping in rogue features. I would say this sounds like a lack of trust between product and engineering. Here are a few suggestions of how to rebuild trust: * Collaborate early and often on a roadmap with engineers and UX to make sure the entire team is bought into the plan. Encourage suggestions from engineers so that they have a voice. * Establish a clear prioritization framework when deciding what to work on. This should be product-led but still involve the whole team. You can consider things like customer value, time to build, alignment with overall business priorities. That way when there are conflicts between you and engineers over what to prioritize, you can use the prioritization framework to resolve disagreements without much conflict. * Share customer feedback so engineers can see the impact of their work and understand why you chose to prioritize certain features over others. * If the engineer still insists on working on a "rogue" feature and assuming it won't damage the product, you can discuss with your tech lead if every sprint your team should reserve 20% for engineers to work on whatever they want. This allows engineers to prioritize issues they want to work on but would never be considered high priority (reliability, design bugs, etc.)

I would describe my product development philosophy as "agile lite," meaning there is some structure but the order of operations can change based on new learnings that arise. The entire product team (product manager, UX designer, and engineers) should be involved at every stage, but different roles will play a leading role depending on the stage. Here are the stages I go through: * Identify the problem: Product manager identifies the top customer problems to solve. * Conduct user research: Product manager schedules customer calls to validate how large of a problem it really is. They collect use cases and get feedback on any initial design concepts, which can be lightweight wireframes and not full, clickable prototypes. UX designer and engineers should be invited to the calls to hear feedback directly from customers. * Ideate: Product manager organizes a brainstorming session with the UX designer and engineers. Product manager identifies the top user stories to solve for and the entire team workshops ideas for a MVP. * Create prototypes and do user testing: UX designer takes on the lead role and creates a prototype based on the brainstorm session. They then schedule customer calls to get feedback on a clickable prototype to test ease of use and whether it solves customers' pain point. * Define product requirements: Product manager creates a document to capture product requirements once designs are finalized. While this doc can be started earlier, even as early as the "identify the problem" stage, requirements should not be finalized until you've validated what you're building with user testing. Here is a sample product requirements doc. * Build MVP: Engineers take on a lead role once requirements are finalized. It is critical that you involve engineers all the way from the start and not just at the build stage. That way by the time you're ready to start engineering work, you've aligned on requirements and expectations and have their buy-in on the project. This collaborative process should reduce any risk of being surprised by what they've built. * Release: Engineers release the product and product managers monitor customer feedback. * Continue to iterate based on feedback: Even after releasing a product, it's important to continue to iterate based on feedback. * Sunset the product [optional] : At the end of a product's lifecycle, product managers should consider sunsetting a product. While this is not a required part of the cycle for every feature release, it's important for product managers to think critically about when they need to sunset a feature to reduce clutter in their product. It's more important to have a product with helpful features rather than a product riddled with less helpful features.

When you lack resourcing whether it's engineering, design, or even product, it's critical to practice ruthless prioritization and managing expectations. Realistically there is only so much you can get done given the resources you have, so you need to work with your team to define what is within scope for a certain timeline. Once you have that, you need to align and set expectations with stakeholders and leadership. If they push you to do more, you can ask what they're willing to trade off to do what they ask. If they're in charge of resourcing you could ask for more resources and explain how much further the additional resources would get you.