Thread
Over the last 9 months we’ve deleted close to 80% of the marketing footprint off ibm.com.

Tens of thousands of pages.

The result is that traffic, conversion and all our experience and NPS metrics are up.

It was a gross project but I’ll tell you about it.
First, why do this project at all?

Simple answer.

The site was impossible to manage for our teams and way too hard to understand and use for our customers.

We were paying for complexity.
The complexity we create is never without some legitimate causes.

IBM operates in well over 100 countries and our website had a sprawling universe of /cc-lc/s as a result. Like 160+.

Further, we’re a big company. Tens of billions in revenue. Hundreds of products and services.
Many people felt like showing the whole of IBM to a new customer considering one product was overwhelming. Understandable impulse.

The result was that ibm.com became a holding company of websites. Sites within sites.

Too often a mirror of the org structure.
It’s easy to guess why that’s not a great idea but it’s not absurd either.

Does it not make sense to put all IBM’s security products in a security chunk of the website?

It doesn’t end up working at scale but you need a better answer for why than lol conway’s law.
The reason it doesn’t work because all the BUs aren’t as clean in terms of normal market taxonomies as security. Compute and storage is an Infra org but users expect to see compute and storage.

So you need to thoughtfully restructure everything, pick the right hierarchies, etc.
So to recap what we have is an overly compartmentalized website, one that is too BU oriented in its structure and we’ve got 160+ copies of this thing (with varying levels of completeness) across the markets and languages we serve.
We’re going to fix this.

The project is called Simplification (codename: just build a normal website) and has three prongs:

- navigation
- core simplification
- geo simplification
And unlike other “simplifications” we had no intention of trading volume for quality.

Our goal was to cut in such a way where we thought we’d be net better across every KPI by the time we were done.
We need to convince the entire business that it’s Good Actually to blow up all the BU and Geo sites.

We started with the core/BU footprint and the argument went like this…
- NPS data says nav on the site is one of the biggest client experience problems in the company
- Our bloated solution/product category footprint (10x bigger than equivalent brands) is the culprit
- Those pages deliver a small percentage of the value and pareto is very real
We told people we thought that the poor structure of the site was preventing every single team from being more successful.

And that we could fix it while putting less than 2% of their results “at risk.”

And that the upside would more than offset that small downside.
People bought the story. Project is a go. We go into data mode.

Inventory entire footprint. We build a set of performance and SEO kpis for every page.

Put prelim keep/delete/consolidate recommendations for every page.

Create prelim new taxonomy.
We schedule 7 all day meetings with every BU. We do all of them in two weeks. Back to back to back.

I open the meeting by saying this is not a workshop. We’re going to make 200 decisions in the next 8 hours. By the end of this meeting this (sub)site will be gone.
And that’s what we did. In two weeks we redefined what the “core” of ibm.com would be.

After that we held a readout, invited every BU team, and delivered the strategy and schedule for deleting or consolidating 1k pages and deploying a new global nav.
Three months later it was live.

The new global nav was deployed to all 160+ locales on day 1 (because those still exist).

It carries over 100,000 distinct urls across all of the supported geographies.
NPS of nav on ibm.com improved by 30% immediately.

And the really cool thing was that our experience scores around content quality improved by the same amount.

It proved our hypothesis that the structure of the site impacts your perception of everything on it.
That took us just over a quarter start to finish. The minute we finished that we turned our attention to our geo footprint.

I will have to return to this thread with a part 2 because I’m on an airplane that’s about to take off.

If no one likes this I’m not finishing it 😳
I’m connected!

One thing I didn’t mention was that we didn’t just carelessly delete 1k pages.

We kept important things. We consolidated everything we could. We had places where we had 3 pages that could reasonably target the same keyword.

Now we have 1.
Everything we did delete got a next best target redirect. No sloppy home page stuff.
The traffic impact was non-existent. We put very little at risk. We handled those things with care. Plus we’ve been growing organically anyway.

The net was basically zero impact on traffic or conversion.
One other thing I’ll mention is that I’m no religious zealot. Every BU leader is someone I need to work with. We need to get this done and have other teams not feel like they got burned, that they hate what we’re doing.
My goal with every simplification exercise was to get what I needed to solve the bigger picture problem, 80% of what I’d do if it’s just me and excel alone in a room.

