<!-- Content Here -->

Product Management Work Program

David Hobbs published a nice post describing how to define a work program for managing your website. The role of website product manager is near and dear to me. In fact, in my CMS Selection and Content Management Assessment projects, I get concerned about long term success if the client has not designated and empowered a strong product manager and a established a disciplined product management process.

What I like about David's process model is that it shows the components of the process and how competing requirements work through that process. The diagram is a nice visual for a product manager when receiving requirements and setting expectations.

What Game is your Team Playing?

I am trying to get a friend of mine to quit his job. No, I don't want him to join the massive ranks of the unemployed. I want him to move to a job that appreciates his talents and efforts. My friend (let's call him Bob) is totally dedicated to his profession. He is continually trying to improve his skills and productivity and wants to help his colleagues achieve better results too. Nobody brings more thought and interest to any task he faces. But he is surrounded on all sides by people who just don't care. They are satisfied by doing mediocre work. If something they build doesn't immediately fall over, they consider it done. If they can assign responsibility to someone else, they will. If nobody else notices a problem, it never happened.

It's frustrating for Bob. He can't accomplish his goals without help or at least cooperation. His company doesn't recognize the difference between his performance and that of his peers. In fact, he is constantly getting passed over. It doesn't feel fair. But it is fair. Bob is just playing the wrong game. Queue the metaphor...

Imagine that you are a world class tennis player. You live and breath tennis. You go into every volley trying to do your best and to improve upon the last one. You invest in coaching and resources to improve your game. If something might help you play better, (like a different diet, a different racket, or even one of those magnetic bracelets) you will try it.

One day, a friend challenges you to a game of Wii Tennis. You start to play tennis as you know how. Your knees are bent. You move your feet. You swing with explosive power. You are playing great tennis... but you are losing. You look over and you see your friend. He is slumped on the couch barely moving his controller with a flick of wrist. He looks like he couldn't walk across a tennis court without losing his breath.

As pathetic as he looks, Wii thinks your opponent is a better tennis player. Wii doesn't care about his form, his position, or how much leverage he has over the ball. Wii only cares about timing and maybe a couple other factors. Your friends knows this and he is not wasting any energy on what Wii doesn't care about. Your friend is the better Wii Tennis player because he has figured out how to do less but still satisfy the minimal inputs that Wii has been programmed to observe.

Bob is trying to play real tennis in his company's Wii Tennis tournament. He is not exactly losing, but he should be winning. The frustrating part is that he could be doing a lot less and get the same results. When he is on a team, he is constantly questioning whether he should be compensating for others by fixing their work — like in a doubles game when you see your partner is not running so you cover more of the court. His extra efforts only result in bumping into things and annoying people who just want to "sit on the couch and casually wave their hands."

Now the big question: who is playing the wrong game? It is difficult to tell if Bob's company would perform better if it paid attention to the finer aspects of how people worked and measured performance more holistically. It is unknown whether the company's customers would appreciate a higher quality product. But there are two things I know. 1) Bob wants to play real tennis, not Wii Tennis. 2) He doesn't have the clout to change the game that the rest of the company is playing.

The reason why I am writing this post on this blog is that I think that this story is very relevant to the pursuit of any type of organizational change, be it adopting Agile development or Enterprise 2.0. Companies can delude themselves into thinking they are playing a different game than they actually are. They may think they have a bunch of real tennis players who are striving for excellence and victory on a dynamic playing field; instead, they have a bunch of Wii tennis players who are looking for ways to minimize their personal/professional investment to only what is recognized. These companies get confused when they put a tool or way of working out in the wild and nobody adopts it; they shouldn't be.

Organizational change is much harder with the Wii Tennis company because you have to actively incentivize every behavior you want to see. It is not enough to say "this will make our company more effective." You have to say "do this specific thing and get points towards your performance review;" and you better not be lying because Wii Tennis players will see right through that. Finding real tennis players like Bob is hard to do — especially if you work for a large company. Real tennis players need a lot of room to move around and large companies tend to compartmentalize people. They need to be challenged in different ways to keep things interesting. Their rewards need to be tied to company achievement. Plus, other employees will get annoyed when you change the game that they have gotten so good at.

