Taking a product view when managing a website project
As Digital Project Managers we’re rewarded for getting the job done, with something as satisfying as a website launch clearly declaring that we have crossed the finish line.
But, there is no finish line for the site owner.
Sites need to be constantly improving and reacting to changes, not just being redesigned, launched, and forgotten, only to repeat the cycle. Web Project Managers play the important role of getting things done, and pushing through to complete important milestones.
Especially if you’re a Web Project Manager at an agency or systems integrator, you may have many legitimate reasons to want (and need) to close out web projects, with perhaps the most important being to get paid. That said, there are many ways of doing solid product thinking even when focus on the project(s) at hand.
Why treat websites as a product
Website product management is management of an organization’s web presence for ongoing and comprehensive quality (see Manage your website like a product: stay afloat in changing seas).
Note that this is not the same as managing a particular product for a company’s website, for example, someone managing a particular magazine title for a media company that publishes many magazines, or managing a website that is specifically a product e.g. Campaign Monitor.
Ongoing management is important, ensuring the organization owning the website is always making changes to the website. This is so that the organization can react to changes in the ever-changing field that we find ourselves in, specifically setting up a process where changes are expected, managed, and executed — always.
Also, by planning for ongoing changes companies can move toward their vision incrementally, responding to the realities on the ground.
Websites should be looked at comprehensively as well. Frequently companies and agencies applaud new sites that look good on their own but actually move organizations away from their goals (see Mind the gap: quality differences in your web presence).
For instance, in working with a very large web presence recently, the top brass applauded the new sites with new features. But this was actually moving them away from their goal of providing a website where site visitors could easily browse the content (since they kept adding silos of content where people would get “trapped”).
So any changes to the website should be considered comprehensively, across the entire web presence. In many ways, product management is managing website change with a business-first mindset.
That means that every change should both be looked at broadly, but also always answering the question “Is this change moving us toward a key business goal?”
Web project management for better product management
Let’s focus on two things you can do to include product thinking in your web project management:
- Challenge stakeholders to think broadly.
- Phase in batches.
Challenge stakeholders to think broadly
Stakeholders often just care about their discipline, silo, or part of the website. Thinking broadly can mean considering the entire web presence rather than just a part of it, or fixing an existing site rather than launching a brand new one.
It can also be thinking through all the customer touch points for a change rather than the first ones everyone thinks about.
Similarly, there is usually a focus on getting things done, now. But you need to think through the long term effects of changes. This may be the hardest one as the project manager to rise above the fray and advocate for, since it may mean delivery delay, but in general you should push for implementation that can best be maintained over the long haul.
Thinking long term isn’t just implementing the requirements in the most technically-sound way, but positioning the requirements and expectations in the first place for long term success.
Not only can this broader and longer-term thinking be applied in the heat of implementation and project planning, but even in project conception e.g. in deciding to make a smaller change but across more of the site.
Underpinning this broader and longer-term approach should be a rigorous focus on what business goals are being served, rather than what new gee-whiz features are being implemented.
Phase in batches
When an organization is a) digging out of the redesign-forget cycle and b) the general feeling of being overwhelmed with what needs to be done on a website, I recommend moving to batching in changes.
As mentioned above, part of the idea is that changes are being made on an ongoing basis, and not just when a big project is happening. Only define the work program for the next phase (let’s say over the next three months). The detailed planning doesn’t happen beyond that to give room for subsequent changes that aren’t even anticipated yet.
Even if you are project managing a bigger change, such as a big website redesign, I recommend defining the project in terms of phases. One phase might be a pilot / Beta, another might be rolling out one set of changes, and another might be the full rollout of your current scope.
Each of the phases should impact the site visitor, and not just the stakeholders. The reason to do this is to get folks accustomed to thinking about their website as needing a series of phases.
Potentially, if you’re an agency, you could convince the customer to even include a batch of changes after full launch that are only identified just before (or even after) launch.
Want more thoughts on website product management? Sign up for pre-release access and discounts on David’s upcoming handbook on the topic.