CustDev, первичное интервью, клиентское интервью, Customer Development и тд.

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

*Customer Development Framework*

Первое - нам необходимо выработать единый формат для проведения Customer Development.
Нужно определить «что мы хотим узнать»:
- Общие проблемы пользователей?
- Как люди их решают сейчас?
- Сколько люди тратят на решение проблемы?
- Сколько готовы тратить?

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

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

Прикладываю готовый Framework для вашего удобства использования. 😉

Решил подойти шагами от простого к сложному, поэтому начну с основ «Кто такой менеджер продукта/product manager?»
Именно от роли и ее грамотного восприятия зависит как будет выполняться работа, какие решения будут казаться необходимыми и исполнение обязанностей роли менеджер продукта будет понятнее.

Кто такой менеджер продукта/product manager?

Представьте, что любой привычный вам продукт из жизни проходит десятки этапов созидания перед тем как вы его можете купить. Product manager (далее - PM), это человек отвечающий за создание, продвижение и популярность своего продукта. Идеально на долгие года вперед. Он является главным идеологом продукта и должен улавливать свою аудиторию: “кто покупает его продукт”, “что нужно сделать, чтобы покупали «всегда» или покупали больше”, “что сделать, чтобы увеличить аудиторию потребителей продукта” и идеально сохранить количество потребителей навечно и никого не терять.

Например, если мы возьмем продукт из жизни, шоколадный батончик Snickers, то через призму восприятия Product manager я бы задался такими вопросами:

- Что я хочу продавать и кому?
- Как этот продукт должен выглядеть?
- Каким должен быть по вкусу?
- В какой момент мой продукт требуется?
- Как сделать его лучше конкурентов?
- Какие у меня затраты на производство продукта?
- Какие затраты на продвижение продукта?
- За сколько мне продавать мой продукт, чтобы было выгодно?
- Какого должен быть цвета?
- Какого должен быть запаха?
- Какого внешнего вида?
- Как его хранить?
- и так далее…

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

Чем больше вопросов и ответов вокруг своего продукта ты соберешь и через себя пропустишь, тем будет легче понять своё детище и аудиторию, которая за него платит деньги. Потому что ни раз в жизни встречал менеджеров продукта, которые определяют дальнейшую судьбу основываясь только на своих ощущениях и «экспертном мнении», но это может приводить к печальному сценарию развития. Одно дело, когда ты сам являешься покупателем продукта, который развиваешь, но ведь, если ты не платишь и никогда не платил за такой продукт, то как ты можешь иметь взгляд покупателя? Не всегда возможно, иметь опыт покупателя продукта - знаю, но есть множетсво способов примерить на себя роль по ту сторону «забора» и при этом делать правильные выводы. От общения с реальными покупателями до внутреннего бизнес-заказчика, который тоже может быть крайне ценен.

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

Что такое продукт и как его необходимо правильно воспринимать?

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

Простыми словами ценность продукта должна быть больше, чем стоимость продукта.

Есть так же понятие “импульсивные покупки”, когда ценность продукта ниже, чем стоимость продукта однако с помощью грамотного продвижения (маркетинга и рекламы) продукта его тоже покупают. По своему опыту могу сказать, что это понятие не относится ко всем продуктам, но точно относится в подавляющем большинстве к продуктам категории B2C.

Для простоты: продукты категории B2C - управляют и влияют на эмоции конкретного человека (покупателя/клиента). В большей степени это “эмоционаяльные продукты” и соответственно их продвижение строится, в том числе, на импульсивности. Существуют так же продукты категории B2B - это продукты решающие “боль клиента” или проблему. Поэтому в этой категории ценность должна быть всегда выше, чем стоимость.

В общей терминологии B2C - покупатель человек, а в B2B - покупатель бизнес (группа людей принимающих решение о покупке).

Также есть категория продуктов B2G - в общем виде это продукты государственного уровня и они решают куда более “сложные” и значимые цели. И их ценность строится от человека к государству и от государства к человеку.

Цифровыми продуктами являются сервисы, например, Яндекс Музыка, Яндекс Лавка, Яндекс такси, Озон, Вайлдберриз, то есть любой цифровой актив, которые можно купить или подписаться.

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

Варианты продажи продукта:

1. сервисная модель
2. подписочная модель
3. однократная покупка (капитальная покупка)

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

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

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

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

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

Перечень улучшений или как принято в ИТ-мире - “список фич”, может быть составлен исходя из:

