Archive for the ‘commentary’ Category

Text Killed the Multi-Media Star

Wednesday, March 10th, 2010

Recently it occurred to me that video and (to some extent audio) has become a less important requirement for most of my web content management clients these days. If I were to extrapolate the interest trend I was seeing back in 2004, I would expect to see the web resemble billions of tiny television stations. But that hasn’t happened. While video and audio remain important for companies in the business of developing and/or distributing multi-media content (primarily for entertainment), multi-media has not achieved ubiquity as a medium for communication. Instead, the focus is still heavily weighted towards text and images. There are some obvious explanations for this trend. Services like YouTube, Vimeo, and BrightCove are taking care of video hosting so my clients don’t have to worry about it. Also, companies have realized that, other than the large file sizes, video is just not so special that deserves so much special concern and attention.

But I think that there are larger forces at work. I experience issues with video both as a content consumer and a content management professional. As a content consumer, I don’t like how video takes control over my experience of the information. Unlike text, you can’t scan video for the little bit information that you want. You have to sit back and wait for the video to get to the point. This is great for entertainment (suspense!) but less so for information exchange. Take, for example, this video (below) where the spokesman just spurts out technical information about a computer. It would be so much better just to have a spec sheet so you could scan right to the part of the specification you want. For a while it seemed like all companies were looking to make their websites more “dynamic” by leveraging multi-media. Customers may have reacted positively at first to the novelty of seeing moving pictures but I think this has played out.

As a content management professional, my issue with video is that it breaks a key principle of content management: the separation between content and format. In video and audio, the information is inseparable from the format. Yes, you can transcode into different encodings and file formats, but reorganizing and editing audio and video is difficult to automate. As a result, video and audio content gets stale and out of date because it is too expensive to change. If you want to change the information, you need to re-produce the whole thing.

There are some things that belong in audio and video, like a recording of some performance or something that you need motion to understand. But in most cases, the production and maintenance effort that multi-media requires introduces an unnecessary barrier between the information source and consumer. This obstacle stands out even more in the social web that tries to blur the line between author and audience. In the social web, video is most successful when it is short, entertaining, and performance-oriented. It is less effective for basic information exchange. The best uses of video I have seen for information exchange is on some news sites where visitors are invited to upload short videos of their eye-witness account. In these cases, the video needs to be authentic (no need to edit!) and shows something that cannot be captured in text and still images. But information about that event is more accessible in plain text.

I am sure that there are people in the video field that have different experiences with the medium. If you have any insights, please leave a comment or send me an email.

Why CMS Vendor Acquisitions are Bad for Customers

Thursday, February 25th, 2010

It just occurred to me that my recent quotes on Fierce Content Management make me sound like the Statler and Waldorf of the content management industry. I really don’t mean to sound so negative but, from where I sit, software company acquisitions are nearly always bad news. My clients are software customers and my job is to help them be better software customers by making better technology decisions. Mainstream software analysts, who are mainly speaking to the vendors, spin acquisitions in terms of what it means to competitors. They talk about how the acquisition changes the landscape and competitive dynamics. Mainstream analysts get pretty excited by mergers and acquisitions. It means that there is movement that needs to be understood and explained. It means that they get to re-answer the question that their software vendor and investor customers always ask “who is the best company in the market and why.”

The software customer has a different question: “which one of these products is the best for me right now and in the foreseeable future.” Market dominance plays a role but customers should be more concerned about their requirements and that the vendor will stick around and continue to focus on what matters to the customer. Customers should care less about who acquired who (today and yesterday) and about more who is at risk of getting acquired tomorrow. Acquisition adds uncertainty and risk that a customer would do best to avoid.

The dirty little secret about software company acquisitions is that, in most cases, they have nothing to do with technology. When one software company buys another, it is usually buying customers. Implicit in the transaction is the understanding that the customers are worth something and the acquiring company can more effectively make a profit from them.
An acquired CMS customer is valuable because switching costs are really high. To switch to another product, a customer would need to rebuild its web site, migrate its content, and retrain its people. Unless the product is totally doomed, the customer will probably stick around and pay support and maintenance for a for a while. The acquiring company can increase profitability by cutting down on product development, support, and sales. Most of these cut-backs directly affect the customer. The vision for the product will get cloudy. Enhancements will come out slower. Technical support and professional services will be less knowledgeable. Market-share will gradually decline. In some cases, the product will be totally retired in favor of an alternative offering by the same company. If there is an option of terminating support and maintenance, it is probably a good idea to exercise that option because the value of the service is likely to decline steadily.

