Countless resources review the craft of product management, whether it’s Marty Cagan’s ‘Inspired’, Eric Ries’ ‘The Lean Startup’, Aakash Gupta’s ‘Product Growth’ Newsletter, or Lenny’s Product Newsletter. But I found that only certain parts applied to my work.
Over time, I realized why. Primarily, that product management was too broad of a definition. The craft has specialized, yet the specialties don’t get much visibility. Most materials focus on consumer products with external users, with specializations like product growth, go-to-market (GTM) or B2B. On the other hand, product management focused on internal company customers is technical work, with specializations such as Machine Learning/AI, Data, or Platforms.
Second, managing a product is different from managing a platform. A product focuses on solving a customer need, whereas a platform solves problems for multiple products. Products optimize locally. Platforms optimize globally. This inherent tension is reflected in speed, metrics, and governance. Product teams push innovation to keep competitive with the market. Platform teams sit upstream of these innovations, and prioritize reliability, efficiency, and operational stability over speed.
Camille Fournier’s 'Platform Engineering' book is the best resource I’ve come across that addresses both of these differences. It felt much closer to the realities of my daily product management work than any other content I’ve come across.
The past few years I've led internal Data and Platform Products across data engineering, data science, and analytics, while operating at the intersection of multiple organizational boundaries. One end of the spectrum are centralized platform teams; on the other is go-to-market sales. This post captures lessons gained from working across these contexts while building, operating, and scaling these products and platforms.
I’ll break this series into two posts. The first covers differences between external and internal customers, and the second covering product versus platform management.
Limited Total Addressable Market (TAM)
The TAM for external products is often an order of magnitude larger than for internal ones. Sizing the market, forecasting industry growth, and interpreting market dynamics are critical to product strategy for external teams.
Internal products are limited to the size of the company. Most internal users passively consume the output rather than actively use the product. A common example is a dashboard consumed by leadership, powered by multiple data sources and pipelines, but built and maintained by data engineers and analysts.
The builders are the active customer segment. For Data Product & Platform teams, its data engineers, data scientists, and data analysts. Some are embedded on external product teams and some centralized. Every organization’s structure and culture are different, which means any advice needs to consider the context.
In rare cases, dogfooded internal products become so successful that they evolve to be customer-facing or open-source. Amazon Web Services (AWS) was built to support their retail business before being released as an external product, and Meta’s AI Llama models are just one of many open-source tools they released.
Product Sense
Product sense is described through tools such as user discovery, segmentation, and prioritization frameworks. They're really just an approximation for taste. Taste is hard to measure. It’s closer to a feeling of appreciation or admiration when we interact with a product that’s helpful or see something beautiful.
These techniques try to capture it, but Goodhart’s law applies here, 'when a measure becomes a target, it ceases to be a good measure.' Like any craft, it’s developed through practice, experimentation, and intuition around which signals to trust and which to ignore.
External customer discovery sessions are typically highly controlled scenarios where account teams are present. They’re heavily influenced by hidden variables such as the account rep’s relationship to the customer, the customer’s team influence in their organization, or perhaps their industry. The goal is to gather enough information to pattern-match and find real signals.
The opposite is true for internal customer discovery. It’s easy to speak informally and frequently to your peers. But they may already be comfortable in how they do something and be resistant to change.
That’s when it’s important to step back and look at the bigger picture. Are you uncovering a deep enough pain point? Which metrics are you looking to impact? Answering these questions requires developing a deep understanding of their jobs to be done, hidden frictions in the organization, and iterating quickly to get buy-in and adoption.
Other risks are users being inaccurate narrators of their issues, proposing nice-to-haves that they consider critical, or not having buy-in from their stakeholders. It’s common for communication gaps between internal users and their consumers to exist. Incentives or metrics change as you cross organizational boundaries, which can lead to a lack of alignment on priorities. Others include skill gaps or team turnover on both the product user and consumer side. That’s why discussions with downstream consumers to understand the full context is also valuable.
In contrast, some users may be so supportive that they end up being too relaxed on requirements. They don’t want to make things too difficult for the Product team, but it ends up being unusable as a result. Using the early versions yourself gives a sense of how painful the experience is and identifies frictions to address.
Product sense is one of the most durable skills in product management and it’s mostly gained through years of experience of shipping products and learning from feedback loops.
Product Metrics
Selecting the right metrics depends on where the product is in its lifecycle.
The first metric to consider is confirming that product-market fit exists. Similar to taste, product-market fit is also best described as a feeling, rather than a number. Renowned venture capitalist Marc Andreesen says, “you can always feel product/market fit when it’s happening. The customers are buying the product just as fast as you can make it.” I’ve experienced product-market fit with both external and internal customers. Customers proactively follow-up for timelines and remove roadblocks to adoption. Any reasonable metric you choose will be going up and to the right.
The next set of metrics tracks product scaling. Well known topline metrics for external customers could be monthly active users (MAU), total hours watched, customer lifetime value, churn, etc. Breaking them down means getting local sub-metrics where Product teams can have more influence. For example, MAU sub-metrics could be Daily Active Users (DAU), Weekly Active Users (WAU) or even a ratio, such as DAU/MAU, which is the % of monthly customers who return daily. Individual teams can focus on sub-metrics, which then positively impacts the topline metric.
Internal customer product metrics generally fall under three categories: adoption, reliability, and efficiency. Their importance is in this priority.
Adoption is a proxy for product-market fit. A rough starting point could be tracking raw volume counts, such as the # of dashboard views or # of models using a feature store. The goal is to find a measurement that’s fast to get started, and then iterate.
Reliability is about earning users’ trust. Users want to know they can depend on your data or platform without issues. It comes in two forms. First is Service Level Expectations (SLA) and the length and frequency of downtime. Second is observability, such as pipeline success rates or # of data quality issues resolved.
Reliability feels boring because it’s invisible. It’s the absence of any issues. It’s a hard lesson to learn, but firefighting unreliable systems creates stress, burnout, and credibility loss. Systems are constantly changing with new data, user groups, or features. I’ve found it critical to reserve a healthy percentage of development capability for ongoing reliability work.
Efficiency is last because a product needs to be adopted and trusted before optimizing. It focuses on saving time, people, or vendor costs. Examples include the # of engineering hours saved with implementing a CI/CD pipeline or automated test framework.
Internal metrics are harder to track because building instrumentation is its own development effort. It’s a product sense exercise on how full-featured it needs to be. Even so, a key metric such as human hours saved is going to be mostly anecdotal or back-of-envelope. A user will share that a previous workflow might have taken them 2-3 hours because they have to move between multiple applications and make modifications at each step. A productized version is fully automated and needs just a few minutes for human review.
A final unique consideration for internal product adoption is the user migration effort to the new product or platform. Earlier, I mentioned users may already be comfortable in how they do something. The new offering needs to be significantly better for them to willingly change. In addition to human process migration, there’s technology, data, and systems involved as well. Leadership pushing new products may underestimate or even ignore the migration cost altogether. Buyer beware, the cost can be more than the value of the new offering but that’s often only learned at the end of a long, messy migration.
Stakeholder Management
Building products for internal users needs ongoing awareness of an organization’s political dynamics. Conventional signs of organizational power are team size or budget, but there are always exceptions. It might be a small team working on visible products or newly hired individuals given leeway to drive change. Keep in mind that company re-orgs happen every few years, which immediately reset power dynamics - sometimes turning allies into competitors or vice-versa.
Camille Fournier describes stakeholders using a 2x2 matrix of Power and Interest. At its core, stakeholder management is about communication. Recognize your audience and flex your language from technical to business, supported by the right metrics, to elevate your internal product team’s story.
High Power & High Interest stakeholders are the ones to stay close to and keep engaged. Direct management, management peers, or senior management of your users fall into this category. They often see relying on a peer team as a risk to their objectives. As a result, what can end up happening is they try to expand their scope to include your team. Consistent relationship building, communicating clear ownership boundaries, and keeping business impact metrics readily available helps continually reinforce your team’s value.
High Power & Low Interest stakeholders are often executives from other divisions consuming the product downstream. They’re not involved regularly. Unfortunately, you mostly hear from them when there are issues. Persistent reliability issues can create a perception that the product or team is poorly run. Reliability is the key metric for this group. They don’t have demanding needs, but need what they have to always work. Poor reliability for too long can leave the Product team vulnerable as High Power and High Interest stakeholders may align with this group to escalate concerns or drive change.
Low Power & High Interest stakeholders are the actual product users. For Data Products & Platform teams, they’re the data engineers, data scientists, data analysts, and can include downstream consumers. They’re the target personas for product discovery as they have feedback on how to improve the product and can provide use-cases that can be productized. Adoption is the key metric for this group, as it signals product-market fit and builds the story of business impact.
Low Power & Low Interest stakeholders are everyone else. They don’t use your products or are aware of your team’s scope. These stakeholders require minimal engagement beyond basic visibility.
Managing stakeholders means continuously negotiating resources, scope, and timing. Multiple stakeholders means several channels where work can be escalated and prioritized outside of the roadmap. Pragmatism requires understanding the context and being flexible, rather than reflexively saying no. Stakeholder support and goodwill is important, especially during budget planning season when there’s heavy scrutiny on investments or when times get challenging with funding.
Shadow Platforms
A unique characteristic of internal users is that they’ll go buy or build a competing product if yours doesn’t meet their needs. It may not even be a technical feature, but a non-functional requirement such as delivery speed.
Competing solutions are called shadow platforms. It’s a slippery slope, as they can negatively impact product adoption, the product team’s credibility, and increase technical debt, if not handled well.
The key tension between end-user product teams and internal product teams is about speed versus governance. End-user teams are closer to the market and incentivized to hit revenue or growth targets. Longer-term maintenance, architecture, or efficiency are secondary goals. Internal product teams, on the other hand, want to limit non-scaleable solutions that require expensive cleanup and standardization later.
I’ve experienced the challenges from both sides.
I’ve run a de-centralized data warehouse and analytics application for sales as an internal Data Product & Platform team. Speed was paramount, governance and data duplication be damned. It took years to clean up data models and implement proper governance.
On the other hand, I’ve worked with centralized Data Platform teams to enable one-off, niche features so that my Data Product team could move faster. I acknowledged the additional upfront manual work for them, but also committed to integrating to the standardized solution once it was ready. Relationships matter here because collaborating well across team boundaries requires a foundation of trust.
Understanding tradeoffs between stakeholders with conflicting goals goes a long way. There would be no platform to clean up and standardize if the business couldn’t grow and react quickly to the market. Alternatively, there would be no new features released quickly if technical debt wasn’t addressed and costs brought under control.
Pragmatism means being willing to tolerate shadow platforms during exploration, but productizing once a solution becomes repeatable or technically risky.
Conclusion
Product management for internal product teams is different from product management for external users. Core pillars such as product discovery and metrics remain the same, but the assumptions to execute are fundamentally different. Business impact can be harder to see, harder to measure, and therefore, harder to judge.
The timeless product management skills are taste and judgement. Taste is knowing what a good product looks like, implicitly captured by metrics such as adoption, reliability, and efficiency. However, other stakeholders may have different definitions of ‘good’ as they have different objectives. Reconciling between these competing perspectives is a core part of effective stakeholder management. Judgement is knowing when to be flexible in the short-term, and when to say no for longer-term benefit. Neither exist in a vacuum. Markets shift, technologies evolve, and organizations change.
Internal product management is the craft in knowing how to navigate tradeoffs that don’t have clear answers, and doing so in a way that helps the organization move faster over time.