Your website is faced with a problem disguised as a benefit: easy changes. Adding content, functionality, or other complexity in the short term is easy, but in the long term can cause your site to sink under its own weight.
Product Thinking
Your web presence isn’t an object of art, like a model ship in a bottle. But we often treat our websites that way, for instance applauding one-off sites because they seem impressive when actually they fracture the user’s overall experience of your brand. Your website is more like a ship with a crew that needs to negotiate changing seas in order to get somewhere.
In particular, you need to think business first (where are you going and under what conditions) and consider the long term and broad impacts of any potential change you make to your site.
Business first
It’s not content first. It’s not technology first, or even user first. It’s business first. People complain about the technology when most of the problem is an ill-conceived or non-existent vision that resulted in a poorly-fitting implementation, or about content when the problem is — actually, it’s often the same thing — an unclear vision.
Fundamentally the first question is: "What do we as an organization need this website to achieve?" Everything else should flow from that. Any specific change to your site should have a good answer to the “What business objective does this improve?” question.
No one expects a racing catamaran to serve the same needs as a cruise ship. Always consider the business purpose of your website, and concentrate on that rather than if it is glitzy.
Think long term
You have an infinite number of changes you could make to your website, and demands from all angles. Most of the people making requests expect quick changes, which is understandable since fundamentally it is easy to make web changes. But you need to treat your website as a product that needs to maintain high quality over the long term. To think long term, always answer these questions for any proposed change:
How will we respond to the next request just like this (and, similarly, how will owners of similar pages react to your response to the first request)?
How will this be maintained?
If you treat this request as an exception, then someone else will ask for the exception. Before you know it, you may end up with more exceptions than your “standard.” But perhaps ever more important is the question of the long term cost of maintaining this change over time. If that new feature is trivial to implement now, it may still cost a lot over time. For example, it’s one more thing that needs to be tested since it’s something else that can go wrong at some point (probably after you and the requester have forgotten about it, but it’s out there for the site visitor).
Building a raft out of drift wood is cheaper than constructing a sturdier craft, but it probably will not last as long. Be very wary of creating one-offs (unless you plan on a limited lifetime), and generally always consider the long term impacts of your decision.
Think broadly
It takes a lot to make a high quality improvement:
Site visitors will interact with it at multiple touch points. Ensure that all the steps are high quality.
Many different teams need to coordinate to deliver the capability.For example, if something is technically implemented but the training group doesn’t teach the teams using the tool how to use it, then the “improvement” shouldn’t have been implemented in the first place.
Different disciplines need to be used. People seem to want to label themselves, and at a minimum have biases on what disciplines are the most important. But any specific change may require many disciplines to analyze and implement it, some of which may not be your core competency.
Multiple site sections may be affected.If the owner of one site section asks for a change, then consider making the change for all similar site sections.
Too often teams throw up their hands to the hard problems, and do things like create a new microsite to respond to an immediate need (which may also immediately fracture the experience for a site visitor). In general, try to only implement things that you can do in a coherent way. In fact, look to defining and tracking metrics to capture coherence (a simple example is how many pages across your entire web presence use your current logo).
Declaring you want to build an aircraft carrier might sound good, but even if you could successfully build it then operating it would still need a very large team with very specialized skills and fits within a much broader naval infrastructure. With your web presence, it’s extremely easy to create changes that don’t fully fulfill their promise by not thinking more broadly about the change.
How to product manage
The suggestions below should help you carry through and implement product thinking, but thinking business first, long-term, and broadly must anchor each of these to be effective. In many ways, the approaches below are ways of rising above the day to day requests so that you have a chance at managing your web presence coherently.
Our websites actually aren’t like ships at all in one important way: we are building our websites at the same time that they are being used. Now that we are looking at a bit more detail about how to product manage, we will step away from comparing our sites to ships.
Go with the flow
Your website frequently gets new content or content updates, “frequently” having very different meanings based on the company. Then there are functionality changes that happen as well, and these happen less frequently than your content changes. You may also have requests for new sites for a large web presence, new content contributor on-boarding, new taxonomy terms, new content types, and other changes. The point is that you have many flows of changes on your website, and you want to streamline each flow while maintaining quality.To streamline content publishing (important!), you may eliminate publishing steps. For the creation of new sites, perhaps site templates streamline the process. Obviously, a key here is setting minimum standards so that just because something is easy doesn’t mean that you create lots. So, for example, having site templates may mean that it’s both faster to create sites and maintain higher consistency, but sites should only be created if they pass minimum standards.
By streamlining the common activities, you don’t have to spend a lot of unnecessary brain time treating each request uniquely. Not only do you improve things internally, you automatically get a bit more consistency for the end user as well.
Keep phasing
Always improve your website. This shouldn’t just be on a big bang project basis.To keep phasing:
Define what you will be doing in the next phase.
Only define the next phase.
Phases should be relatively short (say, three months).
Have an ongoing schedule of when phases are defined (for example,phases are defined by the end each quarter, with input on what should be in the next phase received by the end of the second month in the quarter).
The second point is important: you don’t know what is going to come in the future, so don’t plan like you do. In other words, just plan the details of what changes you will be making for the near term. This also means that everyone can rest assured that you are ready to respond to further changes in the next phase (rather than frozen into what seemed like a good idea months ago).
Phasing means you have set up a process to discuss changes in more considered way, and also concentrates the discussion period so everyone can continue with their day-to-day job.
Respond creatively, yet firmly
Most people making requests for improvements to the website aren’t thinking broadly or long term, so don’t take their requests literally. Furthermore, have a thick skin to say “no” since many of the requests may not be worth the effort (even if you are going to be blasted for denying the request for the current phase).
If someone says they found a new charting library and need it for their web page, they may ask for standard restrictions on their page to be lifted so they can include the code they need. The right answer isn’t “sure, we’ll give you raw HTML access to that page” right away, although it’s so tempting since it’s both easy to implement and will make the requester happy. This is short term thinking since, for example, this will mean less ability to make global changes (what if you wanted to change the color scheme for your entire site including graphs?). Also, this isn’t thinking broadly since you may be overlooking the chance to talk with many stakeholders about data visualization and come up with a solution that everyone would win with. So a more creative approach might be to: a) delay any implementation so you can discuss it as a possibility for the next phase of changes, b) talk with interested and affected stakeholders about the root issue and how to address it, c) define something that could be implemented in the next phase (assuming it is high enough priority), d) implement something in the system that all stakeholders can use, and e) let them use the new functionality to create the functionality for their pages.
By creatively responding to requests rather than just taking orders, you create a gap for the chance to come up with broader and longer term approaches.
This was originally posted on Medium.