Success and failure. Two online product catalog projects. One delivered on time, the other never launched for five years.

Two similar projects. One succeeded. The other we walked away from — and no, it wasn't a budget problem, it wasn't the technology, and the team didn't drop the ball.

Both companies operated in similar industries. Both were large, production-scale businesses with presence across multiple markets. Both had extensive product ranges and a very similar problem: their product catalog had stopped keeping pace with the scale of the business.

The start looked promising for both. A solid brief. Meaningful conversations. Ambitious goals.

And yet the outcomes couldn't have been more different.

The fate of a product catalog project is rarely determined by design or technology. Far more often, it comes down to how the organisation makes decisions.

The brief had taken a long time to put together. It was detailed, multi-threaded, touching on everything from brand positioning to technical infrastructure. It brought together the interests of many departments and was the result of serious internal work.

The operational goals were reasonably clear: better product presentation, streamlined catalog management, PIM integrations, preparing the catalog for internationalisation, and a range of improvements to support employees in their day-to-day work. The business KPIs were fairly broad, but at that stage they didn't raise any red flags.

In both cases, we were invited to review the brief.

We discussed the assumptions, asked questions, and proposed adjustments. The early conversations looked very similar: grounded, substantive, with clear strategic threads and a coherent vision of success.

The decision was made: we take on both projects.

Workshops began, and detailed needs analyses got underway. At that point, both projects looked almost identical — equally complex, equally interesting, and a good fit for our capabilities.

Interestingly, the two projects were carried out with a considerable gap between them. That meant they were handled by almost the same team on our side — the same roles, very similar experience and skill sets. The personnel differences were minimal.

From that angle, it's hard to argue that the design team was the deciding factor.

And yet the outcomes turned out to be completely different.

In the first case, the catalog was delivered on time — which, for a project with this level of estimation risk, is by no means a given — and today it is one of the company's most important sales infrastructure assets.

The second project we walked away from. It ultimately dragged on for over five years, went through multiple vendors, saw staff come and go, and descended into chaos.

There were several reasons.

A brief that had outlived itself

The turning point in the failed project came after the first round of workshops. As we began digging into the details with people across the organisation, it became clear that the company needed something quite different from what it had described in its brief — and what it had been saying in the early meetings.

It quickly emerged that the document had taken almost two years to produce. The person who had written it had since left the company, and nobody in the organisation felt responsible for checking whether it was still relevant.

The company had simply assumed that because the brief existed, it must be correct.

The workshops rapidly turned into a battle over project scope. New opinions kept surfacing, new ideas emerged, further revisions were requested. An outdated brief had triggered a phenomenon well known in large organisations: decision paralysis.

There was no single source of truth, and any attempt to create one required involving far too many people.

In contrast, in the successful project, the brief wasn't rewritten — it was deepened. The organisation held to one direction, refining the details but never abandoning the core assumptions.

Everyone knew what framework they were working within.

Where the project sat in the organisation

The second significant difference was how each project was positioned within the organisation.

In the first company, the project was connected to board level — while at the same time, people from various levels of the organisation were actively involved.

In the second, the project sat solely at the level of the marketing director, supported by a project manager. Access to the board was closed off, and contact with representatives from other departments was severely limited.

In practice, this meant that in the first case we could analyse both strategic and operational goals, building a solution that served the interests of the whole organisation.

In the second, one person was the sole source of truth.

One project, one owner

But the most decisive factor turned out to be someone else entirely.

In the successful project, a clear owner emerged very early on — someone who took responsibility for the whole thing. Not a board member. An operational leader: someone who understood both the business realities and how the organisation worked day to day.

This person was the one who connected the knowledge from different departments, kept the work aligned with the brief, and either made decisions themselves or secured them from the right people in the organisation when disagreements arose.

And there were plenty of disagreements. Product catalog projects inevitably raise questions that organisations tend to avoid:

• which product attributes actually matter,
• which products can be meaningfully compared,
• whether data is consistent across markets,
• whether all departments are talking about products in the same language.

Those conversations are rarely easy.

In the first company, they led to decisions — helped along by a decision-making committee made up of representatives from various levels of the organisation.

In the second company, there was no real project owner. The project had been assigned to a single director-level role removed from the board, and no one operationally felt responsible for the whole.

As a result, for weeks on end the organisation couldn't make even basic decisions — completely destabilising the schedule. And the pressure kept building.

A product catalog isn't a technology project

In many companies, a product catalog is treated as an IT or marketing project.

A new CMS. A new design. A new category structure.

From that angle, the problem looks simple enough: gather requirements, design the interface, choose the technology. But reality is considerably more complex.

A product catalog is a cross-functional project. It touches sales, marketing, product development, operations, IT, customer service, and product data all at once.

Each of those areas has its own needs and its own reasoning. The project very quickly becomes a place where different interests and different visions collide.

The first company was prepared for that.

The second wasn't.

Two projects side by side

What these two projects teach us

A product catalog project quickly reveals how an organisation actually operates. It shows:

• who really makes decisions,
• who takes responsibility,
• whether the organisation can agree on a shared goal.

Paradoxically, the most important part of a catalog project happens before the first screen is designed — in the internal preparation phase.

Setting goals. Defining KPIs. Building a clear ownership structure. Getting your data in order.

Without that, a catalog very easily becomes a project of opinions rather than a tool that genuinely supports the company's growth.

We go deeper on this in our e-book

Every organisation today is grappling with the question of how to use AI — including in product catalogs. The problem is that most companies aren't ready for that conversation yet.

Great concepts and large budgets most often fail at a very early stage — at the point of those initial decisions.

That's why our e-book on modernising product catalogs spends so much time on this first stage: preparing the organisation. Because without it, even the best design team and the best technology can't deliver results.

### Download the free e-book: Build an Effective Online Product Catalog in 2026