business « Content Here

Archive for the ‘business’ Category

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.

Posted in business, commentary | 8 Comments »

Does “Intranet” Need a New Name?

Thursday, February 11th, 2010

James Robertson has an excellent post, Future principle: it’s more than the intranet, where he summarizes a movement to replace the term “intranet” with a word that reflects what an intranet could be. To quote:

There are some that would like to dump the “intranet” name, as it’s associated with the “old” vision of intranets as a publishing platform, a dumping group for documents, and a place for the CEO to post his thoughts.

This narrow vision of the intranet must certainly die. In the process, intranet teams need to go from being custodians of an internal website, to facilitators for business improvements. In many ways, the word “intranet” has too much baggage, and is an anchor for much-needed changes.

I agree that many people hear the word intranet and immediately think “dumping ground” but one does wonder if companies will not sully the next name by their continued failure to execute on the vision. The term “intranet” is actually pretty good and should be able to ride on the coat tails of the internet. The name “internet” wasn’t brought down by failures like GeoCities because there is so much innovation happening; and failure is a necessary by-product of innovation. The difference is that failure kills most corporate intranets. Many intranets are big waterfall I.T. projects that are “complete” after launch. There is no time or budget left to learn from mistakes and adjust — the equivalent of a failed internet start-up but without the decency of shutting the servers down.

I don’t expect companies will improve their execution of intranet projects until they start to change the way they build, launch, and manage internal products. The companies that are ahead of the curve should give their intranet an internal name to make users expect and work for more than the status quo.

BTW, I have a great replacement for the term “intranet” but I am not going to tell anyone because, sooner or later, it will be ruined by some comatose intranet initiative looking for some easy re-branding.

Posted in business, intranet | 3 Comments »

The Dead Zone of Software Pricing

Wednesday, February 10th, 2010

A couple of weeks ago I subscribed to the Lean Startup Circle mailing list and I have been thoroughly enjoying the conversation ever since. If you have any entrepreneurial sensibilities lurking inside you, I highly recommend that you subscribe. The list participants have been in the trenches building companies and are happy to share what they have learned.

Recently, a thread on pricing caught my eye. This doesn’t have to be strictly software licensing fees. It could be subscriptions or services too. Jim Murphy wrote that there are four pricing bands: low (< $500), medium ($500-$5,000), dead-zone ($5,000 – $20,000), and high ($20,000+). What is interesting is the “dead-zone.” In this band the buying cycle is long and complex but the price of the product doesn’t quite compensate for the high cost of sale. I am sure that most successful software vendors understand this either consciously or tacitly and price their products accordingly. From a buyers perspective, I was thinking that a $21,000 software product may have originally been $8,000 but is priced up by $13,000 to get out of the dead zone.

If you look at the CMS market, there are lots of commercial products with sticker prices that hover around $20,000 – $25,000. This range is much smaller than the actual deal size because the list price of $20,000 may be to license a single CPU with little capacity and no fault-tolerance. You will probably also need to add support and training which will typically bring the deal size to the $50,000-$90,000 range. Those figures can certainly justify a sales investment from the vendor. But, because of the complexity, dependencies, and high stakes of web content management, the cost of sale can be very high (remember, you have to factor in the costs of the losses as well as the wins and a flooded marketplace means lots of lost deals). Maybe the dead-zone of WCM is even higher than the average. Maybe it’s more like $10,000 – $50,000.

$50,000 is a lot of money to many web initiatives that tend to have expectations of low costs and rapid results. Open source products like Drupal, Joomla! and Wordpress are doing quite well because they enable design studios (with minimal technical skills) to offer a complete website for half that price by taking a pre-existing theme and some modules and tweaking them just enough to make the site look original. Expression Engine, a free but non-open source product, is showing similar success. In these deals the cost of the software sale is essentially zero because the customer is not buying software; they are buying a website. They are considering font/palette/imagery rather than feature/function/value. Plus, because hosting for these platforms is so ubiquitous, the customer doesn’t even have to complicate the transaction by involving their I.T. organization.