1. Собственных наблюдений / своих экспертных знаний
2. Знаний экспертов отрасли или продукта
3. Гипотез (предположений)
4. Пожеланий клиента(ов)
5. Платных доработок, которые оплатил клиент(ы)

Первые 4-ре пункта должны быть покрыты продуктовыми метриками. То есть product manager должен понимать, что получит его продукт в результате того, что его команда проделает работу над фичей (потратит/инвестирует время). В конечном итоге все продуктовые метрики должны быть “количественными”, то есть улучшения в цифрах, а не в словах. Например: В результате реализации механизма проверки товаров перед выдачей на пункте выдаче Wildberris количество выданных товаров не тому покупателю сократилось до 0,05% с 2,5% от всего товарооборота. А это на минуточку речь о нескольких десятках тысяч товаров ежедневно (2,5%). Здесь есть цифра, на которую целился product manager, когда придумал эту фичу. Потребность в придумывании была из-за количества выданных товаров не тем покупателям, жалоб клиентов и финансовых потерь бизнеса из-за этого.

Есть улучшения “качественные”, когда в результате реализации какой-либо фичи product manager объясняет это тем, что продукт станет, например, современнее, лучше, удобнее, интереснее и так далее. То есть тут нет цифр - одни эмоции и эпитеты. В 99% эти фичи не несут практической пользы для бизнеса, так как оценить их реальный эффект на продукт невозможно. Поэтому даже в таких фичах, которые мы определили как “качественные” необходимо искать “количественные” показатели. Иначе мы можем потратить время продуктовой команды впустую и недостигнуть результата. И это зачастую дорого, особенно при формировании MVP (минимальной рабочей версии продукта).

Разработка и развитие продукта 📌

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

В “*плохих продуктах*” задачи касательно продукта поступают ежедневно незамедлительными к исполнению. В таком потоке - “хаосе”, невозможно говорить о продуктовом подходе в развитии продукта или группы продуктов, которые находятся в ведении product manager.

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

Как с этим справлялись? Для начала внедрили принцип по ведению доски фич/задач - внедрили Kanban. Это когда задачи сыпятся как из рога изоблия однако добавили туда оценку и приоритезацию от “Сделать как можно скорее” (ASAP) до “надо бы вероятно сделать когда-нибудь" (низкий приоритет). Это помогло просто переворить поток. После чего объяснили и договорились как правильно оценивать и расставлять приоритет.

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

Низкий уже ранее рассказал, а вот другие два - это:

- *Высокий* - надо сделать как можно скорее, так как это принесет нам в моменте денег или решить с помощью этой задачи проблему, которая через котороткое время станет критической.
- *Средний* - все остальное, что нельзя отнести к высокому или низкому приоритету. Обычно - это задачи на перспективу, которые дают развитие продукту не сейчас в моменте, но в будущем (в течение 1-2 кварталов точно).

Приоритеты могут меняться и это нормально. Я бы даже сказал их точно нужно проверять раз в период (квартал, полгода или год), чтобы не упустить важное и не допустить проблем в будущем. Именно по этой причине принцип ведения доски с задачами должен быть понятен не только product manager, но и разработчикам. Ребята должны однозначно понимать, что они делают сегодня, что завтра, когда дедлайн, какие есть блоки в реализации задач, что планируется и зачем - поверьте, это поможет в том числе начать слышать идеи от них самих по улучшению продукта.

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

Удобнее делать так: есть год и 4 квартала в нем, отдельно сущность “Ассайны”. Ассайны содержат в себе все задачи, которые идут параллельно с роадмапом развития продукта. Например, то что было выявлено на совещании или переговорах или при общении с другими отделами (продажами, маркетингом, юристами, финансистами и т.д.)

*Роадмап* бывет публичный и внутренний. Внутренний для компании - это то, что захотело руководство, ваша техническая команда и т.д. - то есть внутренний бизнес-заказчик. Публичный роадмап - это ваши обязательства перед клиентами, то что вы публично заявили, что появится в вашем продукте и это от ваш ждут клиенты. В каждом из кварталов есть “вехи” - большие задачи о новом функционале, развитии, исправлениях, которые скрывают в себе кучу маленьких подзадач. Куча маленьких подзадач - это шаги/этапы, которые необходимо выполнить, чтобы веха из роадмапа была выполнена и все: клиенты, бизнес-заказчики, продуктовая команда получили ожидаемое.

Клиент самое ценное, что есть у продукта. Поэтому важно слышать клиентов и понимать их потребности.📜

Как слышать и понимать клиента?

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

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

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

