×Закрыть

По-стартаперски и по-богатому: как делать customer research и почему это полезно любой компании

Всем привет! Меня зовут Паша Педенко. Я помогаю компаниям строить продуктовую культуру. В этой статье мы посмотрим на примерах, как любая компания, будь то стартап или корпорация, может проводить пользовательские исследования и получать от них пользу.

Я сооснователь проекта Raply, конференции Growth Marketing Stage (4 апреля везем сюда спикеров Uber, Dropbox, Adobe, Hubspot и Google) и основатель хакатона Global Hack Weekend (в прошлом году мы собрали больше 1000 человек).

Летом прошлого года я запустил Telegram-канал, где начал писать о том, как мы в Setapp (я тогда еще работал в MacPaw) и Raply делаем исследование пользователей, и заметил, что эта тема волнует многих коллег как из продуктовых, так и из аутстаф-компаний.

Три вопроса, которые задают чаще всего:

  • Зачем это делать?
  • Как начать делать это в моей компании?
  • Кто за это должен отвечать?

Зачем нужен customer research

Исследование пользователей — это инструмент, который решает определенные задачи, например:

  • Экономия денег на разработку и маркетинг. Лучше понимаем пользователей — не делаем то, что им не нужно.
  • Строим эмпатию у команды. Команда знает, какую проблему и для кого она решает, значит делает это более быстро и мотивировано.
  • Знаем, куда двигаться дальше. Узнаем больше о проблеме — знаем, в каком направлении продукт может развиваться.

Исследование пользователей не нужно делать в командах, которые «и так знают, что делать». Обычно это vision-driven проекты, в которых никто ничего не будет менять вне зависимости от того, что скажут пользователи. Дополнительные инсайты в таких системах будут только фрустрировать команду.

В этой статье не будет никаких фреймворков. В ней я постараюсь показать, как компания на любом этапе развития может получить пользу от пользовательских исследований. Все на примерах.

Мы возьмем три компании:

  • Pet-проект с тремя парт-тайм сотрудниками — Raply.
  • Компанию до 200 человек — MacPaw.
  • Корпорация с 10 000+ сотрудников. Это будет Uber.

Raply. Исследуем пользователей «по-стартаперски»

В конце декабря я ушел из MacPaw и мы с моим другом и теперь партнером Виталием Рожевским договорились систематизировать нашу работу над Raply. В первый день работы у нас было несколько звонков с пользователями, которые мы проводили... на Бессарабском рынке, прямо возле ларька с фалафелем.

Виталик общается с Lorenzo, нашим пользователем из New Jersey

Для Raply звонки с пользователями — это возможность подбросить дровишек в огонь. Проект не приносит денег, и, чтобы продолжать работать над ним, нужно находить мотивацию. Это проще, когда видишь человека, для которого строишь продукт.

Кстати, через пару часов после звонка мне переслали следующую переписку. Будьте осторожны — уши везде :)

Скриншот, который мне отправили в личку в начале зимы

Что Raply дает общение с пользователями

  1. Возможность генерировать гипотезы «за обедом» и приоритезировать roadmap.
  2. Поиск «а-ха момента». Продукт еще сырой, и если кто-то им пользуется, то что-то их цепляет. Общение с пользователями помогает выкристаллизовать понимание «а-ха момента».
  3. Эмпатия. Команда лучше понимает, для кого работает. Для Raply — это люди, которые не разбираются в технологиях и производстве музыки, но мечтающие о карьере рэпера.
  4. Огонь продолжает гореть, мотивация повышается даже в условиях, когда есть другие параллельные проекты.
  5. Работать становится веселее. У пользователей появляются прозвища. Так, у нас есть «эмигрант», «бездомная» (в итоге оказалось, что она проститутка, но мы все равно называем ее бездомной), «чувак в тачке» и другие.

Сколько нам это стоит? Только наше время.

Интересные находки в рамках исследования

  1. В основном пользователи Raply предлагают созвониться в Instagram и практически никогда не приходят поговорить с Skype.
  2. Ловить на интервью их нужно «здесь и сейчас», назначать встречи в календаре нет никакого смысла — они им не пользуются.
  3. Знание английского — не гарантия того, что вы друг-друга поймете. Иногда из получасового разговора мы понимаем несколько предложений. Чернокожие техасские ребята, увлекающиеся рэпом, не всегда говорят разборчиво.

