Maintaining platform-product fit.
In 2011, Steve Yegge wrote his Google Platforms Rant, which states “the Golden Rule of platforms is that you Eat Your Own Dogfood,” arguing that APIs are good to the extent that the folks developing them depend on their quality and feature coverage. The memo came to mind earlier this week when a coffee chat with a friend veered towards their conviction that Google Cloud lacks necessary functionality because folks within Google simply don’t build upon their cloud offering. Amazon, conversely, has their teams build extensively on AWS.
The diverging results of these approaches are perhaps most easily seen in the evolution of their respective Identity and Access Management offering. Google’s IAM historically offered an elegant interface but limited support for common usecases like sub-bucket object permissioning. Amazon’s IAM skewed towards extreme flexibility, gleefully sacrificing comprehensibility for completeness. In my opinion. Google’s platform has become much easier to start on and equipped with better defaults for new projects, but remains difficult-to-impossible to operate on as a scaled enterprise user. (Results are also measurable in quarterly earnings.)
Direct empathy, e.g. truly relying on what you build, remains the best vehicle to navigate the perennial tension in platform design between clarity and completeness. What I want to dig into a bit here is why this tradeoff is unexpectedly challenging for internal platforms. How do these internal platforms, created with their users sitting just a few desks away, suffer from a lack of user empathy?
Clarity in creation
Internal platforms come to life to support a company’s first major business. If you’re Uber, that’s ridesharing. If you’re Google, that’s search and search advertising. These initial platforms are built in close partnership between the platform creators and the folks who depend on those platforms to solve a specific, relevant and real set of constraints.
There are rare cases of novelty-driven-development that lead teams astray, but it’s far more common that these systems exercise great restraint in their technical decisions: companies that practice technical gluttony rarely stick around long enough to regret their excesses. Bespoke functionality exists only to the extent that the product core requires it. This technical restraint isn’t because it represents the team’s purest articulation of excellent technology, rather it’s a function of clear requirements and tight timelines.
Early systems are not perfect but they are perfectly appropriate to the exact needs and constraints of the business, which I sometimes think of as “Golden Age” software. Over time the period of platform product fit recedes as the company expands its product line and the engineering team to support that expansion.
Product portfolios
Rapid expansion of the original product stresses the initial architecture, but the underlying platform requirements tend to remain similar as a single product scales. As the product line matures from growth to value, you’ll make different tradeoffs, perhaps emphasizing efficient operation over productivity in developing new features, but many of the platform requirements will remain the same.
The health of venture-backed companies is evaluated through discounted future cash flow, which requires both (1) continued high growth and (2) a plausible path to positive margins. This dynamic predisposes companies to a thrist for growth that’s rarely slaked by a single maturing business line, and forces them to expand into additional business lines that are either earlier in their growth curve (and consequently have more future growth upside) or thoes that are positioned for higher margins.
This expansion into a portfolio of business lines is a defining moment for internal platforms, who have to decide how to manage the tradeoffs between supporting a huge mature business that drives the majority of their revenue today against the needs of miniscule proto-products that ought to drive the majority of future revenue.
Mature products emphasize stability, security, predictable feature development, and establishing efficient economies of scale. Early products require rapid iteration, broad exploration, user validation, and interpret most other aspects of platform quality as friction. Balancing platform priorities across these distinctive product cohorts isn’t a decision made once, but rather an ongoing series of decisions in an iterative elimination tournament. (If this sounds familiar, it’s the Innovator’s Dilemma.)
This transition from single product into product portfolios is a common juncture for internal platform groups to become misaligned with their users, as they struggle to navigate tradeoffs in an abruptly expanded possibility space.
Judging leverage
The initial strategy for most internal platform providers is forcing new products to operate with the same quality and qualities as their most mature product, despite the fact that it took that mature product years of iteration to reach its current level of refinement. This creates considerable frustration for emerging products as they–who have often had their roles sold to them aspirationally as an “internal startup” within the larger company–run into risk and quality management mechanisms designed for problems years ahead of their current needs.
It’s tempting to blame clueless internal platform architects for this oversight, but I think that’s an overly convenient narrative. Instead let’s dig into the organizational incentives and constraints a bit. After all, these are smart people whose fundamental aim is to make other teams more productive, and the same anti-patterns emerge consistently across many different companies.
Internal platforms create indirect value for the companies and teams they support, which is much harder to measure than the direct business impact enabled by product engineering teams. However, platform teams often end up competing with the product teams they support for headcount, culminating in an attempt to tally the indirect against the direct in zero-sum tabulations. This direct comparison is challenging for internal platform teams on several dimensions. Not only is their impact more abstract, but senior company leaders are typically closer to the work of product engineering teams, and rather unfamiliar with the particulars of internal enablement efforts.
This can lead to a dismal loop, where the expansion of product lines implicitly increase the demands on infrastructure teams, followed by product teams surface their frustrations in reduced platform support to leadership, who respond by reducing funding to platform teams due to retrograde impact. This cycle culminates in undersized platform teams and the emergence of homegrown pseudo-platform teams within each product team, deprieving the company of the opportunity to use technology as a leverage point. Without platform leverage, internal work downshifts the fundamental unit of progress from working software to working hours.
Experienced internal platform teams have seen this sequence play out before, and are eager to avoid this dismal loop. The natural strategy for many platform teams is to fight leverage erosion by driving all internal users onto a single, common platform. This allows them to maximize real and percieved leverage to their users, concentrating investment and support into a a single interface, one which is necessarily designed to primarily meet the needs of their loudest user: the mature product.
In this pattern, new product lines often struggle to drive new revenue and growth, as they find themselves trapped renters on a platform whose tradeoffs are inappropriate to the needs of early development. In the worst cases, these new product teams find themselves unable to plan or staff meaningful product development due to the stream of mandatory platform migrations generated by the platforms need to maximize platform leverage to justify their own existence.
This is how companies missing a structured investment thesis for their internal platforms rent-seeking behaviors, even thought everyone involved attempting to rationally maximize their impact for the company at each step along the way.
Investment theses and golden paths
When good intentions are insufficient, deliberate discussion is the next step. Any attempt to address an imbalance in platform-product-fit should start from three truths:
- there is always be more demand for platform work than supply,
- platform and product teams that compete head-to-head for headcount reach ineffective equilibriums,
- company scale culminates in diffuse platform-product requirements.
The two tools I’ve found most effective here are writing an investment thesis and defining your golden path.
An investment thesis articulates the extent to which you’ll support which product requirements over time. For example, you might specify 50% focus on the company’s core mature business, 30% on new product development, and 20% on underlying platform quality. The thesis also articulates how you’ll staff these efforts.
For staffing, a surprisingly effective format is the simplest: identify a ratio between folks working on internal platforms and the size of teams they support, and maintain that ratio. Among others, Facebook has taken this strategy surprisingly far to good success. For this year, you might decide that you’ll have one platform engineer for every four total engineers, and use that input when solving for your overall headcount.
This document is extremely powerful, because it offers the necessary constraints to cascade into the detailed conversations underneath that represent the vast majority of value in planning. Instead of arguing for more headcount or making task-level trade offs across business lines, you’re able to work with each business line independently to maximize the value of the resources that you’re able to allocate. Working collaboratively with users to maximize the shape of platform investment on behalf of their needs is far more impactful than debating the broad strokes allocations.
The other half is designing your golden path, which are a series of composable interfaces and capabilities that support the requirements of your product cohorts. You want your interfaces to appropriately support as many of your internal users as possible while supporting the smallest possible surface area in your interfaces. Periodically look at the new products being developed internally and assess if you need to extend capabilities or relax constraints to serve them.
With both, my best advice is to continue to frequently rethink your choices, and to stay as ambitious in the long-run as you are deliberate in the short-run.