The growth budget was going up. The growth was not.
The business had already won at scale. More than ten million customers, a catalog past six hundred thousand items, an omnichannel operation that worked. And the growth curve had gone flat, which in a company that size produces a predictable response: spend more on acquisition.
That response was the problem, because it treated a structural constraint as a demand constraint. More paid traffic into a platform that could not convert or surface its own inventory well does not fix anything. It just costs more per unit of the same result.
The lever nobody was looking at
I went after the diagnostic before the roadmap, and the answer was not where the attention was.
The largest available growth lever was organic traffic, and it was being suppressed by the platform’s own architecture. Six hundred thousand SKUs and two million variants sitting on a catalog structure that had grown up with the business and never been redesigned for discovery. Search engines could not make sense of it. Neither, in a lot of cases, could customers.
That reframed everything. This was not a marketing problem to be solved with budget. It was a product and data architecture problem showing up in the revenue line.
A catalog is a decision system
This is the part that took the longest to land with stakeholders, and it is the part that generalizes.
At retail scale, the system that governs product data governs the business. Taxonomy decides what is findable. Attribute structure decides what is comparable. Variant modeling decides what is buyable without friction. Every one of those is a decision made once, upstream, usually years earlier, by someone solving a merchandising problem rather than a discovery problem. And every one of them constrains revenue, traffic, and customer experience downstream, permanently, until somebody goes back and changes it.
The organization was managing the catalog as an operational asset. It was actually the platform’s decision architecture.
The four moves
Catalog architecture and taxonomy, redesigned for 600,000+ SKUs and 2 million variants, structured for search and discovery rather than for internal merchandising convenience.
A full PIM migration, from a bespoke system to a Riversand implementation, owned from inception through production. This touched catalog structure, data governance, and the daily workflows the merchandising organization depended on, which meant it could not be run as a technical cutover. It required product, engineering, and business stakeholders aligned on one transition plan, because a migration that breaks merchandising in week two does not get a week three.
Technical SEO as a product strategy, not as a marketing channel. An architecture built for organic discovery, with measurement frameworks that connected specific product changes to specific revenue outcomes.
That measurement piece is what made the rest survivable. Without it, technical SEO work is unfalsifiable and gets cut the first time budgets tighten. With it, every change had a number attached and the program defended itself.
Decision frameworks across functions. Engineering, marketing, and operations had been prioritizing against the loudest senior opinion in the room. The frameworks replaced that with data-driven criteria, which is less about the criteria and more about giving people something to point at other than seniority.
The revenue
Organic revenue grew 331% year over year. Organic traffic grew 29%.
The gap between those two numbers is the whole story. Traffic went up modestly. Revenue went up enormously. That is what happens when the problem was never volume, it was that the right products were not findable by the right people, so the traffic that already existed was converting far below what it should have.
Sixty million dollars in incremental revenue inside twelve months, much of it from product bundling opportunities that had been invisible while the catalog data was disorganized. The product lines sustained 10 to 12% year-over-year growth. And the data-driven frameworks were adopted across the wider product organization, which is the outcome that kept paying after the specific project closed.
The duller, more useful version
The attractive version of this story is the SEO win, and it is the version that gets told, because a 331% number is easy to repeat.
The accurate version is duller and more useful. The company had a growth problem it was diagnosing as a demand problem. It was an architecture problem. The catalog structure had been set by decisions nobody revisited, and those decisions were quietly capping what the business could earn.
The technical work was real, but the decisive move was reclassifying the catalog from an operational asset into the thing that governs the platform. Once that is true, the investment case makes itself.