The sad thing is that this dynamic is practically built into the traditional software company business model. A typical software company burns through investments to first build a product and then build a customer base. At a certain point, the growth trajectory will flatten (or decline) and investors will want to move their money into another growth opportunity. Some companies will be satisfied by having achieved a sustainable business. Others will cash out by being acquired. Others will look to grow by acquiring steady (but declining) revenue streams. The scariest companies to deal with are the acquiring companies — what I call “portfolio companies” that buy up products for their customers and then decide what to do with the technology. When you are a customer of one of these companies the future of the software you bought is vulnerable to the shifting attention of the vendor. If the vendor decides to keep the product around, it means they can successfully drain revenue from you. If the vendor gives you a “migration plan,” it means that they have another product that is in an earlier stage of the same destiny. Neither case is good.

The biggest thing since wood pulp

Thursday, January 7th, 2010

One of my favorite podcasts, Planet Money, recently did a segment on bias in journalism. Apparently, back in the 1870’s, most newspapers were blatantly affiliated with a political party. In fact, their bias was openly stated in their mission statement and it was part of the newspaper industry business model. In return for political support, a newspaper publisher would get lucrative contracts for printing government documents and cushy government posts like postmaster. You historians will remember that Ben Franklin, himself a publisher, was the first postmaster general. The newspaper publishers didn’t do this because they were greedy or unscrupulous; it was hard to make a living publishing a paper any other way. The cost of printing and distributing a paper was more than the audience could afford. Given the options of the low return of serving an audience that can’t afford your product or the high return of serving a political party, the choice was easy.

But then a big technology disruption happened that drastically cut the cost of publishing a newspaper and all of the sudden made the business more profitable. It wasn’t the Internet, it was cheap paper made from wood pulp. Up until that point, the news was printed on rag paper like what our dollars bills are made of. With cheaper paper, a publisher could lower the price and get a higher volume of sales. You could sell even more papers if you had higher quality news. More newspapers entered the market but there were still barriers to entry to preserve profits. Even though the variable cost of the papers was low, the up front fixed costs of the presses and distribution channels kept competition manageable.

Like wood pulp, the Internet also disrupted the news business but in a different ways. While the Internet has reduced the cost of distributing the news (especially over large geographic areas), it has also driven the revenues down. Most importantly, the classifieds business has been eaten up by sites like Craigslist. Advertisers have other options to reach a more targeted audience than general news can. And, of course, there are no barriers to entry. Even an schmo like me can have a blog.

Will the decline of profitability push publishers back to bias? There are some concerning signs. Not so much with the big media brands (although you could definitely make the argument that all publications have their leanings), but there are plenty of examples in blogosphere (and Twitter) where bloggers are paid to promote a product or political agenda. The distinction between professional and amateur media is blurring. We tend to follow people (professionals and amateurs) who share our passion (usually on very narrow topics) and we unsubscribe when they lose our interest or confidence. But very few people are getting rich on having us as an audience — not until they sell out and exploit our trust. Then we will leave as quickly as we came because there is bound to be a fresh new voice that values our attention as unprofitable as it may be.

As an audience that wants to be informed, we need to do two things…. First, we need to figure out a way to compensate for the value that we enjoy. There have been some interesting ideas of establishing non-profits and public-media style structures. Second, we need to become very good critical thinkers. We need to be able to filter and verify the information that is bombarding us. We need to become our own editors if we can’t immediately trust anything in print. I am sure that is what people did back in the 1860’s did too.

WCM needs a new name. Or, perhaps, an old one.

Friday, December 18th, 2009

This post was originally written as a comment on Jon Mark’s excellent post Visions of Jon: WCM is for Losers but it got out of hand and I suspect that it is too long for a comment so I am re publishing it here.

