Interview With David Diamond – Part 2

This is the second part of an interview series between myself, Ralph Windsor, Editor of DAM News and David Diamond, author of the DAM Survival Guide, founder of The DAM Guru Program and former Marketing Director of vendor, Picturepark.  In this instalment, I ask David whether he thinks that the characterisation of vendors as being the ‘villains’ of the DAM world is fair and also whether the role of partners is increasing or declining.  Part one of this interview is also available for those who have not yet read it.

 

Vendors tend to be painted as the villains of the piece by many DAM users and a number of the analyst firms. Some of them have made it integral to their branding. Do you think this is entirely justified now that you’re no longer working for one?

Having been away from the industry for such a long time gives me a new perspective on DAM’s true significance to others in the world. I realize now that the message of digital asset management, content management, or whatever, never really traveled very far outside our industry. And for this, I do blame DAM vendors.

DAM vendors have no vision. I don’t just mean in terms of their products, but in terms of how the use of content has evolved over the past few decades, and how it will continue to evolve.

DAM vendors like to start conversations talking about “ever increasing numbers of digital assets,” and that sort of thing. But more important than the numbers of assets organizations use is the ways in which content is used today versus years ago, or years from now.

So, while the early releases of Canto Cumulus and MediaBeacon and other pioneering systems were impressive for the early 1990s, that DAM 1.0 paradigm never evolved. Instead, others adopted it and it became a standard: “Put everything into the DAM and go to the DAM when you need something.”

Imagine if we still had to go to wells in the yard to get water. We don’t do this today because someone had the vision to bring water into the house and pipe it to every room where it was needed. I wrote about this a long time ago – DAM needs to be the plumbing that routes content from its point of creation to its point of consumption. DAM needs to sit where the operating system sits. Until we get to that point, I don’t see those outside the DAM and adjacent industries seeing it as anything more than a cumbersome extra step.

What we do have now are vendors that are more savvy in terms of marketing. Those early DAM vendors were largely run by engineers, so the ways in which they promoted themselves was usually curious, at best. Once the marketroids were given some power, we started to see what appeared to be leaders emerging out of the pack; but here we are a million years later and there is still no Photoshop of DAM – another topic I wrote about years ago. Why? Because there is no system awesome enough to capture the imaginations of most business professionals.

Because of this lack of vision, DAM vendors have done the world a great disservice. Digital content is still very chaotic at most organizations. Opportunities are missed, and liabilities are increased, all because the process of managing content didn’t improve at the same pace as the process of consuming and using content.

I’ve experienced this in the last year working with my band. Here we are a reasonably successful international band with 40 years worth of content history, and no system with which to manage it—unless you consider Dropbox, email and luck to be content management systems.

I didn’t even know where to begin explaining how wrong this was – not because it wasn’t evident to me, but because it wasn’t evident to anyone else. What I saw as chaos, they saw as a system in place. Was it working? For them, yes.

To this day, I haven’t had the “DAM talk” with our management or my fellow band members because the only thing worse than trying to sell DAM is trying to sell it to those who aren’t asking for help.

But this same group of people do understand the benefits of Dropbox, TSA Precheck and group messaging. I blame DAM vendors for not being able to tell a succinct story, and for not being able to develop software that offers a benefit that is clear and easy to understand.

Consider this: DAM was around before marketing automation or Customer Relationship Management software. In fact, it would be easy to argue why each of those practices need DAM in order to function. Yet the DAM industry remains virtually insignificant by comparison to them.

In my opinion, this is for one simple reason: Those systems are easy to explain, understand and justify. And DAM? It’s about content…no, it’s about metadata…no, it’s a taxonomy thing…no, it’s about rights management! No, wait, it’s workflow automation! Yeah, that’s it! Workflow automation!

It’s a total eyeroll.

 

Your former employers, Picturepark and Canto, both had or have resellers/partners. Do you see their role increasing or decreasing in DAM?

That’s a hard question. The most amazing DAM installations I ever saw came from partners – especially when I was with Canto, because their partner network was huge, and full of talent.

We Canto employees would be working with Cumulus day in and day out, thinking we knew it—that we know what it could and could not do. Then we would go and see a customer installation that was done by a partner, and it wasn’t even recognizable as Cumulus. All of a sudden, Cumulus was doing things Canto never Imagined it could do—but this was all thanks to creative talented partners.  

In some respects, that sort of thing was easier with Cumulus than it was with Picturepark. Cumulus was exclusively on-premise, so partners could mess with each installation however they wanted. Picturepark was primarily cloud-based, and it had a less mature API, so the options partners had were more limited.

It was interesting to me how certain Canto partners became quite powerful in the Cumulus ecosphere. Canto’s connection to some of its most impressive customers were through partners, and I had no doubt those customers were more aligned with the partners than they were with Canto.

Years after I worked at Canto, one of the company’s more powerful partners told me how Canto was making it increasingly difficult for partners to be successful. The theory amongst partners, I was told, was that Canto saw partners making too much money and they wanted a bigger piece of it.