1. Люди читаю “жопой!”;
2. Большиство хотят вам понравиться в диалоге;
3. Мало кто готов давать свое конструктивное мнение - все прикрываются словами: обычно, как правило, стараясь приписать свое мнение к большинству, а не просто взять и выразить свое мнение незнакомому человеку;
4. Некоторые из потребностей настолько абсурдны, что требуются только одному клиенту из 1000 и делать такое ради него одного часто бессмысленно;
5. Люди не знают чего они хотят. Часть тех с кем у вас будет диалог сведется к тому, что их все устраивает.

Это сборник топ-5 выводов после общения с 1000+ клиентами. Поэтому учитесь разговаривать и понимать людей, их мотивы и желания. Докапываться до сути. Делать так, чтобы вам захотели излить душу. Потому что если вы этого достигнете, то с небольшой вероятностью, но сможете получить инсайд, который в дальнейшем превратите в клад - главное, чтобы конкуренты раньше вас не узнали и/или хотя бы реализовали его в продукте позже вас.

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

Из форматов диалога с клиентами существуют:
1\. Живое общение
2\. Онлайн-встреча - идеально/обязательно с камерой (нужно наладить коннект)
3\. Опросы аудитории (вопросы должны быть супер-простыми и однозначными к восприятию)
4\. Голосования (как правило лучше проводить на основании проведенных опросов)
5\. Обращения к статистическим данным, которые собраны каким-то агенством платно или бесплатно. Супер общая информация без персоницикации - подходит на самом первом этапе для старта, но часто это просто статистика и она не так валидна.

Самое интересное это пункты 1 и 2. Они наиболее сложны в реализации, особенно у неподготовленного человека к диалогам с новыми людьми, но здесь кроется плодовитое зерно. 📝

Пример реального инсайда в интервью или как я понял реальную проблему в продукте №1

Различаю для себя CustDev-интервью (проблемное интервью — подтвердить или опровергнуть наличие проблемы) и JTBD-интервью (интервью с пользователем — потенциальным или действующим — для выявления момента возникновения потребности или проблем в твоем продукте). Если про CustDev ты уже слышал из каждого утюга, то про JTBD-интервью знают не многие :)

Кейс из моего опыта

Был у меня продукт, который позволяет сократить затраты на объеме выводимого персонала в крупных ритейл-сетях: Магнит, Пятерочка, Лента, Globus, МТС-салоны, МегаФон-салоны, LIME, Л'Этуаль, М.Видео и т.д.

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

Эффект: крупные сетевые магазины сокращают затраты на перерасход персонала на 10-15% — это миллиарды рублей. Стоимость продукта сильно дешевле этих затрат, поэтому он крайне эффективен.

Но появилась проблема

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

Я начал проводить JTBD-интервью, чтобы понять:

• Причину оттока

• Принцип использования продукта

• Глубину задействования

• В какой момент у директора магазина вообще возникает потребность в продукте

Не то, как мы (владельцы продукта) видим, а то, как видит непосредственный пользователь.

Прорывной инсайт (12-е интервью)

Пообщавшись с 5-ю директорами по персоналу торговых сетей (М.Видео, Леруа Мерлен, Мираторг, Ситилинк, Перекресток), договорился, что каждая сеть предоставит возможность поговорить с 10-ю директорами конкретных магазинов (непосредственными пользователями продукта).

На 12-м интервью с директором магазина М.Видео попалась очень заинтересованная и жизнерадостная женщина. Помимо стандартных тем, решил копнуть глубже — попросил поделиться проблемами, которых не хватает директорам: интернет плохой или проблемы другого характера, что часто обсуждают в кулуарных чатах.

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

Для меня это НЕ целевой сценарий! ИИ продукта не используется, весь смысл теряется.

Копнув глубже: у 95% работников установлены мониторы начала 2000-х — 14-15 дюймов, квадратные, 4:3, разрешение 1024×768. 🫣

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

Что сделал дальше:

1) Подтвердил похожую проблему во всех оставшихся 38 интервью

2) Сформировал метрику оттока: когда глубина использования продукта <60%, эффект исчезает (директора работают дома без ИИ)

3) Набросал эскиз дашборда директора с ИИ-помощником и метриками жизнедеятельности магазина

4) Показал эскиз выборке по директоров от каждой сети

5) Через директоров по персоналу организовал массовую рассылку эскиза для фидбека

6) Поставил задачи разработчикам: добавить дашборд + ИИ-помощник

7) Сделал мини-обучение для новых директоров (учитывая текучку в ритейле)

8) Собрал обратную связь по изменениям

Кейс из жизни product manager.

#кейс@maxboman