Kevin Hale: the subtleties of working with user experience (part 2)

Original author: Kevin Hale
  • Transfer

Stanford course CS183B: How to start a startup . Started in 2012 under the leadership of Peter Thiel. In the fall of 2014, a new series of lectures by leading entrepreneurs and experts of Y Combinator took place:

First part of the course

Kevin Hale: Actually, we constantly conducted experiments on the support service in Wufoo, because we were literally "obsessed" with it. One of the experiments that we conducted was as follows: we heard someone talking about the lack of connection between the emotions that we have when we need help and the satisfaction and the reaction that we get from people when we help them.

Especially often this connection is absent on the network, since we simply do not see these non-verbal signals. So, in the opinion of the author of this idea, there will never be a relationship between us and users until face recognition appears on the network.

We thought: "We are not experts in the field of face recognition, but it seems to us that there is another way to discern empathy." Since we were creating form designers, we added a drop-down list called “What do you feel now?”. We thought that no one would use it and thought it would be a futile experiment, but decided to see what happens.

It turned out that this field was filled in 75.8% of cases. For comparison: the field with the drop-down list “Browser Type” was filled in 78.1% of cases. That is, in fact, people told us: “In the case of my problem, what I feel is as important as the technical features that you need to know to fix the bug.”

We did not prioritize the tasks based on the emotions of those who contacted us, so most clients could not “replay” the system in this way. We noticed that one of the interesting side effects of this experiment is that people began to treat us better. We returned to work and looked at the data, analyzed the text and realized that in written communication, for example, by e-mail, there are only three ways to express vivid emotions: exclamation points, curses, and capital letters. Definitely [according to the results of the experiment], each of these three indicators decreased when communicating with us through the support service. As soon as people had a way to express their emotions, they began to reason more rationally and as a result made our work more enjoyable.

Another surprisingly striking result was that this approach helps you create better software. And this is confirmed by a number of studies. Jared Spool, a user interface designer (one of the largest experts in his field) claims that there is a direct correlation between how much time we spend communicating with users directly and the quality of the resulting design.

He believes that the design process should go exactly that way. Communication should be open. Conclusions cannot be made solely on the basis of reports or graphs. You must interact with customers in real time. Such communication should take place at least every six weeks and last at least two hours; otherwise, your software will deteriorate over time. Our developers communicate directly with users for 4-8 hours every week. This changes our view on software development.

Jared Spool offers a different look at how we create products. Imagine that this spectrum [on the slide above] displays the entire amount of knowledge necessary to use the application. The extreme left meaning is the complete lack of knowledge, the extreme right is all the necessary knowledge. And these two transverse lines reflect the essence of your user interaction. The cross line on the left shows the current level of user knowledge, and the cross line on the right shows what level of knowledge you want to bring them to.

The gap between them, according to Spul, is called the “knowledge gap”. Interestingly, there are two ways to fix it. You either provide the user with more knowledge, or reduce the amount of knowledge required to use the application. And often we, as engineers, those who work on creating products, think: "Let's add new features." But new features only lead to widening this gap.

As for us, we have concentrated our efforts in a different direction. We used 30% of the time spent on development to create internal support tools for helpdesk. But often this time was spent on people helping themselves. For example, we created pages with frequently asked questions, tooltips, and made it so that by clicking on the Help link instead of going to a page with general help documentation, you would get to a specific page with information that is most relevant to what you are working on.

We again and again changed the design of our documentation, constantly conducted A / B testing. One of the iterations on working on the documentation page reduced the load on technical support by 30% per day. This is one of those cases when every day, everyone who works on a product suddenly has a 30% less load.

What happens if everyone continuously works in technical support? I said at the very beginning that development is a function that depends on conversion and turnover. This is the Wufoo growth curve over the first five years [slide above]. The interesting thing is that we did not pay for advertising and marketing; all this growth was provided by the subscribers themselves.

The difference between the number of new users and those unsubscribing from services is extremely small, and this is very important. Many still forget that there is practically no difference between a 1% increase in conversion and a 1% decrease in “turnover”; they affect your growth in exactly the same way; however, the latter, in reality, is much simpler and much cheaper to implement. And we very often neglect this until the difference becomes too big. Usually these tasks are not the most basic employees of companies.

This schedule, frankly, is not one of those that we especially follow at Wufoo, not even one of which I am proud. This is one of those that I am proud of [the slide below], because despite the fact that we have a good, wonderful growth curve, that’s what allowed us to scale, remaining a small company with an amazing culture. And this required us to perform many tasks aimed at realizing the needs of our users.

John Gottman noted that there is another kind of relationship behavior that leads to divorce. In fact, it turned out that there is a subgroup of people living together for 10-15 years, and then suddenly applying for a divorce. None of the indicators suggests that this will happen. Gottman looked through the data and realized: "Hmm, there is no passion between these people, there is no fire." Relations in a sense follow the second law of thermodynamics: in a closed power system, everything tends to collapse, so you constantly have to apply energy and effort to return it to its original state.

Many people think that showing people how “they are valuable to companies” is necessary by creating, for example, a blog or a newsletter. We evaluated our indicators, and it turned out that the percentage of active users, generally speaking, was small; and most of them had no idea about the amazing opportunities that we could provide them.

Therefore, we created a new function and called it the Wufoo Alert System. Wufoo Alert System]. It allowed us to mark in time each new function introduced for users, and each time they opened the application, we looked at the time difference between the moment of their authorization or the last connection and the moment of introducing new functions, after which users received a pop-up message: "Hello, while you were away, Wufoo had cool features."

Without a doubt, this innovation was the most talked about, and I heard about it every time I talked with users. They said something like: "I like this function" Hello, while you were gone ... ". Although I pay the same amount every month, you do something for me almost every week. It's just amazing, I just feel that I get the maximum benefit from the service. "

Besides the fact that everyone supported those who paid the bills, everyone also said “thank you”. And this happened mainly due to the fact that we put an equal sign between the variables "moderation" and "modesty." Every Friday we got together and wrote words of gratitude to our users on ordinary cards. I know that many would not be delighted if they were engaged in such things; it was our tradition, which played the largest role in creating a very close-knit team and in working on what is important to us. Everyone constantly remembered what our goal was and why we did what we did. These were simple cards: simple hand-written words, we still applied stickers with a picture of a dinosaur to them.

Interestingly, this practice has entrenched since the early days of Wufoo. Chris, Ryan, and I tried to figure out what we needed to do to show users how we value them during the Christmas holidays; This idea came to Chris’s head and he said: “Guys, a couple of years ago my mother made me write letters of thanks for Christmas presents to all my relatives, and I really didn’t like to do this, but next year I received very cool presents ... therefore I think we should try it out in our business and see what happens. ”

Thus, for that first year, we wrote Christmas cards by hand to all our users. The second year has come, and we had too many clients and only three founders. We thought: "We are at an impasse, we do not know what to do." And so, we read a book called "The Ultimate Question", and in it the author says that we need to focus on the users who bring the most profit; if you take care of them, then everything will work out. Then we thought: “It should work, we can do it.” And in fact, we wrote only to users who paid us more than others.

January came and one of our longtime dedicated users wrote to us. He wrote: “Hello everyone, I really liked that Christmas card that you sent me that year, and I just wanted you to know: I still have not received my second card and I look forward to it; I know that you have not forgotten about me. Many thanks". We were very discouraged by this. The best way to exceed expectations is to not give a reason to them from the very beginning, so that we are in a difficult position. After thinking carefully, we decided that we should stop doing this only once a year; this should happen every week. And even if we do not reach all our users, this habit itself will mean a lot.

I talked a lot about touching moments that developers do not like to think about too often, so in the end I will share more accurate data. There is an article [and also a book ] written by Michael Trisi and Fred Wirsema and published in the Harvard Business Review several years ago; In it, the authors talk about the focus of market leaders. They argue that there are only three ways to achieve market leadership, and depending on how you intend to achieve it, you should organize work in your company in a certain way: you should strive for the best price, creation of a better product or better overall solution.

For the best price, you focus on logistics like Wal-Mart and Amazon. If you want to release the best product, focus on research, the most striking example of this is Apple. A better overall solution means you have to be closer to the customer. You may notice that elite brands, as well as the hotel business, follow this path. What I like about this path to achieving market leadership is that the third is the only one that anyone can implement at any stage in the formation of his company. It almost does not require money to start. As a rule, it only requires a little moderation and good breeding. As a result, you can achieve success in your market, no matter who your competitors are. That's all for me, thanks for your attention.

Audience questions:

How do you create one product that all user categories will eventually love?
Hale: There is an interesting fine line here. I usually advise people to focus on those who like your product more, especially in the early stages. Whatever the niche, it is on them that I will fully focus.

