Developer Support Myth #1: PSS is Cheaper than Prod-Dev Time
On this edition of "Developer Support myth-busters" I’d like to tackle a popular belief held by several folks that work in product development groups. The belief is that PSS labor is cheaper than dev/test/pm labor. Cost is often used as an argument by product teams (I won’t name the guilty parties) who would like to hand off the job of replying to customer bugs or questions to product support folks.
The problem with this belief is that it makes a couple of assumptions that aren’t true in the case of developer support. I learned this as part of the research I did on my visit to our developer support center.
Assumption #1 Developer Support engineer time costs less than product developer time.
This is just not true in most cases. I met several folks in developer support that have been around a lot longer than lots of individual dev/test/pms that work on product teams. It’s not any cheaper to have them solving problems for customers per hour than it costs to have your developers spend the same time.
It is true that the folks in PSS that do the initial customer data collection and issue routing may be less expensive, but this layer is actually not very effective at solving most of the developer issues that come in. Lead leads me to…
Assumption #2 Customers ask lots of simple questions or file non-valid bugs that could be answered by non-developers
It may be true that you can hire cheaper labor to walk people through running virus scan on windows XP, but it often takes a developer to debug a developer problem or answer a developer question. The issues I listened in on were very difficult and most of the customers had already exhausted their known online search options before actually picking up the phone. The problem is worse than you might suspect. A significant chunk of issues that start with PSS end up getting assistance from product group members.
The same is also true for a lot of the questions that get asked in the forums or bugs that get reported to the feedback center. The bar may be lower than picking up the phone, but it’s just not true that developers don’t search before posting. In the case of the product feedback center we force users to search first and in the case of the forums we’ve made search very easy and actually perform searches on the posting UI.
I won’t say there are no duplicate or simple questions, but the "noise" is far lower than most people who complain claim. I’ve rarely ever seen a product group capable of proving their perception of noise in their assigned questions and bugs
It all boils down to my final point… applicable to any "Web 2.0" company as well as Microsoft. If your company wants developers to build on top of your platforms and possibly with your tools you are going to have to spend real developer time having consistent and constant conversations with your customers to keep them successful and happy.
Comments
- Anonymous
March 16, 2006
"It all boils down to my final point… applicable to any "Web 2.0" company as well as Microsoft."
I strongly disagree with this statement.
A web 2.0 company cannot afford support cost. This does not scale (just like of most of their backend, but I digress) . That's that simple.
As for dev support in PSS, may be a "searching MSDN with Google crash course" would cut costs by having customers not asking in the first place. Just look at dev forums like codeproject.com : it's unbelievable the questions that are getting asked all the time. read : most of the guys asking for an answer don't do their homework and can't find their answer with MSDN partly because MSDN is too hard when it comes to search and retrieval.
To triage 90% of those questions, I believe you don't need to be a developer, just explain how to search MSDN with google. - Anonymous
March 16, 2006
"That's that simple." - Then that would be short sighted for any web 2.0 company that wants to see long term adoption of thier exposed web services and success.
"searching MSDN with Google crash course" - Agreed. One step of reducing cost is to push more users through a good search for their solution. - Anonymous
March 16, 2006
"Then that would be short sighted for any web 2.0 company that wants to see long term adoption of thier exposed web services and success."
Don't forget the ratio of 1-guy companies out there. Support cost just does not scale. Things get better when they finally get funding, etc. but for the most part the comparison with web 2.0 just does not stick.
"One step of reducing cost is to push more users through a good search for their solution."
Powertoys anyone? I'd see this "MSDN with Google" as a nice addition to the VS tool set. Don't let the "let's throw chairs at Google" mantra eat you. ;-)
In fact anything that makes one avoid the MSDN library UI and actual search is a benefit (both the one from the web, and the offline one). - Anonymous
March 16, 2006
Google isn't our friend any more.
An MSDN search for SVSCookie found two matches, neither of which said what include file we had to include ahead of an include file that I included.
A Google search for SVSCookie found no matches.
Google used to have a feedback page where we could report failures. They don't any more. One page still has one phrase saying they do, with a link to a page which doesn't provide that.
Meanwhile, PSS time is cheaper than dev time because PSS can choose between (1) refusing to take a bug report until the victim pays a fee or (2) blowing off the bug report with garbage responses. MSDN managed newsgroups tend to get better service, on average. Today even one question in a MSDN non-managed newsgroup received a rare good response, which even named the include file that I needed.