How to Attract the Elusive Design Recruit

February 26th, 2014

This post was first published on the WSJ’s ‘The Accelerators’ blog on Feb 7, 2014 as part of their month of design-related essays for entrepreneurs.

Good designers are incredibly difficult to find. Ask any entrepreneur. In the last 10 years, as Silicon Valley’s big tech companies have followed Apple’s lead and switched on to the value of design, they’ve also turned up the heat in the war to recruit the best designers. Can an entrepreneur compete with the resources of these multi-billion dollar monsters? Yes, you can. What you may not know is that the Googles and Facebooks of the world, for all of their legendary perks, have attributes that are quite unattractive to good designers. The agile, disruptive startup has more advantages than one might think. Here are a few points to highlight in your pitch to that elusive design recruit.

1. Work directly with the founders

Designers idolize the greats like Paul Rand, Dieter Rams, and more recently Jonathan Ive. Part of what made these design legends so successful was that they all worked directly with CEOs and founders. There were no layers of managers handling communications between Ive and Jobs when the two were iterating on the iMac. Most big tech companies have not evolved to this point. Occasionally you might read about, say, a tech CEO cranking out a logo with her best designers over a weekend, but generally designers have to fight for time with decision makers and when they finally get that time, they have to sit and watch while someone else presents their work. There are no big tech companies that have a designer – and not someone who only manages designers – who reports directly to the CEO. But you just can’t avoid this situation in a startup. Founders, if they aren’t designers themselves, simply have to work directly with designers in order to define and iterate on their product.

2. Building from the ground up

During my time at Google, I – along with hundreds of other designers – designed features for products like AdWords and Search. Not only were those user interfaces subjected to many design hands, but they had been around for years before I touched them. Could I honestly say that those product designs were “mine?” At a large company, there are so many people involved in the process of building a product that an individual’s contributions can disappear. Certainly there is something rewarding about being part of a large team that has broad impact, but it can be difficult in such situations to avoid feeling like you are simply iterating on someone else’s achievement. That is, in fact, what you are doing. Many good designers want to experience the joy of building something from the ground up, to be able to point at something in the world and say with complete honesty “I designed that.” And that’s an opportunity that a startup uniquely provides.

3. You have the keys

Big tech companies have teams of engineers guarding their codebase. They’ve spent years investing in the development of their product, so it makes sense for them to guard that product carefully. But this creates problems for designers who care about seeing their work through to completion. The best designers want the ability to craft the most minute aspects of the interactions they define, and are driven insane when their work is implemented by engineers with less maniacal attention to detail. During my time at Google, there were a few cases where designers where given access to the codebase, but these were the exception rather than the rule. Startups tend to have much more flexibility. In general, you’re able to at least give designers access to make modifications to html, css and javascript. Some engineers may also be happy that they don’t have to focus so much on the front end.

4. You control your destiny

Almost all big tech companies are engineering-driven. And this has given the world many incredible innovations. But frankly what good designer wants their perspective to be considered secondary to an engineer’s? Your startup may also be engineering-driven, but startups tend to be small enough that the culture is still evolving. Having a good designer — someone strong enough to get co-workers excited about the value of their work, — come on board early in a company’s lifecycle, has every opportunity to balance a technical culture with a passion for elegantly connecting humans with that technology. And doing so isn’t just good for designers. As Apple, Square and Nest have shown, striking the balance between amazing design and remarkable technology is also good for business.

Graham Jenkin is the designer of AngelList, the platform for startups. He was formerly head of User Experience for Google Ads and Commerce and SVP of User Experience at Bank of America. 

When you don’t know what to work on

December 24th, 2013

This is one way to think about what to work on.

Ask yourself:
1. Where is the most money flowing right now?, and
2. Where is the most money going to be flowing?

If #1 is working ok, focus on #2.
If #1 is not working well, focus on #1 or else there will be no #2.

Good designers are often unknown

December 11th, 2013

Good designers are rarely appreciated and often unknown. Their solutions are so ‘obvious’ that few get credit for crafting this obviousness.

On the gift of being a designer

October 20th, 2011

In one of his many excellent essays of advice to designers, Pentagram partner, Michael Bierut wrote:

Never forget you have a special gift.

… We live at a time when the tools of design are more available than ever before. What client doesn’t have a nephew who knows InDesign, or, better still, a spouse with a newly discovered enthusiasm for Powerpoint? Graphic design: anyone can do it, right? Well, yes. But the professionals still understand what it means to do something well. And that confidence makes its own statement.

… If you’re a designer, it’s easy to forget that what you do is, in so many ways, amazing. Appreciate that gift in yourself. Appreciate the gifts of others. And look for lessons wherever you can find them.

Next time you’re feeling sidelined by a project team, or under the thumb of an overbearing, credit-hungry product manager, or devalued because you spend more time in Photoshop than in Emacs, please remember that you have this special gift.

Getting Good Design Done In An Engineering-driven Company: My Experience With Google Wallet

October 13th, 2011

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.

 

Your first month as a UX manager

August 24th, 2011

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.

 

Hello Google

March 20th, 2009

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.

We should expect Google to be all out of ideas

February 4th, 2009

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.

“It’s no iPhone”

September 23rd, 2008

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.

Acquisition complete. Now what?

April 10th, 2008

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.