Confessions of a DAM Vendor

This feature article was written by Kevin Groome, Founder of CampaignDrive by Pica9.

Perhaps if we vendors clear the air, customers will be able to see and hear a little better.

Photo by Shalone Cason on Unsplash

“I wyll neuer bye the pyg in the poke. Thers many a foule pyg in a feyre cloke”
— Anonymous Englishman, 1500s

In one guise or another, I have been selling web-based digital asset management software to major brands since 1996. (Strange thing for an English Literature major to say, I know.)

During those 24 years, I’ve seen buzz words come and go at breakneck speed (client/server, peer-to-peer, data warehouse, data mining, et al). I’ve watched “best practices” rise to gospel-like status and fall by the wayside, forgotten, just as fast.

I’ve watched, at the International World Wide Web Conference, as the inventor of Ethernet fulfilled his promise to eat his words if the Internet did not collapse of its own weight by the end of 1996—by putting the pages of his speech in a blender and downing his “Prediction Smoothie” right at the podium.

To paraphrase the good folks at Farmers Insurance, I’ve learned a thing or two because I’ve seen a thing or two.

Perhaps the most important thing I’ve learned is that buyers of enterprise DAM solutions are always—at least to some extent—buying products sight unseen. And sellers of enterprise DAM solutions are always—at least to some extent—aware that this is the case.

This isn’t because of a lack of diligence on the buy-side, or of goodwill on the sell-side. Rather, it’s because the implementation of any software platform across thousands of users creates a level of complexity that defies anticipation.

No matter how many demos or proofs of concept you may conduct, the day will come when you confront a use case that you and your vendor simply did not anticipate.

The DAM pig in other words, is always in the complexity poke. And as a vendor, I can attest that this fact has prompted more than a few clients to cry “foul” over the years.

So to help clear the air, I thought I would confess at least a few of the facts that cause a disconnect between a customer’s expectations of a DAM and what the implemented reality is likely to be.

Confession #1: DAM is not “user-friendly.” 

Yes, it’s true that the transition to cloud-based DAM has ushered in an era of DAM user-interfaces that look less and less like a revamped version of Windows 95, and more like a slick iPhone app. But when it comes to ease of use in DAM, you have to look beyond the front-end basics (search, find, download), and consider the finer points of Information Architecture; Taxonomy and Controlled Vocabulary; Creative Operations, and Roles & Permissions (aka Governance).

When it comes to these issues (each of which deserves a book-chapter all its own), there is a certain level of complexity in DAM that existing systems (at least to the best of my knowledge) simply cannot “simplify.”

Controlled Vocabulary. Let’s start with Controlled Vocabularies. This is a brand- or organization-specific library of keywords (and related synonyms) from which asset-taggers should or must choose, to make search and retrieval of assets easier for end-users.

A basic enough concept, right? Yes and no. When you build controlled vocabularies in corporate environments, most customers find themselves managing a host of industry- and or company-specific terms, each with its own tree of synonyms and variants, and its own lifecycle. And that means management of your controlled vocabulary isn’t just a one-time task, but rather an ongoing management and maintenance job. And in all likelihood, your evaluation sessions with DAM vendors won’t bring that fact up until long after implementation is underway.

Information Architecture: Next, let’s consider the Information Architecture for your DAM or as some would describe it the hierarchy of categories and subcategories into which assets will be organized.

Certainly, most enterprise-class DAMs will give you the ability to define and organize these categories with something approaching a “point and click” process. (After all, everything in software is at some level point and click.)

But the pointing and clicking isn’t the point. The point is building consensus—across departments, divisions, brands and business units—about what the right organizing principles are for your enterprise. And as far as I can tell, consensus in most corporate environments is challenging to achieve and even harder to maintain.

As vendors, we denizens of the DAM world don’t often highlight just how difficult this consensus is to achieve while we’re in the midst of selling our systems. And so, our customers often find themselves in the midst of an implementation without having done this very human (read, time-consuming) work upfront, and so find themselves pressured by time in a process that often resists timely resolution.

With mature DAM customers, this is no great problem. They likely have been working this ontological problem (one of my favorite words) for years. But for less experienced customers, omitting or even compressing this step can lead to a suboptimal solution, which can result in sub-par search experience, which leads in turn to disappointing user adoption, which results in insufficient ROI.

Which just goes to show: if you don’t take the time to name things properly in your DAM, your DAM will develop a bad name.

