Every product team prioritizes work, but few can explain how they do it.
Ask a team lead what their team is working on, and you’ll get a clear answer. Ask them how they decided that was more important than the five other things competing for attention, and it’s suddenly not so clear.
It felt urgent. Leadership wanted it. Sales has already promised it. We’ve been meaning to get to it.
Prioritization happens constantly, often unconsciously. Teams either over-index on strategy, chasing big bets while ignoring the cracks forming underneath. Or, they hesitate to prioritize necessary work because it isn’t “strategic enough.”
At Swarmia, prioritization is intentionally decentralized, and most decisions happen at the team level. But we’ve found that decentralization only works when teams share a common foundation for making tradeoffs. Without that foundation, you get inconsistency, second-guessing, and work that falls through the cracks.
This post describes how we think about prioritization at Swarmia — a set of principles that help teams make explicit, intentional choices about where to invest their time.
Every product team is different. Teams operate in different environments and face different constraints. There’s no single correct prioritization model that works for all. (If someone tells you otherwise, they’re selling something.)
We believe teams are best positioned to make prioritization decisions. They work closely with customers during product discovery, and they understand the codebase and the operational realities of their product area. We also believe that alignment comes from shared context, because we know that detailed plans handed down from above rarely survive contact with reality.
So leadership’s job is to give teams what they need to make good decisions: company goals, market context, product strategy, customer feedback, technical and timing constraints. The decisions themselves belong to the teams.
To create shared vocabulary around prioritization, we group product work into three investment areas:
These categories resemble the balance framework we’ve written about before, with one simplification: we’ve collapsed “Productivity” into Improvements or KTLO depending on context. Breaking out Productivity makes sense for individual teams, but at the cross-team level, this three-part model is clearer and easier to reason about.
Product strategy sets direction for the whole Product team. It’s grounded in company goals, an understanding of our current situation, and explicit choices about where we believe leverage exists.
But strategy is not a complete enumeration of everything teams should work on. If your strategy document lists 47 priorities, you don’t have a strategy. You have a wish list.
A good strategy provides focus. It describes what we’re currently trying to succeed at, and clarifies which opportunities matter most right now. And equally importantly, what we are not trying to achieve right now and why we can leave that to the future.
Teams should first consider how they can meaningfully support the highest-priority strategic items. If their product area doesn’t connect to the top priority, they move down the list. Multiple teams working on the same strategic area is intentional — it increases leverage and prevents spreading efforts too thin.
But teams are also responsible for the ongoing quality and usefulness of their product area. This responsibility exists regardless of strategic initiatives. A team that ignores customer feedback or lets technical debt compound because “it’s not strategic” is failing at a core part of their job.
Product strategy is an important input, but it’s one of several. Our teams also prioritize based on:
Effective prioritization weighs these inputs against each other. A team that only responds to strategic directives will miss critical quality issues, and a team that only responds to customer escalations will never make strategic progress. The trick (and a difficult one, at that) is holding all of these in your head at once — which is why making it explicit is important.
A rough starting point for allocation across the three areas I mentioned:
This reflects a healthy investment balance for a growth-stage company. Treat it as a starting point for discussion. Anyone who tells you the exact right split without understanding your business is fooling themselves (or trying to fool you).
The right balance depends on product health, team sustainability, and context. A team inheriting a product area with significant technical debt might need to temporarily shift towards a 50/50 split between improvements and KTLO, just to stop treading water. A team working on a breakthrough feature might push strategic work to 70%. Expect the numbers to change over time. It’s healthy.
What matters most is that teams make this allocation explicit and review it regularly, rather than letting it happen by accident.
Prioritization happens at two distinct levels, and conflating them causes problems.
At the investment area level, teams decide how much effort to invest in strategic work, improvements, and KTLO. This decision should be guided by the health of the product area and the team. Within each area, teams prioritize specific work based on impact — the value created relative to effort, risk, and confidence.
Teams should continuously monitor signals like:
When teams are overwhelmed by KTLO or support, you should consciously shift effort toward stabilization and risk reduction. When product and operational health are strong, it’s appropriate to increase focus on strategic work.
Review this balance regularly. If you wait until things break, you’ve probably already paid the price.
Within each investment area, teams prioritize for impact. Volume is irrelevant.
What constitutes “impact” depends on the type of work:
The goal is always to maximize value relative to effort. Completing the most tasks or closing the most tickets is what John Cutler memorably coined the feature factory, where optimizing for output over outcomes is the default. It’s easy to fall into, and we try to avoid it, especially now that AI makes generating pure output much easier.
For meaningful work, teams should be explicit about what success looks like. A useful framing is: what evidence would convince us this helped?
Success criteria should be lightweight and proportional to the size of the work. Not everything will succeed. A measured non-result is still valuable if it informs better future decisions.
Teams should regularly review progress, assess evidence of impact, and decide whether to continue, stop, or change direction. The cadence depends on the team and current priorities — anywhere from weekly to monthly.
These reviews should drive decisions. If they’ve become status reporting rituals, something has gone wrong. But what about stopping work that isn’t delivering impact? That’s good prioritization. I’d argue the ability to stop is the clearest sign that a team actually owns its priorities.
Strategy itself isn’t static. It evolves as we learn and as the environment changes. Teams are expected to surface learnings from execution and challenge assumptions with evidence. Our teams actively shape product strategy through what they learn.
Not all work can be planned. Pretending otherwise just means your plan will be wrong. Teams should:
Cross-team dependencies should be mapped early in planning, but some will always emerge mid-cycle. When priorities conflict, dependencies block progress, or tradeoffs require broader input, teams should escalate. That’s what existing forums are for: sharing context and resolving issues that teams can’t solve alone.
The goal of all this is to make implicit decisions explicit. Every team already makes prioritization decisions. The question is whether those decisions are intentional — whether teams are consciously weighing tradeoffs, or just reacting to whoever is loudest.
(Spoiler: it’s usually whoever is loudest.)
None of this is easy, and we don’t always get it right. We’ve chased strategic work at the expense of things that needed fixing. We’ve let KTLO slip until it became urgent. We’ve said yes to too many interrupts and wondered why shipping anything felt so hard. Having this approach documented — and lived out week after week by our talented product teams — doesn’t prevent mistakes, but it makes them easier to spot and correct.
When everyone shares the same vocabulary and the same mental model, that becomes possible. Teams can articulate why they’re shifting investment toward stability. Leadership can support them instead of second-guessing them. And when something goes wrong — and it will — there’s a shared foundation to come back to.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
