AMA: Carta Sr. Director of Product Management, Anton Kravchenko on Platform Product Management

Build with, not for them. Building 0 → 1: From my experience, a new "Platform capability" that evolves behind a key initiative has a much better chance of creating leverage and driving larger organizational impact. This requires a closely integrated or even embedded team placement with a broader alignment on key outcomes. Building 1 → N: this is an area where you'd often experience a lack of internal buy-in as each team is juggling their own set of priorities. Here, I suggest starting by choosing the right tactic: 1. Stick (Enforcement): Teams have to adopt by X date, otherwise their integration with your components could break. When leveraging this strategy, ensure you have executive support to drive cross-org alignment. 2. Carrot (Incentive): This is where you have to sell teams on the value of the newer capability, so they dedicate roadmap capacity on their own. 3. Ninja (Proactive Integration): Your team goes into other teams' codebases and refactors code to use the new API, library, or component, and asks domain teams to review/validate your PRs. Reserve the "stick" method for critical infrastructure changes, emphasize "carrot" to drive voluntary adoption, and fallback to "ninja" for when centralization means faster execution on business-critical initiatives.

At Carta, we follow this framework to invent new products and then iteratively transform them into core competencies: 1. Test & Learn: A test is a non-permanent addition to our product designed to prove or disprove a specific hypothesis. Here, we emphasize speed and innovation with sufficient UX. 2. Feature MVP: A Feature MVP is a feature in which we have high confidence of good performance in our product. It aims to achieve enough user engagement to inform how we should iterate on the product. 3. Feature Iteration: This stage involves the further development of an existing feature to enhance ROI. The focus here is on improving usability and scalability. 4. Platform Capability: This is about creating a reusable and composable infrastructure that empowers other product teams. At this stage, we focus on codifying patterns into APIs to enable other teams to build on top.

Being a successful platform company means offering developers tools and reusable APIs that allow new product experiences to be quickly composed from existing building blocks. Companies that do this well become factories for new features, new products, and new businesses. My personal take on metrics is often multifaceted. I focus on (I) the overall health and success of the platform, (II) the satisfaction and productivity of the developers using it, and (III) the overall business impact.

First, I start with defining the impact. In some cases, the business could benefit from cost savings, better SLAs, or faster time to market for new products and features. It all depends on the business and market conditions, so aligning with your executive team is the first thing I'd do. Next, I focus on capturing, analyzing, and synthesizing qualitative and quantitative data inputs. Personally, I like to meet key stakeholders (PM/EM leads who lead other pillars) to understand their pain points and needs better. With these inputs, I usually generate two artifacts: (I) a platform strategy document outlining how the work we do aligns with business and market signals (II) a shared backlog among teams with RICE scores to help calibrate priority among different types of initiatives.

Whether I focus on a cluster of ICPs or individual ICPs usually depends on (I) time constraints and (II) 0-1 vs 1-N product motion. Usually, when I pitch a new idea to my executive team, I like to clearly articulate a big picture using data and trends and then deep dive into individual customer anecdotes. In other words, I combine explore and exploit strategies and limit my research with just enough data to kick off the debate. This allows me to quickly iterate on everyone's feedback and make a better decision if the cluster or individual ICP aperture is a better fit in my case.

The collaboration among different teams depends a lot on the platform components my teams are working on. For example, Infra requires a lot of collaboration with finance on costs. In contrast, our Public API Platform requires strong collaboration with Business Development as this is our channel team to partnerships. But commonly, as a Platform PM overlooking multiple areas such as Mobile, Frontend, DX, and APIs, I usually work closely with the following departments: 1. Engineering - I engage engineering leads in regular 1:1s, attend team retros, and conduct user interviews. 2. QA - I work closely with this team to capture breaking changes for key platform upgrades. 3. Finance - I align with these teams on infra / third party SaaS tools cost and projections for the new year 4. UX - I spend a lot of time working with design technologists to identify common UX gaps in our Platform 5. Customer Success - to keep the connection with the end customers and proxy their feedback to the platform teams. 

Great question. In short, platform teams mainly focus on serving internal users (commonly developers) with essential building blocks that fast-track development and offer consistency with end-user UX. Let's use Identity & Access Management (IAM) as an example. As a company introduces a new product, the development team behind it will need to ensure users can securely authenticate and manage access. What IAM offers is a standard company-wide engineering framework for how external users (your customers) authenticate across different company products and how your development teams integrate with this service in a consistent yet secure manner. Depending on where your Platform capability is within the technology stack, Platform PMs could have a different level of exposure to end users while their internal user focus remains unchanged.

Build vs buy is a common PM dilemma. As for my own challenges, a couple of examples come to mind: 1. Support & reliability - at Carta, we use Mandrill as our email service provider (ESP). The service was brought in a long time ago and, over the years, became an unsupported offering from Mailchimp. Problems included downtime, unresponsive support, and no major product updates. When we started to evaluate alternatives, we realized that the cost of change was too high, so we decided to add layers of fallback, such as an internal queue. This way, even if the service is down, we queue emails internally and resend them when the third-party service gets back online. 2. Cost - AWS & Circle CI cost was fine for us in 2020, but during the economic downturn, companies, including ours, started focusing on spend. Commonly, the cost of cloud infrastructure is some of the highest expenses after headcount, so our engineering teams naturally started to focus on optimizing the efficiency of our deployments, CI pipeline, etc. 3. Extendibility - Readme & OpenAI are the latest services we've used that offer great baseline functionality, but then we quickly ran into limitations with customization and developer community support (Readme) or rate limits and latency (OpenAI). Often, teams can engineer solutions that remedy the lack of desired functionality; however, staying on top of this with a CSM informed a better decision-making. IMO, procuring a new service is like bringing a new member on your team - they could be a huge multiplier or a detractor. Don't take shortcuts studying the candidates and doing reference checks.

The short answer is that I talk to customers a lot. Going one level deeper, I like to source customer feedback through the following channels: 1. User Interviews (Weekly) - I ensure to schedule at least 2-3 interviews per week with internal or external customers. During these meetings, I take notes and record the conversations, then share the synthesis with my teams. 2. Advisory Board (Monthly) - I find value in nurturing a customer advisory board with a diverse mix of engineering-based seniority, representatives from different codebases, and a balance of long-tenured and newer employees. I run these sessions monthly to share ideas or review our existing goals. 3. Developer Surveys (Yearly) - Depending on the size of your organization (at Carta, we have 300+ engineers), it's practical to conduct a company-wide developer survey to capture the overall sentiment and pinpoint where the problems are. Since this process is time-consuming, I like to gather feedback once or twice a year to inform my team's longer-term investments. Another great tactic to consider is crowdsourcing customer feedback via an ideas portal. This is where you allow your customers to share their ideas for your product and let everyone up-vote the best ones.