I’ve been facilitating design studios with collocated teams for years. Many, including me, have covered the benefits of collaboratively sketching new ideas and concepts with a cross-functional team. Recently though, I was tasked with bringing this exercise to a distributed team. With the product and user experience team in New York and the development team in Vancouver, it proved to be an interesting challenge. What follows is a play-by-play of how we set up the exercise and executed as well as an analysis of the successes and failures of this first attempt. It’s worth noting that this was the team’s first design studio ever – which added another layer of complexity to the event.

We gave the teams a brief heads up of what was going to happen and asked everyone to come to their individual conference rooms with their own laptops. Each conference room had a Mac in it with a location-specific Skype account (i.e., it wasn’t a specific individual’s account – it was the “office” account). The two offices connected to each other via their office Skype accounts so that we could see each other as a group. This was critical as it was the closest we could get to physically being in the same room.

We prepared a very brief (~10 slides) setup presentation that explained the problem statement we were going to try and solve, customer testimonials and data illustrating that this problem was indeed real, the constraints of the solution space and a very brief recap of our customers’ needs. All of this went over very well and the teams understood the material clearly given their existing subject matter expertise.

Priming the pump with affinity mapping

Since this was their first collaborative sketching session, we didn’t want to jump right into drawing. To prime their creative pump, we kicked things off with an affinity mapping exercise. Typically these are done with sticky notes and a white board when the team is collocated.

Local Affinity Mapping

In this case we used a shared Google Doc spreadsheet to conduct the exercise. We asked everyone in both offices to sign in to the shared spreadsheet. The spreadsheet itself had a column labeled for each person. We had 8 team members in the document at the same time.

Blank brainstorming spreadsheet

The team was asked to come up with as many ideas as they could think of to solve the problem statement that was presented to them. Each team member would write one idea per cell in the column marked with his or her name. They had 5 minutes to generate as many ideas as they could. Some brief Q&A preceded the timer starting to clarify the constraints and guidelines for the exercise and the team was off! 5 minutes later we had a spreadsheet filled with about 60 ideas for various ways of solving the problem.

Completed brainstorming spreadsheet

The next step involved each team member reading his or her idea out to the distributed team. Some ideas went by quickly while others were discussed with a bit more detail. The initial purpose of this was to simply have everyone in both locations aware of what was proposed by their teammates. While they could certainly read the spreadsheet on their own, it was much more powerful for each individual to read their ideas. The goal of affinity mapping is to then group these ideas into overarching themes around which the team can agree. In the physical world this is done by moving sticky notes around into the same physical area on a whiteboard or wall.

To simulate this in the shared spreadsheet, the facilitator (me, in this case) began a second sheet in the document using a personal laptop. The second sheet had column headers that reflected themes I was hearing as the group read out their ideas. Each column represented a theme into which a few of the ideas could potentially fit. This was done largely for efficiency of the process. We certainly could have started the second sheet as a group and figured out the initial set together but given this was their first time and we were starting to get a bit behind schedule I took the initiative to create an initial set of theme proposals.

The team was then instructed to take each idea they came up with and copy/paste it into the matching theme on the second sheet. If it didn’t fit they were instructed to create their own theme and were highly encouraged to change the wording of the themes if they felt it was not representative or misleading. Each member proceeded to do this for the next two minutes or so. We ran into some copy/pasting over each other issues. Google docs does indicate when another user has focus on a particular cell with a unique color for each user and their name. This helped a bit but this portion of the exercise got a bit messy. All in all, no theme names were changed and only one new theme was added. My guess is that the team was not completely comfortable with making changes to something that was already presented to them. I expect this to get better and easier with each run through this exercise.

The end result was a spreadsheet sorted into themes with each theme populated by at least 2 ideas and some with as many as 8. We reviewed the themes again as a team, discussed for a bit and agreed that this was a comprehensive set of solutions.

The plan was to break here and move straight into the sketching portion of the exercise but at 2 hours, we ran out of time for this meeting. We schedule part two of the exercise for two days later and allocated another 2 hours to it.