Creative Operations: In a large majority of cases, the first use-case that the DAM will address has to do with marketing and brand management. That means the images you upload into the DAM will need to serve an ever-expanding array of media types, both digital and traditional, with a complex list of attributes for each.

In many DAM pitches that I’ve had the privilege to attend, this complex (and fascinating!) topic is often passed over in just a few moments, as the salesperson waves her or his hand and refers brightly and optimistically to automated asset conversions. When customers press for more details, the most common response is a suggestion to take the conversation “offline” so that the larger group doesn’t get lost “in the weeds.”

This is when my spidey-senses, such as they are, start tingling.

That’s because, as a long-time veteran of creative operations environments, I have seen full-page advertising placements delivered with just minutes to spare before materials deadline—and then come a-cropper because of a pre-flight error caused by a badly converted asset.

So, what can we, as DAM vendors do, to help forestall this unpleasant circumstance?

First, develop a catalog of the top 10 (or 50, or 100) external consumers of assets from the DAM (systems, companies, or individuals) with a clear definition of minimum requirements for each. Next, compare the DAM’s file conversion capabilities, and wherever possible tweak them to achieve 100% compliance with your asset-consumer catalog. Don’t trust theory on this one. Deliver sample converted assets to each of your top consumers, and ask. 

Roles & Permissions: Most DAMs these days allow you to define unique roles for various user types, and to adjust these roles as your needs evolve. When discussed, the term most often associated with this capability is (you guessed it by now) “point and click.” But once again, the promise of simplicity is over-shadowed by the process of deciding how many roles there should be, what those roles should be called, which permissions each role should have, and who has authority to manage these settings over time.

If you want to see office politics codified in a database, this may be the best place to start.

When customers are left to their own devices in defining DAM roles and permissions, there’s a strong possibility that roles will begin to proliferate and, over time, duplicate each other. Precisely because it’s so simple to set up a new role, it’s easier to do so than to have a challenging discussion with a business-unit executive who wants what he wants when he wants it. But as time goes by, and the list of roles looks more and more like an unweeded garden, most DAM managers will silently (or explicitly) wish they had kept things simpler and more disciplined from the outset. Everything from search efficiency to user management to usage reporting, it turns out, would benefit from that discipline.

And what can DAM vendors do to help? First, identify the human aspect of the problem as early as possible. Develop a catalog of roles with your customer and help them to get formal consensus across all the stakeholders that matter. Finally, recommend to your customers that changes in roles happen only rarely (perhaps… annually?) and only with the consent of the DAM governance committee. John Horodyski offers some cogent insights on this in a CMSWire post.

Confession #2: User Adoption is usually not well defined in DAM, and even less often properly measured. 

When it comes to adoption, most DAM vendors like to talk in terms that I can only refer to as “gross.” That is, we tend to focus on gross numbers without acknowledging that some forms of adoption are more important at one phase in the journey and other types of adoption are vital later.

For example, the enthusiastic adoption of the DAM by a member of your in-house agency—somebody who understands the importance of asset reuse and is willing to invest time and effort in pursuit of that goal— is likely to be a lot more meaningful than the download of an asset by an external publication or website that you’ll see once and perhaps never again.

As vendors, it’s up to us to help our customers make these distinctions—and to help them look at user adoption from this more informed point of view. Your typical DAU/MAU/QAU analysis just isn’t enough. We have to help our customer dig into these numbers and relate them to the usage patterns we see in the DAM.

For example, this kind of analysis can show you when the ratio of page-views to transactions is rising — a sign that searches are producing less relevant results, which in turn usually relates to the quality of asset-tagging.

Or again, a prolonged drop in asset uploads may indicate trouble spots in your network that are impeding important users from getting their work done.

As vendors, we can wait for these problems to show up in customer support tickets—or we can do some quick, informed, routine analysis of recent uploads to spot the troubles and help customers address them proactively.

And how is this a confession? Because whenever I, as a vendor, have taken my eye off the data-driven “ball” it’s usually because I let myself fall prey for a moment to the SaaS promise of low-service, high-margin relationships. You know—the kinds of relationships where the subscription fees roll in while machines do all the work.

But the truth in DAM, is that the more I work on my customer’s solutions, and work with them to understand the data their systems produce, the better those solutions work for the customer.

That means, in DAM, that SaaS should stand for Software AND a Service. Because that’s where the long-term win-win is.