When building a company or even just a team within a company, think about what game you are playing. If your industry is commoditized and the difference between average and excellent is under appreciated by the market, it may pay to go after the Wii Tennis players and be very specific about expectations and incentives. If you are competing in a dynamic industry with a large upside, build a team of competitors who will take ownership of optimizing their personal performances and also the effectiveness of the overall team. They will innovate and try new tools and techniques that are offered. Most importantly, they will not stop a practice if it is difficult to do — they will only stop if it is ineffective or if they find something more effective.

Is your organization's digital presence "house poor?"

Occasionally when I do content management assessments I run into what I call the "house poor syndrome." This is when an organization builds a website it does not have the resources to maintain.

Here is the metaphor.

Imagine you have been saving for years to build your dream house. You lived in a rundown house for longer than you would have liked in order to put together as much money as you can; and you collected quite a sum of cash given your income. With this pile of savings you bring in the best architect and contractor and the three of you get swept up in a vision of what an ideal house would be like.

The concept grows. The architect puts in all the latest features he has seen in his architectural magazines. The contractor says things like, "if you think you might want a heated three car garage, it would be cheaper to put it in when we pour the foundation." Pretty soon you have something worthy of your wildest dreams — at least on paper

Then construction starts and unexpected details start ballooning out the expected cost. Forgotten but really necessary items (like a drainage system) need to be put in. By the time you are done, you are way over budget but you can just swing it. You can't really go back out now anyway.

On move-in day you have this grand house and you are excited. Your old furniture looks a little shabby and awkward in the new rooms. Some "future use" rooms don't have any furniture at all but that's OK because you will get to them in due time.

Then a few years go by. You can't afford to heat those rooms let alone furnish them. The elegant landscaping is overgrown. You don't have time to weed those beds. You have made some home repairs yourself and the results are worthy of There I Fixed It. You don't have plumbing skills and you can't afford a plumber. The windows are dirty, every surface is dusty... well, you get the picture.

By this time you realize you are in over your head. The contractor and architect know this too — they don't bring their prospective customers to your home for site visits any more. There is a reason why only the ridiculously rich live in houses like these.

Now, lets think about how that experience parallels a website project.

• You got wrapped up in a dreaming exercise with designers and engineers that want to build something beautiful (with your money) that is a monument to their talents.

• You based your vision on the websites of companies with lots of money.

• You didn't think about the content that you have (your furniture) and how it might fit. Paragraphs of "lorem ipsum" were replaced by one sentence on an otherwise empty page. You still have images with iStockPhoto watermarks in them.

• You overestimated your available time to create content. After a year, the blog still has only one post; the "what's new" section hasn't changed in months.

• You overestimated your skills to maintain the website — the outdated flash promotions, the broken HTML, the awkward looking label images with the slightly wrong color and font.

• You paid for functionality that you can't afford to use or promote: the empty customer forum.

Like with houses, you see organizations "downsize" their websites by migrating to simple tools like Wordpress and keeping things simple. If your resources are constrained, a neat and tidy small site looks much better than a dilapidated mega-site. But, like with an underwater house, it does cost money to get out of an outsized website. More importantly, you have to make peace with your constraints and set your sites to more realistic goals.

But you can save yourself this expensive excursion beyond your limits by taking a practical view during the requirements and scoping phases and think ahead to how you are going to support that content and functionality. When you see whiz-bang Flash elements, ask how will you be able to modify them. When you see esoteric fonts in the style guide and a lot of image labels, ask who is going to produce them and how. In short, think of yourself living with and maintaining every feature you entertain in your fantasy. You could save yourself a nightmare.

PHP + JCR = PHPCR

My former colleague Lukas Kahwe Smith recently gave me a update on what is happening with the PHPCR initiative. Readers of this blog might remember me make a brief mention of PHPCR and the Jackalope implementation. My initial response was that I was unsure of whether the idea would take off but now I am pretty impressed with what I heard from Lukas.