Note: following this exercise, the site cardmapping.com was brought to my attention. It looks very interesting and can potentially replace a physical whiteboard and stickynotes in this exercise. I’ll dig into it further but haven’t had a chance to run it through a proper exercise yet. Any opinions on it would be greatly welcomed.

Collaborative sketching with remote teams

When we reconvened we went through a modified version of the setup deck to recap the problem statement, constraints, user pain points and the themes we came up with during the first session. We then presented the team with the logistics of the collaborative sketching exercise.

The team was provided with a 6-up template:

6-up template

and a 1-up template:

1-up template

and a set of Sharpie markers. We explained to the team that we were going to ask them to sketch 6, high-level ideas based on the themes we brainstormed in 5 minutes. They were encouraged to draw, not write words and to use the sharpies to illustrate 6 separate screens or a set of workflows they felt made sense.

Five minutes later the team produced 8 sets of 6-ups that were filled out with visual ideas about how to solve this particular problem. We asked the Vancouver team to use an iPhone to photograph their sketches and email them to all the folks in NYC. We did the same for the Vancouver folks. We had initially considered simply holding the sketches up to the camera in each conference room but the resolution and the stability of the presenter’s hand made this sub-optimal. The process of photographing the sketches and emailing took about 5 minutes. It was a necessary task but it took a bit of wind out of the sails of the activity, as momentum was built up and people were anxious to share their ideas and see what others did.

With dual monitors we were able to view sketches on one screen and see the remote team on the other screen. This helped connect the dialog and the artifact to the conversation. Typically in Skype conversations participants don’t talk to each other but instead talk to the screen. I was happy to see the team members presenting their ideas both to their collocated team and the remote portion.

Remote design studio and collaborative sketching

Remote design studio and collaborative sketching

Each team member presented his or her ideas to both rooms. Given this was the team’s first time, there were the expected awkward moments of silence but a little proactive moderation through Skype helped move things along. The Skype connection held up well and allowed the remote teams to participate in relative real-time in the critique portion of the exercise. Having the sketches up close on local monitors was critical to the success of the critiques. It allowed up-close inspection of the artifact and direct, relevant questions and answers from the team. In doing some up front research for this activity, several recommendations came in to purchase an IPEVO document camera. It’s relatively cheap at $70 and has a great camera and stand for document photography and transmission. We didn’t use it for this initial round but are seriously considering it for the next go-around. It will be interesting to see how it compares to the simple iPhone-snap-and-share technique we used. At $140 total cost for the experiment (1 camera per office) it’s worth the gamble.

Another tactic we’re eager to try to speed up the sharing of the photos (if we end up sticking with that tactic) is getting them into a Dropbox folder automatically. We’re checking out ifttt.com to see if there’s something we can set up there that will automatically share pics from a phone to a shared folder. I’m aware that the site allows you to have Instagram photos dropped into Dropbox but am concerned that photos taken in that app don’t have the necessary resolution for this exercise.

Conclusions

The team that experienced this remote brainstorming session had never done any kind of exercise like the ones described earlier. This was perhaps a boon for us since we didn’t have to live up to previous expectations of processes and success. It allowed us to run the session as if this is the way it’s always done. The flipside, of course, is that, with no context, the team couldn’t tell us whether this was a better or worse way to elicit the same results. What they could tell us was that they enjoyed the inclusion in the ideation process and the ability to share their ideas with a cross-functional group.

I would deem this remote technique a success. We succeeded in having an 8 person team brainstorm together, share their ideas, draw together and come together around collaborative solutions for a specific problem statement. The distance was a challenge but was largely overcome with technology. Perhaps we were lucky to have a solid Skype connection as I’m sure a spotty one would’ve caused the exercise to fizzle. We learned a lot about what works well and the challenges of facilitating two teams in two different rooms. As with everything, this process is iterative and next time can only get better.

What do you think? Is this a viable technique for your organization? Have you done this before? What’s worked well for you when dealing with distributed teams?

[Jeff]

P.S. — In Part II, I’ll follow up with any learnings from the next round of remote collaboration exercises.