Setapp. Исследуем пользователей «по-предпринимательски»

Когда-то я написал статью о том, как мы в Setapp пытались найти Product/Market Fit. Setapp, в отличие от Raply, сразу запускали как продукт с большими амбициями и серьезными инвестициями.

Во время запуска органического спроса на Setapp не было — никто не ищет в Google «подписка на 130 приложений для Mac». Стоимость привлечения одного пользователя из платного трафика была настолько огромной, что он не окупился бы никогда (точнее, окупился бы в течение 200+ лет). Нужно было что-то менять.

Очевидной идеей было попробовать выделить сегмент пользователей, в котором можно добиться нормального соотношения стоимости привлечения одного пользователя и его lifetime value.

Проще сказать, чем сделать. Мы разослали приглашение нашим пользователям поучаствовать в интервью. На два дня отменили все встречи, взяли несколько банок «редбула» и забронировали переговорку. Основной задачей было выделить «нашего» пользователя.

Что команде Setapp дало общение с пользователями

  1. Понимание портрета early adopter’a — человека, который получал наибольшую ценность от продукта.
  2. Понижение стоимости привлечения платного пользователя в 19 раз (лучше поняли, кого и как приводить).
  3. Отказ от нескольких фич, которые не добавляли ценности продукту.

Чему команда научилась

  1. Никогда ничего не давать пользователю за то, что он пришел на звонок — это искажает результаты. В начале мы предложили нашим пользователям возможность выиграть Apple TV за участие в исследовании. К нам пришел пастор одной из американских церквей и начал заверять на интервью, что он преданный пользователь Setapp. Когда мы проверили аналитику, то оказалось, что он зарегистрировался, но никогда не устанавливал приложение на компьютер.
  2. Общение с пользователями помогает держать связь с реальностью и более уверенно отказываться от вещей, которые не принесут пользователям ценности.
  3. Общение с пользователями — это процесс, который кто-то должен драйвить. В команде Setapp — это были Product Manager и Product Marketing Manager.
  4. Нельзя делать исследование пользователей ради исследования — у этой активности должна быть цель — найти сегмент, валидировать гипотезу, сформировать гипотезу и т. д.

Uber. Исследуем пользователей «по-богатому»

На секунду абстрагируйтесь от машин на литовских номерах, которые наводнили киевский Uber, и подумайте о масштабе этой компании — больше десяти тысяч сотрудников в разных странах и амбиции менять индустрию транспортировок, включая грузовые и авиаперевозки. Так можно представить себе стоимость ошибки в случае запуска «продукта, который не подойдет рынку».

В рамках подготовки апрельской Growth Marketing Stage я пообщался с Naman Mathur, Researcher, International Growth в Uber, и расспросил его о нескольких кейсах того, как пользовательские исследования изменили продукты Uber.

Uber — одно из первых приложений, основанных на том, что пользователь видит карту в качестве первого экрана. Когда команда Uber делала исследование аудитории в Индии, то поняла, что в большинстве пользователи используют старые смартфоны, где приложение с картой на первом экране просто «тупит». Но главное другое: даже если карта работает, они не понимают, как картой пользоваться. Исследование делалось в рамках запуска продукта Uber Lite (упрощенный Uber для развивающихся стран, который весит до 5 МБ).

Когда команда исследователей принесла этот инсайт продуктовой команде, то ей было очень сложно поверить в то, что кто-то не может работать с картой. Убеждения не работали, доказательства не работали.

Единственное, что сработало — это взять продуктовую команду в поле и показать, как их пользователи пользуются картами. В итоге, в Uber Lite карты на первом экране нет.

Naman во время пользовательского интервью в Бразилии

