[Перевод] Кевин Хейл: тонкости в работе с пользовательским опытом (часть 2)
Cтэнфордский курс CS183B: How to start a startup. Стартовал в 2012 году под руководством Питера Тиля. Осенью этого года идет очередная серия лекций:
Сэм Альтман и Дастин Московитц: как и зачем создавать стартап? Сэм Альтман: как сформировать команду и культуру стартапа? Пол Грэм: нелогичный стартап Адора Чьюнг: (часть 1) продукт и кривая честности; (часть 2) growth hacking Питер Тиль: (часть 1) конкуренция — удел проигравших; (часть 2) как построить монополию? Алекс Шульц (часть 1, часть 2, часть 3): введение в growth hacking Кевин Хейл (часть 1, часть 2): тонкости в работе с пользовательским опытом Кевин Хейл: Вообще, мы постоянно проводили опыты над службой поддержки в Wufoo, потому что были буквально «помешаны» на ней. Один из экспериментов, который мы провели, заключался в следующем: мы услышали, как кто-то рассказывает об отсутствии связи между эмоциями, которые у нас возникают, когда нам нужна помощь, и удовлетворением и той реакцией, которую мы получаем от людей, когда помогаем им.Особенно часто эта связь отсутствует в сети, так как мы просто не видим этих невербальных сигналов. Так вот, по мнению автора этой идеи, между нами и пользователями никогда не возникнет отношений, пока в сети не появится распознавание лиц.
Мы подумали: «Мы не эксперты в области распознавания лиц, но нам кажется, что есть другой способ разглядеть сочувствие». Поскольку мы создавали конструкторы форм, мы добавили выпадающий список под названием «Что вы сейчас чувствуете?». Мы считали, что никто не будет им пользоваться и думали, это будет бесполезный эксперимент, но решили посмотреть, что получится.
Оказалось, что это поле заполнялось в 75.8% случаев. Для сравнения: поле с выпадающим списком «Тип Браузера» заполнялось в 78.1% случаев. То есть, фактически люди говорили нам: «В случае с моей проблемой, то, что я чувствую, так же важно, как и технические особенности, которые нужно знать, чтобы устранить баг».
Мы не приоритезировали задачи исходя из эмоций тех, кто к нам обращался, поэтому большинству клиентов не удавалось таким образом «переиграть» систему. Мы заметили, что одно из интересных побочных явлений этого эксперимента — то, что люди стали относиться к нам лучше. Мы вернулись к работе и взглянули на данные, провели анализ текста и поняли, что в письменном общении, например, по электронной почте, есть всего три способа выразить яркие эмоции: восклицательные знаки, ругательства, и прописные буквы. Определенно [по результатам эксперимента], каждый из трех этих показателей снизился при общении с нами через службу поддержки. Как только у людей появился способ выразить эмоции, они стали рассуждать более рационально и в результате сделали нашу работу более приятной.
Другим неожиданно потрясающим результатом стало то, что такой подход помогает вам создавать более качественное ПО. И это подтверждается целым рядом исследований. Джаред Спул, проектировщик пользовательских интерфейсов (один из крупнейших экспертов в своей области) утверждает, что существует прямая зависимость между тем, сколько времени мы проводим, общаясь с пользователями напрямую, и качеством полученного дизайна.
Он считает, что процесс проектирования должен происходить именно так. Общение должно быть открытым. Нельзя делать выводы исключительно на основе отчетов или графиков. Вы должны взаимодействовать с клиентами в режиме реального времени. Такое общение должно проходить минимум каждые шесть недель и длиться не менее двух часов; в противном случае ваше ПО будет ухудшаться с течением времени. Наши разработчики напрямую общаются с пользователями по 4–8 часов каждую неделю. Это меняет наш взгляд на создание ПО.
Джаред Спул предлагает по-другому взглянуть на то, как мы создаем продукты. Представьте, что на этом спектре [на слайде выше] отображен весь объем знаний, необходимых для того, чтобы пользоваться приложением. Крайнее левое значение — полное отсутствие знаний, крайнее правое — все необходимые знания. А эти две поперечные линии отражают суть вашего взаимодействия с пользователем. Поперечная линия слева показывает текущий уровень знаний пользователей, а поперечная линия справа — то, к какому уровню знаний вы хотите их подвести.
Разрыв между ними, согласно Спулу, называется «knowledge gap». Что интересно, есть два способа его устранить. Вы либо предоставляете пользователю больше знаний, либо сокращаете количество требуемых знаний для пользования приложением. И зачастую мы, как инженеры, те, кто, работает над созданием продуктов, думаем: «Давайте-ка добавим новых функций». Но новые функции ведут только к увеличению этого разрыва.
Что же касается нас, то мы сосредоточили усилия на другом направлении. 30% времени, которое тратилось на разработку, мы использовали для создания внутренних инструментов помощи службе поддержки. Но зачастую это время тратилось на то, чтобы люди помогали себе сами. Например, мы создавали страницы с часто задаваемыми вопросами, всплывающие подсказки, делали так, чтобы по нажатию на ссылку Help вместо перехода на страницу с общей справочной документацией вы попадали на конкретную страницу с информацией, наиболее релевантной тому, над чем вы работаете.
Мы снова и снова меняли дизайн нашей документации, постоянно проводили A/B-тестирование. Одна из итераций по работе над страницей документации уменьшила объем нагрузки на техническую поддержку на 30% за сутки. Это один из тех случаев, когда за день у всех, кто работает над продуктом, вдруг стало на 30% меньше нагрузки.
Что происходит, если каждый непрерывно работает в технической поддержке? Я говорил в самом начале, что развитие — это функция, зависящая от конверсии и «текучки». Это — кривая роста Wufoo за первые пять лет [слайд выше]. Интересно то, что мы не платили за рекламу и маркетинг; весь этот рост был обеспечен самими подписчиками.
Разница между количеством новых пользователей и отписавшихся от услуг крайне мала, и это очень важно. Многие все еще забывают о том, что нет практически никакого различия между увеличением конверсии на 1% и уменьшением «текучки» на 1%; они абсолютно одинаково влияют на ваш рост; однако последнее, в действительности, осуществить гораздо проще и гораздо дешевле. И мы очень часто пренебрегаем этим, пока разница не станет слишком большой. Обычно этими задачами занимаются не самые основные сотрудники компаний.
Этот график, честно говоря, не из тех, за которыми мы особо следим в Wufoo, даже не из тех, которыми я горжусь. Вот один из тех, которыми я горжусь [слайд ниже], потому что, несмотря на то, что у нас есть хорошая, замечательная кривая роста, вот что позволило нам масштабироваться, оставаясь небольшой компанией с потрясающей культурой. И это потребовало от нас выполнения множества задач, направленных на то, чтобы реализовывать потребности наших пользователей.
Джон Готтман заметил, что есть и другая разновидность поведения в отношениях, приводящая к разводам. В сущности, оказалось, что есть подгруппа людей, живущих вместе по 10–15 лет, а потом вдруг подающих на развод. Ни один из показателей не говорит о том, что это произойдет. Готтман просмотрел данные и понял: «Хм, между этими людьми нет страсти, нет огня». Отношения в каком-то смысле следуют второму закону термодинамики: в закрытой энергосистеме все стремится к разрушению, поэтому вам постоянно приходится прикладывать энергию и усилия, чтобы вернуть ее в первоначальное состояние.
Многие считают, что показывать людям, как «они дороги компаниям», нужно, создавая, например, блог или новостную рассылку. Мы оценили наши показатели, и оказалось, что процент активных пользователей, вообще говоря, был небольшим;, а большинство из них понятия не имели о тех потрясающих возможностях, которые мы могли им предоставить.
Поэтому мы создали новую функцию и назвали ее Системой оповещения Wufoo [англ. Wufoo Alert System]. Она позволяла нам отмечать по времени каждую новую функцию, введенную для пользователей, и каждый раз, когда те открывали приложение, мы смотрели на разницу во времени между моментом их авторизации или последним подключением и моментом введения новых функций, после чего пользователи получали такое всплывающее сообщение: «Привет, пока тебя не было, в Wufoo появились классные возможности».
Без сомнения, это нововведение было самым обсуждаемым, и я слышал о нем каждый раз, когда общался с пользователями. Они говорили что-то вроде: «мне нравится эта функция «Привет, пока тебя не было…». Хоть я и плачу одну и ту же сумму ежемесячно, вы что-то делаете для меня чуть ли не каждую неделю. Это просто потрясающе, я прямо чувствую, что получаю от сервиса максимум пользы».
Помимо того, что каждый оказывал поддержку тем, кто платил по счетам, каждый еще и говорил «спасибо». И так происходило в основном благодаря тому, что мы ставили знак равенства между переменными «умеренность» и «скромность». Каждую пятницу мы собирались вместе и писали на обыкновенных карточках слова благодарности нашим пользователям. Знаю, что многие были бы не в восторге, если бы занимались такими вещами; это было нашей традицией, сыгравшей наибольшую роль в создании очень сплоченной команды и в работе над тем, что для нас важно. Все постоянно помнили, какова наша цель и зачем мы делали то, что делали. То были незамысловатые карточки: простые написанные от руки слова, мы еще прикладывали к ним наклейки с изображением динозавра.
Интересно, что эта практика закрепилась с первых дней создания Wufoo. Крис, Райан и я пытались понять, что нам нужно сделать, чтобы показать пользователям, как мы их ценим, во время рождественских праздников; Крису пришла в голову эта идея, и он сказал: «Ребята, пару лет назад моя мама заставила меня написать письма благодарности за подарки на Рождество всем родственникам, и мне очень не понравилось этим заниматься, но в следующем году я получил очень классные подарки… поэтому мне кажется, нам стоит опробовать это в нашем деле и посмотреть, что получится».
Таким образом, за тот первый год мы написали от руки рождественские открытки всем нашим пользователям. Наступил второй год, а у нас было слишком много клиентов и всего три основателя. Мы думали: «Мы в тупике, мы не знаем, что делать». И вот, мы прочитали книгу под названием «The Ultimate Question», и в ней автор говорит о том, что нужно сосредоточиться на пользователях, приносящих наибольшую прибыль; если позаботитесь о них, то все получится. Тогда мы подумали: «Должно сработать, это нам по силам». И в самом деле, мы написали только пользователям, которые платили нам больше других.
Наступил январь, и нам написал один из наших давних преданных пользователей. Он писал: «Привет всем, мне очень понравилась та рождественская открытка, которую вы мне прислали в том году, и я просто хотел, чтобы вы знали: я все еще не получил свою вторую открытку и жду ее с нетерпением; я знаю, что вы про меня не забыли. Большое спасибо». Нас это здорово обескуражило. Лучший способ превысить ожидания — не давать повода к ним с самого начала, так что мы попали в затруднительное положение. Хорошенько подумав, мы решили, что нужно прекратить заниматься этим только раз в году; это должно происходить каждую неделю. И даже если мы не охватим всех наших пользователей, сама эта привычка будет значить многое.
Я много говорил о трогательных моментах, о которых разработчики не любят задумываться слишком часто, поэтому в конце я поделюсь более точными данными. Есть статья [а еще и книга], написанная Майклом Триси и Фредом Вирсемой и выпущенная в Harvard Business Review несколько лет назад; в ней авторы рассказывают о направленности лидеров рынка. Они утверждают, что существует лишь три способа достижения лидерства на рынке, и в зависимости от того, как вы собираетесь его достичь, вы должны организовать работу в своей компании определенным образом: вы должны стремиться к лучшей цене, созданию лучшего продукта или лучшего общего решения.
Для достижения лучшей цены вы сосредотачиваете внимание на логистике, как Wal-Mart и Amazon. Если хотите выпускать лучший продукт, сосредотачиваетесь на научных исследованиях, самый яркий тому пример — Apple. Лучшее общее решение означает, что вы должны быть ближе к клиенту. Можно заметить, что этому пути следуют элитные бренды, а также гостиничный бизнес. Что мне нравится в этом пути к достижению лидерства на рынке, это то, что третий — единственный, который может реализовать каждый на любом этапе становления своей компании. Он почти не требует денег для старта. Как правило, он лишь требует немного умеренности и воспитанности. Как результат, вы сможете достичь успеха на своем рынке, кем бы ни были ваши конкуренты. На этом у меня все, спасибо за внимание.
Вопросы аудитории: Как вы создаете один продукт, который в итоге полюбят все категории пользователей? Хейл: Здесь есть интересная тонкая грань. Обычно я советую людям сосредоточиться на тех, кому ваш продукт нравится больше, особенно на ранних стадиях. Какая бы это ни была ниша, именно на них я полностью сосредоточу внимание.Думаю, Бен Сильверман из Pinterest начал свой бизнес с работы с блоггерами из сферы дизайна. Подстраивайте свой продукт под таких пользователей, и в конечном итоге вы определите универсальные ценности, которые будут разделять и другие. Поэтому просто начинайте последовательно прорабатывать такие группы одну за другой.
Есть множество примеров того, как компании допускали ошибки, в попытке «сделать свое приложение забавным». Юмор внедрить очень сложно. Если хотите реализовать что-то остроумное, придется наладить функционал. Как c японским понятием качества: если нет atarimae, не пытайтесь придумать что-то смешное, так как это даст обратный эффект.
Так что, без сомнения, мы в Wufoo стремились в первую очередь сделать сервис максимально простым в использовании, остальное было уже не так важно.
Как сохранить баланс между одержимостью в работе над продуктом и другими задачами как маркетинг и т.д.? Хейл: Когда вы разрабатываете продукт, всегда следует видеть обратную сторону медали — общаться с пользователями. Для нас в Wufoo способом общения с пользователями была служба технической поддержки. Они должны видеть первыми, удачная получилась функция или нет.Такой подход повлиял на каждого в компании, потому что каждый побывал в роли сотрудника технической поддержки, и у всех был социальный стимул делать так, чтобы все работало. Ни в коем случае не стоит зацикливаться только на продукте. У вас всегда должно быть время уделить внимание продукту и потом узнать, что вам говорят ваши пользователи — это своего рода непрерывная виртуальная обратная связь. Так что будьте осторожнее, если у вас ее нет.
Мое мнение о маркетинге и продажах: мне кажется, маркетинг и продажи — это налог, который мы платим за то, что не сделали наш продукт выдающимся. Сарафанное радио — самый легкий метод развития, и именно так развиваются лучшие из компаний. Выясните, как придумать историю, которую люди хотели бы рассказывать о вашем продукте. Так человек, который о ней узнает, станет вашим продавцом. Этот человек для вас — менеджер по продажам.
Как вы принимаете решение вместе с командой инженеров по поводу развития продукта в том или ином направлении? Хейл: Мы обращаемся к службе поддержки — это очень просто, потому что так ты видишь, с какими проблемами люди сталкиваются чаще всего. Мы всегда получаем от клиентов предложения по улучшению сервиса.Неважно, каким будет ваш продукт или приложение, люди обязательно захотят от него новых возможностей, так что вы будете в курсе того, что им нужно. Вам, как программисту, представителю компании, надо не просто следовать их указаниям — иначе вы были бы рабом — вы должны выяснить, чего пользователи хотят на самом деле, узнать базовую причину их потребности.
Если все хотят двигаться в разных направлениях, кто-то должен прояснить ситуацию. Помимо этого, создайте уменьшенную версию каждой небольшой идеи, на разработку которой уйдет не более 1–2 недель, чтобы можно было ее испытать и понять, что получается, а что нет. Опасно, когда у вас есть множество направлений для развития продукта, требующих много времени на то, чтобы в них разобраться.
Можете рассказать историю о том, какую роль «Калиф на час» [англ. The King for a Day] сыграл для Wufoo? Хейл: Да, могу. Итак, я не люблю хакатоны. Я думаю, что они бесполезны (я имею в виду те, что проводятся внутри компаний), так как ты тратишь 48 часов, усердно работая над тем, что для тебя интереснее всего, и 99% от этого так никогда и не доходит до реализации. Это очень печально.Поэтому нам пришла идея, которую мы назвали «Калиф на час». Она реализовывалась в течение выходных. Получилось так: выбирался случайный человек в компании, и он становился «калифом». «Калиф» должен был указывать остальным, что делать с продуктом. Это касалось всего, что его беспокоило в Wufoo, любой функции, которую ему хотелось внедрить: у него в руках были разработка, маркетинг, реклама, ресурсы каждого сотрудника компании — все, чтобы реализовать свои задумки.
И, естественно, мы (руководство) работали сообща, чтобы понять, что мы можем сделать за 48 часов. Мы проводили такой «хакатон» один-два раза в год. Он был огромным толчком и служил для подъема боевого духа, потому что людям больше всего нравилось разрабатывать то, что, как им казалось, сыграет большую роль в развитии бизнеса.
Так что для нас это был способ выделить время на одно из направлений развития продукта. Временами у людей, которые на тебя работают, появляется твердое мнение по поводу того, как должен развиваться продукт. Возможность поменяться местами — хороший способ легкой демократизации.
Вы сказали, что все работаете дистанционно. Но обычно это — кошмар. Как вам удалось прийти к успеху с таким подходом? Хейл: Мы все работаем дистанционно, и мы все работаем недалеко от района Tampa Bay. Мы могли бы позволить каждому работать, где ему захочется, но обычно, пока мы нанимали нового человека и знакомили его с командой, он (новобранец) принимал решение переехать сюда.Работать удаленно очень непросто. Многие любят идеализировать такой подход, особенно сами сотрудники, но суть в том, что офис дает много преимуществ и возможностей, которые вам приходится компенсировать. Но у удаленной работы тоже есть свои плюсы. К примеру, мне не нужно беспокоиться, что мои подчиненные потеряют два часа своего рабочего времени на дорогу. Поэтому главное, что мы должны соблюдать при дистанционной работе — это уважать чужое время.
Мы смогли это осуществить, так как у нас в Wufoo была неделя из 4,5 рабочих дней; неполный рабочий день в пятницу был отведен на совещания и тому подобное. Мы сказали себе: никаких совещаний по развитию бизнеса, никаких переговоров с другими организациями [в остальные дни]. Все они должны быть проведены в пятницу, в этот короткий рабочий день; их запрещено было проводить посреди недели.
И кроме того один день в неделю каждый посвящал технической поддержке. Получается, у сотрудника в нашей компании было лишь три дня в неделю для эффективной работы, чем бы он ни занимался. Но, честно говоря, я твердо верю, что, если у тебя есть три полноценных дня по 8–10 часов, когда ты работаешь только над тем, что тебе нужно выполнить, ты можешь сделать море работы. Поэтому мы договорились, что должны ценить время каждого в течение этих трех дней.
Мы пришли к идее пятнадцати минут. Вы можете переписываться или говорить по телефону с кем-то, но это может длиться не более 15 минут. Поэтому, если у вас возникла сложная проблема, которую вы не можете разрешить за эти 15 минут, вам нужно немедленно отложить ее, чтобы мы обсудили ее в пятницу. Затем вы берете следующую задачу из своего списка.
Я бы сказал, в 90% случаев, проблема никогда не поднималась в пятницу, так как обычно люди откладывали ее до утра, а затем чудесным образом говорили: «А я нашел решение!» или «Да это совсем не такая большая проблема». Большую часть проблем внутри компании не нужно решать прямо здесь и прямо сейчас.
Исключение составляют, например, неполадки с оборудованием или проблемы с выплатами. Все остальное, можно сказать, непозволительная роскошь. Так что сосредоточьтесь на своих приоритетных задачах, насколько это возможно: в результате использования такого подхода наша команда из 10 человек сделала гораздо больше, чем огромное число других компаний.
Наша команда невероятно дисциплинированна, и, должен сказать, существует немного таких компаний, прошедших YC, которые смогли бы повторить то, что сделали мы. Думаю, всего лишь две компании из YC сумели повторить нашу технику поддержания дисциплины. Она требует больше работы совсем другого рода. И часто позволяет вести себя чуть менее активно в плане всего, что касается продуктивности.
Как менеджеру распределить ответственность между своими работниками? Хейл: Мы вышли на окупаемость через 9 месяцев после запуска, и у нас была программа участия сотрудников в распределении прибыли, которая дает им простой и ясный стимул к развитию. У нас было множество вариантов выдачи премий, и оценка результатов производилась на основе того, как выполнялась техническая поддержка, на основе выполнения своих обязанностей, и того, чего каждый стремился достичь.Мне не нравится процесс и механизмы помощи работникам в повышении продуктивности, поэтому единственное, чем мы старались помочь сотрудникам в управлении своими проектами — составление списка задач. Таким списком был обычный текстовый файл, к которому мы открывали доступ в Dropbox. Там было указано имя каждого, и нужно было каждый раз следить, когда кто-то обновлял его содержимое.
Мы решили, что каждый вечер мы пишем туда всё, что сегодня было сделано, а в пятницу просто смотрим: «Вот, что вы обещали сделать на прошлой неделе; вот, что вы действительно сделали. В чем здесь проблема?» И это чрезвычайно просто.
Получается, что следишь за всем, что необходимо выполнить, и не нужно волноваться по поводу управления задачами. Каждый сам задает тон тому, как он хочет, чтобы его оценивали. А для тех, кто отлично со всем справляется, работать подобным образом очень легко. И если возникают проблемы, то так людей и уволить проще.
Я рад, что мне не пришлось никого увольнять из Wufoo, но мы могли очень быстро изменить поведение каждого, потому что смотрели на список и определяли проблему: «Смотри, вот так ты себя ведешь. Ты выполняешь свою работу в самую последнюю минуту и т.д. Это факты, которые ты нам предоставил. Все, что мы должны сделать, это указать тебе на них». И из-за того, что все в компании это видят, создается социальное давление, которое заставляет тебя исправиться.
Как нанимать сотрудников, которые могут работать удаленно, и как организовать такую работу? Хейл: Довольно просто: дайте им работу по дополнительному проекту. Вы предоставляете им работу по контракту, и, по сути, они выполняют ее удаленно. Обычно проекты, которыми такие кандидаты должны заниматься, длятся около месяца — достаточно времени, чтобы получить хорошее представление о том, как люди управляют своими задачи и как с ними справляются. Для нас это было основным критерием оценки; мы никогда не нанимали людей лишь на основании интервью.Еще один пункт, по которому мы отбирали сотрудников — их способность осуществлять техническую поддержку, так как не каждый инженер обладает теми навыками сочувствия, которые помогают бороться с таким «стрессом». Поэтому иногда на интервью я просил людей за 15 минут сочинить письмо с извинениями о невозможности сделать что-то [для гипотетического клиента]. Такой способ позволяет оценить навыки письменной речи соискателя. [Они очень важны], потому что в 90% случаев службе поддержки приходится сообщать клиентам плохие новости, например: «простите, но мы не поддерживаем данную функцию», или «нет, так сделать не получится», или «эта функция недоступна».
Есть ли какие-то хитрости и эксперименты, которые в вашей компании не сработали? Хейл: Я расскажу об одном случае. Кое-что из того, чем на раннем этапе мы пытались мотивировать себя: в целом, мы понимали, что работа в «авральном режиме» очень плохо сказывается на сотрудниках. В большинстве случаев жесткие сроки могут быть крайне изнурительными.Возможно, вы получите прирост в продуктивности, но период восстановления, необходимый для работников, всегда длится дольше, чем время продуктивной работы. А в компании, где нужно, чтобы каждый находился в технической поддержке, был постоянно в строю и постоянно работал над функционалом, нет времени на восстановление.
Поэтому мы придумали организовать для компании отпуск по аналогии с тем, как мы ежегодно поощряем своих пользователей. Мы решили, что если организуем отпуск для восстановления сил, то cможем один раз поработать в усиленном режиме перед этим, а в отпуске осуществлять только техническую поддержку, которая будет всем по силам. В таком авральном режиме работали поначалу только трое основателей: каждый должен был составить список из 10 задач с очень жесткими рамками. Первый, кто выполнит свои семь задач, побеждает, последний становится так называемым «неудачником» на отдыхе.
«Неудачник» должен носить чужой багаж и подавать напитки во время отпуска. Победитель также должен был выбрать место для следующего отпуска. И мы начали работать, и в течение этого времени все были в восторге от этой идеи. Но вдруг Райан понял, что плохо распределил задачи в списке. Осознав, что проиграет, он просто сдался. Так что авральный режим оказался для него унылым, потому что он знал, что проиграет, и потерял все надежды. Поэтому в итоге мы решили больше не проводить таких «авралов». Идея хорошая, и мы любим ее обсуждать, но больше мы никогда ее не реализовывали.