I’m extremely proud (and partially terrified) to announce that I’m writing a book! The book’s topic is Lean User Experience and is tentatively titled, Lean UX: Getting Out of the Deliverables Business. It will be published by O’Reilly (creators of the famed “animal series” of books). While I’m not sure if my book will get an animal or not, I’m vying for either the unicorn or the honey badger .

The book writing process (a brand new experience for me) has begun and my hope is for an early Q2 2012 release date. I’m targeting an audience of designers of all flavors, product managers, software developers and executives trying to fit more efficient, agile design methods into their product creation and design processes. As with all of my writing, the book will provide practical advice and tactics that readers will be able to apply immediately. These tactics will be illustrated with case studies from Lean UX practitioners proving out the methodology in real-world situations. The case study list is shaping up to be an all-star cast of designers, developers and instructors.

I’m very excited about this project (it’s the biggest one I’ve ever undertaken) and I hope you’ll follow along with me both here on this blog and on Twitter as I get closer to the book’s launch. I’ll continue to blog here throughout the process but there will also be several guest posts published on other terrific publications. The articles page has all the details.

Finally, if you’d like to be updated on the book’s progress and publication date, I’ve put together the nifty little Google docs form below. Put your email in there and every now and again I’ll reach out with an update (your address stays with me, never to be shared).

Sign up to stay in the loop:

Thank you!

[Jeff]

It's always time to try something new

As the conversation around Lean UX heats up in the blogs, Twitters and conferences a lot of reference is made to the ideas of lean startup promoted by Eric Ries, Steve Blank and others. Many discussions focus on how user experience and design can exist in the highly iterative and test-driven world embodied by that movement and the companies that employ it. Indeed, lean startup thinking along with Agile philosophies served as inspiration for the Lean UX methodologies and practices I and others have promoted.  It’s no surprise then that when the conversation is focused on other types of organizations the Lean UX approach meets with skepticism.

Many of the questions I get regarding the viability of Lean UX center around three types of organizations – midsize/enterprise level companies, interactive agencies and “other” non-Agile environments. While I won’t address every single challenge and opportunity Lean UX faces in each of these situations, I want to take a high-level look at how this type of thinking can be applied for the benefit of each organization.

Larger companies (i.e., not startups)

Steve Blank describes startups as organizations designed to find a repeatable business model. When those organizations find that business model they shift their focus to scale – i.e., executing that business model at greater quantities and efficiency. This shift drives growth and that growth depends on repeatable processes. Teams are built around these processes leaving little room for iterative evolution of that process. For Lean UX to take root in a larger organization, it needs to start at the team level. An execution team needs to actively decide to try a new way of working. By opening up a new level of communication amongst the team members, new conversations can happen. Members of the team who were never involved previously in the design process are now welcomed in and are not only involved but are encouraged to participate. Design direction and decisions become a broader conversation that brings in fresh internal voices (developers, business owners, subject matter experts, et al) as well as stronger input from your customers.

The goal for this team is to prove the validity of their design solution as early as possible. The designer has the onus, in this type of organization, to break new ground. The initial step is to get buy-in on the design direction from internal members of the team. Conversations around feasibility, scope, general design direction and user experience can all happen at a very early point in the design cycle. Before committing your ideas to pixels even, start shopping them around in their most raw format to ensure that, as you design, you’re heading in the right direction. In addition, you make your teammates aware of that direction empowering them to start aligning their planning and contribution much earlier than they would have in the past.

In all but the most confidential environments, it is usually possible to get a hold of a customer or two. Even if you can’t show them actual work, discussing your proposed solution helps you refine the idea. If through these efforts you learn that the proposed direction is either not feasible or fails to alleviate your customer’s pain points, the investment level made to get that feedback (i.e., sunk cost) is minimal enough that making changes is relatively cost-free.

Enterprise teams can grow to large numbers and the scope of projects can also get big. To break ground for Lean UX, I recommend picking a smaller effort – perhaps even a non-customer-facing project. Taking on a low-risk project allows you to carefully feel your way around your organization’s existing methodologies while proposing new ideas around efforts where failure would have minimal impact both to your team and this new approach.

