Editor&'s note: As the Web goes mobile, every Web company needs to build mobile products. Author Elad Gil, director of Geo at Twitter, has a lot of experience in that area. Way before selling his company Mixer Labs to Twitter last year, he kickstarted Google&'s mobile efforts back in 2004, when Google&'s mobile team &''consisted of 1/4 of an engineer dedicated to maintaining an old WAP search server on the brink of collapse.&'' Gil pulled Google&'s first mobile team together, recruited the first engineers, started discussions with carriers, and was involved in Google&'s early mobile acquisitions which set the stage for Google Mobile Maps and Android. In this guest post, he shares what he learned. Note that Elad works at Twitter but the following piece reflects his view only and does not represent Twitter&'s thoughts or strategy.

In the early days of Google&'s mobile team, we needed to navigate a series of misunderstandings most people have about consumer mobile app development, and how to build a great consumer mobile team and product. Given the ridiculous growth of mobile today, many companies I know are trying to start their mobile divisions and they are making the same mistakes over and over. Similarly, many mobile consumer startups are making a series of common mistakes. This post draws on my experience building Google&'s early mobile team to point out how to overcome the myths people still believe about making super successful mobile applications.

Myth 1: You need to hire mobile experts. Reality: Hire great athletes' mobile &''experts&'' will be useless in 6 months

The natural impulse of someone doing mobile development for the first time is to assume that mobile is somehow different from other software development. This leads to the hiring of mobile &''experts&'', many of whom lack solid consumer product experience. They may have worked on handset design, SMS based services, or for a large carrier. While mobile client development obviously differs from web development (since you can&'t just push a bug fix to all devices), it is very similar to any other form of consumer client development.

This means that while people with deep mobile experience may bring knowledge about a specific technology or the limitations of mobile clients, they often lack the deep consumer experience that is actually much more important for the success of your consumer app.

Additionally, any specialist knowledge the expert may have had will be learned organically by your team within 6 months. This means the value of a &''mobile&'' person will diminish dramatically over time. As with all roles, I would advocate hiring great consumer generalists to fill the spot, as they will have a much larger positive impact over time.

a. Don�a4���a4�t hire &''mobile engineers&''

The first thing people want to do is hire an &''iPhone engineer&'' or &''Android developer&''. The best mobile engineers I have ever worked with were great generalist engineers who picked up iPhone (variant of C) or Android (Java) development. By focusing on hiring great engineers and having them pick up the programming language and platform (including learning its limitations) you will:

For example, on the early Google mobile team we had a PhD student from Yale with no industry experience, an expert on enterprise Java from BEA, and a research scientist at Google. These people helped form a formidable core for mobile engineering at Google.

b. Don�a4���a4�t hire &''mobile&'' Product Managers (PMs)

Just as you should hire generalist engineers for your mobile team, you should similarly find a great consumer product manager to run it. The worst hiring mistakes I have seen people make is to hire PMs with telecom or handset backgrounds to run their consumer products. You need people who understand that the phone is primarily a social device�a4���a4�for example, people love to take photos and share them with their friends (see Instagr.am, PicPlz, and PicBounce)�a4���a4�and that the screens are still small, so focusing on a few key features or interactions is key.

Myth 2: Your mobile codebase is different from regular code. Reality: Its just code. You should treat it as such.

Obviously, developing for a client app that can&'t be fixed via a push to AWS has its own challenges. But the mobile codebase should be something any engineer can contribute to at any time�a4���a4�even if it is just to run internal test apps to try out new features.

Similarly, don&'t let your team use mobile as an excuse to avoid following good software engineering practice. A good release process can apply anywhere.

Myth 3: You need carrier or handset deals to distribute a mobile product. Reality: Focus on standard consumer distribution first, not carriers or handset manufacturers.

When launching a mobile consumer product, many companies make the mistake of focusing on carrier or handset partners for distribution rather then just putting it out there for users to try.

a. Focusing on carriers means you will build the wrong product.

When dealing with a new consumer app, carriers and handset manufacturers will have all sorts of ideas, some of which may be bad, about how you should change the product before they agree to distribute it. This will likely ruin the consumer experience. They may also ask you to support a wider variety of handsets than makes sense for you to build for. Further, all the time spent negotiating with carriers will also distract you from spending your time building things that will delight users.

b. People naturally spread great consumer products.

Think of all the consumer apps that have widespread use and adoption from scratch (Angry Birds, Foursquare, Gowalla, Bump). None of these launched with any traditional teleco deals.

c. If your app is a big success, carriers will come to you for deals.

If your mobile app is being used (or your desktop app has wide enough distribution), carriers will approach you to add your app to their phones. Think Facebook, Twitter, Google, etc&8230', as well as, back in the day, IM clients.

Don&'t get me wrong�a4���a4�carriers and handset pre-installs can widen your distribution dramatically. However, as a startup or new mobile effort, you should focus on direct-to-consumer distribution first. Only deal with these intensive partnerships once you have proven traction with your core app experience and want to reach out beyond the relatively large population that discovers apps via the app store and friend recommendations.

Myth 4. You must build for all platforms from Day One. Reality: Start with iPhone or Android only first.

One of the big fears when building a mobile property is that only a subset of the market can be addressed via each platform (iPhone, Android, Blackberry, Symbian, XHTML, SMS). These days, the best consumer apps are launching on iPhone or Android only first. This provides enough distribution/addressable devices to see if the app can gain traction. Once it gets traction, other platforms can be supported. A great example of this is Foursquare, which launched exclusively on iOS and grew from there.

In part you should choose your platform based on your market and distribution approach. iPhone or Android (as well as increasingly HTML5) are good bets for the US, and increasingly, the rest of the world. You should only build XHTML or SMS based apps if you are focused on the low- to mid-range of developing markets.

Myth 5. (Once the app launches) We are mobile geniuses! Reality: Stay hungry and keep questioning your mobile directions.

Congratulations! You got your mobile app out the door and it is growing 50% month over month. There is an old saying that a rising tide floats all boats. The rapid growth in the overall smartphone market may make your mobile efforts look brilliant due to this ongoing, massive market shift. Make sure to challenge your team&'s thinking on their mobile choices, and don&'t believe the mantra that &''mobile is just different&''. Focus on building an awesome consumer experience and you really will end up looking like a genius.

Mobile is a huge opportunity and will be the primary way many services are accessed in the future. Hopefully as you start a new mobile consumer startup, or build a mobile team for your existing web property, with the tips above you can avoid the mistakes people frequently make for mobile app development.

Photo credit: Flickr/JD Hancock