Lukas and his team from Liip AG have been contributing to Jackalope as part of a large custom, content-centric web application they are building for a client using Symfony2. Jackalope goes beyond standard relational database persistence by providing sophisticated content services like content hierarchy, tree traversal, versioning, and content staging — common weaknesses in homebrew CMSs.

I can see a number of benefits to a PHP developer using PHPCR

• There is less to build than when working directly against a REST interface like Apache Sling. You don't have to worry about making requests and marshaling XML or JSON into programmable PHP objects.

• Your code can store any type of data in the JCR (not just documents). Using CMIS would be a bit of a stretch for anything but document data. Liip has developed an object-to-JCR node mapping layer (called phpcr-odm. Part of the Doctrine project) that behaves like a PHP ORM service.

• The persistence engine is abstracted so you can swap it out with something that meets your performance needs. Jackalope ships with Apache JackRabbit but there are also transports in the works for MongoDB and standard SQL databases. They should be mature by the end of the year.

• You can use PHP to build delivery tiers and other web applications using content managed in a JCR-based CMS (such as Adobe CQ5, HippoCMS, or Magnolia).

If you are building a content-centric web application in PHP, and you find yourself doing unnatural things to a relational database to meet your requirements, consider using Jackalope or the Midgard PHPCR implementation (which is designed more for speed). You are probably already be using Lucene for search indexing, how much trouble can one more Java application be to manage on your infrastructure?

Why CMS Implementations Are Getting More Expensive

Adriaan Bloem is starting to hear both customers and vendors estimate implementation costs to be 7-8 times software licensing costs. That is a big increase over the old budgeting rule of thumb which was 4-5 times licensing fees. I am not saying that there was a sudden increase, but I had been holding onto that old number for a long time so the new number came as a bit of a shock.

My immediate reaction was to try to explain the increase and I thought I would share some of my ideas here.

• Sites and technologies are getting more sophisticated. We have come a long way from the old world of static publishing. Now we are building interactive content applications that can be constantly tuned to optimize visitor experience and maximize business value. The tools have come a long way to support this but that doesn't mean that everything comes out of the box. Every new feature and option requires design, configuration/customization, testing, and management. The market is buying potential and the vendors are selling it — but realizing that potential isn't free.

• Document management is no longer bringing down the average. Back when I heard the 4-5x estimate, it seemed that was across web content management, document management, and digital asset management. Back then many document management projects had minimal implementation effort. There was basic functionality that came out of the box that didn't need to be (or couldn't be) configured. You just had to configure what metadata was captured, roles and permissions, and, for that nice touch of customization, add the client logo. That was OK because it didn't really matter if Company A's document management system looked nearly identical to Company B's. Not only am I seeing more web content management these days, but document management is getting more web-like. Leading the charge is SharePoint, which you use to create an interactive web site out of your documents (plus a whole lot more). Understandably, SharePoint implementations are very expensive. I am seeing the same thing with digital asset management systems that allow you to create an eCommerce-like site to browse through and collect assets.

• The technologies are getting cheaper. Content technologies are coming down in price — not just because of the pricing pressure from open source. The market is maturing and that leads to commoditization and competition. The super high-end products which commanded ridiculously high license fees are quickly becoming irrelevant and being acquired by infrastructure companies for maintenance annuities rather than sales potential. When buyers are using cheaper technologies to build more sophisticated websites, the implementation/license multiplier is going to go up.

The net of all of this is that buyers are seeing the potential of content and are investing in building solutions that can realize that potential. The underlying software products are only part of those solutions, which also require strategy, execution, and continual attention to be successful.

CMS Selection Checklist

