In a peer group session we organized for omnichannel stack owners, a large B2C firm and a B2B enterprise shared case studies with contrasting and identical points. Here are takeaways from each presentation that are worth tracking.

Looking at today’s B2C and B2B martech and adtech systems

The B2C firm had understandably made heavy investments in adtech. Their systems — from content to data and decision logic — had predated their martech stack to some extent. This stems from pre-digital (especially pre-pandemic) business models, where the firm had gone to market through distributors and retailers. Now in the era of growing direct-to-consumer business, “It’s all martech,” the B2C stack leader noted. 

But as their initial engagement strategy transitioned from transactional selling to building omnichannel customer relationships, the firm needed to think about their media buying efforts more holistically in the context of customer journeys. 

Based on the ensuing conversation, it is clear that some leading enterprises are formally structuring marketing plus adtech into “madtech” teams. Even if not formally re-structuring, at a minimum, it became possible to glean that nearly all leading companies are:

• Joining data and marketing teams and making measurement part of every activity.
• Focusing heavily on metadata, both at the campaign and asset level, since it’s impossible to draw analytic conclusions without it.
• Developing more in-house AI capabilities to keep building off early learnings.

The B2B case study revealed similar insights but with a greater emphasis on journey optimization as the initial driver. The firm optimized its ad spend for longer and more complex buyer journeys, not just front-end lead generation. This meant integrating media buying and account-based marketing, which isn’t always easy. They simplified the process by having a single DAM that fueled both media channels and messaging via owned-and-operated properties.

Dig deeper: Customer journey orchestration: What it is and why marketers should care

Closing the loop: Striving for martech and adtech alignment

In theory, better martech and adtech integration and alignment should bring enterprises closer to the holy grail of a single, “closed loop” motion — from media buy to loyal, repeat customer. Yet, all the martech leaders agreed that the processes and analytics required to achieve a fully closed loop remain an aspiration. 

To that extent, you need to avoid over-promising. In a world where most enterprises still struggle to align adtech and martech at a basic level, you may, as one leader put it, “have to work with a “180-degree closed loop.” It will take time to consolidate appropriate technologies, data flows and teams.

The necessary skill sets needed to execute in a blended martech and adtech world are rapidly evolving, too. Increasingly, the lines between technical, content and data people are blurring. Sprinkle in the right level of legal counsel, and you’ve got the makings of a modern madtech team.

All this uncertainty and change enhance the argument to focus on core data, content and process capabilities that can work underneath your adtech and martech stacks as foundational building blocks. This may present the most critical objective for overall architecture this decade. A good time to start is now.

The post How enterprises are pursuing martech and adtech integration today appeared first on MarTech.

Over the past half-decade, Real Story Group has seen the rise of a new category of platforms designed to supply core content to the ever-growing channels of customer engagement. After extensive research, we’ve labeled this modern class of tools as omnichannel content platforms (OCPs). Emerging primarily from the digital asset management (DAM) arena, the headless web content management and marketing asset management markets have supplied some key concepts.

Business use cases

The purpose of an omnichannel content platform is to act as a single source of truth for a highly curated set of reusable, enterprise-wide information assets, such as text, data and media. An OCP manages and distributes just the core assets of an enterprise — not all assets, but a select subset needed to provide consistent customer experiences across channels.

OCPs try to solve the problem of divergent customer experiences and messaging when content gets tightly bound to a specific engagement channel, like your website, email platform, sales force automation platform, or customer support portal. Omnichannel content platforms can provide the infrastructure for process efficiencies and messaging consistency, but they also fuel more personalized customer experiences.

At RSG, we evaluate OCP vendors according to nine generalized use cases.

As you’d find with most marketplaces, the typical OCP vendor will only excel at three or four use cases, so it’s imperative to prioritize your most important business objectives when considering these tools. Also, in some cases, the OCP will deliver those services, while in other cases it will just provide the core content building blocks to be assembled somewhere else by a third party or other channels.

Underneath the OCP covers

At their core, OCPs are component content management systems. However, unlike the technical documentation platforms of the past, they’re built for the media and data-centric marketing era. A key design principle is that text, media and data are all first-class objects. Contrast this with more traditional approaches where, for example:

• In documentation systems, images remain bound to text.
• In most ECM and DAM platforms, structured text and data are subsidiary extensions to files rather than independent objects.

The keyword here is “objects.” To support complex data models with compound assets and sophisticated where-used analysis, an omnichannel content platform needs to be object-oriented, both in code and repository. This is why most of them are built on graph-type datastores.

What gets managed in those datastores? To support specific business scenarios around aggregating assets into specific experiences, an omnichannel content platform needs to support content at an atomic, component level. The types of component assets could include:

• Micro-content (e.g., offer copy, email blocks or text messages).
• HTML micro-experiences (e.g., widgets).
• Document assets (e.g., PowerPoint decks).
• Digital assets (e.g., infographics).
• Video assets (e.g., short video snippets).
• Audio assets (e.g., podcasts).
• Data assets (e.g., coupon codes, pricing, offers and product data).

As discussed previously, the OCP may or may not assemble these assets into compound deliverables. Still, at a minimum, it should make them available and track their reuse (where the asset gets deployed as-is) and derivation (where the asset gets modified for a specific context).

Derivation is an important feature in an omnichannel world where context often gets set at the edge of the customer experience. For example, you may modify a core re-usable video snippet differently for Facebook than for Twitter, let alone a partner website. The omnichannel content platform needs to track these derivations so that, for example, when the core “parent” asset gets modified, downstream “children” owners get notified.

The OCP marketplace

