Act II: The Antechamber
The Wine Retailer And The Apparatus That Wasn't Maintaining Anything
The wine retailer had seven EU markets, twelve product categories, and a pricing process that had evolved over eight years into something nobody had fully mapped since the person who built it had left.
Every Monday, a member of the pricing team would pull the master catalog export and open the workbook. The workbook had a tab for each market—FR, DE, IT, ES, NL, BE, AT—and within each tab, a matrix of per-category multipliers. Sparkling wines had a row. Still wines had a row. Cases had a row. Accessories and gift sets were their own story, which was also their own tab. The multipliers were not identical across categories, and they were not identical across markets. There was a reason for each of them. The reason had mostly been written down, somewhere, at some point. The spreadsheet itself was documentation.
A second team member reviewed the output before upload. The review was sample-based. The sample size had grown as the catalog had grown. The upload files went through a compliance step—EUR prices needed to be integers in some markets, or at least that had been the understanding since 2017. Then the files got pushed.
The whole process took most of a Tuesday, when it went well.
When the migration brief arrived, there was a line marked non-negotiable:
Must preserve per-category, per-market pricing flexibility.
It said this with the weight of eight years of operational habit.
We asked, early in discovery, what the per-category differentiation was actually accomplishing.
Specifically: across the seven markets, were the markups for sparkling and still wines meaningfully different from each other?
The pricing lead opened the spreadsheet. She ran the comparison herself, in the meeting. Sparkling, Germany: 1.27. Still, Germany: 1.24. Sparkling, France: 1.31. Still, France: 1.30.
The difference was real. It also amounted to about three euros on a twenty-five-euro bottle.
We asked whether the difference had ever, to anyone’s knowledge, driven a purchasing decision. There was a pause. We asked whether the category-level splits had been set deliberately or had accumulated through individual adjustments over time. There was a longer pause.
The answer, reconstructed across two sessions, was this: the multipliers had been set deliberately, in 2017, by someone who had understood the rationale and had since left the company. Since then they had been maintained—carefully, correctly, with discipline—because they existed and because no one had asked what they were for.
The apparatus was maintaining a precision that turned out not to exist.
The requirement you inherit is not the requirement you have.
We introduced this idea earlier in this book as a hint—a thing to keep in mind for later—and now we’re saying it with the weight it deserves, in a room with a spreadsheet and seven EU markets and a pricing lead who had done her job faithfully for years, and who, when someone finally asked the right question, found that the job was different from the one she had thought she was doing.
We want to be careful here, because this is the part of the story that is easy to tell wrong.
The realization did not feel like a win. Not in the room. The spreadsheet had been built with care. The process had been staffed and documented and iterated. The Monday ritual was not waste—it was discipline, and discipline has value, and the people who had maintained it were not fools. They were doing exactly what the organization had asked of them, which was to maintain something nobody had ever examined.
This is how organizations accumulate complexity. Not through malice. Not through negligence. Through the ordinary passage of time and the ordinary human reluctance to reopen what is already running. The pricing script worked. The prices were uploaded. The markets received correct output. The fact that a flat market-level percentage would have produced the same consumer-facing prices, within rounding, for every SKU in the catalog—this was not visible from inside the process. You can only see it from outside. The migration was the first time anyone had been outside.
The pricing team built the apparatus. They maintained it well. That is not the failure. The failure is that eight years passed without anyone standing back and asking what it was for.
The question is not what do we need to replicate?
The question is: what have we been paying to maintain that we never had to have?
This question feels harsh to ask out loud. It implies, to the people in the room, that the work they have been doing may not have been necessary. It is worth asking anyway—with genuine curiosity, not accusation, because the goal is not to indict the team but to understand the organization. The migration gives you a rare excuse. Use it.
The pattern is not unique to pricing. We have seen it in checkout: fields that exist because of a tax compliance requirement from a state the brand no longer ships to, still marked required, still tested in QA, still defended in scope discussions. We have seen it in ERP integrations: a webhook that exists because an older webhook failed, the older webhook long since removed, the newer one now firing into a system that stopped receiving it sometime in the intervening years, the error emails accumulating quietly in an inbox nobody checks. We have seen it in the CMS: an approval workflow with four stages, because several years ago there was a brand voice manager who needed to sign off on all copy before publication, the brand voice manager’s role eliminated long since, the four-stage workflow maintained with care in her absence.
These are not exceptional cases. In every enterprise migration we have run at serious scale, somewhere between the discovery workshop and the build, we have found an apparatus like the pricing spreadsheet. Sometimes we have found three. They are not visible from inside the organization that maintains them. That is exactly why they persist.
The requirement you inherit is not the requirement you have. Say it again: the requirement you inherit is not the requirement you have.
There is a failure mode worth naming, because it is expensive and it is common.
When Shopify Markets says you can’t do category-level pricing rules, there are two possible responses.
The first: then we need a PIM.
The second: why did we think we needed that?
The first is not wrong. There are brands with genuine category-level pricing requirements—different margin structures by product type, contractual terms with suppliers that operate by category, catalog architectures where a flat market percentage produces genuinely wrong output. For those brands, a PIM is the right tool. The ceiling is real.
But the second response is also not wrong. And it is the one that gets asked less often, because it requires standing in front of the people who built the requirement and implying, gently, that what they built may not have been necessary. That is an uncomfortable conversation to start in discovery. It is a substantially more uncomfortable conversation to have in month six, after the PIM has been licensed, the custom feed work has been scoped and estimated, and an Expansion Store has been stood up for regional team permissions—when someone finally asks whether the category multipliers are genuinely differentiated.
Shopify Markets has real limitations. But some of the complexity it can’t accommodate was never as necessary as it appeared.
The ceiling is real. The ceiling is also a prompt. The time to take the prompt is in discovery, not in QA.
And workarounds compound. A PIM for pricing, plus custom feed work for the app stack, plus an Expansion Store for regional team access—you have built something more fragile than what you were replacing, and the maintenance overhead follows you forward. Renamed but intact.
We didn’t ask the right question early enough, in enough projects, before we understood this. (Ask us how we know.)
Dear reader: somewhere in your stack is an apparatus like this.
We cannot tell you which one. We can tell you it is there, because it is always there, and because the only organizations where it is not there are the ones who have recently come through a migration. The migration finds it. That is one of the things migrations are for.
Find it in discovery. Ask the question before you license the PIM. Ask the pricing team—not in the group meeting where the official story surfaces, but in a smaller room, with the spreadsheet open, with the question asked plainly: is the precision we are maintaining producing outcomes that matter?
They will know. They have often wondered. They are waiting for someone with standing to ask.
One more thing. Owen Caldwell, who ran his discovery workshop carefully and forwarded the solution proposal with a note that said Looking good—we’re ready to start building, has an apparatus of his own that the workshop did not surface. We are not going to say what it is yet. We will say it is there, and that Owen does not know it is there, and that by the time we return to Greycott & Co., it will have been found.
He is still in the posture, as of this writing. He has not closed it.
Whether he keeps it open long enough is the question we are carrying forward.
Here lies the pricing script.
It ran without error for eight years.
It was solving the wrong problem.