The Great Platform vs Product Debate

Laurence Hart makes some good points in a post this morning about the difference between products and platforms. He encountered this situation when trying to find an Associated Management System (AMS) for AIIM, where he’s now the CIO.

He found that some systems are out-of-the-box solutions to problems. Others are toolkits from which you build your own solutions.

Which option is better is a point of great debate. Which is easier to sell is a settled fact: people want solutions/products, not platforms (hold on a sec – I have more to say after the quote):

Vendor A came in and tried to sell AIIM an AMS. They demoed the features of their system and focused on what AIIM does every day. They hit our pain points and everyone was very excited. The platform was mentioned and discussed, but it was discussed as a feature, not the purpose.

Vendor B came in and tried to sell AIIM the platform. In fact, I felt like we were being sold a CRM system with a few AMS features rather than the other way around. Our internal sales team liked the demo but everyone else was wondering how this system could be deployed without making our lives worse.

Now, note what I said: products are easier to sell, not necessarily better long-term solutions. The average user is only concerned about their immediate problems, and they don’t look far enough down the road to understand that they’re going to have new problems later, which this product hasn’t even considered yet.

We see this with content management all the time. So many products wander into the space with all sorts of pre-built stuff and then feign astonishment that no one has thought of doing this before. Users think, “Hey, these people know my problems and they’ve solved them. I will totally use this!”

Flash forward six months, and the user is thinking, “you know, I’d really like to do X.” Problem is, their product didn’t think of X. Later, “I think Y would be really cool.” Well, Y wasn’t covered either. Neither was Z, for that matter.

As a user’s needs evolve, they start thinking, “it would be really neat if we had something we could build on. You know, something where we were less locked in.” And…we’re back to a platform. (We make a pretty good living, in fact, selling Episerver to people who are sick of being constrained by the system that was supposed to make their lives easier.)

The core problem is this: when developing a product’s features, you can’t anticipate every idea someone is going to come up with. I talked about this years ago in a post about building shopping cart systems:

In most cases, you find that you use less than 20% of the available functionality of any store. But the designers of the system have a real problem, because almost everyone uses a different 20%.

What the product developers end up doing is theorizing about common problems, and solving them in a generic way. What this does is take everyone who has a related problem, and funnels them down a single solution. Sure, you can provide some options and different ways of doing things, but you can’t cover everything, and sooner or later, you get platform-ish.

I discussed this at length a couple years ago in regards to CMS: How Sales Prospects View CMS Platforms vs CMS Implementations:

With a CMS product, you really have four levels of implementation:

1. The raw product.
2. A generic (sample) site built with the product.
3. A vertical-targeted generic site built with the product.
4. A client-specific site built with the product.

Platforms are Level 1. Products are Level 3.

In my mind, the best solution is to do something great at Level 3, while still preserving the value of Level 1. So, start with a platform, and build a product on top of it.

As I mentioned in the previously-linked post, Ektron tried to do this with “Starter Sites,” geared towards a particular vertical. They still have a page on them in their Dev Center, but I think they’ve been abandoned. I looked at a couple of them once, and they appeared to be so hopelessly generic that they could only serve well in the absolute simplest of situations – where a client had no budget for implementation, so the biggest problem wasn’t functionality, but cost.

Blend has considered trying something similar in the higher education space – come up with a common set of solutions to problems we see in university websites all the time. But the problem we find is university sites are so different that the best you can hope for is a library of code and methods which you can re-implement in different ways. A good method for making this all manageable and configurable at the editor/admin level has eluded us.

In the end, I’d like to see a good example of a full-blown CMS platform, which someone has built a top-notch, vertical-targeted product on top of it, and is built in such a way that when the product fails you, you can “reach down” to the underlying CMS and completely re-work things. I’ve seen this in the open-source space a bit, but not much in the commercial space.

If you have an example of such a thing, please comment with details.