Search This Blog

Loading...

28 January 2010

BAs learning from other companies: Google, part 2


This is the second part in a two part post. Check out part 1 before reading this post.

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.