Company rebrand and website rebuild – building for portfolio discoverability

When I joined Gotransverse, the marketing department had been dissolved for about a year. I was the third hire of the rebuilt team. One of the first big things we took on — while also building sales enablement, running analyst relations, and doing everything else a lean team does — was a full company rebrand and a ground-up website rebuild, at the same time.

The rebrand got the attention. New look, new voice, the visible stuff. But the rebrand was the easy part. The hard part, the part that actually determined whether any of it worked, was the information architecture of the site — how a multi-product enterprise platform organizes itself so that a buyer, an analyst, or a search engine can find the specific thing they’re looking for. That’s the fight I want to write about, because it’s the part nobody sees and everybody underestimates.

Two projects that had to be one

The instinct is to treat rebrand and website rebuild as sequential — settle the brand, then build the site to express it. We couldn’t afford that, on time or on people, so we ran them together. That turned out to be right for a reason beyond scheduling: the brand and the architecture inform each other. You can’t finalize how the company sounds until you know what it’s organizing itself around, and you can’t structure the site until you know the story it’s telling. Doing them together forced the questions to resolve at the same time instead of one pretending to be settled while the other caught up.

It also meant the whole thing rested on a small team coordinating with a vendor partner, under real time pressure, while the product kept shipping and sales kept selling. There was no version of this where we froze the company to rebuild its front door. The plane stayed in the air.

Why the information architecture was the real problem

Here’s the thing about a complex enterprise platform: it does many related things, for several different buyers, at varying levels of technical depth. GT-M for mediation. GT-RM for revenue management. Workflow automation. Customer portal. Each of those matters to a different mix of Finance, RevOps, IT, and Product stakeholders, and each needs to be findable by someone who doesn’t yet know your product names.

The old site organized around the company’s mental model — how we thought about our products internally. That’s the default failure mode, and it’s fatal, because no buyer shares your internal mental model. A finance leader searching for “revenue leakage” doesn’t know to look for “GT-RM.” An analyst evaluating the monetization category doesn’t care about your internal product taxonomy. A search engine — or an AI answer engine — needs a structure it can parse into “this company does X for Y buyer.”

So the architecture fight was really a translation fight, the same one that runs through everything I do: reorganize the site from “here’s how we’re structured” to “here’s the problem you have, and here’s where the answer lives.” Product pages that lead with the buyer’s outcome, not the product’s name. Discoverability paths that start from how buyers actually search. A structure that an analyst can navigate to build an accurate picture of the platform without a briefing call.

Building for discoverability, including the machines

One thing that shaped the rebuild: the audience for a website’s structure isn’t only human anymore. It’s search engines, and increasingly it’s AI answer engines — the systems that read your site to decide whether to cite you when someone asks a question. That’s a real shift, and it changed how I thought about architecture.

Structuring for discoverability now means three overlapping audiences. The buyer, who needs to find their problem and your answer. The analyst, who needs to build an accurate mental model of the platform. And the machine — search crawlers and answer engines — that needs a clean, parseable structure with clear semantic hierarchy to understand and surface the site at all. A well-architected site serves all three with the same bones: clear hierarchy, outcome-led pages, unambiguous language, content that answers real questions.

I won’t pretend I had every acronym for this figured out at the time — the vocabulary around optimizing for answer engines was still forming. But the instinct was right: build the structure so a machine reading it comes away with an accurate summary of what this company does and who it’s for. If a crawler can understand you, so can a buyer.

What the rebrand actually had to do

The visible brand work — voice, look, narrative — had one job that mattered above the aesthetics: make a technically complex, somewhat intimidating enterprise platform feel credible and clear to a finance buyer without dumbing it down. Enterprise finance buyers are skeptical of marketing gloss; a rebrand that reads as slick actively hurts you with that audience. The brand had to feel substantial, precise, trustworthy — the visual and verbal equivalent of a vendor who knows what they’re talking about.

So the rebrand wasn’t about looking modern. It was about looking credible to a specific, skeptical, high-stakes buyer. Every choice got measured against that: does this make a CFO trust us more, or less?

What shifted

The rebuilt site and brand became the foundation everything else stood on. The analyst work I did — briefing Gartner, Forrester, IDC, MGI, ISG — pointed at a site that now told a coherent, accurate story, so analysts could self-serve an accurate picture between calls. The case studies had a home that made them findable. The product launches had landing pages built on a structure that could actually support them. Sales had a site they weren’t embarrassed to send a prospect to.

And it contributed to the pipeline growth we saw over the following period — not as a standalone lever, but as the substrate. Better positioning, clearer messaging, and stronger enablement all worked better because they were built on an architecture that made sense. You can’t out-message a confusing site. Fixing the foundation made everything built on top of it more effective.

What did not shift

The honest accounting.

A website rebuild is never actually done, and I need to say that clearly because “we rebuilt the site” implies a finish line that doesn’t exist. We launched a vastly better site. We also launched with known gaps, sections that needed another pass, and content debt we’re still paying down. A rebuild is the start of continuous work, not the end of a project. Anyone who tells you their site rebuild is finished either has a very simple site or isn’t looking closely.

The lean team that made this possible is also its constraint. Doing a rebrand and a rebuild with a small team under time pressure means you make triage calls constantly — this page gets the full treatment, this one gets “good enough for now.” Some of those “good enough” calls are still sitting there. I’m proud of what a small team pulled off and clear-eyed that a bigger team would have shipped fewer compromises.

And architecture decisions calcify. The information architecture we chose was right for what we knew then. As the product portfolio grows and the market shifts, some of those structural choices will need to be revisited, and structural changes are far more expensive than content changes. I tried to build in flexibility, but every architecture makes bets, and some of ours will come due.

What I would do differently

Treat the architecture as the primary project and the visuals as the expression of it — explicitly, from day one. We mostly did this, but the rebrand’s visibility kept pulling attention toward the surface. I’d formalize the priority: nail how the site is organized before litigating how it looks.

Build the discoverability structure for machines earlier and more deliberately. I got the instinct right but I’d now treat parseable, answer-engine-legible structure as a first-class requirement from the first wireframe, not something to strengthen later.

Plan the post-launch content debt into the launch. We launched and then discovered the backlog. I’d rather enumerate the known gaps before launch, publish anyway, and hand myself an honest, prioritized list — instead of letting “we’re done” quietly become the enemy of “we’re maintaining this.”

A rebrand people noticed, an information architecture people didn’t — and the second one was the one that mattered. If you’re rebuilding a site for a complex product that needs to be found by buyers, analysts, and machines all at once, send me a note. The architecture conversation is the one worth having.