The odds were stacked against a successful launch for Google Wallet. While Google had a long history of successful web application development, in-store retail consumer payments was a completely new area. Google’s online payments solution – Checkout – never caught on, and was viewed as a qualified failure. The vision for Wallet included collaboration with financial services companies who, for various reasons, are slow to move and highly guarded about sharing their data with technology companies. The vision also required cross-team (Wallet with Google Shopper and Offers teams) collaboration, something that, for cultural reasons, had rarely resulted in a successful product launch in any organization at Google.

And then there’s the overarching context that this was an engineering-driven company. To successfully launch a product in a market that generates more anxiety for consumers than any other – consumer payments – would require a check on our hacky, get-it-out-the-door-warts-and-all, half-baked launch culture. It would require a focus on user experience. We would need to get good design work done.

Against the odds, I would say that Wallet had a brilliant launch. Given some of its platform constraints, it is yet to achieve wide adoption, but the product experience is excellent and breaks new ground for Google. To be sure, there’s more work for the Wallet team to do, but they’re off to an excellent start.

This article reflects on how we were able to get this good design work done in that engineering-driven culture. It doesn’t talk about design process. It isn’t a step by step guide. No tips on using Photoshop. But it’s my own record of the higher level strategies I used in my role as UX manager to enable this good work to happen. I’m sure that the UXers involved – Alex Cook, Jonathan Yu, Sian Townsend, Chris Nesladek, among others – would have great insight into what it took to get Wallet to market. Hopefully they’ll publish their thoughts. These are some of mine.

What made Wallet UX successful?

1. We fished for champions

To get good design work done in a non-design-driven company, you simply must have a champion with decision-making power. If you’re a design leader and you don’t have a champion, you have to get one. Make this your single most important goal. It’s a rare design leader who can charm a hostile audience and bend them to their view of the world. Jeff Veen is one of the few I’ve seen do this. But Jeff is a freak (in the Tim Lincecum sense). You’re probably not Jeff. Get a champion. In fishing for a champion, try to focus your efforts on people who are likely to be supportive of UX. There’s no point in focusing on an anti-UX zealot. Focus on people who have characteristics that lend themselves to being influenced by the contributions that UXers can make.

On Wallet, there were a number of candidate champions that I purposefully attempted to connect with. Google Commerce VP Stephanie Tilenius was an obvious person to focus on from a pure power perspective, but she also had other characteristics that made her a logical focal point for relationship development:

• She had a passionate desire to force Google to break out of the pattern of mediocre product launches.
• She had the intelligence to understand the value of good design in creating high quality customer experiences.
• She was new to Google… the engineers weren’t completely comfortable with her non-engineering-y leadership style. She didn’t appear to have many allies in the organization. She needed UX as much as we needed her IMO.

How you actually build a relationship with an organizational leader is the subject of another post, or book, but the short version in this case is that, in any communication with Stephanie, I emphasized messages that touched on the characteristics above. “Here’s how we’re going to avoid a Buzz-style launch”, “as you can see, this design makes anything else Google has produced appear average”, “here’s how we can use design review to improve product quality”, “you really need your first product launch at Google to make a big splash, and this design can do that”, etc. This was not about deception. It’s a repositioning of design work and design process to connect with the needs of an individual who is empowered to help you and your team get good work done. I genuinely wanted Stephanie to succeed and in turn for us all to succeed. Cultivating a tight relationship with her was absolutely central to our success.

2. We stopped talking like designers and started talking like locals

To get good design work done in a non-design-driven organization, you have to use the language of the organization. Using the language of design may be useful if you’re talking with fellow designers, or if you’re an agency pitching services to execs. But when you’re in-house, you need to talk in the language of the house. At Google, the house prizes the launch above all else. I used to say to some of my teams at Google “we need to be the team that everyone wants to work with”. This was code for “we need to do all that we can to appear to be driving our projects toward a kickass launch”. Don’t get me wrong – good design process, interim design deliverables and research have their value. They are very useful tools for designers in helping move our process forward. We need them. But when communicating with engineers and PMs, I tend to avoid discussing anything that isn’t clearly connected to the launch.