This is a small, but growing, marketplace. Like most emergent technology markets, you can roughly divide omnichannel content platform offerings into more extensible and complex platforms versus simpler or specialized products.

This looks like a wide-open marketplace, but a few caveats are in order.

• Major vendors – Acoustic, Adobe, Contentful, Nuxeo (now at Hyland) and Oracle – have largely failed to provide unified solutions with object-oriented asset management services; many people consider them OCPs, but they typically come up short.

• Smaller players like Picturepark, Tenovos, and MarCom Central have decent offerings, albeit less robust.
  
• Sitecore’s “Content Hub” offering is separate from its flagship “XP” WCM platform and comes via the acquisition of Brussels-based Stylelabs.

The future of omnichannel content platforms

Omnichannel content platforms will likely not replace your existing content management systems—but co-exist with them. Like many omnichannel services, an OCP becomes an enterprise-wide layer underneath your other content and engagement platforms. You should remain suspicious about any existing content/asset management solution in your stack playing this role. You’ll find them either too bound to a specific engagement channel or too restricted in terms of information types and model extensibility.

This space is also expanding rapidly as enterprises pay more attention to customer experience across channels. With analog solutions for core customer data (customer data platforms) and decision/rule engines (journey orchestration engines) at an enterprise-wide tier, OCPs that unify the management, delivery, and tracking of reusable information assets will become increasingly important.

Ever wonder how frequently marketing software is replaced?
Here’s the answer.

Download the 2022 MarTech Replacement Survey!

The post The rise of omnichannel content platforms appeared first on MarTech.

Well, reality can prove itself quite different. In Real Story Group’s role as a buyer’s advocate for martech stack leaders, we’ve noticed a recurring trend where larger software companies often disrupt well-reasoned martech selection strategies through aggressive and frequently questionable tactics.

Of course, none of this is new, and perhaps vendor bullying today is more subtle than in years past — but it remains just as persistent.

A typical scenario

Imagine this scenario: You and your team go through a proper technology selection process. You do everything right. Your team comes to an educated consensus decision. Based on empirical testing, you are on the verge of selecting a platform not sold by one of the big vendors.  However, these big vendors are aggressive, publicly-traded companies, not used to getting turned down.

So they approach a board member or senior exec at your firm, trying for an end-around your process. Unfortunately, there’s a long history in software sales of “selling up the chain.”  Back in the day, this meant deals on the golf course; more recently, it’s cajoling over lunch, at executive councils, and boardroom get-togethers.

Now it might seem anachronistic to talk about a supplier bullying a customer. As the buyer, don’t you have power in this situation? But that’s just the point. Large martech vendors employ specific methods to disempower enterprise selection teams.

How it works

Here’s what I often see:

1. High-ranking executives from the major software vendor demand a meeting with your boss’s boss or a C-level executive. Given that this vendor may work with other parts of your enterprise and everyone wants to maintain this relationship, they typically get the meeting. Or they have already networked with your leadership at industry events.
2. The vendor touts traditional, one-size-fits-all analyst rankings to prove they are “a leader.” If you select anyone other than a leader, it means a risk to the customer’s business (and, by implication, valuations and careers).
3. They belittle the enterprise selection team: “They’re not strategically thinking like you need to do…”
4. They belittle the selection process: “They got lost in the weeds and focused too much on functionality.” (This is a particularly ugly allegation because the most bully-prone vendors tend to carry the most technical debt, so they often want to avoid test-based selection processes.)

If all else fails, the vendor may dramatically slash their pricing at the last minute as a defensive move or even give something away cheaply or for free. This isn’t exactly bullying, but it warps the process for sure. Just remember, technology is never truly free.

A tale of two enterprises

Recently, I’ve witnessed two dramatically different outcomes to these tactics taken by one of the most notorious of these vendors. (If you’re an RSG subscriber, contact me to hear the gory details.)

The vendor bullied Enterprise #1 into selecting an ill-fitting solution against the wishes of an interdepartmental selection team, persuading a senior executive sponsor that only that vendor’s array of platform offerings would prove robust enough. The implementation was so difficult and expensive that it did not launch after two years. They’re now engaged in a multi-million dollar lawsuit.

Enterprise #2 said no to the same bully. The alternative system they selected has recently launched, and while no technology is perfect, the reception has been positive so far. The losing vendor’s calls and threats haven’t stopped completely. But when questions come from upper management, because the process was grounded in user-centered design thinking, the activation team can prove that their choice will lead to the best adoption and drive better business value.

Ultimately the fate of your enterprise is often going to depend on the strength of your leadership and, by extension, your ability to connect your decision to strategic business objectives. If you can cast your decision in terms of key metrics you’re trying to move, it becomes less susceptible to outside manipulation.

What you should do

First, recognize that often the biggest martech vendors carry the biggest risks.  That doesn’t mean you should avoid the über-players in these markets, but it does mean you have to prepare for them to try to bulldoze over you should you not tip things their way.

Since the bullying is real – and so are the long-term consequences of making bad technology decisions – you need to give your team and leadership the ammunition to push back. Let me know if I can help. In the meantime, feel free to share your experience with this phenomenon via the hashtag #VendorBullied on LinkedIn or Twitter.

Real Story on MarTech is presented through a partnership between MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps enterprises make better marketing technology stack and platform selection decisions.

The post Real Story on MarTech: Beware of vendor bullying appeared first on MarTech.

In nearly every case, DAM buyers find themselves with a desire to advance their enterprises along this phased maturity spectrum. And for better or worse, DAM platforms in the marketplace tend to cater to buyers in one of these phases.

As a DAM technology customer, you’ll want to honestly assess where your enterprise sits on this maturity spectrum and where you realistically want to get. Once you make this assessment, you can choose a DAM technology that will help — not hinder — you from getting to where you want to go.

DAM 1.0: DAM as a basic library

The hard truth is that many enterprises are still at DAM “Zero,” with assets scattered across the enterprise in a multitude of shared drives, cloud file-sharing services, or on personal devices.

So a first step in your DAM journey is employing a unified system to serve as a single location for an asset to reside throughout its lifecycle. A packaged Digital Asset Management system can help you manage images, video, and audio files from ingestion to publication to archive.

DAM 1.0-level enterprises have a system that serves as a library, where staff can go to check-in and check-out assets. This is can prove a significant improvement over an uncategorized mess you endured before.

While a DAM 1.0 library is an essential starting point, you’ve potentially just created another (albeit better) silo of content in your enterprise. The DAM is just another destination to store and retrieve assets. In order to actually do something with these assets, you need to download them from the DAM and upload them somewhere else.

DAM 2.0: DAM as a marketing tech service

For years, digital asset management was either not included or marginalized in the marketing technology conversation. People viewed DAM as the tool of creatives, brand managers, and even (wait for it…) librarians.

Today, most enterprises recognize that DAM resides firmly in the MarTech conversation, but that DAM has become an anchor service in enterprise stacks.

In a DAM 2.0 model, a DAM system is a critical part of the asset creation workflow. Serving as the repository of record for work-in-progress and/or completed assets, it is integrated with upstream content creation systems and downstream systems of engagement.

Designers store their work products within the DAM directly from their creative tools. Marketers who spend their days creating experiences in systems like web content management, marketing automation, ecommerce, or social publishing tools can pull or reference assets directly from the DAM.

The most mature DAM 2.0 implementations are characterized by a smooth flow of content from creatives to customer touchpoints where the DAM is often invisible to key participants, including marketers.

Still, a key limitation for most DAM 2.0 deployments is that this flow of content is uni-directional and missing opportunities to integrate analytics in a meaningful way. Moreover, these implementations remain limited to binary image and media files, perhaps with some associated “copy,” so they typically don’t cover the full breadth of your marketing and customer experience micro-content.

Download Enterprise Digital Asset Management Platforms: A Marketer’s Guide

DAM 3.0: DAM as an omnichannel content platform

In recent years, many enterprises have worked hard to modernize and optimize their marketing and digital experience technology stacks. In most cases, however, silos still persist, and enterprises struggle to provide coherent customer experiences and campaigns across touchpoints.

One way some forward-looking firms are trying to combat content silos is by employing an “omnichannel content platform” or OCP. RSG evaluates a large handful of OCP vendors.

The purpose of an OCP is to act as a single source of truth for a highly curated set of reusable enterprise-wide information assets, such as text, data, and media. An OCP manages and distributes the core assets of an enterprise — not all assets, but a select subset needed to provide consistent customer experiences across channels.

While some OCPs have spun off from the headless web content management and marketing asset management markets, the more capable OCPs have emerged primarily from the digital asset management arena. Several DAM vendors have applied their sophisticated component-level management capabilities to handle narrative content and data alongside of media assets.

In addition to managing media, narrative, and data all as first-class objects, a key feature of a DAM 3.0 system is the introduction of two-way flow of information. For example, robust OCPs should be able to track deployments (including automated pulls) as well as ingest and display enterprise analytics in context.

Finally, OCPs need to be able to manage complex parent-child relationships:

• Between core assets and their many channel-specific derivatives (e.g., the shorter Twitter rendition of a foundational marketing video); and
• Between core assets and where they get included in compound assets (e.g., an image in a video).

In technology terms, this means that OCPs need to be fully “object oriented,” and it turns out that few DAM platforms are built this way. On RSG’s subway map in the past year, we’ve since broken out OCP as a separate (red) line, to distinguish from the DAM (purple) line, though you’ll notice some substantial overlap.

The Red and Purple lines are related, but distinct Source: RSG

The right partner for your DAM journey

Every enterprise lives within one stage of this DAM maturity spectrum, but no one has reached their final destination. Even the most sophisticated enterprises are constantly trying to improve the way they can provide experience creators with the most impactful content.

Like it or not, the DAM marketplace is quite fragmented with regard to vendors’ capabilities to serve each of these phases. We’ve definitely seen cases where enterprise ambitions have gotten throttled by their incumbent DAM vendor. By the same token, I’ve seen enterprises overbuy this technology. An object-oriented, DAM 3.0 (OCP) toolset necessarily brings much more complicated interfaces and integration requirements, and a firm that’s unprepared for this complexity will see negative returns here.

So figure out where you are today, and judge where you’ll likely end up in the mid-term, and make technology choices accordingly.

Real Story on MarTech is presented through a partnership between MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps enterprises make better marketing technology stack and platform selection decisions.

The post Real Story on MarTech: Getting to DAM 3.0 appeared first on MarTech.

While some of the most sophisticated enterprises have figured out how to effectively manage assets, some of you are just starting out on this journey. I regularly hear marketers and IT people say, “I just need something that’s better than Dropbox or Box to manage our digital assets.”

Yet when really pressed, these same people realize that their needs are more nuanced than just a better Dropbox. They are really looking for the functionality Digital Asset Management (DAM) systems were built to provide.

Paying the price

Why specialize here? Because in an era of visual story-telling, managing digital assets is no longer a “nice to have” but a “must have” for digital marketing. Yet even today the rapid growth of digital media-driven experience needs can catch enterprises by surprise, and martech stack leaders often bear the burden of absent asset management services in their stack.

Part of the problem lies at a senior management level, where I’ve found most organizations lack understanding and perspective on the severity of the problem. They don’t recognize its impact on the business and the value that DAM technology can provide. So let’s look at business rationales and then specific problems to solve.

Download “Enterprise Digital Management Platforms: A Marketer’s Guide“

Three rationales

At RSG we’ve seen three major rationales for investing in a DAM tool. At a high level, enterprises face pressure to do the following:

1. Reduce costs and risks;
2. Generate new revenue opportunities; and
3. Improve market or brand perception and competitiveness.

Cost reduction implies greater operational efficiency. You do more with what you have, do the same or more with less than what you have, or wring out costs by optimizing or changing processes. Greater operational efficiency entails increased communication and collaboration; automation; and sharing of resources, systems, and processes.

Keeping important assets under management also reduces your brand and compliance risks, and allows you to apply policies to where and how assets get used, and disposed. This becomes particularly important when you license rights for external creative assets.

New revenue generation requires developing new products or services, finding new or expanded uses for existing products and services, or uncovering new or adjacent markets for existing products. At the core, this process requires operational agility. The organization must have the internal drive and collaboration to change processes and make things happen; the infrastructure must facilitate a quick response to new opportunities.

All enterprises need to produce, manage, and deliver an increasingly broad set of collateral information for each new or revised offering. In other words, your digital and media assets need to evolve and adapt as fast as your revenue streams, and that takes proactive management.

DAM pain points: A quick quiz

How do you know if you need Digital Asset Management technology in your enterprise? Let’s try a quick quiz — how many of these challenges resonate with you?

• You can’t find an image, video, or a piece of media that someone else needs right now.
• Your asset production or distribution process — or some large part of it — isn’t streamlined.
• Too many silos of disconnected, localized “libraries” don’t work together.
• Systems for managing the particularities of video — especially high-definition (HD) video — are lacking.
• Multiple informal systems duplicate or complicate efforts to manage at an enterprise level.
• You can’t readily share media across projects, groups, divisions, partners, or channels.
• Your marketing messages aren’t presented consistently across groups, organizations, verticals, and target markets.
• Your logo is misused, or your brand is inconsistently displayed.
• You want your social, web, mobile, and email marketing channels to work off the same set of base assets for a combined campaign, but they cannot today.
• You have a rich set of images but want to just find those with a particular shade of, say, orange.
• The collaboration, review, and approval cycle is slow, inefficient, and manual; the material isn’t in a form that everyone can review, especially partners or legal reviewers outside the company.
• External or internal specialists frequently re-create content, artwork, layouts, slides, presentations, and assets — starting from scratch even when something already exists.
• Your team can’t respond rapidly to partners, distributors, customers, or clients who need your assets to help you drive revenue.
• Tracking revisions of works in progress or finished works is difficult — are you working with the latest approved version?
• You need multiple different renditions of an asset but don’t have time to make them manually.
• You can’t propagate changes to a source asset to all the derivative variants.
• You can’t track asset use — where it’s used, who is using it, and how frequently it’s used.
• Confusion reigns around the (manual) tracking of licensed photos, images, or other assets.
• Your firm was docked or fined for violating the usage rights of a licensed asset because no one knew the rights, which weren’t attached the image, and couldn’t be readily looked up.
• Product imagery is showing up differently in your ecommerce (or related) platform, compared to the rest of your digital properties.

For how many of those twenty bullets did you check “yes?” If it was more than eight, you probably need a DAM platform, or to revisit your current DAM implementation.

Business scenarios

But how do you know which DAM technology is right for you? As usual, at RSG we’re going to suggest filtering by business scenarios. It’s a measure of the potential richness of these solutions that there are more than a dozen business scenarios for DAM.

That said, the typical DAM platform only excels at only four to six of these scenarios, so you’ll want to prioritize carefully. There’s also a complexity spectrum here: solutions for brand asset management are typically simpler and cheaper than those that support compound marketing asset management or video and audio (media) management.

For a deeper dive, check out this series of posts that describe these use cases in more detail.

Coming full circle

Thus far I’ve been talking about the benefits side, but there’s an expense side to the ledger too. When making your case for DAM, be sure to include a realistic total cost of ownership, accounting for key non-technical costs such as business analysis, education, support, asset clean-up, taxonomy/metadata development, change management, and program management to name a few. As with other technology platforms, the DAM technology itself is typically a small percentage of your overall cost of asset management operations.

There’s one role in particular you need to account for, and it might be new in your organization: librarians. You need someone to manage your assets, ensure they are categorized correctly, findable, and cleaned up from time to time. Your DAM repository is like a library, and libraries don’t function long without librarians.

Which brings us full circle. The larger story here is that content management is critical to omnichannel marketing. So make sure you account for asset management in your marketing technology stack, but also make sure you account for suitable asset management resources for your marketing operations team.

Real Story on MarTech is presented through a partnership between MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps enterprises make better marketing technology stack and platform selection decisions.

The DAM playbook: Getting the most out of your digital asset management system: Coming up at MarTech

The post The Real Story on MarTech: The case for Digital Asset Management appeared first on MarTech.

Based on two decades of helping large enterprises select the right martech platforms, I believe martech customers should overcome any reticence and arm themselves with a methodical approach. A savvy reference checker will employ a variety of different approaches and questions to obtain a richer and more transparent view of potential suppliers. Moreover, reference checking is invaluable when it transcends simple lists of strengths and weaknesses to uncover broader issues of supplier “fit” for you.  And it’s all about fit!

So I’m happy to share twenty-five specific questions for which my Real Story Group colleagues and I have experienced good results. But first, like any good campaign, you need to set it up right…

Prior to the conversation

The first issue to address is: Who on your team will conduct the reference check? Some buyers remand this service to a procurement specialist, who will bring some useful experience to the task, but will not know the subject matter and is only likely to ask check-the-box questions. Ideally, a subject matter expert from your selection team will lead the effort, perhaps in conjunction with a sourcing specialist.

Likewise, try to learn a little about the interviewee before you call (e.g., a quick LinkedIn check). Recognize that their role will be restricted to what they know and how they approached their own implementation. Moreover, you’ll want to recognize the cultural component. For example, interviewees may only make only subtle criticisms or praise, which you in turn need to decode carefully.

Most vendors will give you a list of customers you can call. Note however, that they are likely only to share their most satisfied customers, and in fact often bestow extra benefits for those who provide such references. To counter this potential bias:

• Leverage the list of questions below for many possible alternative inquiries that may subtly expose weaknesses and problems;
• Don’t hesitate to supplement the vendor’s list with contacts from your own industry or networks;
• When reaching out to the interviewee, give them some reasonable context about your project, how you received their name, and how much time you’ll need (ask for an hour but explain you may not need that much time);
• Remember to reiterate that the conversation is “confidential,” so their answers will contribute to your overall knowledge of the vendor, but you will never cite any identifying information about the individual or the company beyond your team; and
• If the interviewee is busy, ask if someone else in the firm could speak to their experience

Site visits are ideal, though obviously time-consuming for everyone — and still a fraught topic during our lingering pandemic. The questions here work just as well on the phone; but don’t hesitate to set up screen-sharing, and some cases, an interviewee will informally show you useful nuggets.  (To make everyone comfy, don’t record the session; just take good notes).

Questions to ask

You almost certainly won’t have time to ask every question below. This is a comprehensive list, so pick and choose based on time available, and the circumstances of your conversation.

1. What’s your role within the company?
   Titles vary. Find out what the interviewee really does.
2. How long have you been using Platform X?
   The longer the experience, the more credible the input will be.
3. For what have you been using the product? Give a brief overview of your own scenarios/use cases.
   This is important context for the relevance of their input for your use cases.
4. What made you select the product in the first place?
   This is additional useful context.
5. Who did the implementation? How long did it take? How much did it cost?
   The quality of an implementation can have a huge impact on success and affect the “reputation” of the technology itself.
6. What was the most expensive part of the solution and implementation? Were there any unexpected costs?
   Interviewees may be reluctant to share financial details, but they may share general TCO advice.
7. What are the top three things your organization likes about the platform?
   The key here is to encourage the interviewee to think beyond personal pros and cons and speak on behalf of the whole firm.
8. If you were the product manager and could change three things about the product, what would those be?
   This is a better way to ask about “weaknesses.” The interviewee may have pause and think here; give them time.
9. Are you on the current release? How have upgrades gone?
   In some cases, the release version can affect answers. If they’re not on a reasonably current release, this is a red flag.
10. What do you know about coming versions, timeframes, etc.?
    Match their answers against what the vendor tells you. This may also provide further hints at key limitations.
11. How has it been working with the vendor? How would you describe their culture? How has your relationship evolved over time?
    The idea here is to distinguish between technology fit and organizational fit.
12. When have you had to turn to the vendor for support?
    This may signal tech-support intensiveness.
13. Where do you go when you have problems and you need really good answers? What user groups do you attend, in person and online?
    You want to know about the all-important community around a technology and vendor.
14. For a future customer, what’s the best fit for this solution? For what types of organizations would it work best/worst?
    This asks the same question about strengths and weaknesses in a different way.
15. What was the biggest surprise you encountered (positive or negative)?
    The answers could forewarn you against potential difficulties.
16. If you had to do it all over again, what would you do differently?
    This question helps you draw from the lessons they’ve learned.
17. Is there anything else that’s significant about your experience with the vendor or the product that we haven’t discussed?
    This ensures that you’ve gleaned as much as you could.
18. Is there someone else in your organization with whom we could talk?
    Sometimes another individual is a more informed resource. Oftentimes, project managers can point you to architects and developers who may have more intimate knowledge of the inner workings of the vendor and technology.

Varying the script for services firms

Thus far, I’ve assumed you’re seeking references for a technology vendor. To gain more insight into services firms (e.g., integrators, agencies, consultancies, or even the consulting arm of the vendor itself) most of the same questions above still apply, albeit with minor tweaks.

For services firms, however, you’ll want to supplement the list above with inquiries on methodologies, project management, experience, and personnel.

1. Did the firm follow the methodology they initially proposed?
   Services firm often pitch impressive implementation methodologies, but in practice, they may not follow them.
2. How many other similar implementations had the integrator done before your enterprise? How well did they know the technology? When did they have to bring in the vendor itself?
   These questions hone in on the all-important dimension of practical experience.
3. How tight was their program and project management? Did they finish on time and on budget?
   Don’t hesitate to be direct about these basics. When things go wrong, it’s often due to projected time frames and budgets.
4. Beyond technical and product-specific experience, what other skill sets did they bring to the project?
   One of the value-adds of using third-party services firms is the extra capabilities — often “soft” skills — that they can bring. Different firms have different specializations.
5. Describe the issue reporting and escalation process. How responsive are they to minor/major issues?
   This is analogous to the support question you’d ask any software vendor.
6. Who were the most capable individuals with whom you worked?
   Services firms are only as strong as the team working on your account. Try to find out who the stars are.
7. Would you use them again? If so, for what, specifically?
   This is another way to understand the best/worst “fit” for an integrator.

Conclusion

References can prove to be extremely useful — not just for final diligence — but throughout the supplier evaluation process. In other words, treat this differently than an employee recruitment, where you might check references only after an initial offer has been extended. Inquire early and often.

The vendor may hold back and not supply references until you’ve signaled intent to work with them, in which case you’ll want to push back. Indicate your intent to leverage references not as confirmation that the vendor is reasonably competent, but as part of your selection process.

Selecting marketing technology is hard. Implementing it is even harder.  You can get smarter at both by integrating comprehensive reference checks into the early phases of your programs.

Real Story on MarTech is presented through a partnership between MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps organizations make purchasing decisions on marketing technology applications and digital workplace tools.

The post The Real Story on MarTech: Ask the Right Reference Questions appeared first on MarTech.

There are many reasons for this, but in my experience, most technology problems originate in the critical early stages of an initiative. Once the boat gets headed in a particular direction, it can be hard to steer it back on course.

Choosing the right vendor and technology for your marketing initiatives is one of the most critical decisions you can make in those early stages. The wrong choice won’t necessarily doom a project, but it can make success much more difficult to achieve.

In the end, selecting technology better means selecting better-fitting technology. Here’s a look at 10 steps for doing just that.

1. Build the right team

Make sure to put together a team in the first place! Too many technology decisions still get made by a single person or department, which leads to a host of problems down the road. For example, I’ve seen marketing teams select tools that couldn’t integrate with the rest of the stack, and IT teams select platforms with prohibitively bad usability for marketers.

An interdisciplinary team of marketing and technical stakeholders is the best way to go. Just make sure the team is chaired by a business leader.

2. Define business success

You’re going somewhere with this new marketing technology. Where? You’d be surprised how many times an enterprise can’t answer that question. Instead, project leaders tend to articulate goals like “We need to replace our outdated marketing automation platform.”

Okay — that’s probably true. But what are you actually trying to accomplish from a business perspective? Do you want to empower more people internally to send messages to speed your processes and broaden your reach? Integrate omnichannel analytics to create better engagement with your existing customer base? Save money by escaping from an overly expensive solution? Those are different goals that could take you to different vendors.

Every selection process will confront you with potentially difficult trade-offs. Clearly articulated business goals provide a consistent touchstone throughout so you can make the right decisions along the way. Business goals as selection criteria also protect you when big martech vendors start bullying your executives.

3. Develop interactive requirements

Most tech selection requirements suck. But they don’t have to.

The first thing to do is close Excel and open Word. Avoid long checklists of requirements and instead tell digital stories. Here you can go back to your familiar marketing playbook of user-centered design (UCD) methodologies, emphasizing use cases, stories or top tasks — it doesn’t matter what you call them. Just do it. (Here’s an example.)

That way, when vendors pursue an agile competition that includes demos, prototypes and training, the experience becomes interactive (because you’re getting hands-on) and real (because you’re telling your unique stories).

4. Get the right shortlist of vendor options

Getting the right shortlist is critical. Too many enterprises waste time evaluating tools that are not good fits.

Don’t use single-snapshot views of a marketplace as a way to determine who should be on your list. Instead, find potential solutions that were fundamentally built to satisfy your most important use cases. In particular it’s time for quadrants to get “real.”

5. Draft a real RFP

Enterprises get anxious about crafting requests for proposals (RFPs), and with good reason: Developing an RFP can be a nerve-wracking endeavor. The selection team sometimes reacts by overdoing it — putting together long checklists of requirements and placing vague demands on bidders.

You can do this differently. RFPs should be human-friendly, human-scale and human-oriented. Get rid of buzzwords and share the stories you developed in Step 3. Yes, you need to include technical and architectural requirements, but even those can be presented as asking more about “how” and less about “what.” If you invite an intelligent conversation, you’ll get much better proposals.

6. Remember: Seeing is (almost) believing

But you shouldn’t put too much weight on written proposal responses to RFPs, because interactive technology will always look different on the screen than it did on paper.

The demo phase is key, because that is where you can really start to discriminate among competing offerings.

Just don’t make the common mistake of letting vendors demonstrate their wares in unstructured ways. Set up a tight demo process where competing bidders show how their systems will work in your scenarios. Likewise, when you’re reviewing integration or other technical requirements, press the bidders to show you live examples with code that is actually running, rather than just showing you diagrams or making vague assurances.

7. But don’t forget that doing is better

Seeing is good; doing is better. Always schedule a bake-off among at least two finalists where the members of your diverse team can get hands-on with the competing systems. This takes effort on all parts — not least because it requires some user training.

This will also likely cost you a modest sum of money, but the payoff is oh so worth it. Test-driving a system with your own scenarios and data gives the best indication of whether the technology — and the vendor — is a good fit. Critically, it also teaches you firsthand about all the changes you may need to make internally to fully exploit the new system.

Five stages of design thinking represented as steps for vetting a martech platform, with the number of prospective vendors in parentheses. Source: Real Story Group

8. Lose the formulas

During this process, you’re going to make “down-select” decisions — essentially voting some vendors off the island. What is the best way to do that? There are many legitimate ways to make decisions: voting, consensus, leadership fiat, and so on. When working with clients, I try to get to a consensus, though that’s not always possible.

There’s one approach you should avoid: mathematical formulas, where team members score the competing offerings and you apply weighting percentages to come up with overall rankings. Such spreadsheet-based approaches offer the chimera of scientific validity, but in practice, they almost never represent the real judgments of the team. What really happens? People retrofit their scores to reflect their own intuitive rankings.

Instead, take a no-B.S. approach of talking openly during wrap-up meetings and inviting members to rank-order and justify their choices, then work to get agreement on which vendors to push through to the next round. The good news is that if you have followed an adaptive, empirical approach as described above, the differences among vendors typically come into very clear relief.