Confession #3: Most claims of performance in DAM are based on insufficient data. 

This is the problem that I like to call “He-Man DAM.” There’s a great temptation for vendors to run some ostensibly objective third-party tests, and to publish the results, hoping that information-overloaded customers will take the numbers at face value.

But in DAM, performance is more elusive than page-load times alone. Sure, your search results page loaded in less than 1.5 seconds. But how many searches and how much scrolling and/or clicking did the user have to do before finding the desired asset? That length of time is much more meaningful—and much more indicative of the value your system is delivering to users.

Data transfer times are a little less ambiguous—but there’s complexity here as well. Does the enterprise SSO impose an unquantified overhead? Are network management tools throttling data transfer speeds down, to make sure the DAM plays nicely with all the other applications being used? By fixating on performance numbers derived from laboratory settings, customers may be lulled into overlooking the factors that matter much more in the real-world user experience. And sometimes, I must confess, the distraction may serve a vendor’s interests well indeed.

So what can we do, as vendors, to make amends? Here’s a suggestion. We run a series of performance-benchmark tests on the most common transactions about three months after system launch (long enough to have a good sense of what the most common transactions actually are). Then, we re-run those tests monthly and share the results with the clients.

Sometimes, this might reveal a need for an infrastructure upgrade. In other cases, we might find our test cases are no longer common transactions. Much of the time, the results will indicate no material change. But in all cases, as a vendor, this performance-benchmarking would help me to work with the customer on the DAM as a living, evolving entity—rather than a “set and forget” implementation. And for customers, the exercise helps to reinforce that the DAM is a unique entity, which has a performance dynamic all its own—and that success should be measured not against external systems, but against itself, with the objective of steady, continuous improvement.

Confession #4: DAM integrations are not always “plug and play.”

As Ralph Windsor has sagely commented, DAM vendors should take an “API first” mentality to everything they do. That is, we should see DAM as a supporting system that feeds assets into other systems purpose-built for specific needs, and we should take it as our challenge to make the process of retrieving those assets, or updating them, as seamless as we reasonably can. Hence all the talk about “plug and play” integrations between DAM systems and, well, just about everything.

But when you pull back the covers, I have to confess that there’s more complexity to most real-world integrations than this “snap-in” mentality conveys. Much of this has to do with the systems that DAM vendors are trying to connect to, which extend far beyond the Zapier examples that come to mind for many customers when forming their expectations.

But in reality, we find ourselves integrating the DAM to systems that were born sometime in the first Reagan Administration and have been getting extended and enhanced ever since. And while SOAP and REST have made our lives SO much easier (thanks, Messrs. Winer, Box, Atkinson, Al-Ghosein and Fielding!), that doesn’t mean we should over-simplify the process. Customers who are aware of this upfront will have a happier time during the integration process, because their expectations have been properly set, and they’ll appreciate the connection (which in the end will feel seamless) all the more because of their deeper understanding of its complexity.

Confession #5: Our DAM isn’t the single source of truth

This is a misconception that falls easily when you first reflect on it. If you try to build one monolithic DAM to serve the countless different needs that you’ll find in the typical enterprise, more often than not you’ll end up creating a sprawling, feature-laden monster that has left simplicity (and perhaps performance, and maybe security) far-behind.

If, instead, you look to create an environment where purpose-built DAMs can serve different audiences, while remaining keenly aware of each other, you can make sure that there is a single source of truth for each asset, but several — even many — sources of truth across the enterprise.

As a vendor, I have to confess that the notion of being the SSOT was very attractive indeed. And in the early days of Pica9, I advocated for this approach, shutting down plenty of departmental and ad hoc storage solutions along the way.

But nowadays, I recognize much more clearly that the right number and right combination of DAMs will vary for each customer. Sometimes, one is the right number; sometimes, it’s not.

What we can do, as vendors, is to acknowledge the SSOT principle at the asset level, and partner with companies we used to see as competitors to serve the best interests of the customer.

This takes a willingness to be vulnerable. It takes a commitment to customer success above maximizing revenues. But in the long run — and in the short run — it’s the right thing to do.

And isn’t reaffirming our commitment to the right thing what confessions are all about?

Kevin Groome is the Founder of CampaignDrive by Pica9. He can be reached at or on LinkedIn,

Share this Article:

Leave a Reply

Your email address will not be published. Required fields are marked *