Internal Content Management System (CMS) Product Management

Copyright 2009 WelchmanPierpoint

1

Internal CMS Product Management

David Hobbs

WelchmanPierpoint LLC www.welchmanpierpoint.com

April 6, 2009


2

Any Content Management System (CMS) needs to be customized to a particular institution's requirements. This customization is not solely a technical matter, and hence needs to have someone wearing both the technical and user hats to define how the product should work at all stages of the CMS product within the organization. In other 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 technical

implementation teams to successfully deploy and maintain a high quality solution • Clearly articulate the product to the internal user community, including how new

features of the core product impact them (for instance, if you are using Documentum, then how changes to the core Documentum product will affect them)

• Evangelize the tool (especially for initial migration) • Regularly interact with the user community to hear their concerns and suggestions

Note that this is different from project management, for instance the person responsible for initial migration into a CMS. The product manager is responsible for the full life cycle of the CMS product in an institution, and also for the quality of the delivery overall including documentation, training, and support. The fact that the product manager must constantly interact with the users (and in fact wear the user hat when working with technical teams) to define and evangelize the product also differentiates the product manager from the program manager. Being the product manager for an internal CMS implementation is different from being the product manager for Adobe Photoshop. Here are some things that are unique to product managing an institution’s internal CMS: • On one level, everyone "has to" use your product. Don't think this makes your job

easier! For one thing, different units within your organization may still try to get out of the system. Also, since people don't have a choice about which system they 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 their input

• In many cases, using a CMS may still be a shift in understanding for people. The main problem this causes for the product manager is that people may not understand 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 way to deal with this is to develop concrete use cases to review with users before choosing 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 been implemented that way (for instance, no longer having control over the whole page).


3

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

1) Publicize participation. For internal product management of a CMS, you will certainly need to at least ask for feedback from all major stakeholders in your organization. As opposed to products that are bought and sold in the marketplace that need to be product managed, you have a captive audience. Unfortunately in some ways that's more complicated since users "have to" use your product. It probably makes sense at some point to set up a group that will govern the content publishing tool. If you do set up such a group, then definitely publicly (on an intranet page for example) publish who comes from each group at all governance meetings. When migrating, it also helps to display how many sites or pages have been migrated by group. Not only does this emphasize that participation is important, but may even help by encouraging some healthy competition between groups.

2) Keep all, deliver some. You're not going to satisfy all of everyone's requirements. Also, some people will take your talking about or investigating possible solutions as an indication that something will get implemented. For instance, sometimes your stakeholders will ask "we've been talking about this for years ‐‐ when is it going to be implemented?" The short answer: "possibly never". The difference between a request and a commitment to deliver must be very clearly delineated. One recommendation for this is to have a list where every unit (perhaps one person per unit can enter requests) can enter whatever requests they want. Requests would never get deleted, but it would be clear which items were not committed for delivery. If you have a voting system, then you could encourage the person who requested the feature could lobby others to vote. With voting in particular, you could clearly point to the request system indicating that no one else voted for it. This also helps with the "this obviously is important" or "this is an institutional priority" when obviously no one is interested enough to vote. You should have the final say on what goes into the product (taking into account resources, batching features in a reasonable way, and other infrastructure needs that most stakeholders are not aware of), but voting 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 who are actually using the content publishing system. That sounds great, but there are three other important groups you need to keep in mind: 1) the content owners (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


4

spend a staff‐year to implement a feature that only impacts your power‐users when you could spend a staff‐month on a feature that improves the lives of your site visitors, then it probably makes sense to work on the one that affects all visitors. This may end up being difficult to argue since your users may try the argument that the software "should" work this way so it should be implemented.

4) Ask for details. It's very easy for users to lob complaints like "search doesn't work" (or more colorfully‐worded variants). There are several reasons you won't want to just take this sort of feedback as‐is: a) it may not be literally true (for example, perhaps they don't even have a relevant page to show up in search results), b) it may not be accurate anymore (you may have made great strides in search but the impression persists), c) it isn't actionable (if you take back "search doesn't work" to the technical team, after laughing at you, they won't know where to start), and d) it isn't measurable/repeatable (for instance, how will you know you've resolved the issue?). Ideally you want to be able to reproduce the problem yourself, but, at a minimum, you should witness the issue yourself. Also, you should drive to understand exactly what behavior they wish to see. Obviously this isn't an appropriate approach when a problem is intermittent.

5) Know details, as well as underlying technologies, to creatively solve problems. Your job isn't to do exactly what the client asks. In fact, if you do everything that everyone asks, something is almost certainly wrong (for instance, you’ll end up with an inconsistent and difficult‐to‐maintain system). You should know the system as well as any user, and know the other requests that users have made. With that background, you can quickly respond intelligently and creatively to issues that clients raise in meetings or even hallways (rather than having to go back to the technical team all the time). You’ll be able to suggest alternate approaches that satisfy more users, are more stable, or help the person more constructively. In particular, you should work out responses to common issues that people raise (such as "But I can do this in Dreamweaver!").

6) Publish a product schedule. If the process surrounding your product management ends up taking off, then people may feel that you're "doing the right thing" and not watching you like a hawk. That said, they will want to at least know they can go to one place and get information on what's happening. No one will expect you to meet absolutely every one of your deadlines, but they'll want to see that you're making most.

7) Day‐to‐day product support. This will probably happen naturally (at least as an “escalation point” for tough issues that others can’t solve), but it helps to be part of day‐to‐day product support for your product, so you both know more details about your product but also get a more visceral feel for the problems your users are facing.

8) A stakeholder group and process with teeth. It may make sense to create a stakeholder group with a clear process for steering changes to the product. If


5

you do form such a group, participation isn't just for fun ‐‐ in fact, chances are it isn't that fun but a lot of hard work. So people have to have a reason to participate. A key way is to ensure that this group really has teeth, meaning that decisions made won’t be ignored (for instance, by top management overturning decisions or by people saying “I was on vacation when that decision was made”). Also, don’t burden the meetings with all stakeholders with too many nitty‐gritty details, but try to work out most contentious agreements with individuals and sub‐groups outside of the stakeholder group (otherwise it will be hard to keep the meeting to true decision‐making).

9) Don’t just go through the motions. If you do form a stakeholder group and process, there’s no sense in having meetings if people don’t attend. In particular, you want the stakeholder to make decisions, and if there aren’t enough people present then it’s probably better to not pretend a decision was made. Related to the above suggestion about a process with teeth, the exact process for deciding if a meeting will be decision‐making or not should be clear to everyone (for instance, defining a quorum under which the meeting is canceled so as to not waste people’s time).

10) Short delivery cycles. You may be tempted to, or pressured to, plan new features for your product far into the future. That said, there are many reasons to only plan short delivery cycles. Probably two key reasons for short delivery cycles are: a) quick feedback on new features, and b) creative and efficient solutions to users’ problems (since you have to deliver something soon, you may come up with a creative quick win rather than suffer paralysis by analysis).

What kinds of skills are needed to pull off the above? Here are some key attributes: • Strong diplomat / negotiator • Able to understand the big picture as well as to walk through mind‐numbing

implementation details • Strong communicator • Thick skin • Positive and can articulate compelling vision • Expertise in web technologies and content management systems

Organizations should consider a CMS product manager a key component of their Web Operations Management, and hopefully some of the above suggestions and background will help organizations introduce the role.

Documents

Internal Content Management System (CMS) Product Management