Breaking the Health System Website Boom-Bust Cycle

Watch on YouTube | Listen on Spotify

Patients’ expectations are not going to wait for your next redesign.

AI is reshaping how patients find and evaluate health information. Internal priorities shift. A health system website launched today will face different demands long before the organization is ready to fund another major rebuild.

Yet most health systems still manage their websites in bursts. They spend a year or two planning, launch the new site, celebrate the milestone, and slowly drift back into reactive work. Several years later, the accumulated friction becomes the case for doing it all again.

Wade Holdraker has seen that cycle enough times to question the model behind it.

As AVP of Digital Strategy and Web Operations at University of Rochester Medicine, Wade is helping lead a large, ongoing modernization and replatforming effort. In our conversation, he described the problem plainly:

“We were redesigning the website, but we weren’t really changing the way the organization managed the website.”

A redesign can replace the website. Product thinking changes what happens after launch.

The redesign cycle creates a burst of progress, then reactive work returns

A redesign creates strategic focus.

For a year or two, the website has executive attention, dedicated funding, clear deadlines, and a team working toward the same launch. Decisions that have been delayed for years finally get made. Old content gets reviewed. Technology gets replaced. Stakeholders show up because the project has visibility and urgency.

Then the site launches.

The project team often gets smaller. Capital funding gives way to a tighter operating budget. The roadmap competes with new requests, internal politics, and whatever feels urgent that week. Old habits resurface.

Wade recognized that pattern across several redesigns earlier in his career. The team would launch, celebrate, and gradually return to reactive mode. A few years later, they were trying to solve many of the same problems again.

URochester Medicine experienced a version of this after launching its clinical experience. As Wade put it:

“People saw the launch as the finished product. It really was just the start.”

The new experience addressed important patient needs. It also surfaced new questions about how faculty, internal teams, and web leaders would work together to support it. They were challenges the organization now had to work through together as the website continued to evolve.

Change management was part of the answer. A redesign creates momentum, but without an operating model to sustain it, the website eventually slips back into reactive mode.

Product thinking keeps the roadmap from collapsing back into request-taking

The difference shows up in who owns the roadmap and how priorities are protected after launch.

Wade draws a clear distinction:

“Projects have start dates, end dates, and deliverables. Products need owners, roadmaps, feedback loops, ongoing investment, and continuous improvement.”

Those elements give the web team a basis for deciding what deserves attention after launch.

Earlier in URochester Medicine’s journey, Wade said the first question behind many requests was simple: “Who asked for it?” Priorities could be shaped by title, departmental budget, or whichever voice carried the most weight.

The questions are different now. Does the request solve a real user problem? Does it improve access or the patient experience? Does it support an institutional priority? Can the team execute and maintain it well?

Governance gives those questions weight.

URochester Medicine has been building an enterprise web governance structure that brings the health system and university into the same prioritization process. It does not eliminate disagreement or make every decision easy. It creates a process for deciding what moves forward when clinical, academic, and university priorities compete.

His shorthand for the problem is blunt:

“Governance sounds boring until you don’t have it.” 
- Wade Holdraker

Product thinking also gives the team permission to pause. Moving every request forward is not the same as making progress. Sometimes the responsible choice is to protect the roadmap, delay a feature, or acknowledge that a decision made today will require rework later.

Resilience lets the website change without forcing the organization to start over

Health systems cannot predict exactly how AI, search behavior, access expectations, or internal priorities will change. They can build the authority and routines to respond before another major rebuild becomes necessary.

URochester Medicine had data showing where providers worked and which services they were associated with. But data built for billing or other internal purposes did not always match what patients needed from the website. A provider might appear connected to every location where they could practice rather than the one or two locations where they actually saw patients. A broad specialty label could also imply that they treated conditions outside their real area of focus.

Moving that data into a new platform would not solve the problem. The organization needed clear ownership, reliable validation, and a way for providers and their teams to keep the information accurate as their work changed.

“Provider data is probably one of the least glamorous but most important investments.” 
- Wade Holdraker

Provider data is only one example. Without clear ownership, content and measurement decay in much the same way.

Patient expectations will keep moving. Your website should too.

Health systems will still redesign and replatform. The problem begins when those are the only moments the website meaningfully improves.

Wade’s closing point is worth carrying forward:

“Resilience doesn’t mean predicting the future correctly. It means building a team and organization that can adapt without having to start over every time.”