Thanks for the great post Jon! I have to agree with you that the term Web Content Management System is misleading because of its diverse focus on multiple publishing channels. You probably remember that in the old days (~1996), the term “CMS” was first used to describe products like Vignette and what are now called ECM systems were just called Document Management Systems, Records Management Systems, etc. When the big DMS vendors started to covet the term “content,” the (then) smaller WCM vendors had to slide over a bit and qualify their category with a “W.” Then some of them started to ruin themselves by trying to expand into document, management, records management, etc. – but that’s another story.

But enough about the Ghosts of Christmas Past… I agree with the point that a WCMS has multiple aspects. I would name three: a management tier to edit semi-structured content, a repository to store the semi-structured content, and a rendering tier to render the content. Usually the repository is more tightly coupled to the management tier so it is often tucked into the management application. In fact, the three components are often bundled for convenience.

In my mind, what sets WCM apart from the other forms of CMS is the C. I still think of Content as having more structure (and less embedded formatting) than what you typically find in an ECM repository. In the ECM world, the structured information is called metadata and is not considered part of the asset (a MS Office file that jumbles together information and presentation). A WCM asset needs to be rendered (given a format) to be useful to a consumer. This is why a WCMS needs a good rendering system.

Most ECM assets can just be downloaded but the range of formats they can take is limited. You can get a different file format (like a PDF) or a different scaling or cropping of an image but the output looks essentially the same. ECM has tricks to add structured information like metadata and embedded tags but that is going against the grain. WCM, which is inherently structured, knows what each of the different elements of an asset mean. I like to say that ECM is documents pretending to be content and WCM is content pretending to be documents. That is, ECM starts with a document and tries to pull information out of it while a WCM starts with structured information and renders it into a .html, .pdf, .xml, or any other kind of document.

So, at the end of it all, I would say that WCM should be renamed back to CM and ECM should be renamed to EDM: Enterprise Document Management.

The Content Here Map of the Information Market

Monday, December 7th, 2009

I generally dislike the “map of the market” approach to describing a software market because the actual use of software is too specific to be generalized into abstract dimensions like “high and low end” or “innovative.” However, during a recent Content Here leadership offsite (OK, I went on a bike ride), I was thinking about Content Here’s positioning in the marketplace and I found a picture to be quite helpful. This is what I came up with (click on the image for a larger view).

The primary point of the diagram is to show that consumers enter the information marketplace with different types of questions and information providers offer different types of answers. The intent of the question appears on a continuum that ranges from problem focused to solution focused. Technology buyers are focused on their business problems. As you progress towards the “problem” end of the spectrum, the questions get more specific and require intimate knowledge of the context and domain to answer. On the other end of the spectrum, the consumers (software vendors and investors) are trying to understand trends that will inform a business strategy for managing (or investing in) a solution. The information on the solution side gets very abstract and speculative because the solutions themselves are designed to be re-usable across many different kinds of problems and software companies need to build products that will be sold in the future. In the center of the spectrum is where the interests of the buyers and sellers converge. Here the buyers are thinking a little beyond the specific problems they are trying to solve today to where they need to be in five years. Here vendors are thinking beyond how their solution measures up today to what buyers need going forward.

All of these questions are important and the marketplace for answers has evolved to answer them. On the sellers side of the diagram, you have the major analyst firms who primarily serve the technology vendors. Their information can also useful to the CIO that is trying to understand trends but it will not be useful for a decision faced today. I didn’t put too much thought into the positions of the “sell-side” analysts on the right side of the diagram. I would love input here.

I am more interested in the left side of the diagram — in particular, where Content Here is focused. My unofficial tag line for Content Here is “Content Here helps technology buyers be awesome at making decisions” (format borrowed from the Joel on Software article: “Figuring out what your company is all about”). Content Here tries to help client’s answer the questions of what technology to buy and what do to with it. To play this role, I need a deep understanding of how the various technology products work — but not as deep as a systems integrator that specializes in that technology or the software vendor’s technical support. Consequently, my reports are very technical compared to other analyst reports. I tend not to go as broad as CMS Watch because I stop keeping up with a product once I realize it is not relevant to my potential client base. Only when I hear that something has changed with the product do I check back (and this is why I don’t publish a list of technologies that I follow or don’t follow). Most importantly, I need to be able to rapidly discover a client’s requirements through an efficient consultative process.