On Wallet, I rarely talked to an engineering manager without expressing my anxiety/excitement/desire to get the product shipped. “Look, I don’t care about blablabla, I just want to get the best product shipped as soon as possible.” And this was true. It’s what I genuinely wanted. But I needed to make sure that my engineering counterparts knew that that’s what I wanted. Because we had this common goal, I had great partnerships with eng leaders Wall, Rob, and AZ.

3. We generated both excitement and anxiety about the vision

To get good design work done in a non-design-driven company, you have to exploit your story-telling skills to paint the picture of what is and what could be. Designers often forget that we have the power and skills to craft a product vision in a form more tangible to humans than a PRD. By prototyping and presenting the user experience vision, and getting engineers excited about the prospect of building such a vision, we create the conditions for our vision to become reality. On the flip side, if a user experience is less than adequate, we can use our story-telling powers to raise anxiety about – and action on – the inadequacies.

In the case of Wallet (and Shopper/Offers), we created – as most project teams do – a presentation of user interfaces outlining the core use cases. We mocked onboarding flows, transaction flows, and movements between applications. We highlighted the clunkiness of app transitions. We highlighted the unnecessary inconsistencies resulting from lack of coordination across disparate project teams. We also highlighted how frighteningly simple and straightforward the Wallet experience was. The presentation told the complete story – warts and gems – of the mobile commerce experience. I delivered it weekly to Commerce leadership. Critically, we printed the presentation and pinned it on the wall in Stephanie’s office, updating it as new designs came to hand. She was able to see the good, bad, ugly of what we were building along with our post-it notes and commentary. We got her and the rest of the team simultaneously excited and upset about our direction. This was a huge help in getting the team focused on solving the most problematic wrinkles in the experience while protecting the good stuff.

4. We didn’t short change visual design

To get good design work done in a non-design-driven company, you have to acknowledge that many Silicon Valley people think that design is only about how products look, not how they work. “You guys make our stuff look pretty”. Yes it’s bloody infuriating but it’s reality. But you can use this to your advantage. To entice executives and engineers/PMs to view your team as a credible design group, present visual design work that blows them away. Wireframes are nice, but high fidelity mock ups are much better. BJ Fogg has published studies on how consumers perceive web sites with high quality visual design to be more credible than less visually appealing sites. The same is true for your colleagues in the workplace (re: their perceptions).

On Wallet, we were short on visual design talent. Jonathan Yu had his hands full with interaction design work. The mega-talented visual designer Sunkwan Kim was spending more time on Emerald Sea and less with us. We had zero visual design support. I had some contacts at a New York-based design agency. I called them to see if they were available. Coincidentally, the same agency was supporting our marketing team. I put the enthusiastic Chris Nesladek on point for directing their work. As you should expect with an agency, the quality of their work was variable, but the good stuff was excellent. They were able to work with Chris’s direction to develop a tight visual design system across all of our mobile applications. The visuals got our stakeholders excited. More importantly – right or wrong – their visual design work helped raise the perceived quality and importance of our collective design work.

5. We aired bad blood, fast

To get good design work done in a non-design-driven company, you have to resolve conflicts fast. Conflicts between eng, PM, design will arise. They always do. In an engineering-driven company, UXers should prepare themselves to lose most of the battles. It’s a numbers game for the most part. Certainly, in a rational company like Google, decisions are made based on merit. But decision makers – unconsciously or not – tend to agree with like-minded people. And that’s more likely to be an engineer or PM. Sorry.

The best you can do is to get all of the affected parties together to air their complaints when conflicts occur. In many cases, when you do so, everyone will realize how stupid the arguments were and will all go back to work. But there will be legitimate gripes. Have everyone air their thoughts. Go around the table. Write down the grievances and start to whiteboard ideas on how to reach a compromise. Show that you want to make allowances. People will reciprocate.

Wallet had some detailed arguments about the fundamental direction of the product. Was it going to be a consumer product or was it a system utility? These decisions would fundamentally influence how the product would be positioned from both marketing and design standpoints. The consumer angle eventually won out, but not without some disappointed people. The good news was that those people got the opportunity to voice their disagreement, were able to make their arguments, and did so to the group leadership.

