Loading

On the Jon Marks EPFDW Dilemma

Ian TruscottObservations, , , , , , , , , ,

Jon Marks (@mcboof) has set a challenge to vendors on his blog – to prioritize various elements of what makes a great CMS product, to choose between Editors, Performance, Features, Developers and producing Websites. I know, I’m not a vendor any more – but I started writing a comment and once it got longer than his original post, I thought hang on…

Here’s the challenge from Jon’s post:

So, here is the deal. I challenge any CMS vendor to rate these in order of priority:

  • Editors – A user interface that is a editor or publisher’s wet dream
  • Performance – The fastest, most stable and scalable CMS in the world
  • Features – The richest set of features any CMS could dream of offering
  • Developers – An open, standard, extensible product that makes developers salivate
  • Website – A product that can give you a kick-ass website, really really quickly

I recommend that you can read the rest of his post and the comments, as he invites CMS vendors to both naval gaze and offer up which one of these children is their favourite.

My take – I guess it goes without saying that in every R&D project office, of every vendor and for every open source developer – this argument is or should be happening – it was certainly my experience – but the frustration is that with a finite developer resource you end up with a compromise.

Compromise is a bad word and here and on Jon’s blog – we have the luxury of donning our smoking jackets, filling our pipes and pontificating on what’s right and proper and not have to deal with the grubby commercial realities. The truth of course is that a vendor has to prioritize based on return on that R&D investment.

But, let’s not let that stop us!

So, looking at the comments on Jon’s post as I write this – two experienced CMS practitioners, Philipe Parker and Zahoor Hussain both sat firmly on the fence, with a view that is was down to the project.

I think Philippe and Zahoor are right – client engagements vary and of course some clients need more of one thing than another, but I think what Jon is driving at is to look at this issue through a vendors eyes of building a single product.

But – is this a single product for a single market?

If my CMS is aimed squarely at the Mom and Pop store market, it would be wasted R&D effort to focus on performance or features, in fact if I focused my effort on the ‘kick-ass website’ creator requirement – I may not even need to offer much up to developers.

This hints at an issue in our market – bit like the WordPress debate… broad church.. big undefined market.. etc etc.. It’s also worth noting that Jon refers to a website, so you hear a collective sigh as the CMS crowd mutter – ‘a CMS is not just WCM’…  (a respectful nod to you folks, but I digress..).

Anyway, lets try and play the game – prioritize..

I agree with Adrian Mateljan, who in his comment defines performance to include stability and reliability.

I don’t think that every CMS should be efficient enough to run every News International website on a rusty old 486 under Rupert Murdoch’s desk – but having something that is there when the visitor or content author have the good grace to turn up has to be #1.

The problem with performance, for a CMS buyer is it is such a complex intangible, with a variety of factors at play – and for vendors, once you’ve got the basics right, squeezing out the extra horsepower is a difficult internal investment sell vs the sexy stuff that helps the product in a demo.

Also today, ‘throwing tin at it’ seems to be an economically viable scalability option for some – I was talking to someone involved in a serious government website project – using a large rollout of a LAMP stack open source product – who was scaling horizontally quickly and cheaply, cloning extra machines and replicating databases. And it was really, really working for them.

So, yes having a reliable platform is priority #1. After that, it gets hazy for me.

Starting with Developers – would seem to be a stuck on, no brainer #2 – right?

A WCM project is no longer ‘crank the handle and spit out a brochure’ – it’s build me a web engagement or experience platform, it’s integrate to social media, it’s show people my back office, it’s mobile apps, it’s marketing platforms, analytics, lead generation etc etc..

The problem for the buyer is that it’s a blessing and a curse, a good developer platform offers great opportunity, but can mask some of the missing ‘out of the box’ must haves for editors as well as product features.

The good news is if a pretty boy pre-sales hacker can build something that fits your scenario overnight, imagine what your crew can do with it in production? The bad news is the hangover of supporting and maintaining the bespoke work.

It is of course a trade off – in a previous life I saw a straightforward, but large government project turn to a behemoth as a systems integrator cut out the ‘out of the box’ vendor functionality (to the point that the software was a tiny bit of the solution) for something beautifully bespoke – but in the process turned themselves into a software developer with all of that maintenance and support responsibility shared by just one client. Bad news for the client as the budget ballooned.

I’ve also seen a client case study presented at an industry event, where the vendor and implementation partner (and presumably the client) were buoyant about a project that was based clearly on a developer platform CMS, the slides spoke of the thousands of lines of code and man years it took to implement – but, it’s a successful project.
There’s a balance here somewhere, can you build and support what you need more efficiently than taking the out of the box, possibly compromised feature?

Yes ‘possibly compromised’ – it’s hell for vendors to build broad adoption into a feature (rather than offering an API and saying get on with it) it means making decisions for the hypothetical customer. Those decisions are hard, the edge cases you need to build to, the current customers you need to satisfy, the future proofing, the support.. etc. This sometimes means that it might not fit your requirement exactly.

Take the example of Jon’s requirement “kick ass websites, really, really quickly”:

Vendor A has the sexiest website cookie cutter you have ever seen, hell even YOUR marketers could work it (but the geeks suspect some back end ugliness there somewhere) . Vendor B has the API that would allow you to roll-out your websites, your way (eventually). Which do you choose? Do you, take the big red D pill or is it a cocktail of E, F and W?

I also think there is a great discussion point here about the crew you have on-board, a debate Jon has championed himself. You want to be innovative and engaging – it’s not going to just come out of the vendors box, a well marshalled set of great, creative developers could be your projects rock stars – differentiating your business.

With my background, I have to talk about the E – Editors. As I’ve written previously, nothing is going to starve to death your beautiful website like a lack of content. Or shackle your progress to engagement nirvana if people are still emailing you press releases to post. But, without P or possibly D – where are you going to post to?

As I said at the outset, it is a compromise – I’d suggest that vendors really want to please everyone – but they have a certain skill set, inspiration, experience, set of customers or whetever that gives them strengths and weaknesses – and buyers need to match those with their requirements.

It would be nice if we could marshal this unruly market into buyer shaped niches, where short lists pick themselves. But, in the meantime in a procurement (boring old advice I know) it’s important that buyers get advice, look at reference sites, carry out POC’s, talk to an implementation partner that understand and have done this kind of thing  before.

Your choice, your compromise? What do you think?

Fancy more of this?

Subscribe to my Rockstar CMO Newsletter