Как Домклик запускает 1000+ экспериментов в год и не теряется в них.

Рассказываем о нашем универсальном шаблоне для запуска MVP «еще один шаблон для экспериментов».

Каждый 6-ой сотрудник Домклик — это владелец продукта или менеджер в продуктовой команде. За 9+ лет истории компании мы накопили огромный опыт и экспертизу в разработке цифровых продуктов. С сегодняшнего дня начинаем делиться ими вовне.

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

Вечером в офисе:

— А что, если нам запустить такой пилот: платить нашим партнёрам комиссию за продажу наших услуг? Мы так быстро себе продажи поднимем.

— Погоди, но в прошлом году Дима такое уже запускал.

— Чем закончилось?

— Не знаю, он уволился. Надо поискать в истории вотсапа.

Часто ли в больших командах вы сталкивались с такой проблемой? И я не про вотсап, а про необходимость «археологических раскопок» по результатам пилотов.

Вы придумали гипотезу развития продукта, как бы её теперь быстро проверить? Обычно в таких случаях мы пускаем прототипы, эксперименты, опросы, MVP и так далее. И часто сталкиваемся с проблемой, что придумали MVP, быстро его запускаем, а после эксперимента не понимаем, что делать с результатами. Или не совсем поняли результаты проверки. Или придумали MVP, собрали на коленке прототип, но абсолютно не подумали о том, как вообще его показывать клиентам.

Чтобы такого не было, мы в Домклик взяли за правило сохранять результаты всех экспериментов. НО! Здесь мы действуем по правилам Agile. Главное — знание о самом факте и контент. Важно сэкономить время и ресурсы для описания экспериментов, чтобы это не превращалось в документацию ради документации, и поэтому мы свели количество полей до минимума. И хотим здесь ими поделиться.

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

Сегмент клиентов

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

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

Ценностное предложение нашего эксперимента

Формулируем ёмко и кратко.

Шаблон: Мы (кто) разработали (что) для того, чтобы помочь (кому) решить (какую проблему) с помощью (секретный соус).

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

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

Каналы дистрибуции

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

Здесь вспоминаем, что слово «клиент» применяется в широком значении. Если эксперимент, MVP или пилот затрагивает только внутренних сотрудников, то нам всё равно нужно не забыть про каналы дистрибуции до них. Если речь об аудитории в один-два сотрудника, то это легко. А представьте, что у вас 3 тысячи человек по всей России. Поэтому нужно обязательно подумать, как мы будем рассказывать им про этот пилот. Это будут какие-то рассылки от лица компании, HR или владельца продукта по почте. Или мы создадим отдельную группу в Telegram?

Какие будут недостатки и нюансы у выбранного канала?

Вовлечение клиентов

Как мы будем вовлекать наших клиентов в использование MVP? Как мы будем получать от них обратную связь?

Под вовлечением имеется в виду вот что. Допустим, мы запускаем пилот на 3000 сотрудников колл-центров по всей России. Если мы просто сделаем рассылку «Дорогие менеджеры, пожалуйста, пользуйтесь каким-то новым неудобным для вас инструментом», то, скорее всего, она попадёт в спам, не будет прочитана или окажется проигнорирована.

Как мы будем вовлекать («заставлять» — плохое слово), доносить ценность? Говорить, что вам так будет удобнее, вам так будет проще. А если им не будет удобно от нашего эксперимента, но нам нужно собрать с них обратную связь, то могут быть какие-то административные, материальные, моральные схемы поощрения клиентов. Скажем, в формате конкурса: трое участников с лучшей обратной связью по пилоту получат то-то.

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

Проверка наиболее рискованных предположений

В английском это называется risk assumption.

Здесь мы простым языком формулируем, что конкретно проверяет наш пилот, гипотеза или эксперимент.

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

конверсия будет Х,

сможем привлечь Y клиентов,

из них у нас получится обслужить Z человек.

Мы должны составить список всех предположений и отсортировать их по важности и рискованности. Ошибка в какой формулировке или числе будет для нас самой дорогостоящей и критичной? Она способна порушить весь пилот. Поэтому выбираем самые важные предположения, и будем проверять их нашим пилотом или экспериментом. Например, проверим, получится ли с помощью email-рассылки привлекать и вовлекать X% клиентов.

Нужно обсудить, какой формат эксперимента мы планируем запустить. А потом коротко и ёмко описать, будет ли это MVP, опрос, качественное исследование, проверка в виде “поддельной двери”, полноценная функциональность или “MVP механический турок” с неработающей функциональностью и сотрудником, который всё делает за спиной у пользователей. Вики о данном методе:

Описываем сценарий эксперимента, как он работает, по шагам от начала до конца. Например:

клиент сделал что-то,

получил такой результат,

затем сотрудник сделал ему то-то,

в конце клиент получил обратную связь.

Один из важнейших пунктов — какие метрики и числа мы будем использовать. Перед началом эксперимента обязательно описываем:

на что мы будем смотреть,

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

Для меня самое важное — это критерии успеха. Как мы примем решение об успешности результата? Авторы половины неудачных экспериментов, которые я видел, не думали о том, по какому критерию будут оценивать эффект.

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

Всегда продумывайте это перед началом. У себя мы называем это «методом машины времени». Представьте, что эксперимент уже закончился, вы получили, скажем, 100 заявок, 12 оплат и 50 клиентов. Что вы будете делать с этой информацией? Хватит ли её вам для принятия какого-то решения? Если нет, то вернитесь обратно на машине времени в начало эксперимента и установите нужные отсечки.

Допустим, по бенчмаркам мы ожидаем, что конверсия должна быть не менее 12%. Теперь мы не попадём в ловушку, когда провели эксперимент, получили конверсию 8% и не понимаем, хорошо это или плохо, много или мало. Иногда некоторые эксперименты можно даже не запускать, если проделать это упражнение и понять, что для успешности предположения нам нужна конверсия 99%, а её мы никогда не достигнем. Тогда зачем тратить время и ресурсы? Лучше проверить другие предположения или покрутить гайки в нашей финансовой модели.

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

Этот пункт ценен не столько своим содержимым, сколько тем, что, заполняя его, мы тратим время на ретроспективу, как завещал Стивен Кови в книге «Семь наук профессионального менеджера». Останавливаем время, ретроспектируем и анализируем. Такую оценку эксперимента часто пропускают при проведении MVP, а ведь она очень важна.

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

P. S. Расскажите, если я пропустил важные пункты, которые вы используете, и выиграйте смайлик с поднятым пальцем от автора в подарок!