Commercial CMS vendors that are inflating their price to get above the dead zone are at a real risk here. Unless they can demonstrate value, their outsized prices will really stick out against products in the bottom two tiers. I think their best strategy is to shrink the dead zone by reducing the cost of sales. This means improving their channel sales and giving more access to customers who can take on more of the burden of evaluating the software. They also need to figure out a way to reward low-touch sales with discounts and charge prospective customers more when they demand the formality and overhead of the traditional enterprise sales cycle.

Posted in business | 3 Comments »

The Myth of the Occasional CMS User

Wednesday, February 3rd, 2010

Not long ago, a university hired me to evaluate their CMS implementation. They were having doubts about their CMS selection because the implemented system was not living up to the lofty promises that got them the budget for the project. It turned out that they did make a reasonably good platform choice but they failed in two of the other critical content management success factors: expectation setting and project execution. The project execution wasn’t horrible for a first try (they were working with a systems integrator that was new to the platform) and there were some remedial efforts already in progress to clean up the implementation. What was really killing them was that a primary goal for the CMS was the notion of “self service.” They wanted their faculty to be able to edit their own profile pages. These faculty pages were more than a simple staff directory. Each entry was intended to showcase the experience and accomplishments of the professor and included a CV, a career narrative, and a history of publications. To maximize content reuse, the content model was highly structured — thereby increasing the complexity of the content entry forms. They might have been able to scale back on the detail but the amount of content they were looking for was not trivial: especially for an individual whose chief concern was not keeping a website up to date.

Often, one of the big justifications for a CMS is removing the webmaster bottleneck and delegating content entry to the people who have the information. The implicit assumption is that everyone wants to directly maintain their portion of the website but technology is standing in the way. But if you visit a CMS customer a while after implementation you are likely to find that the responsibility of adding content is still concentrated in a relatively small proportion of the employee population. Either the CMS never gets rolled out to the anticipated user base or it is rolled out and the user base fails to hold up their end of the bargain so the core content managers take back ownership. There are plenty of exceptions to this generalization — especially when there is an individual who has taken responsibility for outward (or inward) communication for his/her sub-group. For example, you might have someone from the human resources department whose job depends on communicating corporate policies to the staff.

You could interpret failed adoption as evidence of poor usability. That was my client’s inclination. But you need to consider the usability of the other alternative, telling someone else to do add your content for you. Prior to the CMS, a professor would only have to send a terse, typo-riddled email containing some research references or a CV and the marketing department would clean it up, fill in the gaps, put it in the right style, and handle all of the coordination. How can you beat that? You can’t.

Usability can’t take the place of ownership and responsibility when managing content. As long as the marketing department owns the website, they will have the motivation to maintain it to the standards that they have set. It would be unreasonable to expect a professor to put the website above his other responsibilities: teaching and publishing academic books and articles. When the marketing department needs to spend a lot of energy cajoling and coordinating a professor for content, it is usually easier for that marketing department to do the content entry too.

Generally speaking, you can’t delegate content authorship beyond the perception of site ownership. A good strategy is to centralize content authorship and give a relatively long turn around time (perhaps 5 business days) for site update requests. Those who do not feel ownership of the site will be fine with that lag. But those who are annoyed by the lag (or their staff) are good candidates for becoming content contributors. To them, using any CMS will be preferable to waiting a week. If they do complain, their criticism will be about needing more control to produce more elaborate content rather than needing simplicity for basic edits.

Once you scale back your expectation of distributed authorship, the role of an occasional user gets less important. The occasional user is certainly less important than the primary content contributor role or the engaged users that prioritize website management in their list of responsibilities. You shouldn’t buy CMS for the occasional user. You should buy a CMS to maximize the effectiveness of your core users who are primarily responsible for the content and performance of the website.

Posted in business, usability | 3 Comments »

Are content managers ready for personalization?

Thursday, December 17th, 2009