Agencies

There are many flavors of consulting companies and agencies. For the purpose of this post, the word “agencies” means interactive and advertising agencies who take on primarily website design and development work. One of the biggest challenges in this environment is separation of the teams. There is, typically, a client-based product team, the agency provides the user experience and design team and a third-party usually provides the technical side of the equation. Traditionally, an agency will kick off a project with a client, disappear for a while, perform voodoo/witchcraft/magic and return to the client with a shiny object. That object may or may not meet the client’s (or their customer’s) needs and edits/redesigns/negotiations ensue from here.

Applying Lean UX in an agency context means engaging your clients on a much more frequent basis. I recommend setting aside two to three 15-minute meetings a week with the client. These can be virtual, phone or in-person but the purpose is to have an ongoing, regularly cadenced conversation about the direction in which you are heading. In addition, these conversations should always include artifacts that show the progress the agency team has made. These artifacts should be of whatever fidelity and polish is available that day. It’s not necessary to push for pixel-perfect mocks at each one of these meetings. That’s wasted effort, as the feedback will undoubtedly force the relocation of some of those pixels. The goal is to show day-over-day progress and iteration on the concept – yes, revealing to the client the way the sausage is made.

This is critical because it makes the client feel like a part of your team. Their input and feedback inevitably makes its way into the product and they begin to “own” the work. The more they feel ownership over the work the more they will defend it and buy in to the vision you’re selling. If a third-party is providing technical support for this effort, they should also be included so that they can weigh in on feasibility, scope and cost of the features being proposed. In addition, they too will begin to feel as part of the team motivating them to create higher quality product more efficiently.

Non-Agile environments

“But my [insert company type/size here] is not an Agile shop!”  Lean UX has its roots in Agile but its practices are not limited to those environments. Regardless of what your methodology is there is always room to be more collaborative and inclusive in your design while reducing waste. The trick is to jump the rut of historical momentum. Just because it’s “always” been done a certain way doesn’t mean that tomorrow, you can’t come in to the office and try something new. And that something new doesn’t have to be a radical re-architecting of the way your company builds products. It can simply start as subtle change to your design process. For example, instead of disappearing behind your monitor for a day or two on a particular task, take a crack at it with your sketchpad and then walk over to one of the developers on your team (or stakeholder, product manager, whatever) and ask them what they think. Share your idea and get their feedback. Tweak the sketch in real-time until you are both on the right page. With this one simple step you have reduced waste in your process, opened lines of communication and iterated on your product design. Nifty.

These small steps can then be strung together into larger shifts in the way your team works. Find the things that resonate and build on them. As your team becomes more efficient and collaborative, other teams take notice. They begin to ask questions and ultimately want to work “the way” you’re working. It’ll take time but the payoff can be big. Regardless, the change has to start small so it may as well be you, the designer, who kicks it off.

Summary

Lean UX is a different way of applying the broad user experience and design tools we’ve been using for years. In addition, it promotes a greater role for cross-functional collaboration and transparency that has, traditionally, not been a part of UX processes. Interpreted in that light, it’s easy to see that the application of Lean UX can span any type and size of company as well as any development environment. The trick is to have an open mind, try something new, see how it works and iterate from there. Small steps lead to small wins. Credibility comes from those small wins on which you can build bigger change. Give it a shot and let me know how it worked out.

Unicorn: a visual designer with UX skills

I was speaking to an entrepreneur the other day when he mentioned he was looking for a “creative director with UX skills.” He added,”…someone whose aesthetic I really like.” I responded ,”Good luck.”

Having recently completed a year-long search for just such a person I’d resigned to believe this person was a in fact a unicorn. This person may exist – someone may have seen one once – but in most cases they’re simply fantastical stories of designers long-since employed elsewhere.

(Update: I was quickly reminded that I forgot to mention that my search bore fruit. I found my unicorn.)

Why is it so hard to find strong visual designers who have interaction and product design experience? In theory IxD and graphic design should go hand in hand and the market should be flooded. The reality is that a perfect storm of historical design inertia is failing to produce these much-needed hybrids.

