We need to talk about tool sprawl
So many tools, so little flow.
Companies today use an average of 112 software platforms, up from 80 in 2020, and spend up to $3,500 per employee each year on these various tools.
You’re not over budget. You’re over-tooled.
A typical hour for a product manager might include checking a story in Jira, flipping to LaunchDarkly for feature flags, jumping to Sentry for bug reports, then to Slack for the discussion thread, then into Notion to update the status doc.
Each tool serves a purpose. But every switch costs context, and context loss is the silent killer of product velocity.
We call it the fragmentation tax, the real cost of moving fast when you’re moving between too many tools.
The fragmentation tax
The direct costs are easy to spot. A team of 10 using Jira for stories, LaunchDarkly for flags, and Amplitude for analytics might spend $50–100 per person per month. Add it up across the year and it’s noticeable, but not catastrophic.
The hidden costs are what actually hurt.
Context switching eats roughly 20–30% of productivity each week. Not just the seconds it takes to open a new tab, but the mental overhead of remembering where something lives, who last touched it, or which tool holds the source of truth for this particular decision.
Every time your team switches contexts, they lose focus, and it takes an average of 23 minutes to regain it.
Tool sprawl rarely starts with bad intent. Teams grow. Needs diversify. Each new problem—bugs, flags, analytics, deployment—earns its own “best-in-class” solution. The stack expands incrementally, and before long, the connective tissue between tools has broken down.
The problem isn’t the tools themselves. It’s what happens between them. Every handoff is a failure point. Every switch is an opportunity for information to degrade, decisions to drift, or feedback to get lost.
The damage shows up in specific ways.
Decision drift. Requirements get discussed in Slack. Half the conversation makes it into a comment thread. A quarter makes it into the actual story. By the time the feature ships, the team is working from a degraded copy of the original intent.
Feedback friction. A user reports a bug. Support logs it in Zendesk. Engineering triages it in Jira. The feature flag lives in one tool, the original story in another. Reconstructing what happened takes longer than fixing it.
Handoff failure points. PM writes the spec. Engineer asks clarifying questions in Slack. QA tests against acceptance criteria that may not match what was discussed. Support fields questions about behavior nobody documented. Each handoff multiplies the chance of misalignment.
The compounding effect. This isn’t isolated friction—it’s daily drag. A team losing 20% of its week to context switching isn’t 20% slower, it’s completely fragmented. Feedback loops that should tighten over time stay loose because information never makes it back to the decisions that prompted it.
So tool consolidation becomes not just about cutting costs, but about reducing handoffs.
The consolidation play
Most leaders treat consolidation as a finance exercise. Cut SaaS spend. Reduce seat licenses. Negotiate better terms.
But consolidation is actually a velocity exercise. It’s about restoring focus, reducing cognitive load, and tightening the feedback loop between planning, building, and learning.
Here’s how to approach it.
Map your lifecycle first. List every tool your team touches from idea to release. Include the spreadsheets, the Slack channels acting as databases, and the Google Docs nobody’s updated in months. Identify where information drops or duplicates. A story gets written in one place, discussed in another, implemented in a third, and reviewed in a fourth. Each gap creates friction. Don’t try to fix everything at once.
Build around living stories, not static tickets. Keep your rituals. Stand-ups, reviews, and retros work because your team designed them. Consolidation isn’t about changing how you work—it’s about bringing the work closer together. The goal is shared context, not forced processes.
The most successful teams share a pattern. Stories that maintain their complete context through the entire lifecycle—from idea to through deployment through learning. Think of them as living documents that evolve with your product. When decision history travels with the work, teams stop asking “why did we build it this way?” When your stories, feature flags, bugs, and engagement data share the same surface, teams spend less time syncing and more time shipping.
Start with one connection. Pick the junction causing the most pain. Maybe it’s linking feature flags to stories so you stop asking “which flag controls this?” Maybe it’s connecting bugs back to the releases that introduced them. Close that gap first. Let momentum build. When we consolidated our own workflow at Atono, we started by embedding feature flags directly in stories. The time saved wasn’t just in tool-switching, it was in reconstructing why we’d built something a certain way. The decision history lived with the work, which meant engineers spent less time asking and more time building.
Measure what actually matters. Don’t track “tools reduced” or “licenses saved.” Track cycle time. Track the percentage of work that has linked feedback. Track how often your team switches between tools to complete a single task. Those numbers tell the real story.
What we’ve learned
Teams that consolidate well share a few common patterns.
Status meetings shrink. When everyone can see the same timeline, the “where are we up to?” questions disappear. Teams spend review time on what we learned instead of what we shipped.
Engineers ask fewer clarification questions. Not because the specs got better, but because the context stopped leaking. Decisions stay attached to the stories that prompted them.
Product reviews shift focus. Instead of reconciling conflicting status docs, teams talk about what’s working and what isn’t. The conversation becomes forward-looking because everyone’s already caught up.
The velocity gain doesn’t come from working harder. It comes from removing drag.
A few pitfalls to avoid:
Integrations aren’t context. Linking two tools together doesn’t solve the problem if people still have to jump between them to understand what’s happening. Connections create convenience. Consolidation creates clarity.
Consolidation isn’t control. If you’re doing this to centralize decision-making or impose top-down visibility, you’ll optimize for the wrong things. The goal is centralizing information, not power.
Big-bang rollouts fail. Don’t try to replace five tools in one sprint. Start where friction hurts most. Build trust. Expand from there.
Don’t consolidate for finance alone. Cutting SaaS spend is a nice side effect, but if that’s your primary driver, you’ll miss the real win: getting your team back into flow.
The goal isn’t “one tool to rule them all.” It’s knowing the difference between necessary specialization and unnecessary fragmentation.
Most teams discover they’re living with the latter.
The path forward
Tool consolidation doesn’t mean doing less. It means giving your team the space to think, create, and build in flow. When context lives in one place, decisions stay sharp. Feedback loops tighten. Velocity follows.
The teams shipping fastest aren’t using fewer tools because they’re small or scrappy. They’re using fewer tools because they’ve figured out that product velocity isn’t about working harder, it’s about working in flow.
And flow breaks the moment you have to reconstruct context.
Consolidation isn’t a project—it’s a practice. It starts with understanding your current fragmentation, then methodically closing the gaps that cost you the most. When we consolidated our own stack, we moved from six tools to one integrated workflow—and doubled our engineering velocity in six months.
Ready to reduce the fragmentation tax?
See how we consolidated our stack and doubled velocity →
Hey, great read as always. Fragmentation tax is so real.