6. We got the right people on the right tasks

It goes without saying that to get good design work done, you need to have solid talent. But talent isn’t enough. You also need to manage and allocate that talent effectively. Huge projects like the Wallet/Shopper/Offers combo cannot be done by one designer. It takes a team. For that team to be successful, you should have some knowledge of each team member’s strengths, and you need to be opportunistic in assigning those strengths appropriately to get the work done well. This is where the role of a design manager becomes more like a baseball manager. You need to know when to sit your starter, when to bring in your pinch hitter, when to warm up the bullpen, and when to ask the GM to recruit a slugger … if you have a GM. Wallet was fortunate in that we had the right set of personalities at the right time IMO:

• When I started in Commerce, Jonathan Yu and Sian Townsend were the UX team members on Wallet. Jonathan was a very solid, mature, all-round designer. Strong in interaction design, he produced many iterations of the core workflows while the Wallet team was determining the product positioning. Importantly, he had an optimistic attitude and was able to collaborate well with engineers to establish the core interaction and conceptual model for the product. Jonathan was the perfect person to establish a “beachhead” for UX with the Wallet team. Sian Townsend was a technically brilliant researcher who was able to boil her findings down to useful chunks for her audience. She had a keen sensitivity to people’s willingness to accept research, rolled with the punches and got work done in an agile spirit. Yet she was never afraid to raise usability or fundamental product issues that were overlooked. She was a voice of reason.

• Chris Nesladek had been coordinating with Frank Harris on Google Offers but as I spent more time with him, it became clear that he had the most expertise in mobile (coming from Android) and, more importantly, he was the only team member who pushed the broader organization to think about the cross-product implications of their work. Chris was a prolific, detail-oriented designer and had a passionate approach to asserting his vision. He was the ideal person to coordinate a unified design system across Wallet/Shopper/Offers. I recruited him to take on this role, and while it took some time for engineers to warm up to him, he was very effective in forcing discussion and resolution on the most critical user experience issues. He was the change agent that every challenging, multi-team project needs.

• I recruited Alex Cook to the Wallet team knowing that he would be the closer: the designer who could build a team to get the project over the finish line. Alex tends to take big hairy design problems, somehow comes up with rational solutions, then works closely with engineers or directly with code to close out all of the details to get it launched. Perhaps his greatest strength though is in building teams. And that’s what he did. As jyu and I transitioned out, Alex came in, recruited and oversaw the team of designers that got Wallet to launch.

So these were a few of my take-aways from the Wallet experience. Not necessarily revolutionary information here – this stuff isn’t rocket science – but interesting to see it applied in a real world context. I didn’t stick around to see Wallet through to launch. That is perhaps one of my biggest regrets re: leaving Google. Still, it’s fantastic to see such a relatively well polished consumer product delivered by a team at Google. It’s a rare thing. Against the odds, we got good design work done. All of us.

Graham Jenkin was an inaugural Google “Great Manager Award” winner and currently works on product and design at AngelList. You can follow his tweets @GrahamJenkin.

As startups grow and succeed, employees with no management experience are asked to become managers. Some dread the opportunity. Some relish it. But all ask: “how do I get started?” A few high performing designers and researchers – and freshly minted UX managers – at Google have asked me this recently, so here are a few of the techniques I’ve used.

It’s not about you

First things first. Write down your goals, your vision, your fantasies. Write down all of the amazing things that you hope to be as a manager and leader. If you want to be Jony Ive, write that down. If you want to be Dieter Rams, write it. When you’re done in dreamworld, take this list and file it away. You are none of these things, and you won’t be for a long time. But you should dream. You should have a vision. Write it and file it. Come back to it when you’re ready. Your first few months as a UX manager are not about you.

It’s about your team

Next, schedule one on one meetings with all of your direct reports. It’s important to allow a good chunk of time for these meetings, say 1-2 hours each. You may only need to use 15 minutes, but some team members will want to take a full day. My general structure for a first meeting is to focus on projects, asking 2 things for each: what’s working and what’s not. You can get to existential questions in future meetings.

What’s working?

