A Project Management Playbook for E-commerce Companies

A calendar with three or four dates that override everything else

Picture an e-commerce company of around twenty-five to forty people, running its own storefront with an engineering team, a marketing team and an operations function handling catalog, inventory and fulfillment. Most of the year runs at a normal pace. Then a major sale event approaches, a festive-season push, a flash sale, a new collection launch, and for two or three weeks beforehand, everything from every department gets labeled urgent at once: catalog updates, a checkout fix, a marketing landing page, a fulfillment process change.

The pattern repeats a few times a year, predictably, which is exactly what makes it manageable in theory and chaotic in practice. Everyone knows the date is coming. What tends to break down is coordination in the final stretch, when marketing, ops and engineering are all pushing requests at each other simultaneously, and there's no shared view of what's actually committed for the launch versus what's still a hopeful ask.

This is the situation many e-commerce teams are in before they adopt a system that turns "everything is urgent" into a visible, prioritized queue with a real capacity limit behind it.

Before: urgency decided by who asked loudest, last

The first problem is that in the run-up to a sale event, requests arrive directly, a marketing lead messaging an engineer about a landing page, an ops lead messaging about an inventory sync issue, a founder messaging about a checkout flow they noticed. Each message is reasonable, but priority ends up decided by who happened to reach an engineer first, not by what actually matters most for the launch date.

The second problem is the plan itself going stale. A launch scope gets agreed weeks out, based on a guess about how much the team can realistically finish, and then nobody revisits whether that guess is holding up until the week of the event, when it's too late to do anything but cut scope under pressure.

The third problem shows up during the event itself. A live sale surfaces real bugs fast, a pricing display issue, a checkout edge case, and hotfix work has to happen immediately, but there's often no clean queue separating "must fix right now because the sale is live" from the catalog and inventory backlog that was already in progress, so one silently swallows the other.

After: a launch date that stops being a guessing game

The realistic shift for a team like this isn't that sale-event weeks stop being intense, they're always going to be busy by design. What changes is that the intensity gets organized instead of scattered. Requests land in one place instead of three inboxes, what's actually committed to the launch is a visible, capped list instead of an ever-growing one, and if the pace needed to hit the date isn't happening, the forecast says so with enough runway left to actually respond.

It's honest that a WIP limit doesn't make the underlying volume of work smaller during peak season. What it does is stop the team from silently absorbing more than it can deliver, and it keeps live-event firefighting from swallowing the catalog and inventory work that was already committed, so the week after a sale isn't spent discovering what quietly got dropped during it.