OPERATIONS · SHOPIFY PLUS · 7 JANUARY 2025 · 7 MIN READ
Planning a Shopify roadmap you can actually deliver
Most ecommerce roadmaps are a list of things somebody wanted. Here is how to build one that survives contact with a trading year.
Plan a Shopify year around capacity and trading pressure rather than around a wish list. Decide how many weeks of development you actually have once peak freezes, holidays and support load are removed — for most mid-market teams that is closer to thirty than fifty — then commit only to what fits, in quarters, with one clearly named priority per quarter. Everything else goes on a list that is explicitly not committed, which is the part that makes the plan believable.
IN SHORT
- A trading year contains far fewer usable development weeks than a calendar year — count them before committing to anything.
- One named priority per quarter beats five, because five means the team decides the real order without telling you.
- Peak trading is a freeze, not a delivery window. Plan the freeze first and build the year around it.
- Anything that depends on another team — ERP, 3PL, finance, a supplier — is scheduled at their pace, not yours.
- A roadmap with no explicit "not doing" list is a wish list, because nothing has been decided.
Start by counting the weeks you actually have
A calendar year has fifty-two weeks. An ecommerce team does not get fifty-two weeks of development out of it, and the gap between those two numbers is where most roadmaps fail.
Take the year and remove the obvious: a pre-peak code freeze, which for most brands runs from late October into December; the fortnight either side of Christmas when nobody is available to fix anything; and the January returns wave, which occupies operations even if it does not occupy developers. That is already eight to ten weeks gone.
Then remove the invisible work. Support and bug fixing is rarely below fifteen percent of capacity on a store with real traffic. App maintenance, platform changes and the two Shopify Editions a year each cost days rather than hours. Somebody is on holiday. Somebody leaves.
What is left, for most mid-market teams, is closer to thirty usable weeks than fifty. A roadmap built on fifty weeks was never going to happen, and everyone involved will spend the year knowing it.
One priority per quarter, named
The most common roadmap failure is not over-commitment in total. It is five equal priorities in a quarter, which is a way of not deciding.
When five things are equally important, the order gets decided anyway — by whoever is loudest that week, or by whichever ticket a developer picks up on Monday. The decision still happens, it just happens without you and without being written down.
So name one. "Q2 is the checkout." Everything else in the quarter is either support for that, or explicitly secondary and cuttable. This feels reductive on the page and is enormously clarifying in practice, because it answers every subsequent scheduling question without a meeting.
Plan the freeze before you plan the work
Peak trading is not a quarter you deliver in. It is a quarter you protect.
Decide the freeze date first and work backwards. Anything touching checkout, payment, shipping logic or the theme needs to be live and observed for at least three weeks before the freeze, because the point of shipping early is to see it under real traffic while you can still fix it.
- Freeze date agreed with marketing, not announced to them — they have campaigns planned against the dates you are about to close.
- A written exception process, because there will be exceptions and you want them to be decisions rather than arguments.
- Everything checkout-adjacent live three weeks before the freeze, minimum.
- A rollback plan per change, tested, not assumed.
- The first fortnight after the freeze lifts reserved for what peak revealed, not for new work.
Dependencies are scheduled at somebody else’s pace
Any item that needs an ERP change, a 3PL configuration, a finance sign-off or a supplier feed is not scheduled by your team. It is scheduled by theirs, and their roadmap has different priorities on it.
The practical consequence is that these items should start earlier than their size suggests and should never be the thing a quarter depends on. An integration that is four weeks of engineering can be four months of calendar, and the difference is entirely in how quickly the other side answers.
Name the dependency and the person on the roadmap itself. "Q3: subscription migration — needs Ops to confirm billing dates by end of Q2." That sentence does more for delivery than a Gantt chart.
Write down what you are not doing
A roadmap with no "not this year" list has not decided anything. It has just sorted a wish list into an order and put dates next to the top of it.
The not-doing list is what makes the rest credible. It is also the document that prevents the same five requests being re-proposed every quarter, because the answer exists in writing with a reason attached.
Revisit it at each quarter boundary. Things move onto the roadmap from it, which is the point — but they move deliberately, replacing something, rather than being added on top of a plan that was already full.
Review quarterly, against what happened
The roadmap review that matters is not "are we on track". It is "was the thing we shipped worth the quarter we spent on it", answered with the numbers you agreed before you started.
If you cannot answer that, the problem is upstream: the item went on the roadmap without a stated outcome, so there was never a way to judge it. That is worth fixing before the next quarter, because it is the difference between a roadmap and a backlog with dates on it.
Questions this raises
How far ahead should an ecommerce roadmap go?
Commit in detail for one quarter, in outline for two, and hold the fourth loosely. Anything committed twelve months out will be renegotiated anyway once trading, platform changes and priorities move, so writing it in detail costs planning time and buys nothing.
Who should own the Shopify roadmap?
One person with authority to say no. It is usually ecommerce or digital leadership rather than a developer or an agency, because most of the decisions are commercial trade-offs rather than technical ones. An agency should shape it and cost it; it should not own it.
How much capacity should be reserved for unplanned work?
Between fifteen and twenty-five percent for a store with real traffic. Below fifteen percent, every bug pushes a planned item; above twenty-five, you are usually carrying a quality problem that is worth fixing at the source instead.
Should the roadmap include platform releases?
Yes, as reserved capacity rather than as specific items. Shopify ships two Editions a year and a steady stream of smaller changes; some will be irrelevant and one or two will force work. Reserving days for it is more honest than being surprised twice a year.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.