Three Fibs That Some DAM Vendors Tell (And How To Deal With Them)

Over the last few years, I have witnessed a steady increase in the number of consulting clients asking for assistance in helping them select DAM vendors to supply the software used for their DAM initiatives.  This has been something of a surprise as in the past, my firm saw less demand for this kind of service than we do now.  My expectation was that as knowledge of Digital Asset Management became more widespread, there would be less of a need for specialist advice and expertise.  That has not proven to be the case; a number of factors might explain why:

• There has been an increase in the number of vendors who have entered the DAM market recently, especially those who are funded with private equity and venture capital.
• There are now more vendor sales and marketing personnel who have lower levels of background knowledge about DAM which they can draw upon.
• Many DAM users are now replacing systems as they realise they made many mistakes with their previous implementations which they are keen to avoid again.
• The lack of trust that enterprise DAM buyers have of many of the sources of vendor information such as analyst reports and review sites.
• The homogenisation now exhibited by many DAM platforms which makes it more difficult to differentiate between them.
• The near complete breakdown of the price/value relationship in the DAM software market.

One of the other differences between the current DAM market now as compared with 10-15 years ago is how disingenuous it has become recently.  To put it in plainer term, a number of vendors have sales people who liberally tell fibs about the capabilities their products (and sometimes how the solution will be implemented as well).  That isn’t to say this didn’t ever occur in the past, but by my reckoning, the level of brazenness has moved up several notches compared with where it used to be

In this article. I am going to list a few of the fibs I routinely hear and describe how you can deal with them if (or more likely, when) you encounter them yourself.

“Feature X is definitely on our roadmap”

Let’s open with a tried and (oxymoronically) true example of vendor fibbing which never goes out fashion.  ‘On our roadmap’ is similar to the way young children will tell you that they intended to tidy their bedrooms or finish school homework etc. but haven’t actually done it yet.  There is an expectation here that the vendor will get points for a promise which they have not yet delivered on, as though their words alone have a tangible value.

The obvious answer to this is that no one can predict the future so the low risk assumption is that feature X will never exist in their product.  If the vendor would prefer you not to write down the value of their promise to zero, then they can always back it with something.  Like what, exactly?  How about hard cash?  If the vendor cannot deliver the feature you require by a specific agreed date (and in a fully working condition) they have to give you a refund which they contractually agree with you in advance.  If they are unwilling to agree to this, then you can mutually agree that this will be treated as a feature that they cannot provide.

I will acknowledge this is quite a tough negotiating stance to take, but if you want to send a message to a prospective vendor that you expect them to offer more than fine words and good intentions, it is highly effective.

“Feature Y is in beta, but it isn’t available yet.”

This is related to the previous fib.  In some cases (especially those where the vendor is reluctant to show the beta edition) it might even identical.  Let’s be charitable, however and assume that the capability in-question is very close to being in a fully usable condition, but the vendor is very concerned about not making the rest of their platform unstable.  They clearly only have your best interests at-heart and are deeply concerned that your experience of their otherwise flawless platform is not compromised by rushing out a feature which has not been subject to their rigorous quality assurance procedures.  Who could argue with that?  Well I can (and so should you).

If something is ‘in beta’, the conventional meaning of that term is that it has been developed, deployed to a server and had some testing carried out which indicates the feature is almost ready for release.  That being the case, the vendor should be able to show it (with all the caveats about it not being stable etc. taken as a given).  If there is resistance to show the work so far, the likelihood is that either it does not exist or it is not actually ‘in beta’ but is more likely still being developed and it will be some time before it is production-ready (i.e. in a state when you can use it).  Vendor sales personnel have different interpretations of what ‘beta’ actually means.  The only way to find out if their understanding is the same as your own is to see it in whatever condition it is in right now, before you agree to purchase their product.

In terms of how to deal with it, again, if the feature is critically important and competitor firms have it (and can show it working) then the low risk approach is to assume it does not exist.  There can be all kinds of issues which prevent features from being finalised, not least of which is that it is deemed not as important as something else.  It is better to find this out before the ink is dry on contracts rather than the vendor ‘managing your expectations’ (to use the euphemism) after the fact.

On some occasions, the vendor might be the only candidate who offers some critical item of functionality which is in beta.  This does tend to suggest a further search of the market might be necessary, but if that has been done, the other technique is to add a note into the purchasing agreement where the vendor guarantees they will deliver the required beta functionality in a form that is production ready before the implementation is signed off.  If they can’t, they don’t get paid, it’s that simple.

“No one else has ever asked us for this.  Are you sure you really need it?”

This fib is a back-handed form of arrogance and insecurity sometimes displayed by those with a technical/engineering background.  Sometimes I see the same logic displayed when reading forums where someone asks a legitimate question and rather than responding with “I don’t know” (or saying nothing) the resident ‘expert’ poster will instead try to argue that the problem isn’t a legitimate one that is worthy of being solved.

In the context of buying DAM systems, the insecurity arises because the vendor has been completely blind-sided by the requirement and rather than admitting they lack the required functionality (which they perceive as displaying potential weakness) they would prefer to devalue it instead.

My recollection of vendor interactions is generally quite good, especially during selection processes.  On a number of occasions, I will ask about a given feature, the vendor will use this tactic and then subsequently (usually by the next time I am dealing with them) they will have acquired the same capability that they had deemed unnecessary not so long ago.  Quite often when reading vendor sales literature, I will see the very same words I used to describe something presented back as though it were a concept they alone have come up with.

It should be pointed out that while this is often a form of vendor deflection and objection handling, there are also scenarios where the requested feature really is outside the scope of what most people would expect from a DAM system.  To offer an example, around 12 years ago (when my firm still sold DAM systems) we had a sales prospect ask about why we didn’t have a video conferencing facility built into our DAM.  While I can sort of see how this might be something you would potentially do with a DAM, after a decade or more of thinking about it, I am still fairly sure this is something better handled by a different kind of software more specifically designed for video conferencing rather than DAM.

The most effective way to deal with this is diligent market research and knowing the capabilities of a wide range of products.  This usually points towards carrying out some more in-depth requirements analysis before formally reviewing systems with a view to buying them.  Very little (if any) functionality offered by DAM vendors is unique, you will nearly always be able to find at least one competitor who can provide it also.

Conclusion

The above are just a few of the examples of mendacious behaviour exhibited by some sections of the DAM vendor community.  I have a selection of further instances and I may well follow this item up with some more in the future.  I would be interested to hear from any other DAM end-users (or vendors) who have others that they are able to share.

Lastly, it would be very remiss to tar every firm operating in the DAM sector with the same brush.    There are still many ethical vendors who do not engage in these kind of practices.  I  recommend to clients that they take honesty and being up-front as useful indicators of those suppliers who are more likely to deliver superior levels of service and value for money.  Using these fibs to try to swing sales frequently backfires and loses the firm in-question business which they might have won otherwise if they had simply been more straightforward to start with.

If you found this article useful, there are many similar tips, strategies, tactics and advice in a report I wrote recently:  How To Buy Enterprise DAM Systems which is available with a $100 discount for DAM end-users.

Share this Article: