Fight to Make Your Product Great

In the mid-80’s I took my second tech job, at a company called Silicon Graphics, Inc.

SGI, before it officially contracted its name to “SGI”, was a fantastic place to grow and learn. It was intense and focused, and my modest technical know-how in Unix, TCP/IP Networking, and Computer Hardware matched well as the company grew its Unix workstation business and more customers connected computers to Internet Protocol networks. I was soon a main contact point for the most intractable problems from customers, and the Customer Support representative to new product introductions.

The focus and intensity made for arguments, some that probably would seem to outsiders as knock-down, drag-out fights.  But a friend from those days put it well when he said, “We fight with each other, but we fight to make a great product.”

If I came to engineering with a problem and hadn’t done my homework, didn’t have a good handle on what was happening and why, and hadn’t collected useful information from the customer, the criticism was withering. One networking engineer, who I consider an important early mentor, was especially tough. But once I learned to do my research and bring him useful information on real problems, he was very responsive and engaged, helping me pull in other engineers on really complex cases.

My team worked with real customers every day. We had an understanding of how real customers used these computers, and the real environments they were in — the networks, the labs, and the variety of configurations, and why a problem that some might consider a minor annoyance was actually a major disruption for another customer. But often it was difficult to produce clear data supporting our insights. By the time the data was clear, the problem was too big, or at least much more expensive to fix.

This was especially the case in new product introductions. Even down to the question, “Is this ready to ship?”, we were there, contributing to the decision and wielding a rarely used veto. These arguments were often heated, but the Product Managers and Marketing and Sales Execs came to know that our concerns should be considered, even on apparently light evidence. And we knew that a big part of our job in new product intro’s was to ensure that we never needed to use that veto.

It was an environment where you were expected to know your stuff, whether on technical topics or in business. And even if you had a reputation for knowing your stuff, you would get challenged, and you had to fight it out.

As Silicon Graphics grew, it became known as the place the best people all wanted to work. Not because of that original espresso machine that Jim Clark bought for the engineering team, but because of our reputation for excellence in every part of the company.

But as the growth started to accelerate in the early 90’s, things changed. Instead of arguments about making our products and services better, about serving customers, fixing problems and getting things done, the fights became political. Which VP was supporting that position? Who are you? Whose budget is this going to come out of? In-fighting between divisions and groups and backstabbing and office politics grew. SGI had become a “big company.”

Many great people left, but many stuck around. Even if you were unhappy, the growth made it easy to find something new and interesting to do.

But the necrosis had set in.

We were no longer focused on building great products and changing the world. We were fighting the wrong fights.

Building a great product (or service) is never easy. Tough decisions must be made, and among smart, motivated people, coming from differing experience and perspectives, that’s going to cause arguments. And even in the best teams, sometimes the argument will go too far, or stray into personal attacks, or involve some back-channel politicking. And learning to develop an idea and gather support for it is critical to getting anything done in a large organization.

You have to keep bringing everyone back to the point: To make a great product.

Thinking about product design

I had an interesting discussion this weekend about computers and devices and Internet of Things. I’m still sorting out how exactly to articulate this, and then this morning this great example from Marco Arment came to my news feed:

From Redesigning Overcast’s Apple Watch app – Marco.org:

It’s unwise and futile to try to shove iPhone interfaces and paradigms into the Apple Watch. Instead, design for what the Watch really is.

All these devices are testing the creativity and interaction concepts of designers and developers. Whether it’s the Apple Watch, some new “Internet of Things” device, or even something as straightforward, but polarizing, as the new Apple MacBook, Thinking about what the thing is for, and understanding the subtle ways that people will use the new thing — that’s where the magic happens.

Read Marco’s post about his app. The specific are interesting, and the more general lessons essential.

Developers and Apple

It looks like Apple have been doing some thinking about the challenges of a growing developer community. In their fashion, they aren’t telling us much, but at least the change to WWDC ticket sales process and promised availability of session videos during the conference were good steps.

Now they have quietly announced a series of Tech Talks starting in the fall.

Enthusiasm for WWDC 2013 has been incredible, with tickets selling out in record time. For those who can’t join us in San Francisco, you can still take advantage of great WWDC content, as we’ll be posting videos of all our sessions during the conference. We’ll also be hitting the road this fall with Tech Talks in a city near you. Hope to see you there.

News and Announcements for Apple Developers

Still not much in the way of detail, but knowing Apple, there’s a whole planned out strategy behind this. I’m guessing we’ll be hearing a lot more about an expanded developer education and outreach program by the time WWDC is over.

What Lean Startup Is Not

I feel for Eric Reis. He seems compelled to say, in every talk, right in the beginning, “Lean is not ‘cheap’!”

I’m sure it’s because he gets hit with this constantly. Just yesterday I was reading about Education startups and a well-regarded startup founder and investor was quoted as saying that startups in the Education space need to be “pudgier”

“One of the things I feel strongly about is that everybody
pushes the notion of a lean startup,” said Katzman, who founded
the Princeton Review, online education company 2U (formerly
2tor) and his current startup Noodle Education. “And I’m kind
of in favor, especially in the education space, of a pudgier startup.”
John Katzman, as quoted in GigaOm

Katzman goes on to say some pretty smart things about the complexities of the Education market, but this “pudgier” statement has nothing to do with Lean Startup.

I believe the “good mix of people with deep backgrounds in education and business” Katzman calls for would do well to validate their assumptions and develop their product using the Lean Startup approach. Katzman seems to agree — he goes on to recommend strategies very much in keeping with Lean Startup. The video is worth watching.

Katzman makes a great example because he’s an experienced entrepreneur who actually agrees with the Lean Startup approach, whether he knows it or not. This is a guy who knows his stuff, who knows how important it is to listen closely to customers, who tells great stories of realizing after just a few usability tests that his assumptions were wrong. This is a guy we should be listening to, other than his mischaracterization of Lean Startup.

Worried about the cost of Support? Focus on making it Effective!

You want the virtuous cycle, or the vicious one? The key is to create a virtuous cycle of great support, product improvement, and customer loyalty & recommendations. It's a virtuous cycle of good will. Here are the steps:

What customers want, more than anything else, is for your support to be effective. They want an answer their request promptly, they want us to understand the problem they are having, and help them fix it. Maybe they’d also like to understand a bit about it themselves. Oh, and could you make it so that this problem doesn’t happen anymore?

Tall order. But we all know this is right, because it’s what we all want. But it’s too expensive to deliver that sort of service to everyone, right?

Wrong.

Delivering effective support is more cost effective than any alternative. It solves problems the first time, eliminating call-backs and telephone-tag. It understands the problem, and takes the right actions to document the work-around, file the right bug report, and make the right change to the documentation. It gets that understanding built into the product, making the product better and more valuable.

You want the virtuous cycle, or the vicious one?

The key is to create a virtuous cycle of great support, product improvement, and customer loyalty & recommendations. It’s a virtuous cycle of good will. Here are the steps:

– Do a great job of supporting your customers and understanding their problems

– Build what you learn back into your product

– Repeat

This is simple, but it’s not easy. And this isn’t just the job of the support team. It takes a whole company focus.

How to Hire for Tech Support

Tech Support folks should also be friendly and like helping people. They should be communicative both inside the organization and with customers. Dont just expect your team to "be professional". That admonition is at the core of the wooden, scripted responses that frustrate customers.

What should you look for when hiring Tech Support staff? My answer to this may be a little counter intuitive.

Great Tech Support people are:
– Problem solvers
– Friendly and they like helping people.
– Communicative
– Confident enough to say “I don’t know, but I’ll find out”

This last point is very important, and too often overlooked. It’s critical in Tech Support to have a team that will respond well when presented with something they don’t know. Every one of them should not only be comfortable with it, but should relish the opportunity to figure something out.

Tech Support folks should also be friendly and like helping people. They should be communicative both inside the organization and with customers. Don’t just expect your team to “be professional”. That admonition is at the core of the wooden, scripted responses that frustrate customers.

“Knowing the answer doesn’t scale. Hire Tech Support people who can figure things out.”

Why didn’t I include something about technical qualifications? While a foundation of technical expertise may be important in your business, a candidate who is a better problem solver and better with people will still be the best choice, even if they lack experience in some aspect of your product or market. The best Tech Support people learn very quickly, and learn best while solving real problems.

Knowing the answer doesn’t scale. Focusing on “knowing the answer” is part of the “Quick Resolution Paradox” – it puts you on that treadmill that brings ever growing costs and support staff burnout. If you know the answer, you should be working to make sure you never get that question again, first by putting the answer at the fingertips of your users, and then by fixing the product so that this problem goes away forever.

Knowing the answer is a side-effect of providing good support, not its goal.

To make a great Tech Support team, the right hiring is critical. The right folks, with the right skills, will build your reputation with your customers with every call.

Apple Leads in Tech Support

This recent research is shows the difference you can get when focusing on resolving problems:

The study found that customers from each company are generally satisfied with hold times, ease of reaching an agent and agent professionalism. In contrast, there was a significant difference in the percentage of customers who reported their problem was solved: 53% of Apple customers reported their problem had been resolved on the call, while 45% of Dell customers and only 39% of HP customers reported they were able to resolve their problem on the call.

[From Apple Leads in Customer Satisfaction in Vocalabs Tech Support Study | Vocal Laboratories Inc.]

How to use Twitter in tech support

Twitter is getting another big wave of adoption and many people are asking again what it’s for. How could short broadcasted text messages limited to 140 characters be useful? What utility could it possible have?

For tech support organizations I think it’s very useful, in two primary ways:

1. for “eavesdropping” on people who are talking about your company or product, and starting a conversation with them

2. as a signaling mechanism – a way to get a short, simple status message or announcements to an interested group.

Continue reading “How to use Twitter in tech support”

Service feedback, done right.

Check out the post by Jon Mountjoy on the feedback request from Apple after getting his Macbook Pro serviced at the Apple Store. The folks at Apple have done a very nice job on this process. Compare it to what you do. How does your feedback process make your customers feel?

An interesting example is the feedback process for in-store support at the Apple Store:

… There was no logging in, no tedious filling in of silly details. I’m a community member (okay, a customer) – they have all that recorded and integrated with this web property. Awesome. Now I want to fill it in – after all I just had to push one button to get here. Nice touch in having the Genius name there too.

[From Get better at soliciting explicit customer feedback — Jon Mountjoy]

Commercial email, or even tweets, aren’t necessarily spam

  Spam in Twitter is becoming a problem. Full 75% of my new followers yesterday were some kind of crass commercial, “I’ll show you how to twitter for money” or “check out my new multi-level marketing scheme.”

But some folks are using twitter for their business in some useful and interesting way. The latest I’ve learned about is a bunch of food twitters, including @chezspencergo, just profiled on sfgate.com:

Continue reading “Commercial email, or even tweets, aren’t necessarily spam”