267 requirements across five markets, scored into a prioritisation the board could fund — and the basis for eighteen months of delivery that followed.
The challenge
adidas ran a global ecommerce platform and a number of markets that were not on it. Moving a market across is expensive and disruptive, so the sequence matters: go at the wrong one first and the programme spends its early credibility on a market that was never going to be easy.
The roadmap for the year already named five candidate markets and gave each of them provisional dates. What it did not have was any basis for those dates. Nobody could say how much work each market actually represented, because nobody had established what these markets did that the global platform did not already do.
So the roadmap could not be committed to. Not because it was wrong, but because there was no evidence underneath it either way.
My role
Sole consultant. I ran the interviews, built the method, wrote the board pack and presented the findings.
Duration
A single engagement, delivered solo.
Team
Worked with the product owners and group team centrally, and with the five local markets directly.
Outcomes
A scored prioritisation the board could act on, and the foundation for the eighteen months of delivery my company went on to do for adidas.
Requirements analysis
Market assessment
Prioritisation
Ecommerce
The rest of this case study is protected
The detail below covers client context, method and results. It is available on request — drop me a line and I will send the password, or enter it if you already have one.
That password is not right. Try again, or request access.
Context
The question underneath the roadmap
The temptation with a question like this is to answer it by judgement. Ask the people who know the markets, take a view, sequence accordingly. That produces an answer quickly and it is almost impossible to defend when someone senior disagrees, because there is nothing underneath it to point at.
The alternative is to make the comparison concrete: establish what the global platform already does, establish what each market does today, and let the difference between those two things be the measure of how hard that market is. Once the difference is written down requirement by requirement, complexity stops being an opinion.
That only works if the comparison is genuinely like for like. Five markets described in five different vocabularies cannot be scored against each other. Getting everyone onto one list, with one set of definitions, was most of the work.
Approach
Make complexity countable, then score it
Build the requirement set with the product owners
Requirements were generated with the product owners across six functional areas — general setup, .com, CRM, customer service, payments and omnichannel — covering everything from how a product page behaves to how a refund is settled.
Each requirement was captured once, centrally, with its status in the global codebase recorded alongside it. That central list is what makes every later comparison possible: five markets answering the same question in the same words.
Group every requirement three ways
Each one was classified as blueprint, local or delta. Blueprint means it already exists in the global codebase and is not specific to any one market. Local means the same capability, but needing market-specific configuration — a currency, a tax rate, a returns window. Delta means it either deviates from the global code or has not been built at all, and so needs investigation before anyone can size it.
The distinction does the real work in this engagement. A blueprint requirement is effectively free. A local one is configuration. Only a delta carries genuine risk, because only a delta involves work nobody has done before. Separating the three is what turns a long undifferentiated list into something you can reason about.
Interview each market against that list
I then took the same list to each of the five markets and worked through it with them, establishing their as-is position requirement by requirement: what they do today, how they do it, and what they would lose or gain by moving.
Running these myself across all five markets mattered more than it sounds. Consistency of interpretation is the whole basis of a comparative score — the moment two people are judging what counts as a deviation, the rankings stop meaning anything.
Define the to-be by comparison
With the global position and the market position both written down, the to-be proposal for each market fell out of the difference between them: what switches on, what needs configuring, what needs building, and what the market does today that would simply stop.
That last category is worth naming. A migration is usually discussed in terms of what a market gains, and the things it quietly loses are where the resistance comes from later.
267 requirements across six functional areas, grouped into blueprint, local and delta
Score complexity, operations and opportunity
Requirement complexity came straight out of the analysis: how many requirements in each market were a simple switch, how many needed development, and how many of their current capabilities fell out of scope.
Operational complexity was assessed separately, because it is where migrations actually stall. Warehousing, carrier arrangements and the notice periods on existing contracts set a floor under how fast any market can move, regardless of how simple its requirements are. A market with almost no development work can still be the slowest one, if a procurement process has to run first.
Opportunity was taken from each market’s net sales target for the year, which ranged from a few hundred thousand euros to several million. The three scores together produced the ranking.
Requirement complexity by market: simple switches, development work and capabilities falling out of scope
Put it to the board as a discussion, not a verdict
The scorecard was presented as a recommended order with the workings visible, deliberately framed as a discussion with the final priority still open. The point of showing the three scores separately rather than only the total is that it lets someone argue with the weighting rather than with the conclusion — and an argument about weighting is a productive one.
The recommendation put the least complex, most operationally ready market first, and the market carrying both the highest requirement complexity and an unstarted warehouse project last, despite it looking straightforward on a surface reading.
The market scorecard: requirement complexity, operational complexity and opportunity, combined into a priority orderThe resulting roadmap, with the checkpoint that had to be cleared before any market launch order was confirmed
Outcome
A roadmap somebody could actually commit to
267Requirements assessedAcross six functional areas
15%Classified as deltasThe rest already existed or needed configuring
5Markets scoredOn complexity, operations and opportunity
The finding that mattered most was not the ranking. It was that only 15% of the requirements were deltas — everything else either already existed in the global codebase or needed configuring rather than building. That reframes the whole programme. A migration that looks like five builds turns out to be mostly configuration with a small amount of genuinely new work, and that is a very different proposition to fund.
The ranking itself held up because the workings were visible. Presenting it as a discussion rather than a decision meant the debate happened over the weighting, in the room, rather than over the conclusion afterwards.
The durable outcome is what came next: this assessment became the basis of the work my company delivered for adidas over the following eighteen months. That is the part I would point to. A prioritisation exercise is only worth anything if somebody builds from it, and this one turned into a programme.
This engagement involved commercially sensitive material. The method and findings are described here; market revenue figures and commercial terms are not reproduced, and one market is referred to without the name used in the original.
Not every market wanted to be assessed. For some of them this was a step towards a change they had reasons to resist, and that showed up not as objection but as unavailability — sessions that could not be scheduled, meetings that slipped, questions that went unanswered. It is a far more effective form of resistance than arguing, because it costs the person nothing and it looks like a diary problem rather than a position.
I recognised what was happening early and raised it, escalating until the stakeholder had to carve out the time, which is how the work got finished — though not as fast as the client wanted. What I would do differently is the timing rather than the escalation. On an engagement that depends on people elsewhere in the business giving up time for something they may not want, the sponsor’s mandate has to be secured and visibly communicated before the first session is booked, not produced halfway through as a remedy. I would also treat a slipping diary as a finding rather than an obstacle: the markets least willing to talk were telling me something real about how the migration was going to land.
Operational complexity was assessed after the requirements work rather than alongside it, and it turned out to be the more binding constraint. Warehouse projects and carrier procurement move on their own timescales and cannot be compressed by adding people, whereas requirement complexity, in a programme that already has a platform, largely can. If I ran it again I would gather both from the start and probably weight operations higher than I did.
The classification did most of the analytical work, so its edges mattered more than I treated them at the time. The line between a local configuration and a genuine deviation was clear in most cases and properly arguable in a handful — and those are exactly the ones where an effort estimate would have been most wrong. I would have had a second person review the borderline cases rather than relying on my own consistency.
