How Can Platform Teams Prioritize Effectively
A Practical Prioritization Framework to Help Platform Teams Balance Competing Demands Effectively
Platform teams empower product teams to deliver value faster by providing shared tools, services, and capabilities.
But their power comes with a significant challenge: prioritization.
With multiple teams relying on platform support to achieve their objectives, platform teams often find themselves pulled in different directions.
How do you balance competing demands without sacrificing long-term goals or frustrating your stakeholders?
In this article we explore:
How platform teams can prioritize their workflows effectively.
How they can balance immediate needs with organizational goals.
How to maintain strong, collaborative relationships with product teams.
If you prefer listening, you can follow the key insights from this article in an audio format— AI generated.
What is a Platform Team?
Before diving into solutions, let’s clarify what a platform team is.
In their book Team Topologies, Matthew Skelton and Manuel Pais identify four fundamental team types: Stream-aligned teams, Platform teams, Enabling teams, and Complicated subsystem teams.
For this discussion, we’ll focus on the first two.
Stream-Aligned Teams (Product Teams)
Stream-aligned teams—often referred to as Feature Teams or Product Teams—are the heart of most organizations. We’ll refer to them as Product Teams.
These teams own a single product or service aligned with a specific business domain and are closely connected to the customer.
For example, in a banking organization, a Mobile Banking App Team is a product team. They develop and maintain the app, gather customer feedback, and prioritize their work independently to deliver the best user experience.
Platform Teams
Platform teams, on the other hand, play a behind-the-scenes but equally critical role.
They build and maintain internal tools, capabilities, or services that multiple product teams rely on.
Their mission? To make product teams more autonomous by reducing cognitive load and technical complexity, or minimising duplication of effort among product teams.
For instance, a Salesforce Platform Team might focus on developing the foundational capabilities of a Salesforce platform. Product teams—like sales or marketing operations—can then leverage this foundation to create customer-focused features tailored to their specific business domains.
The success of platform teams is directly tied to the success of the product teams they support.
The Prioritization Dilemma
Platform teams are not fully autonomous.
Their workflow depends on the constant stream of demands from product teams, and these demands can be overwhelming.
Without a clear prioritization framework, platform teams may appear flexible and responsive to other teams’ demands. But this approach comes with substantial risks.
Burnout from handling endless ad-hoc requests.
Sacrificing long-term goals for short-term urgency.
Straining relationships with product teams frustrated by delays or unmet expectations.
Sound familiar? Let’s break this cycle.
Prioritization Framework for Platform Teams
No prioritization framework fits all, but here’s a proven model to inspire you. You can start with it and evolve it further so it aligns your organization’s unique dynamics.
It starts with one core principle: transparency.
Transparency between teams - fosters improved expectation management and enables better planning across teams.
Transparency in identifying bottlenecks - essential to uncover challenges in the process and to make informed, effective decisions.
Step 1. Categorize and Prioritize Work by Streams
A platform team cannot manage their workload effectively if tasks are added to their backlog without knowing the request type or its impact.
Begin by reviewing the backlog and categorising tasks into distinct streams. This will provide a clear picture of where the team’s time and effort are spent.
Once the streams are identified, prioritization can be done within each stream, allowing for a more structured approach.
This could typically look like this.
Stream 1: Ad-Hoc Support & Maintenance Requests
These are small tasks requested by product teams. Fixing bugs, making small adjustments to APIs, or providing troubleshooting support are good examples for this.
Dedicate a portion of the team’s capacity (e.g., 30%) to handle these requests while avoiding disruption to other streams.
Very often, ad-hoc tasks are time-sensitive, requiring immediate attention as they block the product team workflow. If that’s the case, address them immediately. If it is an issue discovered with no urgency to address it, you can save it with lower priority.
Stream 2: New Feature Requests from Product Teams
Larger feature requests require more careful evaluation and prioritization.
For example, if Product Team A requests a new capability—automating the export of customer data from a CRM system to their analytics dashboard to streamline reporting—it’s unwise to jump in and build it immediately without first assessing the trade-offs and determining what other work might be deprioritized.
Consider allocating around 50% of the team’s resources to a dedicated stream for such requests.
Evaluate the impact vs effort for these requests.
For example,
If the feature directly supports a high-priority objective (OKR) for the current quarter, it should be classified as high impact.
If the feature doesn’t align with immediate objectives but would significantly simplify workflows for multiple teams, it can be considered medium impact.
Features with limited or niche benefits could be deprioritized and treated with low impact unless their value becomes more apparent over time.
How you evaluate impact will depend a lot on your organization’s dynamics and any agreements or strategies established at a higher level.
Effort estimation doesn’t need to be precise. Simply categorising requests into high, medium, or low effort is usually sufficient for prioritization.
Make prioritization transparent.
Use impact and effort as the primary parameters for prioritising requests. Let these parameters be the drivers, but allow for some flexibility and ideally, make the prioritization transparent and aligned with the relevant stakeholders (see bellow in Step 3)
Stream 3: Internal Improvements and Strategic Platform Initiatives
These initiatives are typically platform-driven objectives aimed at improving scalability, reliability, or reducing technical debt. Automating deployment pipelines, refactoring codebases, or performing code cleaning are examples of this category.
It's important to allocate time for this work. Regular maintenance and code optimization often require 15–20% of the team’s capacity. Occasionally, larger initiatives, such as migrating to a new modern framework, may become a priority for the upcoming quarter, demanding a more significant allocation of resources.
Consistently dedicating effort to these improvements helps mitigate the risk of accumulating technical debt and prevents the gradual decline of the platform team's productivity.
Step 2. Track Workload and Observe Inefficiencies
Categorising work into streams makes tracking way easier and helps identify patterns that may require intervention.
Is each stream receiving the attention it needs?
Can you keep up with the pace of requests?
What is the throughput for each stream?
A common imbalance occurs when high-priority ad-hoc requests (Stream 1) consume the majority of the team’s time, leaving little to no capacity for long-term improvements.
These insights can be invaluable for refining the model, revisiting priorities with other teams, redistributing capacity, or identifying areas that may need additional investment.
Monitor the flow of work within each stream. It’s also useful to build simple dashboards to track progress per stream and make these available to other teams.
Step 3. Establish Shared Governance
To ensure transparency and alignment across teams, it’s essential to establish a shared governance model.
This can take the form of regular meetings (e.g., bi-weekly or monthly) involving representatives from both product and platform teams, as well as global product leadership. These meetings provide a forum to:
Share progress and communicate any relevant changes in capacity allocation. When important - provide insights to justify these decisions.
Discuss trade-offs and resolve conflicting priorities.
Identify under-resourced areas and bottlenecks in the process and adjust upcoming OKRs accordingly.
Adjust the prioritization framework based on observations of inefficiencies or bottlenecks.
When Prioritization Isn’t Enough: Alternative Models
Sometimes, even a solid prioritization framework isn’t enough. In such cases, you can consider alternative collaboration models: open-source contribution model and embedding platform engineers in product teams.
These models often blur the boundaries of platform ownership, shifting some responsibilities away from the platform team. While they do come with their drawbacks, they can be viable in situations where managing inter-team dependencies is critical, and time constraints are significant.
The Open-Source Contribution Model
The open-source model enables product teams to contribute directly to the platform codebase, with the platform team acting as reviewers and approvers.
The benefits of this model are clear: it scales development by distributing the workload and empowers product teams to take ownership of the tools they rely on.
However, this approach also introduces risks. The platform team no longer retains full ownership of the platform. They must establish clear contribution guidelines, maintain comprehensive documentation, and follow a rigorous review process. Without these safeguards, the platform can quickly become disorganized and difficult to manage.
This model is also not effective when the platform team serves as a specialized team such as a Center of Excellence with deep expertise in areas like Salesforce or CRM. If the product teams lack this specialized knowledge, they would be unable to contribute effectively.
Embedding Platform Engineers in Product Teams
In this model, a platform engineer temporarily joins a product team to help them with work that requires platform change.
The primary advantage of this approach is speed and direct collaboration. By working side-by-side, the embedded platform engineer gains understanding of the product team’s requirements and can focus their efforts on addressing these needs.
This model also comes with trade-offs. Embedding engineers pulls them away from their core responsibilities, potentially slowing progress on strategic platform objectives. Additionally, prolonged embedding risks platform engineers losing focus on their specialized skills and expertise.
This model is designed to be a temporary arrangement. Overusing it defeats the purpose of maintaining a specialized platform team, as it dilutes the team’s focus and strategic value.
Tips on Tooling
We don’t dive deep into tooling, but if you’re using Jira, the Atlassian stack can offers solid solutions to streamline prioritization. Here are some key features and tools to consider:
Categorization with Jira Boards: Using standard Jira boards with labels or tags you can categorize tasks by streams. This makes it simple to filter and track progress per stream.
Jira Service Management (JSM) for Ad-Hoc Requests: For high-priority support or maintenance tasks, JSM can act as a centralized intake system.
Jira Product Discovery for Feature Requests: Feature ideas or larger initiatives can be managed through Jira Product Discovery, a tool designed to align requests with organizational goals. It can support impact/effort evaluation and prioritization.
Dashboards for Transparency: Jira’s dashboards can provide real-time insights into workload, task progress, and capacity usage. Tracking the right key metrics, can help you gain quickly insights, foster better communication and data-driven decisions.
Final Thoughts
Platform teams are the foundation of many organizations, enabling product teams to work more efficiently and autonomously.
Though they often operate behind the scenes, the quality of their work is critical—not only for the success of product teams but also for the entire organization.
To be effective, platform teams must prioritize wisely, finding the right balance between immediate needs and long-term goals. By maintaining transparency in their processes, they can foster a more effective product organization and create happier, more productive teams.
How is your organization supporting its platform teams? What strategies have worked for you? Share your thoughts!
Enjoyed this read? Subscribe to Lean Product Growth for regular updates on building and scaling a successful product organization.