I think Ben Silverman of Pinterest started his business with working with design bloggers. Customize your product for these users, and ultimately you will define universal values ​​that others will share. So just start to work through such groups one after another.

There are many examples of how companies made mistakes in an attempt to "make their application fun." It’s very difficult to introduce humor. If you want to implement something witty, you have to fix the functionality. As with the Japanese concept of quality: if there is no atarimae, do not try to come up with something funny, as this will give the opposite effect.

So, without a doubt, we at Wufoo tried to make the service as easy to use as possible, the rest was not so important.

How to maintain a balance between an obsession with working on a product and other tasks like marketing, etc.?
Hale: When you develop a product, you should always see the other side of the coin - to communicate with users. For us at Wufoo, technical support was a way to communicate with users. They should see first whether the function turned out to be successful or not.

This approach affected everyone in the company, because everyone was in the role of a technical support employee, and everyone had a social incentive to make everything work. In no case should you focus only on the product. You should always have time to pay attention to the product and then find out what your users are telling you - this is a kind of continuous virtual feedback. So be careful if you don’t have one.

My opinion on marketing and sales: it seems to me that marketing and sales is a tax that we pay for not making our product outstanding. Word of mouth is the easiest method of development, and that is how the best of companies develop. Find out how to come up with a story that people would like to tell about your product. So the person who finds out about her will become your seller. This person is a sales manager for you.

How do you make a decision together with a team of engineers about the development of a product in one direction or another?
Hale: We turn to the support service - it is very simple, because this is how you see what problems people face most often. We always receive offers from customers to improve the service.

No matter what your product or application will be, people will definitely want new features from it, so you will be aware of what they need. You, as a programmer, a representative of the company, need not only follow their instructions - otherwise you would be a slave - you must find out what users really want, find out the underlying reason for their need.

If everyone wants to move in different directions, someone should clarify the situation. In addition, create a smaller version of each small idea, the development of which will take no more than 1-2 weeks, so that you can experience it and understand what works and what doesn’t. It is dangerous when you have many directions for the development of a product that require a lot of time to understand them.

Can you tell a story about the role of Caliph for an Hour? The King for a Day] played for Wufoo?
Hale: Yes, I can. So, I do not like hackathons. I think that they are useless (I mean those that are held within companies), since you spend 48 hours working hard on what is most interesting to you, and 99% of this never comes to implementation. This is very sad.

So we got an idea that we called Caliph for an Hour. It was implemented over the weekend. It turned out this way: a random person was selected in the company, and he became a "caliph". "Caliph" was supposed to tell the rest what to do with the product. This concerned everything that worried him at Wufoo, any function that he wanted to implement: he had in his hands the development, marketing, advertising, resources of each employee of the company - everything to realize his ideas.

And, of course, we (the leadership) worked together to understand what we can do in 48 hours. We conducted such a “hackathon" once or twice a year. It was a tremendous impetus and served to boost morale, because people liked most of all to develop what they thought would play a big role in business development.

So for us it was a way to devote time to one of the areas of product development. At times, people who work for you have a strong opinion about how the product should develop. The ability to swap places is a good way to democratize easily.

You said that everything works remotely. But usually this is a nightmare. How did you manage to succeed with this approach?
Hale: We all work remotely, and we all work close to the Tampa Bay area. We could let everyone work wherever he wants, but usually, while we hired a new person and introduced him to the team, he (the new recruit) decided to move here.

Working remotely is not easy. Many people like to idealize this approach, especially the employees themselves, but the fact is that the office provides many advantages and opportunities that you have to compensate for. But remote work also has its advantages. For example, I don’t need to worry that my subordinates will lose two hours of their working time on the road. Therefore, the main thing that we must observe when working remotely is to respect other people's time.

We were able to do this, since we had a week of 4.5 working days in Wufoo; Part-time Friday was set aside for meetings and the like. We told ourselves: no business development meetings, no negotiations with other organizations [on other days]. All should be held on Friday, this short working day; they were forbidden to spend in the middle of the week.

And besides, one day a week each dedicated technical support. It turns out that the employee in our company had only three days a week for effective work, no matter what he did. But, frankly, I firmly believe that if you have three full days of 8-10 hours, when you work only on what you need to do, you can do a lot of work. Therefore, we agreed that we should value everyone’s time during these three days.

We arrived at the idea of ​​fifteen minutes. You can correspond or talk on the phone with someone, but it can last no more than 15 minutes. Therefore, if you have a difficult problem that you cannot solve in these 15 minutes, you need to immediately postpone it so that we discuss it on Friday. Then you take the next task from your list.

