BAs learning from other companies: Google, part 2
This article was originally posted to BetterProjects.net on January 28, 2010.
Do a small  number of things very well
When we think of  Google, we think of them as a  search company. While that is what got  them their start, it really  isn’t the big part of their business today.  Now, they are an  advertising company, and a really good advertising  company at that.  Search and advertising are the two primary things, the  bread and butter  if you will, of Google’s business. They are the core to  the company.
To correctly target  advertising, you have to know who your  customer is and where you can  find them. This is where Google’s search  technology comes in to play as  customers give up a vast amount of  information on what is important to  them whenever they search. The more  Google knows about us as  individuals, the more targeted the advertising  they show us and the  more likely it is that the companies placing the  advertisements will  make a sale. Google leveraged their search  capabilities into making  money by selling advertising.
Similarly, its  good for BAs to have a couple  of things they do really well. For me, it  is my ability to communicate  detailed  and technical concepts into  language that makes sense to my customers.  My career started out in tech  support, helping non-technical users to  get their computers back in  working order. The skills I learned in that  role were a perfect fit into  my transition to a BA.
Buy v/s Build
Despite being innovators, Google realizes that  sometimes its  better to purchase a company who already does something  well than to  fight against the learning curve and flounder for a long  time trying to  learn how to do something well. It is hard to admit that  you’re not  going to be able to tackle every problem yourself or that  someone else  would do a better job at tackling a particular issue, but  Google has  done a great job of recognizing these situations and then  finding the  people who have the needed expertise.
As BAs, the same situation  applies. One of the BAs who works  for me understands our company’s data  on a level I can’t comprehend.  When people ask me a question about a  product setup, I often defer the  question to the expert, instead of  faking my way through an answer that  might or might not be correct. The last thing I want is to  ruin the  relationship with my customers by telling them the wrong  information  when I know that the right information is easily  accessible. It also  builds trust in my entire team by building up my  people as experts in  their respective areas.
Don’t be afraid to fail
Google is not perfect. Not even close. When they  first  launched their web-based productivity suite, it was resoundingly  panned  as a massive step backwards compared to desktop versions from  many  vendors. It had limited functionality and it had poor  compatibility with  desktop suites. Pundits claimed it would never be  used and Google was  tossing money away on a terrible product.
The suite  languished for a  long time, receiving only stability fixes and minor  functionality  additions, until the introduction of collaborative  document editing.  Once customers began to understand that many people  could edit the same  document at the same time, the usefulness of an  online productivity  suite was realized. This was the ‘killer app’ that  had been needed to  show that this Google product was not an eventual  failure.
Today, the applications still  lack in functionality when  compared with desktop versions, but the  functionality divide consists of  things that the majority of users never even knew  existed in  the desktop productivity suites. Google Docs has become a  success,  albeit a minor one, because of one feature that isn’t  available on the  desktop, even though in almost every other way it is  inferior to older  and more established products.
We BAs could learn a lot from  that kind of mentality about  failure. No requirements document will be  perfect on its first (or often  even fifth) version. No screen mockup  can encompass all the needed  functionality and interaction. No use case  can cover all possible  directions that a user may go. Yet despite  knowing the limitations, we  should not just toss up our hands when we  don’t get it right on the  first try. We learn what our customers really  need and next time, we get  it right. We look for that elusive ‘killer  app’ that will win approval  from our customers so we have it ready for  them, exactly when they need  it the most.
    
                    