This hybrid approach puts Content Here in between a systems integrator and an analyst company in terms of detail. I am not surprised by low number of competitors because this is a hard place to be. I need to dig into the many technologies I cover by building prototypes and talking with implementors. I also need to understand the business aspects of how the technologies are used. I am always on the challenging slope of the learning curve. I can neither sit back and pontificate on the abstract nor enjoy the luxury of knowing every detail. As difficult as it is to be in this position, I can’t think of a more stimulating business to be in.

That is as far as I have thought things through. I would love to hear your feedback on the usefulness of the concept and the positioning of the different players. In particular, if you are a consumer of information, is the information marketplace serving you with the appropriate level of detail?

The world’s worst WCMS

Wednesday, November 4th, 2009

I just read Philippe “@proops” Parker’s tweet:

there’s no “best” wcm, says @jarrodgingras, but is there a worst one? #fixwcm

My 140 character or less answer is “No” but I have more to say so I will elaborate here….

There is no worst WCMS. In fact, I would go so far as to say that every WCMS is (or at least was) the best WCMS for someone. The reason is this: every WCMS product was built to someone’s specifications. Some WCMS development projects fail in their mission but we rarely see the products of those projects in the marketplace. What we do see are the products that delivered so well on their specification that somebody had the bright idea to get into the business of repeating that success for other organizations.

So every WCMS, at least at one point in its lifetime, was someone’s best WCMS. But software is not static. It changes over time (at least it should) and it is quite possible that poor product management can make software worse. I see that as a very real problem for many of the software products in the marketplace. It takes discipline to avoid feature bloat that clutters the application and makes it less suitable for its best use. Software companies that look to competitors and potential customers for guidance are more vulnerable than companies that listen to their customers who are already using the software.

There is a great philosophy in software product management called “Make it suck less.” The idea is that, rather than add new features to draw in new kinds of customers, make life better for people who already use your software. That is, don’t ruin the software by trying to please everyone.

Sadly few companies take this approach and, as a result, the race to make worse software has a bigger, more competitive field than the race to make better software. Therefore, nobody is going to win the dubious distinction of the developer of the worst WCMS – its going to be a big tie.

Should we start listening to Gartner now?

Monday, November 2nd, 2009

I just read Matt Asay’s article “Time to upgrade upgrade open source perceptions of Gartner” where he gives Gartner credit for finally getting open source. His point is that Gartner has stopped steadfastly arguing that open source’s impact was negligible. On that point, I have to agree. Gartner has jumped onto the open source bandwagon just as it was accelerating out of Gartner’s reach. But what does that really mean? It means that Gartner’s readership (predominantly technology vendors) have forced Gartner to cover a market segment that they are no longer able to ignore. It also means that some of the open core software vendors have gotten big enough that they now represent a decent market for Gartner reports and services.

From a technology customer’s perspective, the value of Gartner’s (and most of the other major analysts, for that matter) opinion is pretty much the same. Main stream technology analysts focus on the business of technology (market share/cap/potential) — not the design or suitability of the products. Market analysts don’t work with the technology. They don’t talk to users or developers. Half of the people they talk to are CIOs who couldn’t identify the user interface of the software they are discussing.

So, if you are a software company or an investor trying to figure out where to spend your money, Gartner’s reports just got a little bit more useful. If you are in the market to buy technology, Gartner won’t help you understand your requirements and what product is the best fit for your organization.

Daniel Jacobson on de-coupled publishing systems

Tuesday, October 13th, 2009

Daniel Jacobson, NPR’s Director of Application Development, has an excellent article on the philosophy of de-coupling the content management tier from the delivery tier. He calls this strategy COPE: Create Once Publish Everywhere. In particular, the diagram is particularly useful in showing how all the pieces fit together.

If you are in the content publishing business (like NPR is), this is absolutely how you need to think about your content technology stack. Your content repository, editorial systems, and distribution channels can get sophisticated and highly specialized so compromise and lock-in can be costly. The delivery tier that came with your content management system may not scale or may not allow you to push the cutting edge if an opportunity to innovate should arise. All of my big name publishing clients have adopted this strategy for their core publishing platform.