But I’m willing to compromise enough to keep everyone at the table.

Even better if they walk out an advocate.
Knowing where to give and where to hold the line is the real key and something for a different thread on a different day.

Now we turn to the geos…
For our geo sites we really didn’t see outstanding role models or any market consistency.

Some sites like gcp and aws are relatively simple. SAP as a ton. HubSpot does only a few langs but does them comprehensively (like translating product screens level comprehensively).
There’s just no consensus on what good is or what users expect.

We cane into the project with only a few things we had to do.

- make the site easier to manage
- not harm global performance

We did a lot of research and analysis.
We sought to answer a few key questions…

- only langs vs country/lang combos
- which langs/countries
- translation quality
- translation pervasiveness
For langs vs country/langs we ended up moving from mostly country to mostly langs.

We were having lots of duplicate content problems because the site was so big we couldn’t consistently localize so content was identical across locales.
The result was that our us-en site was effectively our global english site and we were just pretending it wasn’t.

We did user country to country site analysis for everything and found most people weren’t landing where we wanted.
We are still on this next phase of the journey but we decided that the lang approach would give us the simplest orientation and was aligned to the way our users actually experienced the site.
We built a “locale service” that provides both inferred and user provided data around country, lang and currency preferences.

Apps on ibm.com are still adopting it but it will enable us to provide country context (pricing, chat routing, etc) on global pages.
We may bring back some country sites in the future when we feel better about automation (currently adopting a new CMS!) but we think this will give us a better foundation to work from.
We only made modest changes to our lang support.

We pulled country level revenue data for all IBM, created a little lookup of official langs in every country and just built a table to figure out what we needed to cover to support most of our audience.
We explored the borderline moral argument that we should comprehensively support at least one official lang in every country we do business but the economics are untenable.

Like no chance in hell unless you are doing garbage machine translation.
Which brings us to the next point that bad translation is worse than no translation.

We did a reasonable amount of user research on this and not surprisingly people hate bad machine translation.

It destroys trust and credibility.
And as someone very focused on international SEO right now, I never understood how you’d ever earn a legitimate link to a terrible translation.

And if you can’t earn any links, you’re not going to accomplish much in unbranded traffic.

So translations need to be good.
Finally, we landed on web being the superset of translation activity for two reasons…

- assets, demos, emails, etc are all nice to have but if the web isn’t translated you’re just not visible at all
- the most important content needs are served via web (eg pricing)
That said, one very clear finding that we haven’t found a way to consistently operationalize is that the “translation imperative” is much higher in double-byte langs (Korean, Japanese, Chinese) compared to say Spanish or German.

Ideally you would do more in those markets.
However in practice that is tricky because now you have at least two dif translation depths.

It’s just more cognitive overhead. Oh this thing that works in Japanese doesn’t in German.

We need two plans now.

Not impossible but harder.
To recap…

- We went from 165 locales to 10 langs
- Support langs in web we don’t elsewhere (campaigns, media, assets, etc)
- Bias toward translation quality vs high volume of machine translated content
We had to execute this change across 3 CMSs.

We went one platform at a time and worked through “waves” of country footprints at a time.

We were deleting 5 sites a week for most of 1H 2023. We started with small markets and worked our way up to UK, India, etc.
It was a good thing we did because we had complicated issues with cascading/overlapping redirect rules (ibm.com is an old, big site) that left some things initially broken and in need of remediation.

But by the time we got to India and UK it was smooth.
By the end we had nice real-time dashboards and we could see the minute traffic within a market flipped from one footprint to another.

All that visibility, and doing it one block at a time, helped us make sure we didn’t screw anything up.
And just like core simplification we were more pragmatic than dogmatic. We let some teams hold onto local campaign and event experiences.

We didn’t want 50 pages to stop us from doing what we wanted to do with 50,000.
The net result of all this was…

- better performance for us (traffic, conversion)
- better experience for users (nav, task completion, overall perception of site and content quality)
- easier to manage site and more agile team (fewer things, better)
The “build a normal website” codename was funny but important.

It’s easy to convince yourself why some change is impossible.

The better mindset is assuming it is possible and being creative enough to figure out how.
That’s all for now. Bye.
Mentions
See All
qntm @qntm · May 20, 2023
  • Post
  • From Twitter
Extremely good thread