A few days ago, I was asked by a potential client to provide documentation on my CMS selection process. As readers of this blog know, I write a LOT of articles on the various aspects of selecting a content management system. Probably the most concise descriptions are these two: "Selecting a CMS" and "How to Select a CMS." These posts go pretty deep and I have many other posts that go deeper into the specific activities. But, I still felt like I was missing a nice clean (less bloggy) overview. To solve that problem, I put together this CMS Selection Checklist. The most fun part of writing the checklist was finding all the articles that I wrote over the years that discussed each element of the process. I also see areas where I can write more.

CMS Selection Checklist

Enjoy!

Publishing to mobile is more execution than platform

Mobile publishing functionality is becoming an increasingly important requirement for web content management (WCM) selections and I am starting to hear more customers ask "can this product do mobile?" The fact is, most WCMS have that core functionality built into their DNA since multi-format publishing has been going on since the beginning of time. In the early days it was publishing "printer friendly" versions, PDFs, portlets, or RSS (we only dreamed of mobile). Now we are talking layouts and navigation that are optimized for smaller screens. In fact, what differentiates a WCMS from a document management system is the "rendering" or "presentation" tier that takes structured content and applies a layout template to generate a formatted output. The specific purpose of the rendering tier is to be able to reuse content and publish to different formats.

Just because nearly all WCMSs have the foundation to support a decent experience for a mobile user, it doesn't mean mobile will come easily to your solution. Why? Because WCMSs are also very flexible and give you plenty of opportunity to shoot yourself in the foot. WCMSs allow you to model your content with enough structure to make it reusable, but they don't require it. You can still use a single generic content type and turn your WCMS into a 6 million dollar WYSIWYG editor. You can fail to keep your content DRY. If you committed these sins, your mobile project is when they will come home to roost.

While structured, reusable content is a key to success in mobile and nearly all WCMSs support some degree of content modeling, there are a few non-universal features that will make supporting mobile easier. Look out for these features when evaluating WCMSs.

• Configurable template selection rules. All WCMS should be able to associate presentation templates to content types. You should look for a platform that allows you to configure template selection rules based on criteria like the section of the site or the user agent (browser). Otherwise, you need to build complex switching logic into your display templates.

• Themes. A theme is a collection of templates that define a comprehensive style (layouts, behavior, font, palette, images, etc.) of the site. A theming model allows you to group templates that are used for a style. This makes themes interchangeable and selectable so you can manage a mobile theme (or multiple mobile themes for different devices). It is particularly helpful if the platform allows themes to override each other — similar to cascading style sheets. For example, you could have a base theme and specific themes that override selective elements of the base theme.

• Multi-site content sharing. Designing for mobile is not limited to layouts and styling. There is growing consensus around the value of having a separate site with content that mobile visitors are likely to want. This doesn't have to be fresh, mobile-only content. Rather, it is a subset of the main content with a simplified navigation. Some WCMSs will represent this mobile area as a different "site." Others will represent it as a folder in the hierarchy. Regardless of the semantics, you need to be able to have the same piece of content exist in both of those places at once. Different WCMSs use different metaphors to allow contributors to manage these placements: "locations," "aliases," "references." Some metaphors come more easily to contributors than others but all contributors need training to get it right.

Those are the key CMS features to look for. The rest is in the execution. In addition to content modeling, make sure you are working with a competent designer than knows mobile and web developers that know how to implement the design to make pages lightweight (for example: compressing HTML, CSS, and Javascript; using sprites for buttons and logos; and effective placement of script references to prevent blocking). Also don't forget to account for increased testing.

Content Management Assessment Worksheet

I uploaded this content management assessment worksheet up on Scribd a few weeks ago and buried a reference in another blog post. To make it easier to find, I am reposting it here. I would love for people to put their scores in the comments but I assume that most people would be too embarrassed to share. If you find this fun and interesting, you should take the the CMS Implementation Survey to anonymously share your experiences with others.

CMS Implementation Worksheet

Architecture Aikido

Over the past year I have been doing some side work building a web application for a startup. The project has been very interesting and the process has helped me stay in touch with my inner developer. It has also allowed me to practice agile product management philosophy to an extreme.

