«Срабатывает только 15% идей»: о продуктовом подходе в неайтишных отделах
Когда в 2013 году разработчик Михаил Карпов увидел вакансию руководителя интернет-проектов в Яндексе, он решил, что сделает все, чтобы ее получить. Для этого Михаил три месяца выполнял тестовое задание — провел исследования зарубежных и российских продуктов, опросил пользователей сервисов, похожих на Яндекс, и составил план работ для всего отдела на полтора года вперед. Такой подход к тестовому заданию настолько впечатлил компанию, что Михаила без опыта работы на руководящей должности взяли управлять одним из интернет-проектов в Яндексе.
Коротко о проектах Михаила Карпова
Продуктовый подход проник в неайтишные компании и отделы с двух сторон
В бизнесе часто бывает так: предпринимателю в голову приходит гениальная идея, он вкладывает в нее деньги, команда год над ней работает и никому ее не показывает. А потом оказывается, что продукт не нужен людям, и компания терпит убытки. Чтобы такого не происходило, лучше действовать постепенно. Например, проверить свою идею на части аудитории, и если она нерабочая, то скорректировать или заменить ее.
Я руководил сервисом «Яндекс Работа» — там мы помогали людям находить вакансии. Перед нашей командой стояла задача сделать новую версию сайта. Мы разрабатывали его около двух месяцев, а затем провели тест и показали нескольким десяткам пользователей. Мы попросили их воспользоваться сервисом и попробовать найти вакансию.
Оказалось, что некоторые из участников теста не умели пользоваться пробелом на клавиатуре. Например, писали так: работаводителемвмоскве. Наш сайт не распознавал написание без пробелов и выдавал ошибку на странице. Этот момент мы не могли предугадать, и если бы сразу же без теста запустили сайт, то спугнули бы часть аудитории, которая не смогла бы пользоваться нашим сервисом. На переделку сайта у нас ушло еще две недели, зато мы не потеряли часть пользователей и, соответственно, денег.
Мы обезопасили себя тем, что применили продуктовый подход. Он заключается в создании какой-то ценности для пользователя следующим образом:
- перед тем как вывести на рынок новый продукт, компания проводит исследование потребностей целевой аудитории;
- затем выдвигает гипотезу и тестирует ее;
- оценивает результаты, чтобы проверить жизнеспособность решения;
- если гипотеза не оправдалась, то ее корректируют или меняют, затем опять тестируют и оценивают результаты;
- и только если результат теста оправдан, продукт вводят в работу.
Такой подход —- отличный способ проверить идею и снизить риски. Еще пять-семь лет назад его использовали только ИТ-проекты — он помогал им увеличивать количество пользователей и выручку скачками несколько раз в год. Это заметили компании, которые отслеживали тренды и инновации и пробовали применять их у себя — в других сферах бизнеса. Такие неайтишные компании стали изучать кейсы успешных ИТ-стартапов — смотреть финансовую отчетность и общаться с их руководителями, чтобы понять, в чем заключается секрет столь стремительного и, главное, стабильного роста. Когда они поняли, что одна из причин — это продуктовый подход, то решили взять его на вооружение и применять у себя.
Параллельно на рынке шел процесс увеличения количества продакт-менеджеров, которые увольнялись из ИТ-компаний и переходили на работу в другие отрасли. Например, в компании «СДЭК», «Спортмастер», «М.Видео» — там они начали строить продуктовые отделы. Так продуктовый подход проник в неайтишный бизнес с двух сторон — со стороны следящего за трендами руководства и через новых сотрудников-продактов. Все это привело к тому, что примерно с 2021 года российский бизнес постепенно стал использовать инструменты продуктового подхода для развития разных направлений в компании — в своих коммерческих, маркетинговых и HR-отделах.
Всегда нужно думать со стороны пользователя
В 2018 году я перешел на работу директором по продукту в Skyeng. Моей задачей было сделать так, чтобы продуктовый подход распространился по всей компании, а не концентрировался только в ее ИТ-направлении. Я начал плотно взаимодействовать с руководителями разных департаментов и отделов и объяснять, чем наш подход может быть полезен. Например, вместе нам удалось улучшить работу HR-направления.
Skyeng — быстрорастущая компания, и ей постоянно требовалось расширять штат. HR-отдел был завален жалобами от других департаментов, потому что нанимал в два раза меньше специалистов, чем было нужно. Из-за этого сотрудники не могли выполнять свои задачи, компания буксовала и недополучала деньги.
Особенно остро дефицит кадров ощущался среди разработчиков. Простым решением было взять больше HR-специалистов, которые могли бы нанимать большее количество людей. Но это требовало дополнительных расходов, к тому же было непонятно, сколько именно людей нужно и насколько эта мера окажется эффективной. Поэтому мы пошли другим путем — использовали продуктовый подход.
Чтобы понять, в чем именно состоит проблема, мы оцифровали данные: узнали, сколько людей откликается на вакансии и доходит до разных этапов собеседований, а еще скольким людям компания делает оффер и какой процент отказывается. Выяснилось, что показатель отказов составлял 60% — более половины кандидатов отклоняли предложения о приеме на работу и уходили в другие компании.
Затем мы использовали один из основных инструментов продуктового подхода — посмотрели на процесс найма глазами пользователя. Для этого составили CJM, customer journey map — карту пути клиента. В данном случае клиентом выступал потенциальный кандидат на вакансию разработчика. Мы полностью расписали процесс найма и замерили, сколько времени кандидат проводит на каждом этапе. Нашей целью было понять, почему такой высокий процент разработчиков отказывается от оффера, что их смущает и отпугивает. CJM помогла нам понять, что процесс найма в компании слишком многоступенчатый и между каждой ступенью проходит одна-две недели. В итоге весь процесс найма растягивался на полтора-два месяца. Мы предположили, что кандидатов не устраивал такой затяжной наем и поэтому они сливались.
Чтобы удостовериться в том, что наша гипотеза правдива, мы провели кастдевы — организовали пятнадцатиминутные созвоны с кандидатами, которым сделали оффер и они его отклонили. Так мы выяснили, что эти кандидаты не хотели несколько месяцев ждать оффера и сидеть без денег, а в других компаниях им отвечали быстрее. Затяжные ответы со стороны Skyeng они связывали с нежеланием компании нанимать именно их, а не с завалом в HR-отделе и процессом найма, который трещит по швам.
Так мы посмотрели на ситуацию глазами пользователя, узнали о его болях и перестроили процесс найма:
- сократили этап рассмотрения резюме с пяти-семи дней до двух. Для этого наняли еще одного HR-специалиста;
- сократили количество собеседований.
Этими мерами мы снизили показатель отказов от оффера с 60 до 20%.
Основные ошибки на этапе общения с пользователями — поторопиться, поговорить с недостаточным количеством людей и принять неверное решение. Например, в Яндексе мы дорабатывали функциональность Поиска. У меня была идея, и я так в нее верил, что пообщался всего с двумя пользователями, услышал от них то, что хотел, и на этом успокоился. А когда мы ее реализовали, то оказалось, что она нерабочая, пришлось срочно все переделывать. Если бы я пообщался не с двумя, а с двадцатью пользователями, то не совершил бы эту ошибку и компания не понесла бы финансовые убытки.
Чтобы не ошибиться, нужно разговаривать с разумным количеством людей. Так увеличится вероятность того, что гипотеза оправдается. Здесь основное правило: ты должен общаться с людьми, пока не почувствуешь, что они говорят про одну и ту же проблему. Этим способом можно еще и отсечь «крикунов» — самых активных и громко выражающих свое мнение клиентов. Такие есть всегда, они охотнее всех идут на контакт и дают наиподробнейшую обратную связь, но она может не отражать мнение большинства.
Рассылка: как вести бизнес в России
Каждую неделю присылаем самые важные новости бизнеса, разборы законов и инструкции, которые помогут вести свое дело
Гибкий подход — подстраховка от провала
ИТ-компании придерживаются методологии гибкой разработки, или Agile. Она заключается в следующем: если ты что-то придумал, нужно как можно раньше показать первую версию людям. И в зависимости от обратной связи доработать идею, а затем снова и снова тестировать промежуточные версии. Мы называем это итерациями. Такой гибкий подход снижает риск ошибок и увеличивает вероятность того, что готовый продукт окажется востребованным на рынке.
Методология Agile применима и к созданию неайтишных продуктов для внутренних отделов компаний, потому что помогает приходить к намеченным целям и при этом экономить время и деньги компании.
В Skyeng мы вместе с командой HR создавали новые переговорные комнаты для сотрудников. Выделенная площадь была небольшой, поэтому нам нужно было сделать ее максимально функциональной. Мы решили использовать принципы продуктового подхода и действовать гибко:
- Вначале сотрудники HR-отдела посмотрели, что собой представляют переговорки у крупнейших российских компаний, например у Яндекса и Авито, пообщались с руководителями их HR-направлений и собрали лучшие практики — узнали, какое у них оборудование, планировка, что им нравится и чего не хватает.
- Затем поговорили с сотрудниками Skyeng и выяснили, для чего и как часто им нужны комнаты для переговоров, сколько человек в них обычно собирается. Еще узнали у команды, чем ей нравятся те переговорки, которые уже есть, и что в них можно было бы изменить. Так мы поняли, что сотрудникам нужно побольше небольших помещений, куда вмещалось бы всего несколько человек, и несколько больших переговорок.
- И дальше мы использовали методологию Agile: расчертили помещение и построили временные перегородки, которые можно было двигать. Затем установили в них всю необходимую мебель и оборудование и смотрели, какой размер комнаты будет удобен сотрудникам. Нашей целью было создать как можно больше маленьких переговорок, и при этом чтобы в них не было тесно определенному количеству людей. Мы попросили сотрудников бронировать время в тестовых переговорках и смотрели, сколько человек туда приходит. Так мы несколько раз двигали перегородки, пока не нашли оптимальный вариант — две большие переговорки и около десяти маленьких, рассчитанных на двух-трех человек. Они нужны были сотрудникам, чтобы быстро обсудить рабочие моменты и не отвлекать коллег в опенспейсе.
Если бы мы сразу без теста сделали переговорки с бетонными стенами, то, скорее всего, оказалось бы, что три человека на час занимают единственную большую переговорную комнату и еще несколько коллег ждут под дверью, когда она освободится. Но что-то изменить уже было бы сложно, люди работали бы менее эффективно, и это сказывалось бы на результатах компании.
Гибкий подход при создании нового продукта мы использовали и в коммерческом отделе Skyeng. Руководитель отдела столкнулся с проблемой: он хотел увеличить продажи и создал новый скрипт — расписанный план беседы с потенциальным покупателем. Этот скрипт сразу же стали применять все менеджеры: они работали так неделю, и в итоге продажи упали на 30—40%. У Skyeng большая часть выручки шла именно через отдел продаж, когда менеджеры обзванивали потенциальных клиентов и предлагали им курсы, а те с помощью банковской карточки почти сразу их оплачивали. Поэтому из-за неудачного скрипта компания сразу же потеряла миллионы выручки.
Чтобы не повторять неудачный опыт, руководитель отдела продаж обратился к нам в отдел продукта, и вместы мы решили попробовать использовать продуктовый подход. С командой они доработали новый скрипт, но мы ввели его в работу только экспериментальной группы, в которую включили всего 5% от общего числа менеджеров. Если бы у них что-то не получилось, компания не понесла бы большие финансовые потери, а сам скрипт можно было бы снова доработать. Так мы сделали первую итерацию: обучили новому скрипту десять менеджеров по продажам, и они неделю его использовали. Затем сравнили их результаты с результатами сотрудников, которые работали по старым скриптам. Когда мы заметили, что новый скрипт снова не работает, то опять его скорректировали. Всего было около пяти итераций, пока мы не увидели, что экспериментальная группа показывает самые лучшие результаты. Мы тестировали скрипты около трех месяцев, и когда нашли лучший вариант, то обучили ему остальных сейлзов и раскатали продукт — скрипт — на весь отдел.
Но есть сложность, которая отличает создание офлайновых продуктов. Это человеческий фактор: в «живом» мире сложнее прогнозировать результаты. В ИТ ты запрограммировал машину, и она работает. Люди же часто ведут себя непредсказуемо. Например, Skyeng может решить, что все его 10 000 учителей со следующей недели должны вести уроки в белых рубашках. У 500 из них такой одежды может не оказаться, и они проведут уроки в рубашках другого цвета, а кто-то придет в свитшоте или даже тельняшке.
Плюс нужно учитывать, что у людей может быть плохое настроение или самочувствие, в их жизни могут происходить события, как позитивные, так и негативные, которые влияют на их работу. Например, ребята из отдела продаж так долго работали по старым скриптам, что они им надоели. Сотрудники настолько обрадовались новому плану беседы, что на энтузиазме в первую неделю напродавали на 50% больше курсов. А когда их энтузиазм спал, оказалось, что сам скрипт нерабочий. Поэтому важно определенное время смотреть за результатами — от нескольких недель до пары месяцев в зависимости от ситуации.
Только цифры говорят правду
Один из основных принципов продуктового подхода — это только цифровая оценка результатов. Это важно, потому что без аналитики можно принять неверное решение, основываясь лишь на ощущениях, отзывах или собственном видении. Здесь в игру вступают аналитические отделы, которые помогают посчитать и сказать, насколько текущая версия продукта рабочая и сколько она приносит денег.
Когда в Skyeng внедряли новый скрипт, команда коммерческого отдела поставила задачу департаменту аналитики изучить следующие цифры: количество звонков, продаж и продолжительность теста. Так они увидели, что два звонка привели к одной продаже — это хороший результат. Двадцать звонков — к пяти продажам, результат получился уже хуже. Затем проанализировали 2 000 звонков и поняли, что скрипт нужно доработать. Без подробной аналитики можно было принять неверное решение.
Особую сложность для аналитики представляют продукты отдела маркетинга. Там часто ориентируются на отзывы и комментарии в приложениях, соцсетях и на сайтах. Например, отдел маркетинга разрабатывает новую рекламную кампанию и в ее рамках создает новый дизайн дебетовой карты. Руководство в восторге, потому что карта получилась стильной, а на планерках сотрудники отдела маркетинга показывают скриншоты писем благодарных пользователей. Но потом может оказаться, что карту с новым дизайном стали реже заказывать. Поэтому финальное решение по продукту нужно принимать только на основании цифр.
Когда я работал в Яндексе, компания запускалась в Турции. Чтобы быстрее там развернуться, отдел маркетинга придумал рекламную кампанию: организовал розыгрыш Lamborghini среди тех, кто скачал и установил Яндекс Браузер. Это выглядело круто: пользователи со всей Турции писали нам, какие мы классные. Многие устанавливали наш браузер всем своим родственникам, чтобы повысить шансы на победу в розыгрыше. Это была эмоциональная и яркая кампания, но она принесла бизнесу в основном убытки. Это выяснилось, когда мы посчитали, сколько денег потратили на такой розыгрыш и сколько Яндекс заработал на новых пользователях в Турции. Оказалось, что люди скачали браузер, но использовать его не стали и сразу же удалили после объявления результатов розыгрыша.
Благодаря моему 14-летнему опыту работы с продуктами я пришел к выводу, что в среднем работают только 15—20% идей. Это немного, поэтому нужно всегда быть готовым к тому, что идея не подойдет, как бы она ни нравилась. А подошла она или нет — показывают цифры. Еще 40% гипотез — это серая зона, когда никаких изменений не произошло. Например, как было сто продаж, так и осталось. Это плохой результат, потому что бюджет и время на разработку и тестирование были потрачены впустую.
Фотограф: Мария Цветкова
Как вы используете продуктовый подход в своем бизнесе или работе?