I had a conversation recently with a web team at a college who were stuck in a painfully familiar trap. They had a sprawling, chaotic website that had grown like an untended garden over the years. They knew it was letting users down. They had plenty of ideas for how to make it better. And yet, every time they tried to improve things, they hit a wall.
Sound familiar? I suspect it might.
The team had been there for years, and they had developed what I call "institutional scar tissue." Every suggestion was met with an internal voice saying "we tried that once and it didn't work" or "I don't have the power to change that." They had been worn down by years of small defeats until the only option that felt possible was incremental improvement to what already existed.
And incremental improvement, when applied to something fundamentally broken, is a bit like repainting a house with a crumbling foundation. Sure, it looks nicer from the street, but you're still one bad storm away from serious structural failure.
When you try to fix an existing website, you inherit all the reasons it became broken in the first place. Every stakeholder who fought for their pet page is still there. Every "but we've always had that section" is still lurking. Every technical limitation that forced an awkward compromise is still constraining your options.
Worse, you're starting from a position of defense. You have to justify why something should be removed or changed. The burden of proof is on you to explain why the current state is wrong, rather than on stakeholders to explain why their content deserves to exist.
This is exhausting work. And it rarely produces genuinely transformative results.
Now, if you've been reading my stuff for a while, you might be thinking "hang on, Paul. Haven't you spent years telling people not to do periodic website redesigns?" And you'd be right. I have. I've written at length about how the boom-bust cycle of website redesigns is damaging. How you end up with a shiny new site that slowly decays until someone throws a tantrum and the whole thing gets rebuilt from scratch.
Incremental improvement is almost always the better path. Small, continuous changes based on real user data. No big-bang launches. No throwing out the baby with the bathwater.
So why am I now suggesting we do exactly what I've warned against?
Because sometimes the rot runs too deep. When you're dealing with thousands of pages of redundant, outdated, and trivial content, when every attempt at incremental change gets blocked by institutional politics, when the team has been so beaten down that they can't imagine anything better, you need a different approach. Not a traditional redesign where you migrate all the old problems into a new template. Something more radical.
You need to imagine what you would build if you were starting from nothing.
The approach I suggested to this team was counterintuitive: stop trying to fix the website. Instead, imagine you're building from scratch.
If you were launching this college's online presence tomorrow with no existing site, what would you build? What are the actual tasks people need to accomplish? What questions do they have at each stage of their journey? Strip away all the accumulated cruft and think about what a prospective student genuinely needs.
For a college focused on student recruitment, it might be shockingly simple. Someone needs to find a course, understand if they can afford it, and apply. That's perhaps 200 pages of genuinely useful content. Not the thousands that currently exist.
Don't announce that you're redesigning the website. That triggers immediate defensiveness. Every stakeholder starts worrying about their territory. Before you've finished your sentence, half the room is already composing their objection.
Instead, frame the whole exercise as a thought experiment. "We're not proposing anything. We're just imagining what perfect could look like. What would we build if we had no constraints? If we were starting fresh tomorrow?"
This framing is disarming. People stop defending and start dreaming. They can engage with the vision without feeling threatened, because it's explicitly hypothetical. No one's being asked to commit to anything yet. It's like asking someone what they'd do if they won the lottery. They'll tell you all sorts of things they'd never admit to wanting otherwise.
But, don't do this thought experiment alone.
Bring in a few trusted people from other departments early in the process. Ask them what excites them about what better could look like. Let them shape the vision alongside you.
When you do this, something important shifts. It stops being "the web team's idea" and becomes a collective vision. Those collaborators become invested. They'll defend it in meetings you're not in. They'll sell it to their own teams. And if one of those collaborators happens to be a senior executive, you've just gained a powerful champion who can clear obstacles you couldn't even see.
Think of it like rolling a boulder down a hill. The hardest part is getting it moving at all. You're pushing and straining and it barely budges. But once you've got a few people pushing with you, momentum builds. Energy creates more energy. Excitement spreads. What started as a small team's thought experiment becomes something the whole organization wants to see happen.
The output of all this imagining should be something tangible. Not a document. Documents don't generate momentum. Prototypes do.
You can write the most beautifully reasoned strategy document in the world, and everyone who reads it will walk away with a slightly different interpretation of what it actually means. But show people a clickable prototype where they can move through the experience from beginning to end, and suddenly everyone is on the same page. There's no ambiguity. They can see it, click through it, and imagine themselves using it.
I often recommend teams create what I call a "shiny thing." This is a functional prototype of the ideal experience, built quickly and without worrying about all the practical constraints. It's not meant to be launched. It's meant to excite.
The UK Government Digital Service did exactly this when they were trying to transform government websites. They got a small budget to build a prototype of what better could look like, ignoring all the legacy systems and political constraints. When they published it and got public feedback, everyone loved it. That enthusiasm created the momentum to push through all the obstacles that had previously seemed insurmountable.
Once you've got people excited about this collective vision, something interesting happens. You flip the burden of proof. Anyone who objects is now the one ruining the party.
"Our CMS can't support that" stops being a conversation-ender and becomes a question: why not? Shouldn't our systems be flexible enough to deliver what users actually need? "But we've always had it" no longer works as an argument either. If it doesn't serve the vision everyone now wants, it's the thing that needs justifying.
Remember COVID? Working from home was impossible before 2020. Absolutely out of the question. IT couldn't support it, security was a nightmare, productivity would collapse. Then suddenly it wasn't impossible at all, because there was enough momentum and desire to make it happen. Organizations can change dramatically when they really want to. Your job is to make them want to.
One final piece of advice: keep your projects small and separate.
When you're trying to create a new vision, scope creep is your enemy. Someone will point out that you also need to consider existing students. Someone else will mention that the CMS is being replaced next year. Another person will want to tie in the new CRM system. Before you know it, your focused vision has become a massive, unwieldy initiative that will take years and satisfy no one.
When people try to expand the scope, don't fight them. Simply agree that their concern is important and deserves its own dedicated project. "You're absolutely right, existing student retention deserves as much attention as recruitment. We'll run that as a separate project and link the two together later."
This way, you can actually make progress on one thing instead of being paralyzed by trying to solve everything at once. Perfect is the enemy of good, and "comprehensive" is the enemy of "actually getting shipped."
If you're stuck maintaining a website that feels like a lost cause, I'd encourage you to try this approach. Stop asking "how do we fix this?" and start asking "what would we build if we were starting fresh?"
Map out what users actually need. Create a prototype of that ideal experience. Get stakeholders excited about the vision. Then, and only then, start figuring out how to make it real.
The constraints that feel immovable today might prove surprisingly flexible once people genuinely want what you're proposing. The trick is giving them something worth wanting.
If you're an in-house digital leader trying to drive this kind of change and finding the organizational politics overwhelming, I offer one-to-one coaching to help you build influence and lead with more confidence. Sometimes having someone in your corner who has navigated these waters before makes all the difference.
