How Launching Fast With WebOps Adds 5+ Years of Life to Your Site

Much of our industry is trapped in a mental prison of “relaunch” thinking. It’s one of the biggest drivers of dysfunction in the status quo. We’ve preached against this for years, and it remains one of the clearest and best ways to understand the WebOps difference. 

People understand on some level that a website should be a work in progress, a living artifact. There are grand ambitions for a breakthrough capability or integration in every yearly planning session. But the reality is that most organizations struggle with the fundamentals. Independent research shows that 80% of teams take a week or longer to affect even minor changes to their website. How do we escape this nightmare? 

Take a moment and imagine a different way. Another world is possible. Let’s follow the story of two teams over a year; one using WebOps, and the other doing a traditional relaunch. The race between these teams is illustrated on the graph below — two different lines each burning through 50 units of velocity over 12 months — but let’s talk through the narrative of what’s going on.

Image

Launch Early With an MVP or at End of a Death March

In the first leg of the journey, the WebOps way is to identify a Minimum Viable Product (MVP) as your criteria for launch. The traditional route waits for everything to be ready before going live. Because WebOps is about digital business velocity, you can let go of “pixel perfection” and focus on steady improvements. Perfect or not, those pixels have no value until they appear on a customer’s screen.

Practically, this might mean going live with improvements to only some of the web experiences or with a subset of the features and capabilities on your roadmap. But you get to value faster, with more of your resources still in the tank, which is huge, as we’ll see.

The truth is, much of the heavy lifting for a successful WebOps practice happens before a single design is sketched or a line of code is written. It starts with getting buy-in on the priorities and purpose of the website (or site portfolio). 

One common downfall of web projects is they turn into “boil the ocean” affairs, overloaded with expectations. It feels like there are a zillion stakeholders... because there are! The website is the canonical digital identity for the company, so there will be no shortage of strong opinions. 

Goal alignment is absolutely necessary to make the kinds of trade-offs necessary to successfully define “minimum viable” and get off to a fast start. That’s the path of the WebOps team. They have clarity on their mission and the resources and remit to go live on their own timing. They get to market much faster, launching just four months after their kickoff.

At this point the team on the traditional path is still working furiously behind the scenes. Big projects have a lot of complexity, so, usually, you discover things midway through that you didn’t anticipate at the beginning. It’s common for these projects to start running late. Often because a different team is needed, or fully takes over, to actually “go live,” there can be a lot of surprise setbacks and friction with the IT team that will support it after launch.

The combination of tons of expectations, delays in delivery and organizational silos ramps up the pressure. This leads to a final surge or “crunch” in month seven where the team goes all out to get to the launch. Sometimes this is a short burst of effort to get over the hump, but it can easily turn into a weeks-long (or even months-long) death march.

Post Launch: Hit the Ground Running or Running on Fumes?

So the traditional way is to get across the finish line exhausted. Your day one after launch is a team that’s on the verge of burnout. The prevailing vibe is “I’m glad that’s over,” or “never doing one of those again!” There’s energy for a few bug fixes but usually that’s about it. You downshift into a “maintenance mode.”

Contrast with the WebOps team. They probably also did a hard sprint for launch, but their scope was reasonable and there was a lot less risk. Nobody is spending Sunday night on LinkedIn responding to recruiter emails. A good rule of thumb for a WebOps implementation is that you “go live” with at least half your budget left to burn. 

The WebOps team got their MVP up and running just a few months into the project. It’s not perfect but it works, and they have a backlog and a roadmap, so they can jump right into their first iteration. They also have telemetry on their key metrics so the build → measure → learn cycle can begin.

The WebOps team is now working off a combination of organizational priorities and real-world signals. By keeping the same staff before and after going live, they didn't lose all of their velocity in a rushed handoff from builders to maintainers. The team iterating on the site knows the ins and outs.

Their content team is humming, and they’re shipping material improvements to the design, user experience, or the Martech stack every week or two. They’re showing these changes to stakeholders ahead of time to make sure they’re on-target, and building trust by following through on delivering things that didn’t make it into the initial MVP launch.

By contrast, the traditional team is struggling. The honest truth is that everything they specced out nine (or more) months ago wasn’t 100% correct. People have all kinds of change requests that are really hard to fulfill because in “maintenance mode” those resources aren’t there, and even if they were they don’t have a way to make iterative changes. They can post content with what they’ve got, assuming it was built correctly, and maybe start thinking about a point release to fix the most obvious flaws next quarter, but that’s about it.

Meet the Market with a Bang, or a Whimper

What happens to traditional projects is that the maintenance mode grinds to a halt. Trying to rewire things on the cheap without a good software development pipeline results in a lot of compromises, so the administration of the site by content editors becomes increasingly idiosyncratic and capricious. Marketing starts piling more and more tags on top of the site to try and hit their goals. Simultaneously, mounting technical debt in the underlying application makes every additional change at that level slower and riskier to deploy.

This is how so many organizations end up having to file JIRA tickets to get simple copy changes done. Their web stack is more like a late-stage game of Jenga. Staff turnover means only one or two people even understand how it works, and even those people are kind of afraid to touch it. The site gets more and more dated, and eventually after another year or two the cycle begins again (unless it can be broken; stay tuned for more on that).

For our WebOps team, the back half of the year is when they really have a chance to shine. They’re not downshifting into maintenance mode, they're upshifting, feeling their cadence, knowing their velocity. They have real market signals on what’s driving results. Now they can start doubling down and getting more ambitious with what they take on next.

WebOps teams are able to turn successful experiments into real website changes in a matter of weeks if not days. They can keep the content model and admin experience current with the needs of the business, and ensure that publishing is really democratized within the organization, building reusable components that empower non-technical team members with a “no code” approach to building out campaigns.

They’re also able to support the intricacies of the rest of the Martech stack, much of which flows directly through the website. They’re testing things before they go live, so nobody is ever surprised by a sudden drop in speed, or data getting dropped from some critical reporting pipeline. A good WebOps practice will easily go five years or more before needing to even think about another major platform upgrade.

Stay tuned for part two, where I’ll talk you through the steps to take with your organization to escape the website relaunch cycle!

UPDATE: want to read on? Check out Seven Steps to Escape the Relaunch Cycle.