I’ve found that “what’s working?” leads to lots of great discussion. It’s an opening to discover work and collaborations that your team member enjoys. Take special note of collaborations. If there are people from other disciplines that your team members enjoy working with, chances are they are open to more collaboration with UXers, including you. If your team member shares work with you, it’s important to resist your desire to critique. You will have that opportunity in future meetings.

What’s not working?

“What’s not working?” will be their chance to vent or pontificate. Let it happen. UXers are emotional people. They put their work out into the world every day, and every day that work is critiqued by people who have no background in UX and no place critiquing. You know how demoralizing and frustrating that can be. Chances are very good that at least one person on your team is ready to explode. Use this session to actively listen. It will be therapeutic for your team, and invaluable for you. Make special note of problematic co-workers – chances are good that you will need to interact with them or their managers in the future.

Anything else I need to know?

The last thing I ask is if there’s anything else I need to know. This discussion may start quite innocently with upcoming vacations and unfulfilled requests made to previous managers. But you may also uncover some more significant issues, some that may warrant HR (if you have an HR department) or founder-level involvement.

Getting to something actionable – The Top Three

When starting out as a manager, it’s important to get runs on the board early. It shows your team that you get things done, that you’re here for them, that you listen. It builds loyalty. After your meetings – what’s working, what’s not working, and anything else – you’ll have a huge list of issues to deal with. It can be an overwhelming list. To get runs on the board, focus on three things in your first month:

1. Paperwork
2. Workload
3. Issues with co-workers

Paperwork can appear inane – like approving a vacation, requesting a promotion review, clarifying compensation information – but can be extremely valuable to your team members. People tend to avoid dealing with higher levels of management or HR, sometimes to their own detriment. Take care of these issues for them. Be careful to differentiate between what an employee can do for themselves and what you should do as a manager. If you feel like you’re being someone’s admin, push back.

Workload is almost always a problem. UXers are overworked. You should use your judgement to understand whether there is a legitimate workload issue. If you think it is, there are a few strategies you can use. First, don’t allow any more work assignments to your team member. No new projects. Second, take a look at the list of projects in their pipeline. Many UXers feel overwhelmed simply because they have lots and lots of small projects. Context switching is a time waster and productivity killer. If you see anything in their project queue that could be better handled by an engineer or PM, write to the project team and let them know that you’re moving your person off of their project. Ask to meet with them to understand how you can transition your person off of that project. Don’t leave teams in the lurch, but don’t let them take an allocation for granted. Third, make a note of the other projects in their queue. You won’t be able to fix workload in those projects in the first month. Save them for later.

You can’t expect a quick fix when one of your team members is dealing with a problematic co-worker. It will take time. But get the ball rolling now. Meet with that person and their manager. Understand the issues. Get the context. Listen, and don’t try to be a hero. Just injecting yourself into the conversation can make a difference. Many problematic people become aware that your team member has an advocate, and may back off or adjust their behavior. But others won’t. This later camp require more work… and another post.

What’s next?

You need to get to know your stakeholders. Here’s where you get lots of ideas for making a difference and building your influence in your company. That’ll be the subject of a future post…

TL;DR

In sum, when starting as a UX manager:

• Write down your personal goals and file them away for now. It’s not about you.
• Meet with your team members. Understand what’s working, what’s not, and anything else.
• Get stuff done in your first month. Clean up paperwork. Address workload. Start conversations with problematic co-workers.

Graham Jenkin was an inaugural Google “Great Manager Award” winner and currently works on product and design at AngelList. You can follow his tweets @GrahamJenkin.

Doug Bowman is without a doubt an extraordinary designer. Doug and I were “peers” in Google’s User Experience organization before his departure last week. I say “peers” in quotes because, while technically we were peers in that we reported to the same director, my capabilities and talent pale in comparison. It was certainly an honor to be within the same team as Doug and to benefit from the fruits of his work. We will miss him and his contributions dearly.

Doug’s recent article about his departure from Google contains many truths. Of course Google is a company run by engineers. Yes many design decisions are driven by data. But Doug’s description of how design is viewed at Google is an oversimplification.