Last week I read Andy Hunt's article "Uncomfortable with Agile" and I have been ruminating on that feeling of being in a constant state of discomfort. If you click through and read the article, you will learn that discomfort is a good thing. The alternative is blissfully trusting a process — and then finding that you were wasting your time. Agile revolves around challenge. You challenge your assumptions and your limitations. That discomfort that you feel is really the sense of awareness that everything is in play and you are personally are accountable for a successful outcome.

Recently, I have been feeling like architecture in an agile environment is a little like wrestling or aikido. The goal is to maintain your balance and stay on your feet. Your opponent (the customer) pushes requirements in one direction and you respond by building up the architecture in that area like you might move your feet to stop yourself from being knocked over. Then, all of the sudden, the customer changes direction and you need to quickly adjust. The trick is to never over-commit in one direction or the other. Over-committing will put your balance at risk because, if the direction of force changes, all your weight will be on the wrong foot.

We see over-committing in architecture all the time. You go in thinking one feature will be the center of the application but then you find that little thing you built on the side as an afterthought is the killer feature. This is especially true with startups that are constantly "pivoting" or redefining their product. In my experience, most over-commitment sins are done in the name of performance optimization. You structure the data or the code in such a way that you can cut some corners and shave some processing time. Sometimes these optimizations are absolutely necessary but they leave you exposed for the next weight-shift. When this happens, your next iteration is spent regaining the balance of the application (refactoring) rather than adding new features.

The next time you are in charge of the technical design of an agile project, think of it as an aikido match. Fluidly adjust to changing requirements but try to stay away from positions that extend too far from a position of balance. Otherwise plan to take time getting back on your feet.

Grading Your CMS Implementation (Voice Over Edition)

I gave this talk at the J. Boye Conference in Philadelphia last week (GREAT conference by the way. I already verbally committed for next year). My slides are posted on the J. Boye site and you can also get them on SlideShare.

One thing I tried to do with this presentation was to reduce the amount of the bullet points in my slides. While I thought this made the presentation better, the slides are less useful for people who were not there (and also people who were there but missed or forgot the pearls of wisdom I was dropping down). Because of that, I thought it would be a good idea to write a blog post with some of the slides and some key points that I talked about. Here goes...

It is more than just a software project

It is extremely rare that an organization just installs and configures a CMS. A CMS project is nearly always in the context of a much larger initiative that might involve:

• A site redesign

• Major IA rework

• New visitor facing functionality

• Organizational change

So it is really a mistake to think of it and evaluate it as just a software project.

It is a roller coaster

Every project goes through this roller coaster. The business case and software sales process raise expectations by talking about the potential of the solution — long term potential. Launching a new CMS is a tough transition. It doesn't feel anything like the rosy future you were promised.

• This is a time when you are supporting two sites: you need to keep the wheels on the old site as you migrate content onto the new site.

• The new tools are unfamiliar to content contributors. They don't know the short cuts and work-arounds.

• The content you are moving is not as good as you thought so there is unplanned work to improve it.

• There is organizational pressure to show results for all the money spent.

• You were probably thinking that you were crossing the finish line but now you realize that the real work is starting and it is going to be a real slog.

There is going to be a dip. It is just a matter of amplitude: how high did you let your expectations get and how much pain did you go through around launch time. A great project may not dip below neutral satisfaction but I have never seen a project easily achieve the loftiest of hopes for it — at least not on day-one.

The components of your grade

Grading a CMS implementation is matter of measuring the dip and we do this in three dimensions: Vision, Execution, and Platform. Vision is what you are doing and why. Execution is your action against that vision. Platform is the tools that you build on.

How the components fit together

Another way to look at it is you have vision driving execution which then produces results that inform vision. This cycle is supported by a technology platform.

Setting your goals

• You should have defined, communicated and aligned behind goals.

• Every stakeholder should be able to give an elevator pitch stating the goals, why they are important, and their role in helping to achieve those goals.

• Goals should be related with organizational goals.

• Goals should be measurable. At any point in time you should be able to tell if you are getting closer to your goals or moving away from them

Your content strategy

