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

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

Dr.Explain - это классическое десктопное ПО для ОС Windows и продукту уже 18 лет.

В первые годы жизни продукта, направление разработки было примерно понятно - помимо уникальных фишек, типа автоматической аннотации скриншотов и быстрого предпросмотра, надо было сделать большой объем обязательных для такого класса программ вещей: импорт из одного набора форматов и экспорт в другой набор, толковый редактор, локализацию интерфейса и проработку его эргономики и т.д.

И мы как крабы на галерах неистово кодили без лишних рефлексий.

Однако, чем большей историей обрастает продукт, тем сложнее каждый раз принимать решение в какую сторону его развивать дальше - горизонтально, цепляя новые ниши и пользовательские сегменты, или вглубь, улучшая жизнь текущим пользовательским сегментам. Но даже выбрав стратегическое направление, все равно сложно определиться с тактикой - какие именно фичи надо добавлять, а какие надо улучшать.

Кстати, иногда мы и выкидывали целые куски функциональности из программы, которые не давали большой ценности пользователям, но явно перегружали продукт и усложняли разработку. Не практикуете такое?

В последние несколько лет проблема выбора направления каждого следующего шага встала во весь рост.

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

В унисон этому хору пели и свои голоса в голове, призывая по очереди то начать вылизывать существующие куски функциональности, то совершить прыжок веры и загрузить команду на год-другой созданием Звезды Смерти, которая уж точно взорвет весь рынок HAT-инструментов или перенесет нас на принципиально другой рынок. Ха...

Работая над этой проблемой, за несколько лет я перечитал уйму книг и статей по модным фреймворкам - Lean strartup, Jobs To Be Done (JTBD), Голубые океаны, Customer development, Data driven development, Growth Hacking и т.д. Лекции и презентации по управлению продуктом на YouTube и ConferenceCast.tv также были засмотрены до дыр.

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

Но... Занимаясь всем этим я наконец-то заметил одну простейшую закономерность...

Программа реально становилась лучше, если релизу предшествовало одно из трех событий:

• состоялось плотное, например часовое, общения с пользователем,
  
• удалось понаблюдать за работой пользователя, стоя у него за спиной,
  
• кто-то из команды сам поработал длительное время в программе.

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

Для иллюстрации приведу простой пример.

Все сотрудники, приходящие в команду, независимо от их роли должны сделать в Dr.Explain небольшой проект. Так они понимают суть продукта, минимально изучают его, формируют свой пользовательский опыт и ... выполняют роль подопытных кроликов.

Одна новая сотрудница решила написать краткую документацию к электронному учебнику по английскому языку. В учебнике было много ярких красочных экранов. Наблюдая за ее работой, я обратил внимание, что она прищуривалась и всматривалась в экран каждый раз, когда ей нужно было сделать снимок (скриншот) экрана. Оказалось, она банально не видела на пестрых экранах ярко иллюстрированного учебника оранжевую маркерную обводку вокруг захватываемого окна. При этом она не говорила, что ей неудобно. Скорее всего, она даже не понимала того, что ей неудобно. Она даже не вздыхала и уж точно никогда не написала бы об этом в техподдержку. Она просто щурилась и наклонялась к экрану. Это можно было заметить только со стороны.

Вечером того же дня в треккер легла новая задача.

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

В голове потом еще долго скулила мысль - "Почему мы не сделали этого несколько лет назад?".

По итогу стало понятно, что надо охотиться за живым пользовательским опытом. Причем - и чужим, и своим.

В общем, я решил поставить эту охоту на поток, а основным оружием выбрал глубинные интервью.

Первые интервью я решил проводить сам, как основатель проекта. Об аутсорсе первых шагов не могло идти речи. Во-первых, никакой наемный менеджер не чувствует продукт так, как его чувствует product owner. Во-вторых, привлеченный сотрудник работал бы жестко по скрипту и точно бы не стал отступать от скрипта и углубляться в какие-то детали, почувствовав их важность по ходу разговора с клиентом.

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

Специального отбора кандидатов на интервью у нас не было. Механика у нас налажена давно. При каждой покупке лицензии в CRM автоматически создается задача связаться через некоторое время с покупателем. Когда наступает время контакта, мы отправляем контактному лицу письмо с целью инициировать ответ и начать беседу. Если такой ответ есть, начинается переписка с целью получить обратную связь, отзыв или даже написать совместный кейс.

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

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

Некоторых пользователей даже не приходится просить продемонстрировать экран, они сами настаивают - "давайте я вам сейчас покажу..." В результате я могу увидеть, как выглядят их проекты, как они пользуются программой, какой еще софт у них установлен и запущен и много другой полезной и профилирующей информации (развивайте наблюдательность).

В крайнем случае, если человек настаивает исключительно на голосовом общении, используем обычный телефон. Редко, но иногда люди сами звонят в ответ на письмо.

Если первое письмо осталось без ответа, следует еще серия контрольных сообщений.

Первым делом решил поискать готовые структуры для интервью. Опять погрузился в JTBD и customer development - методологии, в которых очень многое строится на интервью. Для тех, кому интересно как задавать вопросы, как отличать хорошие вопросы от плохих, как готовиться к интервью и обрабатывать результаты, традиционно посоветую книгу Роба Фитцпатрика "Спроси маму".

В итоге я собрал свою структуру глубинного интервью. Оно состоит из более, чем пятидесяти вопросов, которые покрывает одиннадцать блоков-аспектов взаимодействия клиента с нашим продуктом: Решаемая проблема, Выбор решения и принятие решения о покупке, Контекст использования, Командная работа, Получаемые результаты, Знакомство с продуктом и т.д.