I would say that in 90% of cases, the problem never came up on Friday, because usually people put it off until the morning, and then miraculously said: “I found a solution!” Or “Yes, this is not such a big problem.” Most of the problems within the company do not need to be solved right here and right now.

The exceptions are, for example, equipment problems or problems with payments. Everything else, one might say, is impermissible luxury. So focus on your priorities as much as possible: as a result of using this approach, our team of 10 people has done much more than a huge number of other companies.

Our team is incredibly disciplined, and I must say, there are few such companies that have passed YC that could repeat what we did. I think only two companies from YC were able to repeat our discipline maintenance technique. It requires more work of a completely different kind. And often it allows you to behave a little less actively in terms of everything regarding productivity.

How can a manager distribute responsibility among his employees?
Hale: We reached the payback period 9 months after the launch, and we had a program for employee participation in the distribution of profits, which gives them a simple and clear incentive for development. We had many options for issuing bonuses, and evaluating the results was based on how the technical support was carried out, on the basis of fulfilling their duties, and what everyone sought to achieve.

I don’t like the process and mechanisms for helping employees to increase productivity, so the only way we tried to help employees in managing their projects was to draw up a list of tasks. This list was a plain text file, which we shared with Dropbox. Each name was indicated there, and each time it was necessary to monitor when someone updated its contents.

We decided that every evening we write there everything that was done today, and on Friday just watch: “This is what you promised to do last week; that's what you really did. What is the problem here? ”And it is extremely simple.

It turns out that you follow everything that needs to be done, and you do not need to worry about task management. Everyone sets the tone for how he wants to be evaluated. And for those who do an excellent job with everything, working in this way is very easy. And if problems arise, then it’s easier to fire people.

I am glad that I didn’t have to fire anyone from Wufoo, but we could change everyone’s behavior very quickly, because we looked at the list and identified the problem: “Look, this is how you behave. You do your work at the very last minute, etc. These are the facts that you have provided to us. All we have to do is point you to them. ” And due to the fact that everyone in the company sees this, social pressure is created that forces you to improve.

How to hire employees who can work remotely, and how to organize such work?
Hale: Pretty simple: give them work on an additional project. You provide them with contract work, and, in fact, they perform it remotely. Usually, the projects that such candidates should be involved in last about a month - enough time to get a good idea of ​​how people manage their tasks and how to cope with them. For us, this was the main evaluation criterion; we never hired people based on interviews only.

Another point on which we selected employees is their ability to provide technical support, since not every engineer has those empathy skills that help to deal with such “stress”. Therefore, sometimes in an interview I asked people to compose an apology letter in 15 minutes about the impossibility of doing something [for a hypothetical client]. This method allows you to assess the writing skills of the applicant. [They are very important], because in 90% of cases the support service has to give bad news to customers, for example: “I'm sorry, but we don’t support this function”, or “no, it won’t work out like that”, or “this function is not available”.

Are there any tricks and experiments that didn't work in your company?
Hale: I will talk about one case. Some of the things we tried to motivate ourselves at an early stage: in general, we understood that working in an “emergency mode” affects employees very badly. In most cases, tight deadlines can be extremely debilitating.

You may receive an increase in productivity, but the recovery period necessary for workers always lasts longer than the time of productive work. And in a company where it is necessary that everyone is in technical support, he is constantly in service and constantly works on functionality, there is no time for restoration.

Therefore, we decided to organize a vacation for the company, by analogy with the way we annually reward our users. We decided that if we organize a vacation to restore our strength, we can once work in enhanced mode before that, and on vacation we can provide only technical support, which will be affordable for everyone. At first, only three founders worked in such an emergency mode: each had to make a list of 10 tasks with very tight boundaries. The first who will fulfill his seven tasks wins, the latter becomes the so-called "loser" on vacation.

The "loser" must carry someone else's luggage and serve drinks during the holidays. The winner also had to choose a place for the next vacation. And we began to work, and during this time everyone was delighted with this idea. But suddenly Ryan realized that he had poorly distributed tasks on the list. Realizing that he would lose, he simply gave up. So the emergency mode turned out to be dull for him, because he knew that he would lose, and lost all hope. Therefore, in the end, we decided not to carry out such “rumors” anymore. The idea is good, and we love to discuss it, but we never realized it again.

[ Continuation of Startup School at Megamind - translation of a lecture by Stanley Tang and Walker Williams ]

Also popular now: