Skip to main content

Website Product Management

Managing a website, whether the target visitors are internal to an organization or are in the public at large, is not merely a matter of slapping together some web pages and linking them together. It's also not merely about design.

No, managing a website includes such challenges as:
  • How do you elicit and prioritize the requirements for the website?
  • How do you position and market the website to the target audience?
  • How do you test your assumptions and continuously adjust to the needs of your target audience?
Note that those who manage any product face the same challenges. In his recently-published book, Website Product ManagementDavid Hobbs teaches us how to manage websites as the "products" they are.

David was gracious enough to allow me to interview him about website product management and post his answers here. Enjoy!

Q. Why is product management important for websites?

A. Organizations are usually stuck in the rut of thinking of their web presences as a series of projects. On the face of it this may not seem like a problem: after all, some changes to websites are big enough to warrant project management techniques. That said, the emphasis causes problems in a variety of ways: a) it leads people to believe that maintaining a website is more of a technical problem, b) a focus on what’s possible (or fits within a budget) rather than what’s important, c) it overlooks ongoing change (and probably even maintenance), d) it comes too late to integrators / development shops, e) and it leads to disjointed efforts. Product management needs to drive what all those projects are doing, and also to ensure that the organization is set up for other types of changes that are smaller than projects. Fundamentally, product management needs to make sure the web presence is coherent.

Q. How is website product management different from product management elsewhere?

A. First off, it’s extremely easy to make changes to websites. Of course, some readers may think “it’s not simple to change my website,” but that is a process or implementation issue. At its core, it’s easy to make website changes. Since it’s always “live,” if you make some simple changes to HTML (or other components of the site) then the whole world sees the change. But this could also be said of products that are delivered via the web. So the real differentiator is the natural inclination for a wide range of folks to feel like they “own” parts of the site. Sometimes the ownership is legitimate, and sometimes it is less so. Of course any product has a range of stakeholders, but usually pretty much everyone (and certainly every major group) in an organization feels they own chunks of the website. That’s the reason in the book I focus on the need for everyone to think of their website as a product, and not just some central team. 

Q. When managing a website, what are the very most important things teams can do to manage them more like products?

A. For website product management, I break it down into three key ways of thinking: business first, long term, and broadly. So perhaps the most important thing teams can do is to consider each of these three aspects when considering any change. So when you are thinking about changes:

Ask first what the business need of the change is. If that isn't clear, then you probably should not do it (even if it is “easy” to do).
How will this work long term? Is this implemented in a way that will be difficult to maintain? Does it box you in for future change? Is it unnecessarily adding complexity to the implementation (or to the site visitor)?
Is this just going to benefit one group, or will it help the website broadly? 

You don’t have to buy the book to get a free flowchart to better handle website change.

Q. What activities of website product managers are the most strategic?

A. I don’t necessarily advocate that someone has the title of “website product manager.” Depending on the size of the web presence, an existing role could take on this extra responsibility. Regardless, I advocate for broad acceptance within an organization of product management thinking. 

I think the most strategic activities are: 1) defining the vision for the site, and 2) rising above the day-to-day requests in order to set a solid foundation (what I think of as getting the bones right). There is a subtle dance between these two. You can’t just declare a vision that isn't implementable. Actually, you can and people frequently do — they just aren't very helpful and usually counterproductive. The vision needs to be inspiring, grounded in the business need, and implementable. To be implementable, you need to think about how long term and on an ongoing basis how your goals will be met (just implementing once isn't enough). In particular, one of the most damaging things that can happen to a web presence are one-offs, and these happen all the time. Frequently one-offs are lauded as victories. But they often lead to an even more disjointed experience. The bones need to be defined to accommodate the types of changes that will be happening and not break.


Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

Is Customer Development Pseudoscience?

The “Science” of Lean Startup Lean startup practitioners embrace the scientific method, seeking the "truth" about what business model and strategy will lead to product success. We do so by: Formulating hypotheses Crafting and running experiments to test them Learning from the experiments Iteratively feeding our learnings back into revised hypotheses Sounds pretty scientific, at least in spirit, doesn't it? Yet this process actually neglects a key ingredient in the scientists' mode of operation. To identify what’s missing, let’s examine “customer development”. Customer Development Steve Blank is one of the pioneers of the lean startup movement. He introduced into the lean startup lexicon the term “customer development”. Customer development consists of sessions and interactions with customers to test hypotheses. For example, a product manager might interview a prospect, asking if she agrees with the product manager’s hypotheses about the problem