By Deane Barker | June 7, 2012 | 2 Comments
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:
- The raw product.
- A generic (sample) site built with the product.
- A vertical-targeted generic site built with the product.
- 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.
What This Links To
What Links Here
Great post. In our case, both were platforms. In fact, we wanted a solution that could act as a platform for our needs. Vendor B did have a less mature solution that was better than their demo, but everyone lost faith that they understood the business.
That’s why solutions sell better. It gives faith that they understand the problems that the platform is meant to solve. The techies have to make sure that the platform is a true platform and that the solution has a future.
One problem you mention is platform vendors building vertical solutions. That was brought up in the comments of my post. That is usually a bad bet. The platform vendor usually develops the solution after a couple engagements within a vertical and aren’t committed to the solution or the vertical.
When you get to the CMS world, as opposed to the AMS world, a platform is more important. In the AMS space, you are really focused on an open system. In CMS, you need it to be open AND able to support multiple solutions.
We actually were discussing this at lunch today before I saw your post. We have been taking the approach of streamlining our customizations (on top of eZ) so that they can be rapidly and flexibly adapted to meet the highly custom requirements of our clients.
We work primarily with clients who would never consider an out of the box solution because it would prevent them from achieving their existing business goals effectively and their site is too important to them to cut corners on.
We see the CMS as a framework that enables rapid development of commonly needed site components, reduces chances for bugs, gives the client a more sound investment, creates an upgrade path, etc. It is more a toolset that a site that has configuration options.
Interestingly, it seems that the bigger the community on an open-source product (thinking of WordPress here), the more this line gets blurred. There are so many quality plugins and themes for wordpress (most of which can be forked and customized) that people are getting many more options for less investment than they could a few years go.