However, as I have warned in earlier posts, the flexibility may not be worth the cost for all publishers. Unless your business model depends on aggressively leveraging your content and you can afford to play on the cutting edge, a lighter weight “website in a box” style architecture may give you the flexibility you need without the additional complexity and cost of building and integrating these de-coupled systems. As an example, Drupal is rapidly becoming a popular platform for small to medium publishers and also for smaller initiatives in larger publishers. And you cannot get a tighter coupling of management and delivery tier than Drupal. One strategy that has been used by early Drupal adopters (that have grown out of their forked versions of the platforms) is to use Drupal to publish into a custom delivery tier.

As an architect, I love the COPE model and I think that most successful, large scale content businesses will eventually converge on that strategy. However, as a pragmatist who also serves publishers in the lower and middle tiers of the industry, I know that the resources and expertise may not be available to go straight to that architecture. Still, at the very least, every publisher needs to start thinking on this level: creating and storing content in presentation neutral way to keep options open.

Another flower war

Wednesday, September 30th, 2009

Not quite the War of the Roses, there is a little skirmish happening between Magnolia International (as in the CMS company) and Ma.gnolia (the off-again, on-again social bookmarking site). The squabble began shortly after Ma.noglia’s recent resurrection (it had shut down in February 2009) when Magnolia International issued what appears to be a Cease and Desist order. It is a little unclear because it was written by Magnolia’s CEO, Pascal Mangold (not an attorney) and it seems to be more of a request than a demand.

I am no trademark attorney but, since that hasn’t stopped anyone else, I figured I would weigh in from a common sense perspective. I understand how Magnolia International would want ma.gnolia.com to be out of the picture. They probably also want ExxonMobile to stop using magnolia.com. ExxonMobile probably wasn’t paying attention when, then Obinary International, Magnolia registered magnolia.info to market their new open source CMS.

Does Ma.gnolia have the right to use their domain? I don’t know. There are very specific legal distinctions to determine legal and illegal trademark infringement but I don’t think it really matters. In the real world, it happens all the time. This is why you try to grab all the variations of your domain (.net, .org, and .biz as well as -sucks.com, -sucks.net, and -sucks.biz) when you are branding your company. You do your best to claim your little spot on the web and you work with what you’ve got. Getting lawyers involved is an expensive distraction.

I am sure that Pascal knows all this and that is why he wrote his own letter. Hey, it was worth a try. Maybe this will lead to a negotiation for Magnolia to purchase gnolia.com. Who knows how serious Ma.gnolia is about their business. Personally, I don’t think I would use a bookmarking service that had a track record of closing down and opening up again.

This is not a particularly interesting story. What would be more interesting is if Magnolia International went after ExxonMobile. What the heck is ExxonMobile doing with that domain anyway?

Fixed bid implementation work: a marriage made in Vegas

Monday, August 3rd, 2009

Most of my CMS selection clients are not just looking for software. They are looking for a solution that includes software and also a hefty dose of services to configure, customize, train, and support. Typically, once we have narrowed down to a short list of products, we start looking at systems integrators that can help develop the solution. A well-executed implementation and roll-out of a marginal product usually yields better business results than a train-wreck project to implement best-fit software. You need to work with a services organization (internal or external) that can partner with you to define and develop the solution that achieves your goals.

The other day, I was talking with a friend about projects gone bad and he asked me if I ever worked on a big fixed bid project that both client and supplier felt went very well. After considering all the projects that I worked on and the projects that I hear about as an analyst, I had to say no. There was always disappointment and frustration on either or both sides (usually both). But I was able to think of many iterative time and materials relationships that benefited both sides over years of working together. I have now been out of the systems integration business long enough to say, without any personal agenda, that fixed bid systems integration work is a failed enterprise.

The best analogy that I can make is that a fixed bid contract is like marrying someone you met at a craps table on a Las Vegas vacation. I am not saying that all spontaneous Vegas marriages fail, but they definitely have the odds stacked against them. Here is why; during the sales process, both sides get wrapped up in the deal and suppress rational doubts and concerns. They force themselves to believe everything is going to work out. They force decisions and assumptions that turn into a millstone hanging around the neck of the relationship.