While there are many teams within Google that view design process as a problem in logic requiring data to solve, there are others that do not. While there are many Googlers who view designers as people who tinker with link color and border widths, many do not. Doug’s experience was unfortunately clouded by the teams and executives he was asked to work with.

My experience has been different.

I oversee the work of a team of designers focused on Google’s advertiser and publisher products – known within Google as simply “Ads”. As Doug mentioned, the talent and intelligence of designers at Google is incredible and the Ads team is no exception. To highlight a few: Google Analytics’ Doug van der Molen is a brilliant design leader with remarkable vision and entrepreneurial spirit. Feedburner’s Matt Shobe – who now applies his talents to new publisher products – breathes life into his products by injecting them with personality. And Ad Planner’s Ken Moore has talents that only a select few can truly appreciate.

Within Ads, we don’t work on projects which aim to determine the highest monetizing shade of blue. Nor do we focus on tweaking border widths. Rather, we work on complex, large-scale redesigns such as the soon-to-be-announced new AdWords interface. Or major feature upgrades to Google Analytics. Or new product designs for … well, I can’t talk about that just yet.

To design successfully in this environment, we simply must partner closely with product management and engineering. And we do. PMs and engineers understand that designing usable interfaces to support complex workflows for our advertisers and publishers requires something more than opinion and data. It requires skills that only designers can bring to bare. Skills that go beyond color theory and making things look “pretty”. Yes we use data to assist in decision-making, but data takes a back seat when teams develop the kinds of design innovations you experience in Google Analytics, the new AdWords UI, and other products delivered by the Ads team.

It’s not all perfect of course. There are certainly times when designers are somewhat marginalized, or when engineers or PMs pull rank when a decision has to be made. But these times are rare.

Perhaps what differentiates this team of designers is that we don’t expect the rest of the company to bow down to our design wisdom. We earn respect by demonstrating the value of good design through our work day in and day out. By working with our partners, not in spite of them.

Some may give up when faced with an organization less aligned with their discipline than they would like. Some say goodbye. We say otherwise.

There has been somewhat of a debate going on between Matt Cutts and Om Malik around whether Google has any big ideas.  The debate kicked off after Google Tasks for Mobile launched and generated a bit of blogosphere buzz.  Om responded to the buzz with a tweet: I think google has no big ideas. this morning they announced a to-do-list. FGS. Remember the Milk MUCH better.

To be sure, the idea of a to-do list isn’t necessarily something one would classify as big.  And yes, there are plenty of great products out there that handle task management in a much more comprehensive and convenient way than Google’s late-to-market effort.  Remember the Milk is a brilliant tool.

This debate seems like a complete waste of time, but I somehow feel compelled to add a perspective to the mix.

We should expect Google to be all out of ideas.

Why?

Google is a search and advertising company.  As much as we like to personify the brand – “Google does this”, “Google thinks that”, etc. – it is ultimately a business and the individuals running the business will tend to make decisions that maximize revenue or minimize costs.  It won’t always do this, but it will tend to, especially if it’s a public company as Google is.

Once a business comes across an idea that generates a bucketload of revenue, the decision-making process of that company tends to stifle innovation beyond this idea out of fear that these newer ideas will “cannibalize” their cash cow or will take “resources” away from making their cash cow even fatter.  Again this isn’t always the case, and this analysis is a simplification, but this “defend against innovation” mentality is baked into the DNA of all businesses and is difficult to avoid.  Google is no exception.  Larry and Sergey identified an opportunity to build a better search engine, and eventually found a brilliant revenue stream in text-based contextual advertising.  That’s Google’s big idea.  Their teams executed on this idea extremely well, and now the business is swimming in cash.

Now that they’re swimming in cash, we should expect to see Google defend against innovation which may harm their revenue stream.  We should actually expect that Google has no more ideas, or at least very few good ones.

The fact that individuals push their ideas within the company, get buy-in, and eventually launch – like the Tasks team – makes Google unique and interesting, and is a testament to the perserverence of those individuals.

But if we’re looking to Google to be the one true source of innovation, we’re looking in the wrong place.

Today’s launch of the world’s first Google Android powered phone is certainly an exciting event.  The team that has worked on Android has done incredible work, and, while no one knows for sure, the product will more than likely have some degree of success in terms of units sold and revenue generated.

At the core of the Android experience is obviously Google search.  Like Chrome, Android is an attempt by Google to gain wrestle control of the mobile or browser user’s search experience from those that currently control the platforms that underpin that experience – carriers, mobile OS developers, browser developers, and other “intermediaries”, most notably Microsoft.  Toolbar was a great success in maintaining Google presence in the hearts and minds of many users, and in preventing Microsoft from making it’s search experience the default for the majority.  Chrome and Android can be viewed as smart attempts to work this same strategy.

Unfortunately for the Android team, the most common thing that people will say about the phone is that “it’s no iPhone”.  It isn’t.  The Android user experience is good but can’t be described as perfectly elegant at this point.  But it will get better, and great applications will be developed for the phone … hopefully for Google there’ll be one or two killer apps that will make the platform and the phone a must-have at some point.

But I must say the marketing effort around Android has been abysmal.  The iPhone has set the mobile user experience bar incredibly high, and disparaging comparisons between Android and iPhone are inevitable.  Yet there was limited expectation setting from Google.  Surely there could have been a more appropriate and explicit re-framing of the objectives of Android.  The whole “it’s about the platform not the experience” line, as genuine as it is, doesn’t really resonate with people that have been spoiled by (or even just heard about) the iPhone experience.

Who knows what the business impact of this poor marketing effort will be, but I certainly feel for the hard working engineers, designers and others who, after all of their blood, sweat and sleepless nights, will suffer from the “good but not as good as …” complex.  Let’s hope that this kind of feedback will inspire them to create something even greater.

Someone from the office pointed out this article and discussion by Fred Wilson over at AVC.

Fred talks about an alternative to M&A; as an exit strategy for companies, but also discusses the degradation of services following an acquisition: delicious, feedburner, and TACODA being some of the examples.

Open platforms like Linux, Google’s Android, Open Social, and Facebook seem to have many positive attributes. Arguably, they allow for a community of developers to create a suite of applications and to use the power of that community to rapidly improve on those applications. This generally means good things for users. Users are more likely to be treated to a broad range of choices when a platform is open, and specific niche audiences are more likely to be supported in some way by some small group of developers somewhere. It’s generally a feel-good story.

But what happens when the “owner” of that open platform is a commercial enterprise? The experience of Facebook developers Social.IM and FriendVox may be an indication. It seems that in their efforts to use the Facebook platform to develop unique and interesting applications, they ran into a challenging competitor – Facebook. With the launch of Facebook chat, Social.IM and FriendVox and other developers of chat applications for Facebook are pretty much washed up. Any chance of getting additional rounds of funding or selling their business have been dramatically reduced. Why would anyone want to develop on a platform when the platform owner is likely to reproduce your product for its own purposes?

Google’s recent launch of App Engine and the silliness of its Campfire rip-off demo will most likely scare a few developers as well. While not an open platform as such, App Engine provides another large company the opportunity to see how others innovate and then replicate that work. While this isn’t what happened with the HuddleChat demo, the opportunity is there.

Certainly, there are products out there that have received a huge boost in traffic and revenue by developing on the Facebook platform. But small software startups who are looking to protect their IP should be wary of jumping on the open platform bandwagon.

In an interview published at GigaOM, Facebook CEO Mark Zuckerberg explains the monetization opportunity that his social network site represents:

People go to a content site to see a specific kind of content and will trust those ads relate somehow to it. On Facebook, people are not coming to see content from Facebook; they’re coming to see what other people are sharing, so the most natural analog would be having the ads be information shared among the people. Because so much of our society has some commercial component it seems like there will be a way to both share information and line that up with what advertisers want.

Some amount is happening as advertisers pay to accelerate that distribution of information. The amount they’d be willing to pay is proportional to how much it is accelerated.

So the story is that, on a social network, when enough people are looking at what other people are doing, and the social network blends into that experience ads that relate to what those people are doing, you’ll have yourself an effective marketing platform. That seems reasonable, but I doubt that this is where the true value of a social network lies. In fact, I believe that this model is a poor deal for advertisers when compared to what’s already out there in the online advertising marketplace.

Consider some of the other online advertising models for comparison.

Search is arguably the most effective. Users of a search engine have an intention that they express in the search box. Both ads and “non-ads” – that is, organic search results – are displayed in response to that intent. Either the ad or the non-ad could be an effective answer to whatever question or problem the intent poses. So there’s a good chance that an ad will be selected by the user. For example, if I want to learn about mp3 players, my search produces relevant informational content and commercial content … either could fulfill my curiosity.

Contextual ads on a content site, like a blog or an online newspaper, can be an effective and relevant information path for users once they’ve read or partially read the blog or news article. Traditionally, clickthrough rates on such sites are lower than search engine ads, but advertisers can still get good return on ad spend if they are careful in targeting content sites. Back to our mp3 example, if I’m reading about mp3 players, perhaps a review of a specific mp3 player, once I’ve completed reading that review, mp3-related ads can open a door for me if I’m ready to make a commercial decision.

On a social network site, as Zuckerberg suggests, people are interested in people. There is less of a direct commercial opportunity in this. If I use the mp3 example again, perhaps the best I can hope for as an mp3 player advertiser is to target users who are frequent users of iLike – not exactly a strong indication that they’re in the market for an mp3 player. Or perhaps they’ve set their status to “in the market for an mp3 player” … right.

So I think Zuckerberg has got it wrong (or maybe he’s just not offering up the true value of his platform). There’s limited opportunity in the advertising model he references. The bigger opportunity is in brand building. Having personalities, celebrities, brands, and commercial entities live within the social network universe and use that platform to build relationships with other social network users is the way that these platforms will generate huge advertising dollars.

There’s an ever-growing chorus of pundits that are questioning the orbit-level valuations of social networking sites, Facebook in particular.

That’s not to say that there isn’t enormous potential in businesses built around the types of communities that are actively poking and stalking each other on social networking sites — but the current range of direct advertising-based approaches to monetizing such sites are misplaced.

Google’s recent forays – and misfires – in this space are representative of this issue. The search advertising model works great for search, but fails to convert into clicks at the same RPM on MySpace and elsewhere.

And that’s because use of a social networking site is fundamentally different to a search experience. Users of social networks are less likely to be searching for products than they are to be searching for their friends and colleagues.

For instance, if I want to find a buddy of mine from high school, I’m probably going to use Facebook. And what I’d consider a “success” in this interaction is … I find his profile. That’s a pretty specific success measure. There’s very little chance that an advertisement will help me in this task. I’m going to ignore advertising while going through this flow.

But if I want to find information about a product or about pretty much anything else, I’m going to use Google. And a “success” event in this context could vary widely. It could be that I find an ecommerce site that sells the product, that I find a review site with UGC on the product, or that I find a TV ad for the product on YouTube. And there’s every chance that an ad may help me in this task – particularly if the ad is presented by a vendor or site that I trust more than those sites listed at the top of the SERP.

In other words, advertising doesn’t help me do what I want to do on a social network. Advertising can actually help me do what I want to do when I’m searching.

Contextual advertising works great for search. Contextual advertising sucks for social networking.

Sure social networks will make money from contextual advertising, absolutely. But RPMs will be strikingly lower relative to traditional search-based contextual advertising.

So is the revenue generating potential of Facebook over-hyped? Doomed even? Not necessarily.

It seems that those marketers who understand the value of brand advertising – of relationship deepening with respect to a brand – will, and already are, drawn to social networks.

Artists in particular are set to benefit. MySpace’s focus on music is no accident. People tend to think of their relationship with rock bands, rappers, etc as very personal – taking advantage of that emotional need through a MySpace community is a perfect way to deepen relationships and directly and indirectly lead to sales. Extend this beyond music artists into authors, fashion designers, Apple Computer … any commercial product or entity about which people are passionate, and you see the opportunity.

Marketers get this. Software engineers struggle to get this. Companies like Google will continue to struggle to monetize social networks at the rates they expect so long as they’re run by software engineers.

Business models that allow commercial enterprises to turn social network eyeballs into communities around their product will succeed. The tried and true contextual advertising models won’t.