I have been catching up on product demos recently and have seen some really elegant functionality for marketers. Several products have introduced modules that allow CMS users to plan, implement, and measure multivariate testing, search engine optimization, and personalization without the continued support of a developer. A developer has to put the tools in place but, after that, the CMS user can fully control the behavior of the site and optimize its business impact.

It is easy to get excited by this functionality. But then you think of the difficulty your average organization has with even the basic aspects of content production and you wonder if they ready for these tools. How can you do an A/B test if getting someone to write option “A” is a struggle and option “B” would be a miracle? Of course, not all companies suffer from these issues. The more sophisticated publishers and eCommerce companies have been doing these advanced site management activities even when the technology stood in their way, much less facilitated them. But your average marketing site is still in the dark ages when it comes to managing content.

Will your average marketing group be able to leverage this functionality? Or will it be yet another unused feature that clutters the user interface? My hope is that once contributors and site managers start to experiment and see results, they will rapidly evolve to be more committed and proactive in the same way social media participants started to embrace tagging when they saw their work start to surface in more prominent places. A tight and accurate feedback loop is important in any learning process so maybe access to testing and metrics has been the missing feature rather than usability-oriented functionality like in-context editing. It is probably more effective to make a task interesting and rewarding than to make that uninteresting work easier to do. The former strategy will cause a user to overcome any obstacle he is faced with. In the latter strategy, there will always be some excuse not to do the work. I touched on this idea in an earlier post called “What your intranet needs is a publisher!”

That is not to say that all you need to do is drop in personalization functionality one day and your organization will immediately change. I have seen many organizations fail with this approach because they didn’t have the content to support it. I saw a slide from a Sitecore (below, click for a larger image) demonstration that shows a gradual maturity process that begins with understanding your users and your content and ending with real time personalization.

I very much agree with the model but I think that the trick to success is being able to see real results at every step of the way. Most organizations will not have the commitment to sustain a continuous effort through long periods of no results. Results are easy to felt from the conversion tracking step onward. Getting to that point, however, will require organizations to aggressively push through traffic analysis, experience analysis, and content profiling. Perhaps there is room to get some intermediate outcomes along the way that can keep an organization hungry for more. These outcomes can’t just be in the form of a spreadsheet that is out of date by the time that it is presented. There needs to be some tangible business impact like being able to make a small change to the website that yields some measurable result. If this is not possible, the best one can do is time-box this period of no feedback and have faith that the results will be worth that fixed investment.

They are just coming on the market now but I am really looking forward to seeing the organizational response to these marketing tools. The early adopters will certainly benefit from the functionality because, by being early adopters, they have already shown their commitment to improvement. It will be really interesting to see examples of this functionality transforming mainstream organizations that have struggled in the past.

Posted in business, personalization, sitecore | No Comments »

How much technology ownership can you outsource?

Monday, November 23rd, 2009

Over the past few years we have witnessed the transfer of website ownership out of the technology organization and into the department that owns the information. This has been a positive trend. While technology is certainly necessary to run a website, what makes a website successful is the content and its ability to communicate to an audience. Even though most I.T. departments recognize this, they have other systems that compete for enhancement resources and they often find themselves blamed for latency on web initiatives. Furthermore, technology is an easy scapegoat for more embarrassing organizational deficiencies like not having skilled and motivated contributors. Removing I.T. from the equation puts power and accountability squarely in the hands of the people who own the content (and the conversation) and removes any and all ambiguity about who to blame when the website fails to produced desired results.

As attractive as these outcomes are, transferring ownership is not comfortable. It puts a business manager into a position that he or she has not been in before: an owner of technology. Growing up through the ranks of leadership, most managers didn’t sign up for planning technology projects, directing technical staff, or taking shifts on “pager duty.” They purposely avoided a technical career track and neglected to build those skills. On a good day, they can ignore technology but on a bad day… well, we try not to think about those. Instinctively, the business manager wants someone who he can shout at (or hover over) until the issue is fixed. But who is that person and who pays him?

