You’re a spokesperson, why do you talk about things breaking?
Every once in a while you will find someone saying something “bad” about a product of the company they work for. This could be employees or — god forbid — even official spokespeople.
It happens to me, too, for example when my browser crashes on me. The inevitable direct response to this is most of the time some tweet in the style of:
Should a spokesperson of $company talk badly about it? Think about the followers you have and what that means for the people who worked on the product!
It is a knee-jerk reaction making a lot of assumptions:
- that the person is not rooting for the team,
- that the person is abusing his or her reach,
- that the intentions are to harm with this
- that criticising a product means criticising the company and
- that the person has no respect for his or her colleagues.
Or, that they are bad at their job and cause a lot of damage without meaning to and should be chastised by some other person on Twitter.
All these could be valid points, had the person mentioneded something in a terrible way or without context. It is — of course — bad style and not professional for any employee to speak ill of their employer or its products publicly.
However, things go wrong and things break, and no matter if you are a professional spokesperson or not, it is simply honest to mention that. It also begs the question what is better: help the team that build a product to fix an obvious issue by owning the fixing process or to wait till someone else finds it? The latter means you’ll have a much shorter time to fix it.
It is ironic that an audience who hates sales pitches and advertisement is complaining when an official advocate of something points out a flaw.
It all comes down to how you mention an issue. You can cause a lot of good by mentioning an issue. Or you could cause a lot of problems.
How to report a failure and make it useful
Things you do by mentioning a fault:
- You admit that things go wrong for you, too. That makes you a user of your products, not a salesperson (or shill, really)
- You mention the fault before somebody else does. This puts you in the driver’s seat. Instead of reacting to criticism, you advertise that you are aware of the issue and that you are looking into it. It is better when you find a flaw than when the competition does.
- You show that you are a user of the product. There is nothing worse than a spokesperson who only listens to what the marketing team talks about or who starts believing exclusively in their own “feel good” messages about a product. You need to use the product to be able to talk about it. And this means that you inevitably will find problems.
- You stay approachable and honest. Things go wrong for all of us — you are no exception.
Of course, simply complaining is bad form. To make your criticism something useful, you should do more:
- Be detailed about your environment. Did you use a developer edition of your product? What’s your setup? When did the thing go wrong?
- Stick to one thing that goes wrong. “Browser $x is unstable” is a bad message, “$x just crashed on me when trying to play this video/game” is an OK one.
- Report the problem internally. In the best case, this should happen before you mention it. You can then follow up your public criticism with a report how the issue is being dealt with. This step is crucial and in many cases you already find a reason why something is broken. You can then mention the issue and the solution at the same time. This is powerful — people like solutions.
- Investigate what happened. Other people might run into the same issue and there is nothing more powerful than a post somewhere on how to fix an issue. Don’t let the thing just lie and be broken. And don’t let people come up with quick fixes or workarounds that might prove to be harmful in the long run.
- Deal with the feedback. People fixing the issue shouldn’t have this as an extra burden. This is where your job as a spokesperson comes in: deal with feedback in a grown-up fashion and keep people updated when things get fixed or more information is unearthed why something happens.
It is very tempting to just vent when something goes wrong. This is not good. Count to ten and consider the steps above first. I am not saying that you shouldn’t report things that annoy you. On the contrary, it is part of your job to do that as it shows that you care about the product. It makes a lot of sense though to turn your gripes into actions.
When not to mention an issue
There are times though when you should not mention an issue. Not many, but there are. It mostly boils down to who will suffer by you mentioning the problem.
- Don’t punish your users. It is a bad idea to publicly talk about a security flaw that would endanger your users. That needs immediate fixing and any public disclosure just makes it harder to fix the problem. It also is a feast for the tech press. People love a security drama and you and your press people will have to deal with a lot of half-truths and hyperbole by the press. You don’t want a bug tarnish the trust in your company as a whole, and this is what happens with premature security issue reports and the inevitable spin the press is wont to give it.
- Don’t report without knowing who can fix the issue. Investigate who is responsible and give them a heads up. Failing this will cause massive bad blood in the company and you don’t want to have to deal with public feedback and internal grumblings and mistrust at the same time. A scorned developer is not one that will do things for you or help fixing the issue. They are much more likely to join the public conversation and strongly disagree with you and other critics. Be the person who helps fixing an issue by showing your colleagues in a light that they deal with problems swiftly and professionally. Don’t throw blame into the unknown.
- Don’t report your own faults as problems. You might have a setup that is very unique and causes issues. Make sure you can reproduce the issue in several environments and not just one setting in a certain environment. Make sure you used the product correctly. If you didn’t, write about how you used it wrongly to avoid other false reports of bugs.
Be aware about the effects you have
Reporting bad things happening without causing internal and external issues requires good communication skills. The most important part is keeping everyone involved in the loop and be very open about the fixing process. If you can’t be sure that things will get fixed, it might not be worth your while to report them publicly. It would be a kind of blackmail or blame game you can not turn into something useful. Instead, be prepared to respond when others find the problem — as inevitably they will.
Stay honest and open and there is no problem with reporting flaws.