Internal CMS Product ManagementDavid Hobbs

WelchmanPierpoint LLCwww.welchmanpierpoint.comApril 6, 2009

Any Content Management System (CMS) needs to be customized to a particularinstitution's requirements. This customization is not solely a technical matter, andhence needs to have someone wearing both the technical and user hats to define howthe product should work at all stages of the CMS product within the organization. Inother words, you need a

product

manager would do the following:

•

Define how the content publishing process should work

•

Work with internal training, documentation, technical support, and the technicalimplementation teams to successfully deploy and maintain a high quality solution

•

Clearly articulate the product to the internal user community, including how newfeatures of the core product impact them (for instance, if you are usingDocumentum, then how changes to the core Documentum product will affectthem)

•

Evangelize the tool (especially for initial migration)

•

Regularly interact with the user community to hear their concerns and suggestionsNote that this is different from project management, for instance the personresponsible for initial migration into a CMS. The product manager is responsible for thefull life cycle of the CMS product in an institution, and also for the quality of the deliveryoverall including documentation, training, and support. The fact that the productmanager must constantly interact with the users (and in fact wear the user hat whenworking with technical teams) to

define

and evangelize the product also differentiatesthe product manager from the program manager.Being the product manager for an internal CMS implementation is different from beingthe product manager for Adobe Photoshop. Here are some things that are unique toproduct managing an institution’s internal CMS:

•

On one level, everyone "has to" use your product. Don't think this makes your jobeasier! For one thing, different units within your organization may still try to getout of the system. Also, since people don't have a choice about which systemthey are using, they may have a bad attitude about the system in the first place.

•

You know exactly who your stakeholders are, so you should explicitly get theirinput

•

In many cases, using a CMS may still be a shift in understanding for people. Themain problem this causes for the product manager is that people may notunderstand what they are getting into enough to even tell you what they want,until you give them something they know they don't want. A potentially good wayto deal with this is to develop concrete use cases to review with users beforechoosing a CMS so they know more what's in store.

•

In many cases, people enjoy hands‐on HTML or developing web sites themselves.So you will have people upset with the tool for reasons that, by design, have beenimplemented that way (for instance, no longer having control over the wholepage).

Most of the below pointers are geared toward internal product management asopposed to generic product management, and some may not apply to your situation.Here are ten suggestions to managing an internal content publishing platform as aproduct:1)

Publicize participation

. For internal product management of a CMS, you willcertainly need to at least ask for feedback from all major stakeholders in yourorganization. As opposed to products that are bought and sold in themarketplace that need to be product managed, you have a captive audience.Unfortunately in some ways that's more complicated since users "have to" useyour product. It probably makes sense at some point to set up a group that willgovern the content publishing tool. If you do set up such a group, then definitelypublicly (on an intranet page for example) publish who comes from each groupat all governance meetings. When migrating, it also helps to display how manysites or pages have been migrated by group. Not only does this emphasize thatparticipation is important, but may even help by encouraging some healthycompetition between groups.2)

Keep all, deliver some.

You're not going to satisfy all of everyone'srequirements.

Also, some people will take your talking about or investigatingpossible solutions as an indication that something will get implemented. Forinstance, sometimes your stakeholders will ask "we've been talking about this foryears ‐‐ when is it going to be implemented?" The short answer: "possiblynever". The difference between a request and a commitment to deliver must bevery clearly delineated. One recommendation for this is to have a list whereevery unit (perhaps one person per unit can enter requests) can enter whateverrequests they want. Requests would never get deleted, but it would be clearwhich items were not committed for delivery. If you have a voting system, thenyou could encourage the person who requested the feature could lobby othersto vote. With voting in particular, you could clearly point to the request systemindicating that no one else voted for it. This also helps with the "this obviously isimportant" or "this is an institutional priority" when obviously no one isinterested enough to vote. You should have the final say on what goes into theproduct (taking into account resources, batching features in a reasonable way,and other infrastructure needs that most stakeholders are not aware of), butvoting is a solid and clear way to get important input from your stakeholders.3)

Differentiate stakeholders.

You'll naturally end up working with the people whoare actually using the content publishing system. That sounds great, but thereare three other important groups you need to keep in mind: 1) the contentowners (who probably aren't the ones who use the content publishing system),2) the overall management for the groups the content publishers work in, and 3)your actual web site visitors. The last group is the most interesting, because,after all, the site visitors are the most important stakeholders. If you have to