First, design schools have traditionally not taught interaction design or user experience design skills. There is certainly sufficient material within the realm of academic Design to fill four years of curriculum. If you try to tack on the various fields of study commonly associated with UX (cognitive psychology, information architecture, research methods etc) you’d end up with 6-8 years of classes. However, providing at least foundational material sprinkled throughout a formal BFA program could be a good start.

Second, graphic designers get gobbled up quickly by the agency world. Unfortunately for those freshly minted designers, most agencies (especially the big ones) don’t value IxD or UX design. They throw the words around but when push comes to shove they sell advertising and interactive marketing. Designers are rarely offered the opportunity to witness, much less participate in, true interaction design work.

The experience designers collect through school and agency doesn’t prepare them to solve the challenges of workflow, transactional systems and information organization. This is not to say that they are incapable of this work. It’s just that when a hiring manager inside a product focused company starts assessing candidates, the most common gaping hole in those resumes is the actual design of products. Predictably this then perpetuates the cycle of visual designers going to agencies (where their lack of UX skills are not a barrier to entry) and not learning these much needed skills.

Why do you think there are relatively few of these unicorns?

[Jeff]

No two are alike!

Every person grows up thinking they are unique and special. Your mother told you that and, to this day, you believe it. The customers coming to your web site are no different. They each come expecting you to deliver an experience that is custom-tailored to their exact needs and desires. They want you to remember them, what they did, what they like/dislike and what they will likely do in the immediate future. Meet these demands and your product (website, et al) is the shit! Meet it not (sorry for the pseudo-Braveheart riff) and your site is shite (which is the opposite of “the shit!”).

There is no possible way you could deliver each of your customers a generic experience that would meet their expectations – they believe. But they’re wrong. With enough traffic through your application, patterns emerge. These patterns become evident through regular, vigilant review and analysis of your usage analytics (aka “the data”). Very quickly you start to see which users are performing specific actions and the correlations between those users. Add in a healthy dose of user profiling and you start to fill out your “typical” customers. Augment your findings with some qualitative research (yep, talk to your customers) to understand their motivations and very quickly you’ve moved away from individual snowflakes into similar “piles” snow – also known as personas.

It’s those personas that allow you to create a finite number of experiences that are “customized” to each user type. All of a sudden the scope of your personalization efforts is reduced from infinite options (aka impossible) to a handful of core flows that will satisfy the majority of your product’s user personas – and make each customer feel special. It’ll be our little secret.

[Jeff]

I once sat next to a newly-diagnosed MS patient while walking him through an online description of the progression of that disease. It was devastating.

Another time I interviewed a long-suffering Psoriasis  patient about her frustration with the lack of progress on treatment. It was infuriating. 

I once sat next to a job seeker who had been unemployed for 2 weeks. He was invincible. And so was I. 

Yet another time I sat next to a jobseeker who was unemployed for 6 months. He was desperate for communication – of any kind. So we talked. 

Empathy is the true comprehension of what our customers, visitors and users feel when they reach out for our service. Without it, we’re designing blind. 

Get out of your cube, office or co-working space. Go meet your customers. Ask them how they’re feeling. Understand them and they’ll know it. You’ll find them in your products and services. 

[Jeff]

I totally wasn’t. And the image below proves it:

The award I got for "inspiring" off-spec feature development

I received this illustrious award after coining the phrase “rogue developer” while on the AOL Explorer project (a surprisingly successful browser AOL launched in the early-mid 00′s). To me, a rogue developer was a software engineer who came up with and implemented their own feature or, at the very least, presented a prototype to the team for consideration.

As the Lead UI Designer on the project, this infuriated me at the time. I took great pride (not to mention time and pain-staking detail) in the thoroughness of my designs and, equally as important, my spec documents. They were pixel perfect and they were 100% correct and rigid. No deviations or the project would slip!

It’s worth mentioning that AOL in the early-mid 00′s was a waterfall shop. Very very waterfall. So waterfall in fact, they should’ve named our conference rooms Niagara and Iguazu. I was only 5 or 6 years into my career and waterfall was all I knew so I followed process. It was no surprise then that when “rogue development” took place it drew my ire.