This wasn’t a surprise to me because I saw the launch of Canto Professional Services while I was still at Canto. I considered it to be a colossal strategic blunder. I recall fighting with the company’s then CEO about it because I didn’t think we should be competing with the very partners who had delivered to us all those killer DAM installations and creative Cumulus add-ons.

A partner can make four or five times as much on a sale as the vendor, which I guess can make a vendor jealous. But, of course, the vendor is making money on all licenses sold, so I figure that what a vendor should be focused on—increasing license sales. If they are unable to do that, it’s certainly not the fault of the partners.

Again, no vision.

On the Picturepark side of things, partners had far fewer ways in which they could alter the application. Picturepark started out as a cloud service, so the plan was never that partners would be making considerable changes. “Configuration, not customization,” was the mantra. The idea being that a heavily customized application was more difficult to upgrade reliably, which was true.

I can recall many times at which Canto would issue a patch for Cumulus that would cause some partner add-on to explode. Sometimes this was Canto’s fault, but not always. Often, it was Apple or Microsoft—usually Apple—that would change something on the OS level that broke something in Cumulus that, once fixed by Canto, broke something a partner had developed.

This was rarely a concern at Picturepark because the system ran only on Windows, and the cloud aspect of deployment meant Picturepark engineers could test things before they were rolled out to customers. This advantage, of course, fell by the wayside when the company decided to offer an on-premise version of the software.

In a way, on-premise Picturepark was the worst of both worlds. On the one hand, you had to deal with customer installations that would vary in terms of OS versions, hardware differences, etc. On the other hand, because you shared a code base between the cloud and on-premise versions, you still couldn’t let partners do whatever they wanted, in terms of customization.

There were also significant differences in the ways in which customers saw the two systems. Cumulus customers wanted to experiment and tweak everything; Picturepark customers largely wanted to just login and start working. I suppose this stemmed from the cloud vs. on-premise thing—folks who want cloud solutions are likely less interested in fussing with anything.

This was really evident when I was writing case studies. At Picturepark, I would log in to a system to start writing a study only to find a system that was virtually stock, right out of the box. It would take me days to figure out what to say about a system that I hadn’t already said about previously studied systems. At Canto, it would often take me days just to figure out what the hell was going on inside a system because they were each so completely different.

With regard to the future of partner networks, I think this will largely depend on the partners’ roles. If a partner is one who advises, guides and provides services on the more organizational side of things – taxonomy, metadata, structure – things like that, I think that role can’t go away. Customers just don’t know how to do this stuff at first, and their systems will be a mess without thought in these areas.

Partners who are more on the development side of things will need to choose their vendor partners carefully. Not only do you have the concept of developer friendliness, in terms of API capabilities; but you have to consider where the vendor sees itself in terms of offering its own services. Will it pull a Canto and compete with partners? Does it have a good track record with regard to warning partners about API breaks and other system changes? Is it transparent with partners with regard to what add-ons or features it plans for the future?

To proclaim a product as “API-first” goes only so far. Is the vendor also “partner-first”? Is it proactively building a partner network, or just allowing one to exist?

One of the concepts of the “economic moat,” which can be used to identify healthy businesses, is called “network effect.” It basically means that there is benefit in being there because others are there. Facebook with only a hundred global users would not be an enticing social platform. Likewise, a mobile platform with only a few dozen apps would neither attract users nor the developers needed to build more apps.  

Partner networks can be seen the same way: A lot of partners can lure more customers. And because there are more customers, more partners want to sign up, too. Similarly, a lot of add-ons or other expansion options can lure customers and developers who, because there are customers, figure they can make money building even more add-ons and expansions.

This is network effect. It helps identify those vendor partners who are safer bets, with regard to investments. Just because a vendor has many partners doesn’t mean that’s where a new partner wants to be. The trick is in how that vendor works with the network. Do they understand the value of network effect? Are they working the network to increase value to all partners and customers, or are they using the network merely as an additional sale channel?

I advocated at both Canto and Picturepark that we build a directory of partner roadmaps. The idea would be that, if we knew Partner A was already 60% through the development of an XYZ widget, that we could tell Partner B, who tells us they want to build an XYZ widget, that they might want to spend time elsewhere.

We wouldn’t have been sharing competitive information, or even identifying who was working on what. The idea was just that we try to save these smaller companies the time and money they would waste by working on something that is going to put them into a competitive battle they cannot afford.

It would help the partners and, I figured, it would help the vendor, too. Everyone is better off if the scope of development is as wide as possible – that’s network effect. Five versions of the same interface to some tape archive isn’t going to do anyone much good.

Both Canto and Picturepark rejected the idea, even though I couldn’t find one partner who didn’t think it would be fantastic.

—

In addition to this interview series, next week on Tuesday 16th April 2019 at 11am ET, David, Carin Forman and myself are participating in a collaborative webinar panel on The State of DAM Today which will be moderated by Frank DeCarlo and hosted by the London DAM and New Jersey DAM Meetup groups.

Share this Article: