"I get to review this before you publish it, right?" A media day botch job we all need to avoid

Profile picture for user jreed By Jon Reed May 28, 2018
Summary:
In our line of work, there's nothing more awkward than the phrase "Can I review this before publication?" We all need more customer use cases. Here's ten tips to avoid the gotchas - and ensure a great experience for the customer.

man-in-box-fail
After I wrote How to screw up a vendor analyst day, media relations folks felt left out. They wanted to know how to screw up their days also. Or, perhaps, how to avoid it.

Well, for its sheer awkwardness, nothing beats this trade show moment:

A terrific interview with the customer ends. Handshakes and smiles. We're now going to write up a use case readers will learn from - one that gets across the value of the vendor better than any AI demo or project pan flute they could play.

Then, as we're all leaving, the customer asks:

I'll get to review this before publication, right?

Everyone sits back down. By the time we walk away, the case study is tossed in the proverbial garbage bin in the sky. Everyone is asking themselves, "What just happened?"

Awkward - how did we get here?

No, I'm not going to call this a waste of time. Any chat with a customer is time well spent, whether an article comes out of it, or not. It is a screw up, however, because in that moment, that question should never come up.

It should have been put to bed long before any appointment was made. All parties bear some responsibility, but in this case, the vendor and/or PR rep gets the lion's share.

How did we get here? Customers are typically found for media interviews through some type of internal reference or advocacy program. They have probably already done a published, vendor-sponsored use case or video use case.

Done properly, these vendor-sponsored use cases are important, and are terrific sales tools. They are a great chance to validate proof points, such as money or time saved, revenues increased, or improvement of customer/employee experience.

But there's a problem. Vendor-sponsored use cases have a very different publication process. Most vendors allow their customers a chance to review and approve use case text and videos. Brand mentions are run by the customer's internal PR for naming compliance; their legal team reviews it.

Quantifiable numbers are validated by a project manager, or, perhaps, are removed at the customers request, causing the vendor to shed a marketing tear. A sizeable chunk of those use cases never see the light of day. For whatever reason, they don't make it out of the approvals process alive. The customer determines what vendor-related endorsement material goes public - as it should be.

But this type of approval process is not applicable to a media interview. And that's where we get into trouble.

At diginomica, use cases are at the heart of our editorial because that's how tech gets a gut check. Customers want to learn from each other. Yes, these journalistic use cases are powerful marketing tools, but that is not why they were written. They reach readers who aren't (yet) interested in watching slickly produced testimonials or packaged case study PDFs from that vendor.

They carry weight because the journalist had editorial control. Our diginomica use cases have a rough edge or two. An unexpected challenge, a partner that was given the boot, a project setback overcome. Results happen amidst problems. No surprise - those are the imperfect stories readers trust.

Obviously, those third party stories lose all credibility if they are subject to any kind of external approval from the vendor or the customer. Alas, a perception lingers in some quarters that brand message can be controlled to get across a scripted positioning message. That's not what we see, though. We see enterprise buyers who can sniff out those agendas.

Ten tips for better use case interviews - and no gotchas

So how do we get around these problems?

1. Customers must know ahead of time what type of interview they've agreed to have, what type of content will result, and what approvals they will get - or not.

2. Sometimes it still makes sense for customers to talk to analysts and media, even if the content they share isn't for publication. The blogger/analyst should receive advance notice of those terms and also agree, or not.

3. If customers are presenting at a conference session, be it a workshop or keynote, they should be notified, by default, that info is considered public. That means it might get tweeted, quoted, or featured in a piece, without any 1:1 interviews. If that's unacceptable, I'd advise not using that customer as a presenter. Marking the session as "closed" to media is a fall back option, but isn't full protection for the customer in today's everyone-can-tweet environment.

More questions from customers that media relations must anticipate:

4. Customers may have negative perceptions of media that need to be overcome. It's entirely fair for them to wonder, "If I don't control what's written, I could get exposed in some way." Media outlets must earn the trust that customer stories are not fodder for sensationalism. Savvy vendors send customers sample writeups and bios to help the customer assess the option.

5. "Can I see sample questions?" If a customer agrees to a media interview, but insists on a scripted list of questions, that's also a prep fail. That's not how a good article gets written. This is up to the individual writer, but I am happy to provide an informal topic flow for a customer to get them comfortable.

I warn the comms person that I can - and will - go off the reservation with follow ups, but it's a helpful framework to share. The most effective use cases have quantifiable benefits we can point to. That's one aspect customers should prepare for in advance. You can't share numbers off the cuff.

Otherwise no prep, no scripts - I just want customers to be comfortable. They'll talk about things they know well: the challenge, their role, what they did about it, what the implementation process was like, tangible outcomes, advice for their peers.

6. "What about factual inaccuracies?" Blogs have a wonderful immediacy. Unfortunately, they are also a breeding ground for the occasional typo or factual error. Customers are assured: any factual changes such as misspelling the name of a new product will be fixed immediately. But be forewarned: "factual" is more subjective than we tend to think.

The realm of what a publication like diginomica will fix after the fact is narrowly defined and limited to obvious inaccuracies. Requests for brand compliance, for example, are not necessarily factual. There may be reasons, such as readability, for not repeating an elaborate product name again and again, and shortening it instead.

The only area where I have ever negotiated a change beyond a strict definition of facts is when a customer said something that they later realized compromised their own livelihood. If someone's job is actually at risk due to something they inadvertently said, then I'll work hard to figure out a proper solution. That's happened maybe twice in the last five years. In the cases I recall, the quotes appeared harmless, but weren't harmless internally to the customer. The right thing can be worked out. Usually that replacement language needs to be negotiated back and forth until the right compromise is reached.

Caveat: an editorial interview is for on-the-record content, but we can still leave something off the record. Interviews do veer off the record from time to time. At the end of the interview, if there is any question on something that was shared, or how it was phrased, we come to an understanding right there. By the time we leave the room, everyone is comfortable with the discussion and what, if anything, will be left out.

Beyond the basics, a few more:

7. Vendors - consider not having a handler in the room. The best customer interviews I've ever done are just me and the customer. Having a PR handler in the room does change the dynamic and can result in a muted conversation. This isn't something for all situations, but when there is confidence in the customer and the writer, consider giving it a shot.

8. Media and analysts is a blurred line. Diginomica is right in the middle of that line, so we end up attending both media and analyst sessions. All should be exposed to customers, at least via a panel. Surprisingly, I've heard some analysts tell me they aren't interested in talking to customers. But the vast majority enjoy being able to query a customer, even if they don't publish use cases in the public domain.

9. A panel will not have the same impact as a personal interview. Most "customer panels" are overly-massaged PR festivals and don't result in good content. A good customer panel is unscripted and open - a topic for another time. If you want to ensure good stories, make the 1:1s happen as well.

10. A published vendor use case isn't required prior to a journalistic interview, but it can help. How? Because then you should have a set of validated numbers and quantifiable results that can be shared with the journalist. As long as the prep work for the journalistic session also includes the aforementioned no-approval/this-interview-is-different disclaimer.

If you prep it, you'll rock it

There's plenty of other ways to screw up a media day, such as: no customers at all, or, the wrong customers for where the vendor is headed. Or: no press conference. Or: a stilted press conference that spoonfeeds the keynote messages. But those are topics for another time.

Oh yeah - if you've got a great customer use case you want us to consider, do let us know. It's well worth the effort on all sides, and we're here to make it happen.

End note: for more on journalistic interviews, see my companion piece, Nailing the journalistic interview - dos and don'ts for your customer reference program. You may also want to check the snafus in Nine ways to botch a customer case study.