Everyone wants to be a platform
We always want what someone else has
When (tech) companies grow to have multiple products (lines of business), there is a natural tendency to split into platform vs. product teams. Product teams own user-facing products or features that contribute to a user-facing product. Platform teams own horizontal functionality that is used by multiple product teams, leveraging economies of scale and providing consistency across products for user and developer benefit. We typically think of platform teams as behind-the-scenes infrastructure, but they can also own user-facing functionality, such as login or admin screens or security features. What constitutes platform functionality varies between companies over time, but the key is that platform functionality supports the product and isn't something we would sell by itself.
The behaviours of platform and product teams differ:
Platforms are used by multiple teams, products, and features.
This means they must operate at a higher bar of scale, reliability, and performance than their consumers; this is an expectation, even if not explicit. This drives more rigour in their development process; for example, their design incorporates scale. Typically, this also means feature delivery takes longer.
Platforms must be more generic as they service multiple disparate teams and products. They must be extensible where appropriate and enforce consistency across consumers (e.g., all build pipelines look the same, and all UX have the same look and feel). Consistency also means being opinionated about how a platform component is used.
Platforms are expected to be ready when a team wants to use them, especially for seemingly obvious features. Consumers have high expectations, perhaps unfairly so. It doesn't help that there are perceptions of platform teams taking longer to deliver (because of the higher quality bar they need to hold).
Product teams focus on specific use cases for their target market(s).
New products and features just need to work. They can start in beta quality with lower scale limits as they're trying to validate whether the product or feature is valuable to users; there's no point in baking in high scalability and reliability if there's no product-market fit. Technology choices are based on speed to market. Sometimes features are simply manual processes; automation comes later if there is usage.
Products and features are optimised for specific use cases. Focussing on specifics typically gives good initial user experiences and allows teams to find their product-market fit. Abstractions can come later when we understand our product. This means products and features are not easily reusable, at least initially.
As engineers, we strive to maintain clean models, as they are extensible and more easily maintained. Sometimes, these models are based on how our platforms or company works. However, we may need to compromise on the purity of our system to match users' mental models, which may be influenced by the realities of the industry or how other incumbent products work. We especially have to avoid "shipping our org chart".
Models are flawed, this included, but this has served me well and will do for this post.
You always want what someone else has
Challenges arise when platform teams want to be product teams and vice versa. When a platform team builds functionality targeted for specific use cases like a product team, it can be hard to reuse between multiple consumers, defeating the purpose of a platform. Perhaps platform functionality is released with beta quality in terms of reliability or scale, far below consumers' expectations.
Similarly, when a product team over-engineers its functionality (e.g. a brand new product designed for Google scale), time to market is longer, and the product may be too complicated for users, leading to a non-viable product.
Once these patterns set in, an ‘us versus them’ mentality can set it, which is detrimental to working together as part of one bigger team and is hard to reverse.
Why does this happen?
Company vision and strategy:
When a company says it is a platform company, it is easy for all teams to interpret it as 'we should all be platform teams'. Building a platform product certainly requires some aspects of platform thinking, but a product team executing as a platform team runs the risk of not releasing fast enough. It is valid to consider the product's reliability upfront, but high scalability is probably not necessary until you get some users.
Conversely, a product-focused company probably has more product engineers, so platform teams are staffed with product engineers who need to switch their mindset explicitly.
Perception of who is rewarded:
If leadership continually rewards product teams, e.g., celebrates their financial impact on the company, and doesn't bring up platform teams in company-wide forums, it is easy for platform teams to become deflated and then strive to release products to gain visibility. Unfortunately, this comes at the expense of providing value as a platform.
The converse can also happen, but more on an individual level. Platform engineers can achieve a broader impact on a company far more quickly than product engineers because their functionality is used by multiple organisations across the company. It is then perceived that promotions are easier for platform engineers.
Platform teams are all encouraged to act like they are building a product. Sometimes, we are pointed to the famous Amazon manifesto, which talks about all team's services being externalisable but is commonly taken to mean platform teams are building products.
Platform teams should learn many lessons from product teams, such as directly linking their work to company customer value, being proactive with users, and focusing on direct user experience (e.g., good APIs and API documentation, making it easier to externalise). However, this doesn't mean operating exactly like a product team.
Be comfortable with yourself and show empathy towards others
As an individual on a team, it is vital to understand your team's role in your organisation and the company at large. This should guide how you and your team operate to be most effective in the company, both in your day-to-day intra-team work and how your team interacts with others across the product-platform division:
Product teams also generally expect platforms to be complete and ready to go, and it is frustrating when platform features are advertised but need to be more polished as this delays product teams getting features out to end users. As platform teams, this means having reasonable foresight into what their direct customers (i.e. product teams) need ahead of time to be sufficiently complete (at platform-expected quality). This isn't always possible, so be willing to offer 'good customer service' by accommodating some quick fixes and improvements when products try (and possibly fail) to adopt your features.
When co-building platform features with products (a good pattern for shared experience features, but that is another post), platform teams should remember that product teams generally prioritise delivery velocity over feature completeness and scale. While a platform team should plan and design to an ideal long-term state (a year or two out, not ten years!), think of short incremental milestones from which an end-user can get value. Also, product teams probably don't care to hear about the long-term vision, so don't go overboard explaining it.
Platforms have to be built for scale and commonality across all consumers. This is hard and takes time. Have a little empathy for platform teams and set expectations accordingly. Don't cry bloody murder to leadership every time to get product team requirements met, as this just randomises a platform team's roadmap and makes it worse for everyone. Instead, work collaboratively, possibly deciding to take on more work in the short term (without prejudice!).
Platform and product teams can also learn much from one another:
Understanding our users goes beyond direct users to all personas our systems impact. Ultimately, a company, including its platform teams, serve end-users. Product teams are the gateway to end-user feedback; platform teams should leverage this. This extra understanding can help platform teams find suitable design constraints to meet real-world needs (versus hypothetical requirements that engineers can dream up in isolation). Platforms can also better explain how to use their features by relating to end-users, a language that product teams understand (e.g. prefer 'we shard by user account' over 'we shard by container ID'). Finally, the more platform teams can relate their work to end-users, the more easily they can justify company investment.
Platform teams are generally good at designing and operating at scale, with high transaction volumes, low latencies, and rapid incident detection and remediation. Product teams can also learn much about operational excellence from (good) platform teams when their product scales (and this knowledge is generally good for an individual engineer’s career).
It is also essential to understand your personal strengths and interests. Some engineers are better attuned to being in the platform, and others are better product engineers. Use this information to guide your career growth goals and job choices. Maybe after a long career as a platform person, you want to experience life as a product engineer (like me) or vice versa. Or if you're going to climb the ladder as an engineer, platform teams probably make that easier if that work style suits you.
Finally, as a leader (individual contributor or manager), it's critical to translate vision and strategy messages to the folk on the ground by reassuring teams of their value in the broader organisation. Yes, we're a product company, but as an infrastructure platform team, we make sure the product team's developer experience is lightning-fast so they can deliver value to customers quickly. Or, as a product team in a platform product company, our success is based on product-market fit, so let's find that first rather than designing and building for Google scale from day 1.