9. Negotiate early and often

Most customers don’t start to negotiate fees and terms until they have chosen a vendor. That approach disempowers you in several respects. First, the loss of competition erodes your bargaining power. Then time pressures work against you, as pressure builds to start deploying the platforml you’ve chosen.

Instead, you should start negotiating when you start receiving the first responses to your RFP. You should insist on comprehensive price proposals and draft agreements up front. Start to whittle away excess fees, push back on weak service-level agreements, and challenge any unfriendly terms. And make it clear that responding to your concerns is a condition for getting to the demo round — and for making it from the demo to the bake-off. And after the bake-off, engage in further negotiations before announcing the winner.

Your mantra at every step should be, “Price and terms are part of our decision process.”

Vendors will push back. They are experts at this game. You likely are not an expert, but you’re the buyer, so you should set the process and you shouldn’t worry about hurt feelings. Everything gets reset once you sign the contract, so get the best contract you can.

Read more from Jarrod Gingras of The Real Story Group

10. Pilot quickly

The best way to confirm that you made the right choice, and the best way to understand how things will be different with the new technology, is to launch a pilot test in a live environment as soon as possible. While the bake-off was not designed to create a production instance, in the pilot you want something you can actually roll out to customers or your workplace peers.

So pick a good pilot — not something too complicated, but still a representation of the value you want out of the platform. You may want to launch the pilot in a single country or specific marketing use case. However you set up the pilot, proactively capture lessons learned before moving on to a broader set of rollouts.

The end goal

In the end, selecting technology better will lead you to selecting better-fitting technology. A new platform itself is no guarantee of martech success, but choosing the right tools sets you up to succeed at all the other changes your team needs to carry out.

Real Story on MarTech is presented through a partnership between MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps organizations make purchasing decisions on marketing technology applications and digital workplace tools.

The post The Real Story on MarTech: 10 steps to making better vendor selection choices appeared first on MarTech.

What’s a bake-off?

In the context of an agile martech selection project, a “bake-off” is really a competitive proof of concept where the two vendor finalists are asked to mimic a real sprint, and then show you how to get hands-on with at least some parts of their proposed solution.

The key to a bake-off is customizing it to your requirements, with your ingredients (content and data), your bakers (participating employees), and your ovens (your real environments) — although typically you’ll employ the vendor’s kitchen (a.k.a., cloud environment).

Sometimes labeled a “sandboxing” or “prototyping” exercise, this approach is particularly well-suited to vetting marketing technology, since marketers should be familiar with both the empirical nature of the effort, and the general idea of A/B testing.

A bake-off story

Consider this experience I had at Real Story Group helping one of the largest hospitals in North America select a new digital asset management platform. After a productive vendor demo phase with five competitors, the selection team identified two finalists. However, “Vendor A” emerged the clear leader among the team.

It was tempting to just abandon the plan to conduct a bake-off and simply start the implementation with Vendor A. However, in the interest of full due diligence, the selection team went ahead with a bake-off where Vendor A and second-place “Vendor B” each had to implement three high-priority use case scenarios. During the bake-off weeks, the hospital’s marketing and IT team worked side-by-side with the vendor’s implementation team, learning how to use the platforms and execute some tasks themselves.

At the end of this phase, the team assessed their findings, and here’s what they learned:

• While Vendor A’s user interface had dazzled during the vendor demos, when it came to building out the hospital’s most common use case, it was Vendor B’s workflow and interface that resonated most with the hospital’s marketing team;
• When it came to using the hospital’s real content (high-res photos from numerous photo shoots), Vendor B was able to demonstrate much faster ingestion times;
• When it came to accessing each systems via mobile devices (a common request), certain key functionality was not available using Vendor A’s solution (this never came up in the vendor demos);
• When the hospital’s marketers reached out to each of the vendor’s help-desk, Vendor A’s help-desk never responded, but Vendor B’s help-desk addressed an issue immediately;
• And, something that should never be underestimated: the hospital’s team liked working with Vendor B’s team more than Vendor A’s team.

As you will often hear RSG analysts say, there is no perfect vendor or perfect product. And I don’t mean to cast Vendor B as a perfect fit in this case. But they were a really good fit for this client — something the enterprise would never have known without engaging in the bake-off. Vendor A was partially reimbursed for their time and Vendor B used the bake-off work as a head-start on the actual implementation project. The hospital has since implemented their new DAM and the project has gone well.

Addressing the nay-sayers

If you still get resistance to this approach, consider switching the analogy from food to cars. Let’s say you’re buying a new vehicle. Would you purchase it after watching the salesperson drive around the dealer’s lot? If you’re going to be using this car for the next five to ten years, you need to get behind the wheel yourself. The only question then is: how long a test drive?

In the case above, a one-week head-to-head bake-off proved sufficient time to get the information they needed to make a decision. In some cases, you’ll want a longer time and in others, a shorter time will suffice. The key determinant in terms of level of effort should be: how critical is this platform in your stack? Something that’s an “anchor tenant” in your martech mall will require at least a week of testing per bake-off finalist. More “boutique” solutions may only need a couple days of hands-on testing.

Business value

Like all good things, a useful bake-off takes time and attention, since the mechanics can get tricky. But the payoff is worth it:

• By engaging your end-user colleagues in a way that feels relevant and useful to them, via hands-on testing, it bodes well for their support during tough implementation times;
• Testing your own requirements against reality enables you to reprioritize your objectives midstream, before you’re locked into a particular supplier;
• This sort of prototyping allows you to jump-start your initial implementation and reduce the time from contract to value;
• By learning (most of) the shortcomings of the winning vendor, you can plan around them;
• You get a better sense for realistic implementation costs before you select a solution, and you also gain some valuable time and space to negotiate the best deal;
• You obtain a more accurate preview of likely operational, process, and staffing implications for any new platform — implications too often underestimated in the martech world.

