Time to stop promulgating the "Contact sales for a fix" myth
Prelude
Initially, I wrote this about Backup Exec, because that's where I ran into this problem. I'm also a SAV & SEP veteran but don't recall seeing this heinous language in their KB articles. So maybe it's a Veritas thing. But, whatever...
...then it occurred to me that while BE may (or may not) be the only Symantec enterprise product to which the symptom applies, the cure is universal. Because it bridges a huge gap between the goals of Symantec Sales, Support, Connect, Knowledge Base, and Product Managers. So I've taken the unusual-and-hopefully-not-presumptuous step of tagging it to all available products. It is global.
That kinda makes it Ideas spam, I know. Never done it before; probably never will again. Hope you can forgive me!
Don Quixote Battles Symantec
Two KB articles I've browsed recently contain variations on this boilerplate (emphasis mine):
"There are currently no plans to address this issue by way of a patch or hotfix in the current or previous versions of the software at the present time. This issue may be resolved in a future major revision of the software at a later time. However, this particular issue is not currently scheduled for any release. If you feel this issue has a direct business impact for you and your continued use of the product, please contact your Symantec Sales representative or the Symantec Sales group to discuss these concerns."
We'll ignore amusing marketing-speak redundancies like "currently...at the present time" and "a future major revision...at a later time", because they brighten our days of dealing with Symantec software bugs. The specific articles that prompted my diatribe are:
http://seer.entsupport.symantec.com/docs/329110.htm
http://seer.entsupport.symantec.com/docs/328487.htm
But a quick Google search shows me there are many, many more.
OK, call me Don Quixote: Just because no-win battles are so much fun, I recently pursued the Sales appeal in the second article, which, as it happens, "impacts [me] and [my] continued use of the product". Even posted an Idea about it a while ago, which, for your voting pleasure, is:
https://www-secure.symantec.com/connect/idea/fix-bews-125-update-324011-now
And my experience with Sales was EXACTLY what I expected (paraphrased, here):
Initial response: "Hunh? What are you talking about?"
Subsequent response, after long explanation, including all those geeky TLAs non-nerds like salespeople people hate: "You're kidding! They said to contact Symantec Sales??? No, you really need to contact Symantec Technical Support."
Classic Catch-22: Support (via KB) refers me to Sales. Sales does not understand the problem, much less the KB article, and refers me to Support. No one does anything, so backups keep failing.
I have been in IT for over 20 years, and know good and well that Sales (Symantec or otherwise) has NO technical competence, and NEVER cares or listens to what the customer needs. It's not their job. They're hired to push product, and that's all they do. Once you've fallen for the sales pitch and have a license, you're Support's problem. Just give us a call at renewal time.
Sales is a COMPLETE AND TOTAL waste of time for technical people.
And (at last!) my Idea
The "Contact Symantec Sales" boilerplate must be ruthlessly exorcised from every single KB article that contains it. That's an obsolete, failed policy from the bad old days that sounds, in theory, like it should work. Because who is more tuned in to customer needs than sales...right? Well, if sales really had any technical savvy and valued customers' need for bugfixes instead of new and improved icons, maybe. But they don't.
It needs to go away. And in its place:
- Agree/Disagree buttons, just like Ideas threads here on Connect, and with equal impact on product development.
- A button that automatically creates an Idea thread, or opens an existing Idea thread, linked to the KB article, for those who want to expand on the issue, including making a business case.
- Policy that Symantec product managers are required to heed data thus generated--and are provided the dev budget to implement them.
One could suggest that perhaps all that's needed is for it to be sales' responsibility to listen to the customer. And perhaps it should. (Sales listening to the customer: What a concept!) But we all know that has never worked in the history of computers. And maybe in the history of the analog world, too.
Passing our real-world input through the filter of Symantec Sales is lip service. If, instead, Symantec really intends to do what's important to us, then making communication between enterprise customer and product manager as short and direct as possible will be essential. The detour through sales must be removed.
Some thoughts from the front line
Hi Jeff
Thanks for taking the time to put your thoughts down, it's interesting to get feedback on how these things are perceived.
I work alongside many of our sales account managers as part of our technical pre-sales team and the way I have always looked at the organisation is as a line of overlapping circles with sales at one end and support at the other. The idea is that each has their own areas of responsibility, but overlaps with one or more other areas via a number of official or unofficial interfaces. As the pre-sales team, we try to bridge the gap between the account manager and the product management team by focusing customer feedback and enhancement requests through what we call (in EMEA at least) our Technical Champions programme.
Each product has a local technical pre-sales person (usually at least one per country/region)responsible for liasing with their technical product management counterpart and collating all requests for enhancements. We have regular meetings between these champions, produt amnagement and engineers and the one thing they are always looking for is feedback from end-users who have to use products in the real world. This wish-list is always longer than our development budget and lifecycle allows - if we covered every single platform combination and feature addition, we would spend far more than we actually receive in revenue.
I'm sure the product management folks have tried various ways to prioritise this in the past, but sometimes the economic reality kicks in and if a big customer says ' if you support xyz, then I'll buy so many licences' , then we are more likely to develop it. When we ask you to talk to your sales team, it's so they can work with you locally to understand why the feature is so important to you and quantify the difference it would make. It's as much to help you build the business case for using it as it is for us to develop it. We're not claiming it's a perfect system, but I would recommend that you ask to have a discussion with the relevant pre-sales engineer that works with your account manager and ask about this enhancement escalation process. I'd be interested in any furhter feedback.
Comment
And my experience is being told to use the Product Enhancment form.
Not sure, but I think Connect
Not sure, but I think Connect "Ideas" are the new Product Enhancement form...
Thanks,
Kyle
Symantec Trusted Advisor
If your question has been resolved, please be sure to click "Mark as Solution"! Thank you.
I'm told the Product
I'm told the Product Enhancement Form goes to Marketing NOT Product Management and that Marketing decides what new features or fixes are included in new releases. Marketing should have NOTHING to do with development unless they acutally use the product and can program the changes.
Untrue
Hi,
This is untrue.
Please let me know who "told" you this so I can ensure they understand the process for future reference.
Thanks,
//ian
Can you say this for ALL of Symantec?
What makes you think this is untrue? It might be the general rule but my own experience is that at least one Product Manager has been heavily involved in setting development priorities for future updates. Symantec is comprised of many companies with different cultures that have been acquired over the years and I would very much doubt that every PM has been made to toe the party line - it's just contrary to human nature.
Why not publish the "process" here for our future reference, so that we can understand what the party line actually is ?
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Scroll Down....
Hi,
I posted below last week which went some way to outline the process, scroll down some and you should see it at the bottom.
To your point, I'm not sure I understand your post:
You said: >>It might be the general rule but my own experience is that at least one Product Manager has been heavily involved in setting development priorities for future updates
Yes, that's typically how it works. Product Managers (indeed, teams of product managers) research and provide the data to engineering that prioritises the feature schedules of future updates.
I was responding to a comment that said that submissions to the enhancement sites go to Product Marketing, which isn't true.
If you read my post below, you'll see that these forms are being phased out and redirected to Ideas - which Product Management (for the majority of symantec products) are tasked with managing/moderating.
Hope that clarifies it, please let me know if not.
//ian
Black Hole
Yes, the venerable Product Enhancement Form - when submitted, travels via the 11th dimension straight into the black hole at the centre of our galaxy, never to be seen or heard from again.
Until such a time as Product Enhancement Forms are logged and feedback provided so that suggestions can be tracked from suggestion to implementation (or to rejection) then I will remain totally sceptical about their merit.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
I agree
The whole process should be made more transparent (visible to both the customers and the tech support engineers that support those customers).
Symantec Connect is the best
Symantec Connect is the best tech support board I've ever seen, and the Ideas section may be its best feature. Leveraging the Ideas feature for this process, as I suggested, will go a long way to achieving that transparency.
Sales is welcome to add their angle, as well. Didn't mean to imply that they shouldn't. I just don't want to be forced to go through sales to cast my vote, because my experience is that my vote will never be counted.
Finally, many who use the KB and read those "We're not gonna fix it unless Sales tells us we have to" paragraphs don't have Sales contacts. Someone else does purchasing.
I'm a computer consultant. My clients do their own purchasing with rare exceptions. I help select the product, set it up, maintain it, and am the one who researches problems on the KB, and read the paragraph in question. The clients are generally as clueless as the sales people when it comes to tech issues. I report back to them on things they need to be aware of, including the issue I cited, but I can't count on the client to take action or to even understand why it's important. By and large, I can pretty much count on them to ignore my advice because they have their own jobs to do, and many have NO IT background.
So there's a BIG disconnect involved in reliance on Sales to drive bugfixes. The net result is a compromised product. And when a backup product fails to back up Active Directory, as in the case I cited, that's a pretty big failure. One that anyone responsible for a system knows shouldn't need Sales' blessing to get fixed--and which blessing it probably will not receive. Because with or without a fix, they'll still be able to sell as many buggy BEWS AD Option licenses as they want.
Involve the developers
It is my observation that the guys (and gals) that actually code the new releases frequently have no contact with the *real* world and with user issues.
Thus product suggestions from users, who normally have a substantial understanding of IT and the product in question, are filtered through sales and product marketing personnel, who frequently have limited or zero applicable technical experience, into a to-do list of enhancements and fixes which are eventually passed to developers. Consequently, there is a lack of technical continuity from bug reporting to the bug fixers and as a result, the next release often fails to solve many of the issues which "bug" users.
I would like to see developers manning the support lines for at least one day per month so that they can see first hand what the issues are, out in the real world. Bug reports should also go first to the devs, so that they can apply some criteria to the report - a simple scoring system on how significant the bug is, and how difficult to fix. This scoring system would then enable the non-IT literati in sales and marketing to make informed decisions on what to implement in the next release.
Connect is a good board, but could learn a lot from the guys who sell and support Winbatch - a product I've been using for over a dozen years. The developers are totally involved in the product and its uses, and updates are regular and comprehensively documented. It's interesting how they can continue to make money while offering outstanding service and support.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
I agree
I agree with you
.
Firstly, great post Jeff and thanks for the feedback.
I'll give a bit of background which should cover some of the comments in this thread.
Given the number of mature/semi-mature product acquisitions Symantec has made, you can probably guess that there are usually processes already embedded for the pre-acq customers to make enhancement requests and/or field their feedback about defects.
With the particularly larger acquisitions (Symantec/Veritas, probably Messagelabs too), the processes are likely set in stone and documented all over the place - much like in the Support KBs that Jeff mentions.
Side Note: I actually came from the Veritas side and spent a couple of years in Support. That boilerplate was one of many sanctioned by our legal team for use when a defect was in a shipping product and wasn't being addressed immediately because of a valid & sustainable workaround (or because it's not a defect per se and is classed as an enhancement).
These KBs should get updated as and when the issue is set to be addressed in a release (usually a service pack or roll up or next major release).
IMO, the main reasons the 'contact your sales guy' is in there is because they should know how much $$ value is associated with that problem.
For example, let's say it is stopping Customer A rolling a product out because of a niche problem with some form of homegrown application they have.
If this customer is worth a few million $$ to us, it's going to be more likely to get fixed quickly as opposed to a smaller customer worth a few grand.
Of course, this is a very simplistic outline and there are many other important factors that go into defect triage.
The reason it doesn't say "Call support" is because they can't really do anything for you at this point. The defect has been escalated and engineering should be aware of it now. All Support can tell you is to subscribe to the document so that you get a notification when it is targeted to a release.
The other option is to send the customer to a enhancement submission form, as some posts above have alluded too.
As I said at the start of this post, you can imagine there would be quite a few different feedback mechanisms.
In early 2008, when I moved over to the Product Management team on the security side, I noticed that there was a massive disconnect between customers feedback. Depending on how long you'd been a Symantec (or Veritas) customer, you could have 3 or 4 URLs to submit feedback. Indeed a few customers were submitting it to all of them to cover their bases.
Getting access to the feedback was a pain and support engineers were getting some pretty bad feedback in the Customer Sat surveys because their customers didn't get any feedback at all.
A few teams here have spent a bunch of time working on making it easier and more transparent to get feedback to us and from you, the customers.
One of these initiatives is to 'fix' the enhancement request.
So, if you go to http://enhancement.veritas.com or http://enhancement.symantec.com where does it take you?
That's right, straight back here to the Ideas portal.
Got an enhancement request? Create an "idea" here.
Found a KB that really should be fixed in a next release? I'd create an "idea" here.
Read other peoples ideas.
Join in the discussions.
Our main strategy moving forward is to keep the enhancement process as transparent as possible.
You'll see Product Managers, support engineers and developers commenting, refining suggestions and updating the status of your "Ideas" (i.e already available, next release etc).
Now, we've really only started to push this out over the last couple of months, since May, and i'm sure you can imagine it'll take AGES to update everything and make sure that everyone knows this is here.
I hope this is useful information. If you have further comments feel free to post them below or contact me off list at ian_mcshane@symantec.com.
Cheers!
//ian
I think Ian summed it up quite well!
A variety of audiences see these ideas - I literally send them to the internal folks to ensure they are aware of 1 thing or another. Considering the amount of ideas (over 1000 since inception a few months back) it will obviously take time for the product teams to review the ideas and potentially set the status.
.
Add to that, we are "closing the door" on the other "enhancement request" URLs which are found on google and through our properties, and you have a single-point-source for providing your input.
If there's an idea that has +++++ votes, and no status is set, let me know. I'm human, and do miss a few now and again - but with your help I'll ensure the ideas are getting reviewed by the correct internal teams and management, which include Senior Directors of Product Management.
Best,
Eric
Oh, that a man's reach should exceed his grasp
"If there's an idea that has +++++ votes, and no status is set,
let me know."
How many is +++++ votes? ;)
Regards Andy
"It's not too late to panic ..."
Would you like to reply?
Login or Register to post your comment.