In part 1 I talked about how a conversation on my blog took a frustrated customer with problems to a situation where they got sales to quote them for another Oracle product. Part 2 is a more personal branding issue.Generating Consulting Opportunities
I contacted a reader of my blog who'd added some comments and I got the reply below:
<company X> is using Oracle as well, but they are not fully implemented across the globe. I'm noticing that we are having a hard time with intercompany transactions as they relate to foreign currencies.
I was researching the issue on google and I came across your blog. I think your blog is a great tool for questions, but I think I have too many question to ask on your blog. I was wondering if you did any consulting work?
Happy as I am in my job, especially now I'm working on GL too, it's always nice to have other options. Of course this might lead to Oracle Consulting getting some work from this person, which would be nice too.
What is also really important to note is the research started with Google; not the user documentation, not support, not metalink or OTN, straight to google. I had a similar experience yesterday, I needed to know the IP address of my netgear wireless router. I didn't go and dig out the instruction manual that came with it (not sure if I still have it), I didn't go to netgear.com and start to navigate through that, I just googled it and I had the answer in seconds (192.168.0.1 for the record) and I have no idea what the source of the information was, I just know it worked. So if you have information about how best to use your products, you better get those tips and tricks out there so google can find them. I call it Help 2.0, but it seems other people have thought of that term already.
UPDATE: I now have added part 3 in this series.
Posts
10 comments:
David, thanks for the link. You know, I'm actually creating a presentation righ tnow and the one slide that's still blank is one titled "Blogging and Technical Writing." Your post seems to give a good argument for having technical writers blog about the products they document. However, I have a couple of questions.
First, if you start getting a lot of questions from the field, how do you avoid falling into the time-consuming support role answering readers' questions and helping solve their problems?
Second, if there is relevant information for the products, shouldn't the info be included in the product's help files, which should also be posted online? That info should be indexed by google as well, right?
As for PR and creating a bridge with the field, I couldn't agree more. Also, I like the non-marketer speak of regular team members writing about the product.
Tom,
I am trying to write a presentation which I was going to call 'Why Product Development Should Blog' but after thinking about the Help for Oracle's upcoming Fusion Applications I decided to call it Help 2.0 - then I cam across your blog researching the term. To answer your points
First - This is a concern many people have. A blog is a very scalable way of interacting with the field, you answer a question just once and it is there for all to see. The spur for me to start blogging was spending so much time answering the same half a dozen questions at Oracle Open World - I wanted to get the information out there - now, I don't answer those questions anymore I point people at my blog.
Second - It could be included in help files, but blogs are more conversational and current and other people can add content apart from the doc writer. I see a place for both. I also see a case for making help files more interactive.
Thanks for your response. Keep up the good work.
We face an educational challenge with blogs because most people (at Oracle, at our customers, in the world) hear "blog" and think "mundane journal", not "information source".
This is changing quickly, but the perception remains. David's blog is a great case study for how to engage customers, but he blogs in his spare time. My goal is to get blogging into the DNA of our product teams, so it's a formal job function and not just something done by passionate types like David.
Ultimately, both standard documentation and informal conversations are needed.
Jake,
This perception starts to change as people start to hit blogs when they do a google search. If I search for 'R12 Intercompany' I don't care if the result is a blog, a user doc, a forum post, or something else.
People will come for the useful information and stay despite the occasional mundane journal' type posts interrupting the useful information :)
Agreed. Say "read my blog", and you're likely to hit that prejudice. However, as you point out, get a blog post from Google for your keyword search, and you're much more likely to click through.
Totally agree with you. Let me give you my perspective. I use Linux extensively and whenever I run into trouble I use google for help. More often than not the information I need is available on forums, blogs and group emails (in that order). Most of the time if not always, I end up finding solutions and solving the problem on my own without expert's help. Using this I have managed to perform complex tasks without actually talking anyone's help. I managed to fix a bug (on my own) in a C code without actually knowing the code thoroughly. This not only saves time and money, but also improves efficiency. So, what I call Google and this new style of support, is Self Support 2.0. Help 2.0 can be used, but the word Support is important. For Self Support 2.0 you don't pay any support charges. Your cost is zero.
Now the success of Self Support 2.0 depends on how much information is available on the internet and how well connected they are. Self Support quotient can be used to measure how well Self Support is for a particular product/search. Note, just putting documents/readmes/etc on the internet will not increase your Self Support quotient. That is where blogging comes into play. Blogging is one of the key factors of Self Support 2.0. I can explain why maybe in another post, later. Self Support 2.0 is critical for any product development organization. Say, an ERP company wants to sell their product. One of the key factors (often discussed widely) is how much cost goes into support and for hiring engineers to implement the product. Now here is where my theory comes into play, the cost of engineering or support is inversely proportional to the amount of Self Support 2.0 quotient the product has. So if a product has lot of information available widely on the internet and is accessible via Self Support 2.0, then the cost of engineering/support is low. Well, I can't prove this, but if you think about it, it happens to be true. Take for example, Java professional are cheaper than Oracle Applications professional. People might argue that this depends on demand supply. Yes, no doubt, but if there is something which is easy to learn then the learning curve is low. You can train your existing resources in no time to learn new products.
To summarize, blogging is very critical for the success of Self Support 2.0. The success of product depends on Self Support 2.0 and thus blogging is very crucial.
Venkat,
Great to hear your experiences - thanks for the detailed comment and introducing me to the the term "Self Support 2.0"
For enterprise software I don't think Self Support 2.0 will replace the need for Support, I hope it is a supplement to support which provide a more personalized 1-1 service that is hard to get from blogs and forums.
Yes, completely agree with you again. Self Support 2.0 will not replace the traditional Support, but will supplement it. 1 to 1 Support is definitely need for any enterprise class production environment. No doubt on that. But the value of Self Support 2.0 should not be underestimated. If I can get the information I need in 10 minutes by Google search, I won't spend 1 hour just to log a service request. Which means I can learn quicker, and when I can learn quicker it means lower training costs, and in long term a win win situation for everybody - product development company, clients, developers, etc. More often than not, developers don't have access to Support or cannot afford it (unless ofcourse the company they work for has access to support). What do they do then? They either ditch the product or use something that can is easy to learn. One of the reasons Eclipse is widely successfully is because Self Support 2.0 quotient for Eclipse is high. Try this exercise out - starting trying out JDeveloper and Eclipse. Both are more or less same in terms of basic features. You will soon decide to use Eclipse because you find information about it easily. One may argue that it Eclipse has plenty of plugins which makes tasks easy. True, but since people found Eclipse easy to use or information about it easily available, they build lot of plugins for it. Evangelism does come out of high Self Support 2.0 quotient. In the long term, Self Support 2.0 reduces engineering costs which is a key in the IT/ITeS industry as major costs are associated to engineering.
Many will disagree with me, but in the years to come, Self Support 2.0 will be more valuable than the traditional Support. Self Support 2.0 fosters Evangelism which is important for wide acceptance of a product. Again, I am not saying traditional support will be eliminated, but Self Support will be important for a product's overall success in the future. Let me know what you think about this.
Venkat - I agree with your comment. A quick google search is what I will try first and so my success with a product will be determined to an extent by how good support I get from the evangelists. Product development need to be out there evangelizing too, writing blogs providing helpful information and building the self support community, I agree with you that we should not underestimate the power of this support model.
Post a Comment