Project Management for SaaS Development

The board has two customers, and they disagree

Most project management advice assumes a project has a start and an end. SaaS development doesn't work that way once there's a single paying customer on the product. There's no version of the plan where the team stops shipping new features to go fix things, because both are happening on the same live system, this week, at the same time.

The result is a board under constant pressure from two directions. Product wants the next roadmap item planned and estimated. Support wants the bug a customer is currently annoyed about fixed today. Both are legitimate, both are urgent by someone's definition, and a tracker that treats them as the same kind of item (sequenced by whoever shouted last) is how roadmap commitments quietly slip a sprint at a time without anyone deciding that on purpose.

What a continuous-delivery team actually needs isn't a bigger backlog. It's a way to see, in one glance, how much of this sprint's capacity just got eaten by production work, before that becomes an explanation offered after the fact. This is the specific split ShipSprint's triage inbox and per-column WIP limits are built for: production work gets sized and capped instead of just absorbed.

There's a subtler cost too: a team that's constantly interrupted starts padding every estimate to survive the interruptions, and the padding becomes indistinguishable from the actual work over time. Nobody can tell anymore whether a feature genuinely takes three weeks or whether three weeks is what's left after the interruptions that always happen.

Leadership usually only sees the symptom, not the cause: a roadmap that consistently runs behind, presented every quarter with a slightly different explanation. Without a way to actually see how much of a sprint went to production work versus planned features, "the roadmap is behind" and "the team is absorbing more incident work than anyone budgeted for" look identical from the outside, and only one of them is a team performance problem.

Triage before it becomes a Slack fire

Bug reports and incident work land in a triage inbox rather than as a message to whoever's online, which does two things at once: it stops an urgent-sounding report from jumping the queue just because it arrived loudly, and it forces someone to actually size it against the sprint before it lands on the board. Not after, when the commitment's already been quietly broken.

Per-column WIP limits do the rest of the work. When the "in progress" column is capped and a production fix has to go in, something visibly has to come out, or the column visibly overflows. That's a much more honest signal than a sprint that just runs long every single time without anyone naming why.

The GitHub sync (Team plan and up) keeps the two kinds of work honest against each other: a merged pull request for a hotfix closes its card the same way a merged feature branch does, so the record of what actually shipped this week, features and fixes both, comes from the code, not from memory at the retro.

Deciding what counts as "roadmap capacity" in the first place

Teams that handle this well tend to stop treating production work as an exception and start budgeting for it as a known cost. A fixed share of each sprint (a fifth, a quarter, whatever the historical average actually is) gets reserved before planning starts, rather than discovered as an overrun after the sprint ends.

That number comes from the same velocity data the forecast already uses, so it's not a guess dressed up as a policy. A team that's spent 30% of the last six sprints on production work isn't an anomaly that needs fixing before next quarter's roadmap gets planned. It's a fact the plan should already account for, and it's exactly the kind of fact ShipSprint's forecast is built to surface on its own, without anyone digging through six sprints of notes to find it.

The alternative, planning as if production work won't happen and then explaining every quarter why the roadmap ran behind, is the more common approach and the less useful one. It produces the same conversation every quarter instead of a number anyone can actually plan around.

There's a version of this that goes further, and it's worth naming: some teams run two effectively separate queues (a roadmap sprint and a standing "keep the lights on" allocation) rather than one blended sprint that quietly absorbs both. Whether that split makes sense depends on how volatile the production load actually is; a product with a stable, mature codebase rarely needs it, while one still shaking out early scaling issues usually does.

Keeping the roadmap honest when reality keeps interrupting it

• Reserve a portion of every sprint's capacity for production work up front, instead of discovering after the fact that it consumed the whole sprint
• Route every incoming bug report through triage, sized and prioritised, before it lands on anyone's board
• Let the forecast, not a gut feeling, say whether the roadmap is actually still on track after a rough week
• Write the postmortem where the next person doing the same debugging will actually find it

None of this makes production work stop happening. It makes it visible enough that the roadmap commitment made in the planning meeting matches the one the team can actually keep.

Same rigor as any engineering board, one plan wider

The mechanics underneath (sprints, story points, cycle time, GitHub-synced cards) are the same ones a team running a single internal project uses; see the software development use case for that side of it. What changes for a live SaaS product is the triage layer sitting in front of the board, and a forecast that accounts for interruption as a fact of life rather than an exception.

Every workspace is an isolated tenant with two-factor authentication and an admin action log, worth checking on security if your product handles customer data and your own SaaS agreement gets asked about vendor practices, which it eventually will.