В каждом блоке есть профилирующие вопросы, которыми мы выясняем есть ли смысл идти вглубь (например , "Лично вы принимали решение о покупке?") и актуализирующие, которыми мы вытягиваем конкретные факты, формулировки, цифры (например, "Какие у вас были сомнения на счет приобретения лицензии?").

Надо понимать, что вопросы нельзя задавать в лоб, чтобы интервью не выглядело как допрос. Это должна быть беседа, в которую эти вопросы встроены естественно. Их формулировку желательно менять в зависимости от контекста и ситуации. Кстати, и поэтому тоже сложно аутсорсить такую задачу постороннему невовлеченному человеку.

Изначально я оформил структуру интервью, как опросник с полями, которые собирался заполнять по ходу беседы. Перед каждым интервью я распечатывал этот опросник. Я понимал, что вбивать ответы сразу в электронную форму по ходу разговора нереально, а вот бегло стенографировать я смогу. Но через несколько интервью я отказался от такого подхода.

Собеседник во время разговора мог не следовать логике интервью и шел в своем рассказе от одного аспекта к другому, следуя собственной логике, или вообще мог без единого вопроса с моей стороны начать непрерывный рассказ о всем, что у него наболело или о том, что его интересует. Я никогда не прерывал такие монологи, т.к. они во-первых показывают, как клиент мыслит и какими ментальными моделями оперирует, и, во-вторых являются бесценным источником оригинального пользовательского опыта. Я просто фиксировал все существенные факты из пользовательского монолога в полях опросника, постоянно перелистывая его взад-перед. Затем я смотрел, какие вопросы остались незатронутыми или неактуализированными, и задавал их или доуточнял.

Это листание опросника взад-перед и поиск нужных полей для записи во время беседы было не очень удобно, поэтому эволюционным путем я пришел к следующей схеме: структура интервью у меня распечатана на одном листе в виде mind map, как подсказка, с которой я сверяюсь. Все тезисы беседы я просто стенографирую на чистом листе сплошным потоком. После беседы я просто заношу тезисы с листа в соответствующие поля электронной таблицы. Такой процесс намного проще - структура постоянно перед глазами, а записи ведутся последовательно - не надо шебуршиться в ворохе листов опросника и отвлекаться на поиск нужных полей для фиксации ответов.

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

Структура нашего глубинного интервью со всеми вопросами в виде mind map (ментальной или интеллект-карты) есть на сайте предпринимателя-интроверта TheNerd.ru.

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

Например, когда пользователь говорил, что он не смог что-то сделать в нашей программе, а я точно знал, что это там можно сделать, у меня естественно возникал праведный порыв сказать - "Ну как же, вот же у нас там есть... Что же вы ....".

В этом момент надо просто жестко сказать своему эго: "Заткнись! И слушай..." Лучшим решением будет выслушать все претензии, а потом спросить - "А где и как вы искали эту функцию? Где вы предполагали ее увидеть? Как обошлись в итоге без нее? Что у вас получилось? Сколько времени вы на это потратили?".

Ответы на эти вопросы и дадут вам инсайты для точек роста и улучшений.

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

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

Например:

Формулировки и описание проблемы
- "Нужно подготовить мануал"
- "Нужно собрать видеоинструкции"
- "Делаем учебник для пользователя"

Как принимали решение о покупке
- "Показал результат на экране директору: - Смотри, Михалыч, вопрос только в водяных знаках. Цена вопроса - 22 рубля. Берем? - Говно вопрос!"
- "Делать в Ворде - проще пойти и застрелиться."
- "Ворд уже достал. Посмотрел на ваш - все, что нужно, есть. Купил"

Специфический жаргон и свои названия для ваших функций
- Используют словосочетание "захватить раздел" вместо "заблокировать раздел" или "взять на редактирование".
- Называют "дерево разделов" "рубрикатором".
- "Подшиваю видеоинструкции в 1С"

Сценарии использования
- "Используем для себя и для обучения новых сотрудников."
- "Кидаю ссылку на мануал монтажникам"

Какими качествами наделяют ваш продукт
- "Нет этого гребанного Ворда"
- "Запускаешь и сразу понятно, что делать"
- "В целом впечатление положительное"

Как начинали работу
- "Быстро вкатились в работу."
- "Заводил продукт в команду другой сотрудник"
- "Импорт не получился из-за ошибки в документе. Копировали разделы в новый проект руками."

Сильные эмоции
- "Линейка ходит не градированно, без snap-а. Выбешивает!"

Какие личные глубинные задачи они решают вашим продуктом
- "Мой проект перестали называть "шараж-монтаж"
- "Стало больше свободного времени"
- "Совесть больше не мучает"

На этапе анализа тезисов из интервью я разношу их по таблице, согласно структуре интервью. Получается так:

Дальше с этой таблицей начинаем работать для поиска идей гипотез роста. Это просто кладезь.

После серии первых интервью, появилось достаточно четкое понимание, основанное на конкретных примерах и проговоренное с пользователями:

• какие стороны у нас сильные и что мы можем использовать в качестве УТП и в маркетинге, причем мы знаем каким языком пользователи описывают эти аспекты;
  
• в каких моментах у нас есть полные провалы по функциональности и нас замещают другими способами - тут наши основные точки роста;
  
• какие профессиональные роли исполняют наши пользователи в своих командах - упрощается квалификация лидов и сегментирование целевой аудитории;
  
• какую ценность дает наш продукт в финансовом и эмоциональном плане - используется для построения обоснованных предложений и структурирования цены;
  
• как мотивируют себя или руководство к покупке лицензий и какие противодействия встречают.
  

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

Однажды я услышал и принял от одного серьезного предпринимателя такую мысль:

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

Всем удачи в бизнесе!

#jtbd #growth_hacking #управление_продуктом