The supplier talks himself into believing that he fully understands all the requirements and that every detail about his approach to solving them is accurate. That is simply impossible. No matter how long the pre-sales cycle lasts, it is impossible to fully understand every requirement and bring to light every latent expectation. The client doesn’t know what he wants until he sees what he doesn’t want. The initial estimate may have even been trimmed down because it “looked too big.” The client also assumes he fully understands the requirements and believes he is reasonably flexible about the design details. He trusts that the fixed bid contract ensures the delivery of the solution in his minds eye for the agreed upon price in the stated time frame.

After the deal is consummated, there is a short honeymoon phase where everyone seems to work together productively. This analysis phase goes smoothly because the stressful deadlines are far away and there are no concrete tests for progress. Sometimes a project can go through design without any awareness that it is horribly off course. That realization usually happens during the first development milestones when it is clear that the developer and client had significantly different understandings of the specification (if there even is one). Then things start to degrade very quickly. Both sides are stressed out and start to blame each other. Both parties feel like the other is being unreasonable. The contract that was supposed to protect everyone is turning into a handcuff connected to the most annoying person in the world. Both sides start looking for a way out.

Any successful partnership depends on both parties working collaboratively and creatively to solve problems as they come up. A fixed bid contract prevents this cooperation by making the relationship inflexible. But, you may ask, how much flexibility is realistic when a client has a limited budget and has promised a certain outcome of the project to company leadership and/or the customers? With a fixed bid contract, there is at least clear chain of blame. The business blames the project sponsor. The project sponsor blames the project manager. The project manager blames the consulting company. The consulting company blames the employees. The employees feel miserable and quality suffers. The contract provides unambiguous blaming instructions but it doesn’t solve the problem. The project is delayed and other costs will be realized.

A better strategy would be to partner with the supplier to jointly design and develop the optimal solution within those budget, time, and quality constraints. Achieving this kind of solution is an iterative/incremental process. The final solution will gradually materialize as options are explored and learning occurs (see Tracer Bullets). But this kind of cooperation requires a huge amount of trust and, sadly, very few business relationships enjoy much trust at all. Especially given the perceived track record of failed technology projects.

So, how do you achieve this level of trust? It takes time. Just like it helps to date before you get married, you want to start off with some small, low risk projects. Both sides need to believe that if they work at it, the relationship will last a long time and benefit them. There also needs to be transparency and equal rewards. The systems integrator needs to be transparent about their capabilities and experience and they cannot expect a huge windfall over a single project. The systems integrator should consume project resources (budget) as if they were his own. The client should expect to pay for what he gets and not try to trick the supplier into committing to unreasonable results. As Graham Oakes says, if you do not try to the make the relationship a win-win, you will probably wind up being the one who loses.

When you are buying services, you are really buying effort — not a result. A good project team will multiply the effort you purchased with skill and experience to deliver great things (maybe even better than you originally thought you wanted). The problem is, buyers are ill-equipped to gauge skill and experience. They feel more comfortable with the illusion that they are buying tangible results. Services companies that prefer to sell results rather than effort do so by charging a high risk premium (or “value pricing”) and having employees that can step up and overwork when the risk gamble is lost. So, the buyer is either overpaying or has hired an overworked team. Neither of theses options sounds particularly appealing.

If you do find yourself forced into asking for a fixed bid contract, do not assume that you can just set your calendar to the planned launch date and wait for the results. Instead, manage the project as actively as possible. Set up lots of intermediate milestones with exit criteria to test that the project is on track. If possible break up the project into multiple small fixed bid phases. For example, have a fixed bid design phase that ends with a prototype or semi-functional core of the application. Make sure that the design considers implementation budget as one of its requirements or constraints. Business owners: don’t let your staff get away with throwing the systems integrator under the bus when a project fails. Make them equally accountable for the outcome of the project. If the system integrator is underperforming you should learn of it one quarter of the way into the project; not within weeks of the planned launch date. Even better, don’t force your staff to come back with a fixed bid contract. Encourage the assembly of a high performing team of staff and consultants that maximizes the value of your budget.