How could this developer think he knows what customers want? What makes him think he can design an interface? That was MY job and I’ll be damned if someone else took that responsibility away from me.

None of these, of course, were valid concerns. Reading that award now, I am actually proud to have received it. I inspired “undocumented creativity.” 2010 Jeff is very proud of 2004 Jeff for doing that — even if 2004 Jeff didn’t like it very much at the time. I’ve come around to seeing the benefits of working closely with developers (and product mangers, and QA, and marketing et al) on concepting and developing product ideas. Together we create better finished products.

I look forward to inspiring a lot more undocumented creativity in my career.

[Jeff]

P.S. – Interesting side note: The junior product manager on the AOL Explorer project was Tim O’Shaughnessy who is now the CEO and co-founder of a little company you may have heard of – Living Social. Nice.

I just returned from a week in hot, sweaty and rainy Orlando, FL where I spent the bulk of my time at the Agile 2010 conference. It was my first time at such a specialized, non-design conference and I was doubly excited since I also presented. I went down with many questions — how are other organizations dealing with transitions into Agile? Is Design and User Experience even a consideration? What challenges and ultimately what solutions are people finding that work well for their teams?

I came down to Florida with those questions. I went home with them too. To be fair, I did get a slew of new tactics to try but the general vibe is that many folks are struggling with Agile — especially when trying to incorporate a design team (of any size, skillset or configuration). I focused my attention on sessions that dealt with the core problems with this integration as I see them — personalities and planning.

I found Lisamarie Babik‘s session on Coaching Introverts interesting and useful as it focused on pulling the quieter members of the team into the process more. I also spent time in Jean Tabaka‘s Visioning session. While it was a bit fluffy for my tastes it did give me some good ideas on how to focus the team on the things they want to achieve and not on the negative perceptions of an Agile design environment.

Jeff Patton and Desiree Sy — both UX/Agile legends at this point — provided strong tactical sessions on how to plan product design activities into the sprint timeframes. I found those sessions valuable and both individuals extremely friendly and forthcoming for conversation and differing opinions (Jeff I’d met once before but this is my first time meeting Desiree in person).

My presentation on integrating UX and Agile is embedded below. I feel like it struck a nerve with the folks who attended as it dealt directly with the failures we experienced at TheLadders as we’ve been integrating UX into Agile. But, more interestingly than that, it showed that even when good ideas fail, you can iterate, tweak and try them again — which is the essence of being agile.

I’ve been lucky enough over the years to be able to hire many people to the various teams I’ve led. Over the course of all of these interviews I’ve discovered that there are three core components that make a candidate a desirable addition to my team. While these three traits have emerged over the course of interviews focused on User Experience and Design teams, I believe they are applicable across all disciplines, industries and positions.

And so, without further ado, the three secrets to getting hired are:

