When the ship needed repairs, they ordered new sails.
A growing SaaS company accelerated feature delivery while the product beneath it needed stabilizing.
Meridian is fictional. Names, industry and details are changed; the pattern is drawn from real organizational situations.
The setup
Meridian was a mid-sized SaaS company, three years into a product that had found its market. The platform worked. Customers paid. Renewals were solid.
Underneath the healthy dashboard, response times were rising, edge cases were multiplying and the support queue was growing faster than the team could clear it. Engineers spent more time investigating production issues than building anything new.
The foundation was cracking quietly, while the visible measures of success still looked reassuring.
The decision
Leadership saw high retention, positive customer sentiment and a sales pipeline full of requests for features the product did not yet have. The obvious answer seemed to be acceleration: more features, faster delivery, a bigger roadmap.
They hired three engineers, split the team into two squads and set ambitious quarterly OKRs. The team had been signaling that something was wrong, but the message it received was clear: build, ship, deliver.
What happened
The new features shipped. Every release also added complexity to a system already struggling to carry its own weight. The engineers raised the issue in retrospectives and planning meetings. A senior developer documented the stabilization work that needed to happen first.
The document was acknowledged and moved to the backlog for 'next quarter.' The sprint board kept moving.
Six months after the acceleration decision, a major enterprise customer experienced a three-hour outage. The customer stayed, but demanded a remediation plan and a pause on new features until stability improved.
The diagnosis
Only then did leadership ask what kind of work the team actually needed to do. It had been operating like a Fishing Vessel: fast iterations, an aggressive roadmap and velocity as the main measure. In this season, it needed to behave more like a Tanker: protect reliability, reduce risk and make deliberate changes to a critical system.
The OKRs measured what was delivered. Nobody had named what the season required.
What a Compass would have changed
Before accelerating, the leaders could have asked one uncomfortable question: What type of vessel are we right now, and what would success look like in this season?
A shared answer might have meant pausing parts of the roadmap, explaining the trade-off to sales and investors, and allowing stabilization work that produced no visible new feature. It would not have been an easy decision, but it would have made the cost of continuing explicit.
The ship needed repairs. They ordered new sails.
The navigation note
Every organization has seasons when its most valuable work is nearly invisible on a sprint board: stabilizing, reducing debt and rebuilding a foundation. Without that work, everything built on top becomes more expensive to maintain.
The broken compass here was not a bad team or a bad leader. It was the absence of a shared language for naming the season and leading accordingly.