I didn't go into content strategy too much here because that is a huge topic on its own. I merely introduced what I call the first principles of content strategy. If you have a good handle on audience, information, and behavior, you are probably on the right track to a good content strategy.

Setting expectations

A shovel doesn’t magically produce a hole. A new shovel will be most appreciated by someone who has been desperately scratching at the earth with a stick or his bare hands. Digging is hard work. A shovel makes the effort more productive. Similarly, content production and management is hard work. It's hard to learn and serve your audience. A CMS is like a hand-tool. The right tool will make a dedicated team more effective. If you thought you were getting out of hard work, your expectations were probably unrealistic.

Platform vs. Execution

Platform and execution are often difficult to pull apart. The platforms are so configurable that it is not easy to tell if an issue is intrinsic to the platform or if it was self-inflicted by the execution. Different elements tend to gravitate toward one side or the other but there is a big grey area.

Training

Training is the single most important component of any content management initiative. If your training program is successful, your users will know their roles and have the skills to perform them. They will be able to achieve their goals no matter what obstacles are thrown in front of them. Unfortunately, training is an afterthought in most content management initiatives and is funded by budgetary scraps left over from earlier phases.

You need to think about training 4 stakeholder groups: contributors who add content and participate in workflows; developers who support and enhance the solution; administrators who keep it running; and visitors who consume content. I got a little push back here by people who took the last group literally. I don't mean dragging all the site visitors into a classroom. My point here was that when you make major changes to your website, you need to think about how to help your visitors through the transition. Don't believe me? Remember the Facebook, Digg, and Gawker redesigns and all the agida they produced? Visitor training strategies may include redirects so the old URLs work, search functionality that maps old terms to new terms, and instructional text.

Training programs are most effective when you:

• Incorporate classroom and practical elements

• Time classroom training so it happens right before trainees need to do the work — so they don't forget what they learned.

• Closely monitor and support users as they are starting to work on the new platform. This is when habits are formed (the good ones and the bad ones too).

Content Modeling

Content modeling is important because it determines how content is stored and managed in the system. This has implications in how content is authored and, more importantly, what you can do with the content. More structure means better reusability but it also makes the content contributor more dependent on the template developer to control what the visitor sees. You need a balance. In order to achieve that balance, your content contributors need to buy into the notion of separating content from layout and you also need to give them formatting tools where they need them.

This is an example of unstructured content. The editor used styling to give the impression of structure. The CMS would have a hard time doing things like creating a summary of this content on an index page or optimizing this page for a mobile device.

After beating this example up, I will defend it by saying that in this case a wiki was the right tool because the organization didn't have access to presentation template developers, had plenty of content editors, didn't have a lot of content, and needed to be nimble. A wiki is not a bad platform for Wikipedia either. So the amount of structure really depends.

Worlkflow

Here I gave my Manufacturing/Legislation metaphors of workflow. If you want to increase efficiency with workflow you need to have specialists at the ready to help produce content. Workflows dominated by approval steps publishing down. Don't aspire to the assembly line but create Congress.

Presentation

Most of the technical effort of a CMS implementation is usually in developing presentation templates. This is where all of your display logic is. Any visitor-facing behavior is also coded in presentation templates. There are two ways to fail here. Inefficient code that does not use caching effectively or has sub-optimal content queries will cause your site to become unstable when under load. Sloppy, repetitive coding will be a long term maintenance nightmare.

Instrumentation

Instrumentation is more than just tracking hits and unique visitors. Those metrics can be useful for signaling major issues and trends but you really need to be tracking data that will tell whether your strategy is working or not. This gets back to my point that content strategy is based on Audience, Information, and Behaviors. Instrument your site to tell you whether or not your information is driving the right behaviors from your audience. Collecting the right data will help you refine your vision and strategy so you can iterate toward long term potential that your business case promised.

At the end of the session, I handed out this Content Management Assessment worksheet. I encourage you all to think about a CMS implementation you were involved with and grade it. How did you do? If that was fun, please take my survey!

CMS Implementation Worksheet