So if you are in the market for new technology, don’t skip the phase where your people test the new system with real-life use cases. As we’ve seen with dozens of successful selections, devoting the proper resources to conducting a proper bake-off before you commit to a solution will ultimately leave a much better taste in your mouth.

Real Story on MarTech is presented through a partnership between MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps organizations make purchasing decisions on marketing technology applications and digital workplace tools.

The post The Real Story on MarTech: Never skip a bake-off when selecting a new platform appeared first on MarTech.

In the last fifteen years, my focus shifted from designing and building web experiences to helping enterprises select the right technology to support digital experiences in a multitude of channels.

However, the design-thinking that emerged in those early days — and has become the norm for modern UX — applies directly to how enterprises should evaluate possible technology solutions.

The right way: design thinking

Any discussion of buying marketing technology right has to start with the idea that you are not looking for the “best” solution, but the best-fitting solution for your particular circumstances: your requirements, capabilities, resources, risk tolerance, and specific business objectives. Notions of “fit” become liberating, since you dispense with the impossible job of finding some universally ideal solution. “Fit” is also empowering, since it gives you a natural approach to vetting solutions.

That approach is design thinking, a methodology grounded in empathy, ideation, and testing. There’s a lot to say about this concept, but for our purposes, let’s just summarize it as:

• Business-focused
• Human-centered
• Story-based
• Collaborative
• Hands-on and test-oriented
• Iterative and adaptive

At Real Story Group (RSG) we’ve found it the ideal methodology for selecting marketing technology, where real humans — your Martech/Ops/Marketing/Digital/Compliance/Systems/Dev teams — are trying to create better experiences for other humans: your customers and prospects.

How to begin

It starts, of course, with establishing the business case for new or replacement technology. Clearly document the top six-to-eight business objectives for the new technology to guide your selection and implementation teams going forward. When you reach decision points, this becomes your principal touchstone. And as a practical matter this list also serves as your prioritized vendor evaluation criteria.

Then build an interdisciplinary selection team, with ample IT participation — just make sure it’s headed by a marketer or other business leader.

From there, you can start the actual selection work. Sometimes people ask, “how much time and effort should we put into this?” The answer is, it depends. If the solution you’re looking to select will become an anchor tenant in your marketing stack, then you want to build a broad team and invest several months (or perhaps more) time into it. If it’s more of an experimental or “boutique” component in your stack, then you can invest less time and fewer resources.

Either way, you’ll want to follow some version of the steps in the chart below.

Filtering the solutions

Design thinking tells us to follow a five-step path of Empathize > Define > Ideate > Prototype > Test. It turns out this works very well for selecting marketing technology, with perhaps a greater emphasis on testing throughout.

Following an adaptive process, you filter through a range of solutions via testing to find the right fit for your marketing needs. But that begs the question: what exactly do you test?

Five stages of design thinking represented as steps for vetting a martech platform, with the number of prospective vendors in parentheses. Source: Real Story Group

Test via stories

Too often we see selection teams overly focused on features rather than use cases. Whatever you do, avoid “check box” requirement spreadsheets, where you ask the vendor: can you do this?…Can you do that? As a practical matter, vendors have seen all these questions and have figured out how to check all the boxes. A better approach focuses on

1. How the solution works
2. The impact on real humans (colleagues and customers)

Here, design thinking means centering your solicitation on user stories. These are real-life narratives that describe your information, your processes, your anticipated business results, and above all, the people — your prospects, customers, and employees interacting with the system. To the extent possible, narratives should reflect “to-be” journeys and as such become aspirational.

User stories become the backbone of a process centered in empathy, bounded by healthy skepticism, and open to ideation. As such, stories will:

• Reside at the center of your RFP/Tender;
• Provide relevant material for the demo phase; and
• Serve as test cases when you start vetting prospective vendors during a bake-off round and optional proof of concept (PoC) phase.

Recall that this is an adaptive process. Your stories don’t have to be perfect at first. You can improve them at each stage as you learn more.

Test early and often

The key to learning more is getting close to actual technology sooner rather than later, first by hosting demos of your stories, not generic vendor reference implementations.

How many vendors should you invite to demo? It depends. Initially, you’ll want to explore as wide a set of potential suppliers as possible, to give yourself the best odds of finding an optimal solution. This is a process of getting to a “long list” first, and but then you’ll want to filter to a “short list” (perhaps via proposals) to actually demo.

Then — for the love of god, people — always test any solution hands-on with real people, before inking any contract. Ideally you do this via a competitive bake-off. I’m dumbfounded to regularly see large enterprises license a solution without ever trying it themselves. That’s like watching a car salesperson drive a vehicle around the dealer’s lot and deciding you want to buy it!

Remember this is a test-based process, so you can always iterate. Still not convinced after a bake-off round? Listen to your instincts and continue with a more involved PoC if the stakes are high enough. Perform your diligence under your timeline, not the vendor’s.

Read more about design thinking.

More to Review

There’s a lot more to review here about trade-offs, decision styles, and vendor sleights of hand. For details and examples, check out my book, The Right Way to Select Technology (Rosenfeld Media). If you want the inside scoop on how marketing technology vendors really work, investigate RSG’s evaluation research.

Real Story on MarTech is presented through a partnership with MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps organizations make purchasing decisions on marketing technology applications and digital workplace tools.

The post The Real Story on MarTech: Apply design thinking to select the right vendor appeared first on MarTech.