Key Points:
Your site faces a constant stream of possible changes. How do you decide what to do? Let's look at the life of a requested website change (or download the one-page flowchart).
The request itself
Obviously there are lots of sources of possible change, but in this case we'll look at a requests for specific changes from a site user or backend content contributor (for example, to add personalization features to a page). One of the main things you want to do when evaluating the request is have a consistent way of considering whether to implement them. As is covered in the book Website Product Management, the answer to the request may not be a simple "yes" or "no." In fact, one of the reasons to have a clear process is to give the breathing room to potentially shift the conversation toward addressing the root business problems, sometimes even grouping together seemingly-disparate requests to resolve them in unexpected ways.
1. If it's streamlined, just do it
Content publishing should be simple and support the standard day-to-day needs. This would be an example of a self-service process, and the amount your streamline depends on your organizations (and things like how many publishers you have and how often they publish). You can also streamline things that aren't entirely self-service (for example, setting up a new conference site may be standard for your organization but still take the development team to flip some switches).
So when it comes to a specific request, if it's streamlined then just do it! Saying this is a bit of a chicken-and-egg statement, since, if you're like a lot of organizations, not much is streamlined now. Or you may have streamlined activities that should not be easy (like raw editing of HTML). But you need to sort out an easy way for people to make routine changes. Otherwise you will just always be swamped and unable to move forward.
Note: part of effectively streamlining is to have rules in place about when that activity should even occur, for instance by only creating conference sites for conferences. That sounds ridiculous to say, but of course we have all seen cases where people try to get around the intent of systems by trying to squeeze in changes where they shouldn't.
2. Apply product thinking to the request
Let's assume the requested change isn't something that's been streamlined (the above is a snippet of the the one-page flowchart). Since you should always think of your website as a product, the next step is to apply product thinking to the request, with four questions:
- Would this request move forward business goals? Clearly, not doing so should be a major ding against the request, making it unlikely to be implemented.
- Would this benefit just one group? Again, if it does then that makes it a much less attractive request. Teams sometimes argue that requests would be an experiment, but are you really committed to treating it like an experiment (for instance, you will "back out" of the experiment if it doesn't work out, and there is a reasonable path of how this could be applied to other teams).
- Can it be implemented now in a way that benefits everyone? If not, then it isn't nearly as high impact.
- Will it be implemented in a way that can be managed long term? If all these tests pass, then this request is more likely to be implemented.
3. Always phase changes
Here comes something that may be counterintuitive: waiting. Making what amounts to one-off changes are expensive, so you need time to think about the requests, and perhaps talk in detail and explore those that are the most promising. You may say, "But everyone is waiting already! This isn't a solution but a problem!" The point is to have a regularly-scheduled, ongoing review cycle. So for example, if you have a three-month cycle, then everyone knows that all the non-streamlined requests will be considered the first two weeks of every quarter. Then based on a wide range of criteria the work program is developed from these requests. Notably most requests will not be implemented in any particular cycle, and in fact many will never end up being implemented. But there is a regular cycle to consider them (with thinking about the change in light of your website being product as an important part).
If the change is not accepted, then there are two alternatives: a) not making a change to the request and having it considered again as-is in the next review schedule, and b) changing the request. This may even mean turning it back into a standard request (for instance, if the request was for a new feature to the page, the requesting team may decide to just publish the content without that feature).
Streamline, look at how the change would affect your website as a coherent product, and have a regular review cycle
Fundamentally, you need to set up a process for considering requests. One of the anchors of the process should be making it easy for people to do the most common tasks (like publishing content in an effective manner). For those that are not optimized, first look at the possible change in light of keeping your website a high quality product, and then review the changes on an ongoing basis.