1. Have kick-ass chops — in other words, be the best you can be at whatever it is you’re trying to getting hired to do. This means knowing the discipline, the tools and the outputs. Unless you’re applying for an entry-level position, there will be an expectation that you will know how to perform the job. The onus is on you to be the best you can be at that job. Also, your new team and manager don’t want to train you in the craft – perhaps they’ll train you in the specifics of how to perform the craft at that specific workplace but they’ll expect that you know what you’re doing.
2. Have an opinion — when asked at an interview how you feel about a particular subject, technique, outcome, etc have an opinion on the subject — even if that opinion differs from your interviewer. Also, use the opportunity to showcase that you have opinions about your industry and discipline. On my team, I seek out new ideas, thoughts and reactions — most managers do. Your point of view matters — even if it’s different than the commonly-held opinion.
3. Have the initiative and passion to pursue that opinion (the one in #2) — You’re good at what you do. You have definitive opinions on how things should be done and why certain techniques work and others don’t. The last ingredient is initiative. Having initiative means finding your own motivations and energies to push those opinions and drive the direction of the work you’re responsible for.  Without this last piece, your opinion is just an idea in your head. Growth companies look for team members who can move the company forward. Initiative moves your ideas forward which in turn moves the company.

I believe so firmly in these three traits that I actually tried to push through a job description (for every job on my team) with just those three things on it recently. Perhaps it’s a bit short but, to me, it says it all. Now, granted there will be corporations that may frown on some of these traits. It’s at that point where you have to ask yourself, if you have and value these traits, if that’s the place you really want to work.

Share these 3 secrets to getting hired with your networks. The more folks we get out there working in these ways, the better the output of the world’s best companies will ultimately be.

[Jeff]

I recently bought a car. It’s a 2007 Mustang GT. It’s metallic gray with custom wheels and I loved it the minute that I saw it on the Paramus Chevrolet dealership lot. Not too long after that serendipitous sighting I was the new owner of that car. The Mustang was perfect inside and out with three exceptions:

1. The custom after-market stereo seemed to work but did not emit any sound
2. It only came with one key
3. The manual (hey, I love manuals) was missing

Hotness from the right

My salesman at Paramus Chevrolet promised that all three of these things would be taken care of after I purchased the car. We even wrote a “we owe you” slip to ensure that no one at the dealership “forgot” what was agreed on at point of sale.

I returned a week later to have an amplifier installed in the Mustang to make the radio work. Turns out that the radio was also a CD player (nice) and a navigation system (even nicer) but, although now making sound, the face plate would not retract fully making it impossible to place a CD in the player nor was it possible to switch out the West Coast navigation DVD for an East Coast one. This rendered the navigation system unusable.

Hotness from the left

So, to recap — I am now the proud owner of a beautiful sports car (the kind I dreamed of as a teenager) and yet the three things that were agreed upon for post-sale disposition have gone unresolved and have left me with an unsettling feeling about the dealership’s motivations and legitimacy. After many unresponsive email attempts and phone calls, I tracked down the sales manager. He told me that I should go to Best Buy and find out what a new version of the car stereo would cost and that they would split the cost with me — $300. Installation was another $200. So, at this point the dealership is squabbling with me over $500, a key and a manual — ALL of which was promised to be taken care after I purchased the car. I spent over $20k at their establishment only to have my purchase experience and ANY word-of-mouth praising I might do eliminated in an instant — over $500, a key and a manual.

I continued to send emails, voicemails and the occasional drive-by to see if I can get them to move on any of these items but the result is always no response or no budging on any item. So, Paramus Chevrolet, you’ve lost me as a customer. I will not tell my friends to purchase cars in your lot. Here’s why:

• In an information-at-the-ready world where anyone can provide any product or service to anyone else the CORE differentiation is customer service. That service can only be delivered by humans and it’s those interactions with those humans that drives the perception of the experience with your dealership.
• The best type of transaction is one that instills trust. As a used car dealer you are starting in the red. You must work extra hard to earn a level of trust from your customers that make them feel good about dropping tens of thousands of dollars in your establishment.
• Hassle-free experience. That is your goal. That’s what you should strive for. Making it nearly impossible for me to get a hold of my salesman, his manager or anyone else to resolve this only exacerbates the issue.
• Any sales or influence book will tell you that word-of-mouth referrals are THE MOST valuable thing you can gain from your customers. Why would you risk so much future revenue over $500? In retrospect, it makes even less sense than before.

Case in point — recently at my workplace, TheLadders.com, we reworked our refund policy so that getting your money back from us was hassle free and painless. We want to provide good service but in the event it doesn’t meet your needs or expectations we want you to leave happy as well. As soon as the changes for this policy went into effect, our customer satisfaction ratings jumped over 30%. Even customers who were not happy with our product, left happy with our service.
Losing a customer is easy. Gaining and keeping a customer is hard work but the payoff is exponential if done right. Customer service is for the long term. Thinking about the short-term gain/loss ensures that you’ll continue to work even harder to gain new customers. For me, it’s too late. Paramus Chevrolet has lost me as a future customer but perhaps the next time this happens, $500 won’t be too much to spend to keep that customer and earn their trust.
[Jeff]