The first step is to hire a web development shop (systems integrator) to do the initial implementation. Even if you are an I.T. organization, I recommend bringing in a systems integrator who has significant experience on the platform you plan to deploy. These systems are extremely flexible, which means that there are plenty of bad design choices that you can make; you want to work with someone who has ruled out at least a few of them. But what happens after launch? An optimistic (naive, really) approach is to believe that, once the system is implemented, business users can just run it themselves. That doesn’t work. Even if you are lucky enough to have no bugs and contributors that don’t make mistakes, a successful web initiative attracts ideas for making it better. Ignoring those ideas is demoralizing to the users and causes them to dislike the solution.

In many cases, the business unit will create a retainer relationship with the systems integrator where the system’s integrator plays the role of outsourced I.T. This typically only works when there is an internal staff member who plays the role of “product manager” and directs the external development team. Otherwise, the relationship can get very costly as hundreds of uncoordinated change requests start to degrade the usability and maintainability of the solution. It is also costly to have this external partner provide the first line of support. You don’t want to pay consultant rates to triage “the Internet is down” and “I can’t find the ‘any‘ key.”

If it is critical to the business that the website continually adapt to changing requirements and opportunities, it will expensive to maintain a team of consultants working on an endless enhancement queue. At some point, it will be cost effective to hire internal development resources to implement routine enhancements (like template changes). I think that more and more companies are falling into this category. The web is changing so fast. You need to try new things and continually improve.

Here are some staffing levels to consider:

Infrequently changing website: one website product manager managing an external developer. The product manager also does training, contributor mentorship, and first line technical support (including pager duty to differentiate between an unplanned outage and “the AOL is broken.”). The product manager should also maintain and interpret website analytics reports and Google Webmaster Tools.
Continually optimized website: a website product manager with web developer skills. In this case, the product manager has the skills to reliably execute routine template edits and basic system administration tasks (configuring accounts and roles on the system, unlocking files, etc.). It is a good idea for the third party systems integration company to regularly review new code to suggest refactoring for quality, maintainability, and security. Like with the previous staffing level, the systems integrator is also brought in for larger, more complex enhancement projects.
Steadily changing website: a website project manager managing an internal web developer. The web developer has solid DHTML development skills and is proficient in the template developing syntax of the WCMS. Like with the previous level, a third party systems integrator does periodic code review and executes larger enhancement projects. The development queue consists of a medium size (3 days to execute) enhancement, plus a steady stream of tweaks.
Rapidly changing website: when I interviewed publishing companies for my Web Technologies for Publishers report series, I learned that most successful web publishing companies had a development team of between 2-5 developers and deployed new code as frequently as once per week. If your business is your website, this is the staffing level that you probably need.

Full outsourcing of all technology knowledge and ownership is not realistic. At the least, you need to have staff that understand the technology enough to know what to do and how to direct people to do it. How much you go beyond that depends on how aggressively you need to advance your platform.

Posted in business, management | 1 Comment »

Paul Graham on Post Medium Publishing

Tuesday, September 22nd, 2009

Paul Graham, has an interesting essay on Post Medium Publishing. The general gist of is that publishers have never really been in the “content business.” They have been in the business of selling paper (the embodiment of the content). Digital publishing, with its ease of replication, devalues paper as the embodiment of content and exposes the weakness of a pure content business. Publishers can either give content away and look for ad revenues or they can come up with some new embodiment that is both desirable and defensible. Personally, I think that publishers are in the audience business. They command an audience that advertisers are willing to reach. But the audience business has become more difficult with the increased competition from all sorts of information sources. Many people, like Graham, are looking for that new embodiment or channel that will bring back the exclusive audience attention that was so profitable back in the golden years of publishing.

Graham also invalidates some of the successful content market examples publishers are looking to emulate. For example, Graham says that iTunes (held as the gold standard for a successful content business) is not really a content store. Rather, it is a “toll-booth” that charges people to access the most direct path to their listening devices. Apple controls the path, it gets to charge a fee. If you don’t control the device or the channel, you are back in the unprofitable content business. It appears that Time, Inc. has a strategy here but who knows if they will be able to create that market.

Posted in business, publishers | No Comments »