Что команде Uber дает общение с пользователями

  1. Понимание того, что действительно важно для пользователей. Перед запуском на новом рынке Uber отправляет туда команду исследователей. Так, они открыли, что для пользователей из Бразилии самым важным всегда будет безопасность, в то время, как в Африке — доступность. Индийские пользователи никогда не будут платить карточкой. Впрочем, как и пользователи из Египта.
  2. Возможность роста за счет инсайтов, специфических для определенной географии. Технологически продукт может оставаться тем же, но всегда проще стать частью существующего паттерна поведения пользователя, чем создать новый. Так, появился киевский эксперимент с возможностью заказа Uber по телефону. По словам Naman’a, эксперимент стал настолько успешным, что сейчас его масштабируют на пять дополнительных городов.
  3. Идеи для новых продуктов в рамках существующего сервиса. Например, исследователи поняли, что в Индии и Африке пользователи ездят в основном на короткие расстояния и не очень переживают о комфорте. Так, в Индии появилась возможность вызывать трехколесные авто (тук-туки), а в Кении появился продукт Uber ChapChap с low-end машинами, которые удобны для коротких перемещений.

Чему команда научилась

Пользователя не интересует, что приложение делает на бекграунде. Важно только решение его конкретной проблемы. Как пример, Naman приводит историю о том, как один из пользователей, с которым он делал интервью, воспринимает YouTube.

В Бразилии команда Uber общалась с 65-летней пользовательницей Uber. Кроме Uber, который она использует для поездок в церковь, у нее на телефоне было два приложения — YouTube и WhatsApp.

Экран телефона 65-летней пользовательницы из Бразилии

На вопрос «Что для нее YouTube?» она ответила: «Это место, где всегда есть мои песни».

Оказалось, что каждый день она заходит в это приложение и слушает пять своих любимых песен. Ей не интересен алгоритм, который делает точные рекомендации. Ей не важно, как быстро работает поиск. Только ее пять песен.

Я из этой истории вынес одну мысль: когда мы строим технологический продукт, мы думаем о куче кейсов. Пользователей же, зачастую, интересует один. В этом разница между нами и ними.

Кто должен отвечать за пользовательское исследование в продукте

Я считаю, что команда. Хорошая продуктовая команда знает, какую проблему и для кого она решает. Или готова признать, что у нее нет ответа на этот вопрос и попробовать его найти.

У команды должен быть на это запрос. Решить его можно с помощью дополнительных ролей — бизнес-аналитика, продакт-менеджера, исследователя — или дополнительных процессов.

Иногда вы строите продукт для пастора, а иногда — для проститутки. И чаще всего этих людей нет в комнате, когда вы принимаете те или иные решения. Нужно набраться смелости и их туда привести.

Спасибо, что прочитали этот лонгрид. Мне будет приятно, если вы подпишитесь на мой Telegram-канал.


P. S. Я планирую написать небольшую книгу о том, как делать пользовательские исследования, и о том, как это меняет продукты. Если у вас есть истории, которыми вы готовы поделиться — пожалуйста, напишите об этом.


Иллюстрация: Алина Кропачова

LinkedIn

9 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Забавно, что лгунишкой оказался именно «пастор одной из американских церквей».

Интересная статья — очень «заземляет» (возвращает от витания в облаках). Пишите ещё.

1)

В ней я постараюсь показать, как компания на любом этапе развития может получить пользу от пользовательских исследований. Все на примерах.

Очень уместный формат для данной темы.

2)
Понравилась манера/структура изложения.

Небольшие абзацы, маркированные списки, уместные иллюстрации цифрами — удобно читать по-диагонали (быстро скроллить и выдергивать ключевые идеи). При чтении «подряд» не устаешь от портянок текста.

Спасибо за статью.

Спасибо за обратную связь!

Дуже цікаво, але часто користувачі самі не знають чого вони хочуть, поки не отримають нафарширований фічами застосунок і не виберуть для себе щось одне, дослідження користувачів дає поверхневе розуміння потреб.

Звичайно, не знають. Але дослідження якраз і робиться, щоб виявити проблеми. Користувачі не мають говорити, що ми маємо зробити, але вони мають розказати про проблеми, які ми можемо вирішити.

Отличная статья о важности исследований перед непосредственной разработкой. У нас этим часто пренебрегают. Спасибо за интересный материал, Павел!

Подписаться на комментарии