894
Всякое о продукт менеджменте в финтехе
Чисто случайно в один из чатов закинул свой чек лист - как я смотрю на продукт который надо оценить или с которым надо что то делать. Вроде зашел по реакции, решил и тут пошарить.
1. Какую проблему решает продукт.
2. Как мы поняли что проблема есть
3. Как мы поняли что решение - подходит.
4. Юнит эконмика и сопуствующие метрики.
5. IT Архитектура продукта и где лежат данные.
6. Команда, кто за что и какие процессы.
7. Рынок (альтернативы, проникновение, потенциал)
8. Три самые большие проблемы которые мешают развитию продукта.
9. Управляемость. (если завтра хочу изменить цену/дизайн/онбординг/провести АБ тест) - как мне это сделать.
10. Метрики внимания и использования. Типичная сессия, типичное поведение пользователя и тд.
Завтра буду выступать в открытой части Aha в онлайне.
Расскажу о том какую нудную, но важную работу по продуктовой аналитике мы делаем
Если что приходите, всем рад.
https://aha.matemarketing.ru
Выученные уроки из прошедшего
Не то чтобы я не видел сложных и кризисных ситуаций до этой весны. Но впервые прохожу такую ситуацию в управленчеких ролях.
Хочу поделится пачкой выводов, которые сделал для себя по итогам произошедших событий.
Хорошие и плохие практики в формате тезисов.
Не буду банальное, "не паниковать, не ругаться друг с другом, составить план и тд"
1. Знай, что с клиентом.
Понимай, что с клиентом: что начали делать, что прекратили делать и чего ждут.
Эта информация даст больше понимания и прозрачности в ситуации неопределенности.
В этой ситуации легко можно унести фокус с клиента на внутренние дела продукта. В этой ситуации легко разъехаться по ценности и решаемым проблемам с клиентами, что черевато их потерей. Необдуманно подняли цены, потеряли клиентов.
2. Новый продукт это долгая и кропотливая работа.
Мозг продакта так устроен, что генерирует пару десятков гипотез в неделю даже в ситуации полного штиля. Когда происходят тектонические сдвиги в ситуации, легко поддаться соблазну и побежать "срочно делать тот самый продукт, который решит нужные проблемы".
В марте в финтехе была куча шума вида: "Давайте срочно сделаем сервисы для: поиска новых поставщиков в Китае / оплате сервисов и переводов / новых инвест продуктов.
В массе ничего реального и большого быстро не появилось. Что-то только начинает созревать.
Новый продукт это не спринт, а марафон, который требует соответствующего отношения к себе. Пожжете кучу энергии а результата не будет.
3. Доверять процессу.
Ничего не поменялось в процессе для создания нового продукта. Проблемы, гипотезы о решении, проверки, анализ результатов, MVP и тд. Это не перестало работать от того, что вокруг все в дыму.
Ряд неплохих идей и мыслей были запороты метаниями и нервной суетой.
Не стоит изменять процесс вне оговоренных точек и трепать себе нервы между измерениями.
4. Делать то, что приносит быструю и ощутимую пользу.
В действующем продукте надо сосредоточится на конкретных и измеримых целей.
Короткий цикл обратной связи в ситуации высокой неопределености особенно важен. И для команды и для клиентов
и для продукта.
Ряд команд пошел делать долгосрочные вещи которые решали проблемы вида "доллар по 150" и
"Удаленное открытие ООО в Армении для параллельного импорта". Это казалось важнее, чем глупости в UX.
Спалили кучу ресурсов. Ситуация три раза поменялась. Глупости в UX до сих пор там.
Не знаете что делать - делайте то что принесет пользу здесь и сейчас.
Внеплановое и короткое включение по мотивам личных переписок.
Многие не знают как посчитать LT когорты к определенному
сроку жизни без экселя и средневзешенной, имея на руках только
показатель ретеншена.
Умирающая на постоянный процент оттока когорта это геометрическая
прогрессия. У геометрической прогрессии много хороших свойств,
одно из которых - возможность посчитать сумму первых членов.
Сама формула легко гуглится. Чуть творчески ее переработав
можно выделить вот такое
time =12
churn=0.05
q=(1-churn)
LT12=(1-q^time)/(1-q)
Я очень часто сталкиваюсь с использованием усреденных показателей на для расчета продуктовых метрик и принятия решений. Иногда это ок, но надо осознавать, что разрыв с реальностью может достигать десятков процентов.
Почему так и что с этим делать
Описал все на медиуме
статья
Немного продуктовой аналитики.
Уже четвертый час работаю над дизайном АБ теста.
Сильно ограничен в выборке. Вот нужных пользователей - 1700.
Нулевая гипотеза - метрика не поменяется,
Альтернативная - метрика значимо изменится.
И в силу малого количества пользователей, и параметров распределения метрики
получается обнаруживать даже жирный эффект в 10–15% только в 1 случае из трех.
А вот отсутствие эффекта (когда его реально нет) я вижу в 95% случаев. И это хорошо.
Выяснил этот эффект благодаря моделированию
кучи синтетических АА и АБ тестов (писал про это не так давно.)
С такой чувствительностью - тест запускать нельзя. Не найдем эффект.
Обычный подход - увеличить выборку. Но я этого сделать не могу.
У меня есть следующие возможности для оптимизации.
- размеры временного окна наблюдений
- изменение критерия (среднее, медиана и т. д.)
- обработка данных.
С первыми двумя - понятно, а вот с обработкой - хочется остановится подробнее.
Основная проблема низкой чувствительности — это высокая дисперсия метрики.
Существуют разные способы снизить дисперсию, от стратификации до экзотичных способов трансформации данных.
Один из самых простых и надежных способов — Это СUPED.
Идея проста. Использовать значения до эксперимента и их связь со значениями после эксперимента
как поправочные коэффициенты для сокращения дисперсии
Не буду грузить статистикой, для желающих вот принципиальная работа
А в моих синтетических тестах использование CUPED дало двукратный рост чувствительности.
Eсли у вас аналитики просят больше пользователей - попросите их поискать способы
усилить чувствительность. Иногда это получается. Да и в принципе, продакту полезно разобраться в дизайне АБ тестов.
В таблице представлена как менялся процент случаев в которых мне удавалось найти эффект
когда он реально был,в зависимости от оптимизации метрик
размер_эффекта базовая_метрика_процент_успеха базовая_оптимизаця CUPED_метрикаЧитать полностью…
1 1.01 0.059 0.088 0.283
2 1.02 0.059 0.088 0.291
3 1.03 0.089 0.132 0.334
4 1.04 0.109 0.162 0.352
5 1.05 0.099 0.147 0.398
6 1.06 0.109 0.162 0.403
7 1.07 0.109 0.162 0.427
8 1.08 0.129 0.191 0.437
9 1.09 0.139 0.206 0.491
10 1.10 0.158 0.235 0.645
11 1.11 0.188 0.280 0.658
12 1.12 0.198 0.294 0.756
13 1.13 0.208 0.309 0.755
14 1.14 0.218 0.324 0.768
15 1.15 0.267 0.397 0.750
Тут произошло странное.
Наткнулся у продактов на непонимание, как проверить качество метрики математикой. И что такое вообще качество метрики.
Короткий ликбез ниже.
Дано:
Метрика, которую используем для анализа изменений(а для чего еще нужны метрики). Например, доходность клиента за месяц.
Для каждой метрики нам по существу надо дать ответ на 3 вопроса:
1. Позволяет ли метрика не ошибаться: эффект есть или его нет(пусть это вероятность ошибки первого рода)
2. Позволяет ли метрика замечать эффект, когда он реально есть. Это мощность теста(или 1 -ß)
3. Интерпретируем ли эффект от метрики: действительно ли увеличение среднего дохода на клиента в месяц приводит к увеличению доходов на клиента вообще.
В общем смысле:
По первому и второму пункту наиболее часто это 0.05 для α и 0.8 для (1 -ß).
По третьему сложнее, есть отдельная наука, как это вычислять. Мне хватает корреляции.
Большинство данных будут иметь либо биномиальное, либо степенное, либо лог нормальное распределение. Часто есть данные по метрике за прошлые периоды.
Проверить первый пункт можно следующим образом:
Промоделировать AА тесты. Mного раз (1000–10000) случайным образом выбрать 2 репрезентативные группы из данных и при помощи стат. критерия(отдельная тема, но пусть будет t.test для среднего дохода) сравнить выборки между собой.
Чтобы соблюсти условие в 0.05 вероятности ошибки первого рода, 95% АА тестов не должны показать стат. значимое различие.
Проверить второй пункт аналогично:
Выбрать много раз (1000–10000) по 2 репрезентативные группы, но на этот раз последовательно увеличивать реальные значения в одной из групп на 1,2,3...n % процентов, пока эффект не начнет быть стат. значимым в тесте.
Тут важно понять, на каком проценте увеличения метрика уловила изменение.
Идем за эффектом в 0.03, а мощность(чувствительность) метрики позволяет ловить только 0.1 процент увеличения. Такую метрику использовать нельзя, не заметим эффекта. Нужно либо обрабатывать данные(например, взяв логарифм значений для логнормального распределения), либо менять метрику, либо увеличивать количество наблюдений в группах, либо менять критерий, которым оцениваем на подходящий.
Проверить третий пункт:
Посмотреть сонаправленость метрики.
В случае с доходом все более-менее понятно, но часто мы пытаемся соотнести метрики вида "Время сессии - Ретеншен". И тут надо убедиться, что на исторических данных увеличение времени сессии коррелирует с вероятностью ретешнена(важно помнить, что корреляция не означает причинно-следственной связи).
Моделирование - мощный инструмент контроля качества метрик. Оно дает возможность оценить полезность метрики и реже ошибаться в АБ тестах.
Для трюков с моделированием хорошо бы освоить R или Python на начальном уровне.
У меня есть новый герой по управлению продуктовыми командами.
Думаю что за этим будующее.
Все меньше нужны асбтракнтные менеджеры, и все больше нужны люди которые будут реально писать требования, реально ставить задачи и анализировать данные. А не на встречах разговаривать разговоры и размышлять о ценности.
Давно не писал, запускал продукт.
Много вокруг на тему поиска ценности происходит.
На рынке мало случаев когда продукт не сумели сделать. Меньше случаев когда
не посчитали экономику. Главная проблема которую вижу - поиск ценности
И тут не стоит себе врать. Ценность это не то что делает команда.
Это то почему пользователь выбирает продукт. Что можно сформулировать парой предложений.
Последние два раза когда я спрашивал какую ценность создает команда получал такие ответы
"Мы делаем интеграционный сервис для команд которые хотят привлекать баунс трафик от
нецелевых переходов на маркетплейсы"
"Мы делаем агрегатор маркетплейсов с лучшей ценой размещения"
Это кстати хорошие продукты, с шансами.
Но проблема в том, что ценность там это "Дешевый источник массового трафика" и "дешевая техника".
Вроде очевидно — но вызывает другие вопросы. Единственный источник?
Цена лучшая?
У пользователей хватает альтернатив. И купить трафик, и технику и лайки посмотреть — достаточно предложения.
И где заметки вести и где диаграммы рисовать, телефон, которым звонить, карта которой платить.
Поиск ценности заключается в честном ответе пользователю "Почему я должен купить именно у тебя?"
Это важно не для того что бы продавать. Вокруг ответа на этот вопрос и строится продукт.
Четкая формулировка ценности мгновенно приоритизирует беклог, наполняет его, создает понимание
какая нужна аналитика.
Если продукт банк, до денег в котором не доберется ни одно
правительство. - То сразу ясно, кто клиент, где этот банк открывать, какие сотрудники, какие продукты. Даже размер процентов по вкладам ясен.
Да даже какая газета на столе в отделении банка тоже ясно.
Много пустых раздумий и разговоров от того что ни продакт ни команда не
понимают ценности.
Нет - продакта ответ
Работа продакта - это решать, что делать.
Помимо очевидных плюсов, такой склад ума генерирует десятки идей.
Плюс как правило люди приносят кучу идей, на тему что делать с продуктом.
В этот момент тяжело определится, что стоит брать в работу и почему.
Курсы и паблики на этот счет отвечают моделями скоринга и приоритизации.
RICE, КАНО и тд.
Это уход от ответственности за продукт.
Я бы хотел поделиться другим подходом.
Нужно для каждой фичи ответить на ряд вопросов.
1. Какую проблему решаем этой фичей?
Нужен честный и детальный ответ, оптимально - выраженный в метриках продукта.
Например - "Хотим принести больше счастья клиенту" - плохо.
"Чиним конверсию на 5-м шаге воронки на 20%" - хорошо.
2. Как узнали что проблема есть?
Люди часто подменяют факты умозаключениями. Важно убедится, что проблема есть, она корректно сформулирована и очевидно проистекает из данных.
И сразу говорю, что "Отклонение больше 2 сигм от прогнозных значений конверсии" - это не очевидно.
"50% клиентов не могут заполнить форму" - вот это очевидно.
3. Cколько денег на этом заработаем?
Продакты в крупных компаниях живут в ощущении что деньги - бесконечные. А финансовые результаты - это цифры на слайде.
А зарабатывать деньги это не важно. Мир, работает иначе, и в нем если ты не зарабатываешь деньги, через три месяца ты увольняешь команду, а через 6 закрываешь продукт.
Уверен, что главная задача продакта - делать лаве.
4. Что будет если этого не сделаем?
Какие реальные последствия от бездействия ? Кто пострадает? Сколько потеряем клиентов?
Уговорить себя что-то делать легко. Научится отказываться сложно.
"Если этого не сделаем, то ценность нашего продукта для клиента будет ниже чем у конкурентов." - туфта.
"Если этого не сделаем - закроет регулятор". - просто и понятно.
5. Сможем ли это поддерживать?
Вопрос, о котором часто не думают. Поддержка замедляет движение.
Каждый операционный вопрос, который должна решать команда, крадет время у развития продукта.
Не надо умножать сущности без необходимости.
"Нам нужно нанять 10 специалистов на поддержку этой фичи" - крепкий повод задуматься.
6. Как поймем что проблема решена.
Последняя проверка. Если в голове есть четкий образ результата, что должно измениться с внедрением фичи - то и измерить сможем.
Если нет возможности измерить результат, возможно не стоит и делать.
В моем случае, четкие и честные ответы на эти вопросы дают четкое понимание, что,нужно делать а что нет.
И нет я отвечаю намного чаще чем да.
Вижу много продактов и аналитиков которым трудно структурировать информацию и организовывать процесс поиска проблемы.
Любая проблема вызывает пучок гипотез , которые будут перебираться одна за одной.
Например, задав вопрос - почему вырос отток?
В ответ вполне реально получить список неплохих идей вида
- уходят к конкурентам
- у нас дорого
- продукт перестал соответствовать требованиям
- плохая поддержка
- технические проблемы
И все это может быть так. Но проверяя гипотезы одну за одной - тяжело найти причину за гарантированное время.
Альтернативный путь - это использовать принцип MECE
Смысл - описать все возможные решения проблемы так, чтобы они не пересекались и не дублировали друг-друга. То есть «нарезать» общую задачу на части, каждая из которых будет уникальным и неповторимым решением проблемы
Это позволяет решать проблемы значительно быстрее и эффективнее.
Подробный разбор метода
На русском
https://why.esprezo.ru/mece-principle
на английском
https://www.caseinterview.com/mece/
Я много проверяю тестовых заданий и много помогаю с дизайном экспериментов.
Вижу какую тенденцию
1. Продактам тяжело формулировать гипотезы в принципе
2. Продактов научили формулировать в виде "Покрасим кнопку- поднимим конверсию на 10% и снизим стоимость привлечения на 2000 рублей"
Хорошо что формулируют. Плохо что часто от желания показать " мы на цифрах!!!" заваливают эксперименты
Хочу поделиться своим подходом.
Итак - мы собрались что то проверять. Мы всегда проверяем конкретные вещи, про которые мы можем на простом языке
сформулировать понятную идею которую мы собираемся проверить.
Начнем с простого
"Покрасим кнопку - увеличим конверсию"
"Дадим всем карты - увеличим доходы по картам"
Чуть более сложное
"Если снизить цену - то рост объема компенсирует выпадающие расходы"
"Если останавливать подписку у заснувших клиентов отток уменьшится и мы заработаем больше, чем потеряем " (привет нетфликс)
Смысл в том, чтобы уйти от выдумывания конкретных цифр,
к моделированию условий при которых изменение имеет экономический смысл.
Выбрать метрику для проверки это ответственно. Разобравшись на предыдущем шаге какой эффект мы ждем
принять решение о конкретной метрике намного проще. Проверяем гипотезу об уменьшении оттока от остановленной подписки-
измеряем отток в контрольной группе. (спасибо, кэп)
Где нужно называть цифры и зачем они нужны практически (ну кроме соревнования кто сильнее впечатлит CPO)
Дело в том, что в большинстве стат критериев которыми будут оцениваться АБ тесты требуется понимать размер эффекта для
того, чтобы получить стат значимость.
Например, если мы подняли продажи в 10 раз, то нам достаточно 100 клиентов в контрольной группе.
Если мы подняли продажи на 0.00001% то нам нужны миллионы клиентов чтобы доказать стат значимость.
Поэтому практический смысл большинства цифр, предполагаемых по эксперименту - нужен для расчета размера контрольных групп.
Для этого достаточно ответить на вопрос
"Какой минимальный размер эффекта меня устроит?" мне нужно изменение минимум на 5% и тд.
Итого набор хороших практик
1. Формулируйте идеи, так , чтобы было понятно как они логически работают.
2. Моделируйте условия в которых понятен экономический смысл мероприятия.
3. Выбирайте метрику, которая показывает тот эффект за которым вы идете, а не зависимые от него метрики.
4. Определяйте минимальный размер эффекта который вас устроит и от него считайте контрольные группы
Очень крутая статья Руслан Фазлыева
про глубокую работу и книгу Кэла Ньюпорта.
Мне всегда было важно не все успевать ,а концентрировано работать. Часто я за пару часов могу сделать огромный объем работы, но требуется состояние потока.
Рекомендую и кнингу и статью
https://aznakai.medium.com/в-работу-с-головой-39bc749d3a2a
От размышлений и лирики - к практике.
В разговоре с важным для меня человеком всплыло - что общая беда контента - мало практики.
Много концепций и общих слов, а мало конкретики.
Одна из доминирующих концепций созданий продуктов здесь и сейчас - управление продуктом при помощи аналитики.
Но очень мало материалов и объяснений - как именно принимать решения по продукту на данных.
Я хочу поделится своим подходом - на примере реального кейса. Как из очень сырых и низкоуровневых данных достать
экономику продукта за 30 минут.
https://rpubs.com/strut/725566
P.S - про инструменты, сделаю отдельный пост. Коротко - все сделано при помощи R. Rmarkdown для оформления.
Сегодня состоялся один разговор, из важных. Со старым товарищем обсуждали былое и думы
Вообще самое сложное деле продакта - разносторонность.
Всем приходится варится в куче контекстов - от архитекутры и конкретных методов апи
до продуктовой стратеги, управления командой и мотивации людей. Я не говорю про анализ данных и прочее.
Это конечно предъявляет планку, и это сложно по-честному. Но не это определяет.
Мы пытались сформулировать что определяет твой успех. По факту - скорость принятия решений.
В любом контексте и под любым давлением.
Еще в консалтинге (а это близкая по информационной плотности среда) - я видел разбитых
консалтеров. И они были умные ребята, способные в спокойной обстановке принимать хорошие и взвешенные
решения. Только жизнь устроенна таким образом, что на все важные вопросы приходится отвечать
посреди горящего дома. Все умные и добрые когда все хорошо. Но определяет - другое.
Насколько ты хорош под давлением и в стрессе.
Я недавно подписался - что буду любое продуктовое решение принимать внутри одного дня.
Посмотрим как будет.
Кстати - быстро принимать решения - хорошо считать и структурировать.
Раз вспомнили консалтинг - то иерархический подход к принятию решений и MECE - мощные штуки.
А бывает так, что про UX не очень думают). Знакомый показал, а я проверил.
Итак задача. Узнать цену производителя на конкретные часы.
Омега (швейцарские часы ) не смогла сделать форму регистрации на сайте что бы ее можно было пройти.
Потому что очень хотят спрашивать язык на котором присылать ньюслетер и без него не региструют.
Но поля указать язык тоже не добавили. Рега заблокирована
Но и это еще не все
Что бы узнать цену - надо написать в бутик. Само по себе очень странно.
Но если написать в бутик (а кстати в несколько бутиков с одного емеила написать не получится без регистрации)
То ответ приходит
"Привет, у нас нет сейчас такого на складе"
В итоге, омега не зарабтает приличный кусок маржи, который бы могли заработать.
Вот так грузинская шаверма смогла, а омега не смогла.
Знаете что это?Это UX.
Так привозят шаверму в некоторых доставках Тбилиси.
Отмечают как приготовлена шаверма. Не маркером пишут на ней(иди разбери почерк), а ставят галки.
Если заказал две+ понимаешь, какая где.
Нет вопросов как приготовлена.
За этим стоит серьёзный объем работы.
Список действий:
1. Узнать что проблема такая есть.
2. Придумать как аккуратно решать
3. Разработать вариации приготовления
4. Включить в дизайн упаковки
5. Настроить интеграцию с доставочными сервисами
6. Выстроить процесс где кухня будет отмечать.
Вряд ли это можно померить аб тестом. Плотность заказов не позволит ловить эффекты в районе ретеншена.
Да и честно говоря это вряд ли перекроет спрос по цене/вкусу.
Так что UX - это не только про прирост в метриках.
Это "Посмотри как пользователь делает и реши какую-нить его проблему".
Реальная работа над UX выглядит именно так.
Надо продолжать.
Поговорили с Юрой Агеевым, про то какой теперь финтех и какие деньги.
https://youtu.be/aifHsyXNj-A
Продолжая тему прошлого поста.
LT - не единственное место, где плохо. Расчет ARPU / Среднего чека из традиционной формулы тоже таит в себе много нюансов и ловушек)
Написал о них на медиуме
Поговорил с Юрой Агеевым (Конференции Product Sense, подкаст make sense) про финтех. Есть подкаст есть видео)
Читать полностью…
Принято считать - что вот на западных рынках продакты намного сильнее, чем в России. Отчасти это так, в силу того что выше ставки, конкурентные рынки.
После десятков проведенных мной интервью на позиции менеджеров продукта, и решил посмотреть, как устроена структура интервью на западе и оценить уровень кандидатов
И по большому счету - разочаровался.
Люди с образованием за сотни тысяч долларов совершают много когнитивных ошибок.
https://www.youtube.com/watch?v=se6Soyi2k0U
Девушка из стенфорда, которая идет в фейсбук.
На вопрос - как она бы встраивала платформу с фильмами в экосистему фейсбука довольно быстро
начала рассуждать про использование имеющегося социального графа для создателей видео.
Какая ошибка - поиск решения не от проблемы, а от инструмента.
Говорит при этом круто, в классной тональности.
Но это явно магическое мышление. Прикрутим социальность к процессу создания видео.
https://youtu.be/e0Nj_eYDj2s
Парень с оффером из гугла. Примерно та же проблема.
Нет ни слова о том, как будет валидировать, что проблема реальна.
Как поймет, что у него получилось.
https://youtu.be/aJxiSYiNwXk
Девушка, готовясь к майкрсофоту, на вопросе про product KPI льет воду про инфлюенсеров и блогеров.
Это конечно небольшой срез, но какого-то превосходства, кроме как в софт скилах над ребятами с наших рынков
я не вижу.
Кто планировал - можно дерзать)
В жизни продуктов наступает момент, в котором принимается решение о масштабировании. Это сложное решение.
Главное требование - рациональный и трезвый взгляд на состояние продукта.
На этапе формирования гипотез врать себе даже полезно, но при переходе к масштабированию надо четко понимать состояние элементов продукта, так как масштабирование увеличит проблемы.
Как понять, что пора.
- Юнит экономика сильно положительная и есть запас по ухудшению. Со временем привлекать становится дороже. Хорошо, если соблюдется LTV/CAC ≥ 3 ("Life time value"/"Customer Aquasiotion cost"). На масштабировании стоит ожидать резкого взлета стоимости привлечения. Если получится в итоге прийти к 1.5, то это неплохой результат.
- Есть четкое понимание, как масштабироваться - каналы, управление привлечением, воронки. Есть четкий ответ, как получить в продукте в 10 раз больше пользователей, чем сейчас, подробный ответ как получить в 50 раз больше и примерный, как получить в 100 раз больше. Не протестированный канал привлечения не то, чем кажется. Если в спешке начинать подключать каналы, будут потери в деньгах.
- Определена ценовая политика. Любые метания с ценой на масштабировании будут его тормозить.
- Нет простого способа еще расширить круг потенциальных клиентов.
До того, как масштабироваться.
Разобраться с операционной моделью.
Серьезно, это важно. Именно с этого из продукта растет бизнес.
Рост будет происходить со скоростью самого медленного участка бизнеса.
Деньги на масштабирование будут тратиться со скоростью самого быстрого участка - это маркетинг. Участок, рост которого требует больше, чем линейного вложения ресурсов в перспективе, остановит масштабирование(вопрос на какой точке).
Как найти такие участки.
- Везде, где люди. Люди плохо масштабируется: нанимать, учить, управлять, контролировать - это требует больше и больше людей на управление. Люди быстро заканчиваются.
- Везде, где требуются ресурсы материального мира: место на складе, место в контейнере, реальный чип в устройстве и тд.
Что с ними делать.
- Упрощать и автоматизировать процессы. Выкидывать лишнее.
- Понять, что можно будет быстро купить.
- Понять, насколько критично падение в качестве. Например, сложно масштабировать поддержку с нужной скоростью. Жертвовать будете временем ожидания ответа и качеством ответов. Что случится, если оно сильно изменится?(смотри примеры российских маркетплейсов, рост которых сильно сдерживало качество поддержки).
Экономика.
Любое масштабирование это цикл:
- Тратим, чтобы привлечь.
- Зарабатываем на тех, кого привлекли.
- Часть заработанного тратим на то, чтобы привлечь еще.
Через это нужна трезвая оценка:
- Сколько денег на "вкинуть в маркетинг".
- Как быстро пользователь окупит себя и позволит привлечь еще одного(важно учесть, что мы еще тратим деньги на команду, сервера и прочие расходы).
- Стабильный и постоянный приток пользователей лучше метаний от "Покупаем за любые деньги" до "Возьмем чуть-чуть".
Техника
- Убедиться, что продукт масштабируется с текущим техническим долгом.
- Убедиться, что все в порядке с практиками dev ops. Быстро откатиться, быстро увеличить мощности, быстро накатить релиз - это должно работать.
- Убедиться, что продукт стабилен и не падает раз в неделю.
Беклог.
- Сложно одновременно дорабатывать функциональность и масштабироваться. Либо то, либо другое в один момент времени.
- Фокус команды в момент масштабирования должен быть направлен на устранение проблем, а не на прирост.
- Главная оценка для приоритизации задач - влияние на масштабируемость.
Аналитика.
- Надо знать, куда смотреть, чтобы принимать решения.
- Научитесь принимать решения быстро, это очень важно.
Боевой дух
- Надо понимать, что будет давление: от инвесторов и стейкхолдеров, от своих амбицией.
- Держитесь и принимайте решения со спокойной головой.
В продукте нет вещей, за которые не несет ответственность владелец продукта. Придется разобраться и в маркетинге, и в финансах, и в управлении.
Так за МВП и быструю проверку гипотез.
Современная мета управления продуктом предполагает что надо
а) Рано показать продукт пользователям
б) Сделать это без или с минимумом разработки.
Проверять C1 и то как конвертит офер - это очень важно.
Но руководствуясь этими идеями можно застрять в ловушке не сделанного продукта.
Как это происходит.
Продакт менеджер нашел идею и обернул в продукт с ежемесячной подпиской.
На "руках" запустил продукт что бы проверить метрики и воронки. (C1, C2,...Cn)
Решил продать клиентам. Потратил много сил на запуск, продал.
Предполагается, что это способ понять интерес пользователей за минимум денег.
За ряд итераций, поднять конверсию в первую покупку до нужной, разобраться с причинами низкой конверсии во вторую покупку.
Отточить механику и только тогда тратить деньги на автоматизацию и идти в масштабирование.
А в реальности.
Куча энергии будет потрачена на ручной запуск.
Конверсия первой волны — плохая. Но сколько то клиентов купят. Опыт клиента надо обеспечивать вручную.
На продакта и команду уже ложится нагрузка по поддержанию процесса. Конверсия во вторую продажу низкая, потому что
продукт работает "на руках" , ограничен по функционалу и реальную проблему не решает. А часто еще и не соответствует предложению на лендинге.
Каждая новая итерация теста конверсии добавляет еще пользователей в ручной продукт, и делает пользовательский опыт еще хуже (больше клиентов - сложнее вывозить)
и еще глубже роняет конверсию.
В итоге нескольких месяцев усилий измученный продакт приносит цифры вроде
5000 лидов, 100 клиентов, конверсия в первую продажу - 2%, во вторую 15%.
На основании этих данных сложно сделать вывод, насколько продукт реально нужен, какая у него экономика, решает ли
проблему пользователя. По сути - время было потрачено зря.
Недавно запустил сложный транзакционный продукт. Разработка шла долго.
Сделал только самое важное. (даже коммуникации не автоматизированы — для примера)
Продукт по первым приметам - зашел. Получил долю справедливой критики о том, что запуск нужно было сделать проще и быстрее, пусть и на ручном труде.
Клиентский опыт - проверяется полноценно. Над продактом не висит ручная поддержка.
Как лучше - сложно сказать, это контекстный вопрос.
Главное, четко понимать что нужно узнать и какие данные получить. Как эти данные будут интерпретироваться эту информацию, какую проблему клиента решает продукт
Моя позиция - быстрая проверка гипотез это быстро разрабатывать и давать такой опыт клиентам, который решает проблему.
Безумная гонка за ручной проверкой часто вредит.
Нет смысла пытаться продать скейтборд клиентам, которым нужна машина.
Но куча картинок про МВП убеждают меня в обратном.
Маленкая фича
Часто себе напоминаю, что нет маленьких фич.
Если делать нормально — то любая фича большая.
Например, в продукте случаются скидки. У них есть свойство заканчиваться.
Клиента нужно сообщить о том, что скидка заканчивается. Например, при помощи пуша.
Задача — по факту простенькая.
Определил триггер, сделал текст, разработка, тестирование.
Но если начинать смотреть на этот сценарий с точки зрения создания ценности для клиента, то оказывается, что этого недостаточно.
Возникает ряд новых вопросов.
Клиент смахнул пуш. Появляется следующая группа проблем.
Куда ведет пуш.
Какое целевое действие.
Какой tone of voice в этой точке взаимодействия?
Какой вариант работает лучше?
Как достоверно определить что этот вариант работает лучше?
Вот только в этот момент начинается работа с ценностью и пользовательским опытом.
Дальше больше.
Какой нужен подход к клиентам у которых закончилась скидка.
Что и когда клиентам предлагать в следующий раз.
Как изменить коммуникации по отношению к этом клиента.
По этим вопросам нужны данные, волевые решения, контроль результатов и метрик.
Разумеется, в силу приоритетов не каждую задачу можно прорабатывать настолько глубоко.
Но без глубокой проработки шансов создать реальную ценность для клиента немного.
Нет маленьких фичей :)
О юнит экономике писать легко, но надо и о лирическом.
Кейсы и проверенные практики.
Частый запрос продактов и команд - вынести какие-то практики и решения. Кейсы, подходы.
Это вроде как даже ценится как аргументация.
Нетфликс то, а фейсбук с гуглом се. :)
Скептично отношусь к этому. Не потому что считаю себя умнее. Везде куча крутых людей.
Время готовых решений ушло.
В 2012 году в консалтинге - проект редко брали, когда после пары встреч с клиентом не знали какую методологию будем использовать.
Почти всегда брали проект - когда было несколько похожих проектов в прошлом. Этот вариант - любимая работа консультанта - менять название клиента на слайдах прошлого проекта.
Мой выход из консалтинга пришелся на важный момент.
Раньше клиенты покупали готовые решение. Мир изменился и клиенты ждали формирования решений в процессе. Система заточенная на продаже кейсов рухнула и накопленный опыт перестал что -либо значить.
Большинству из нас приходится ставить годовые и квартальные цели, хотя и рассказываем об аджаилах. Этот подход с декомпозицией годовых целей компании придумал Питер Дакер в 1954 году. В 2010 году еще случались проекты по внедрению. В страт. домах спрашивали этот фреймворк на собеседовании.
Наработки по этой методологии за 70 лет не стоят ничего.
В продуктовых делах наступает такое же. Важно уметь быстро разбираться, а не знать. Скажу непопулярное - насмотренность переоценена.
Понимание связей, умение выстроить правильные цепочки абстракций - принесет больше чем посмотреть 50 лендингов у конкурентов.
Юнит экономика
Все научились считать юнит экономику.
Ок, LTV-CAC - операционные расходы на поставку единицы продукции, жестко привязанные к единице продукции.
Ок, не надо класть расходы на офис, команду в юнит экономику.
Главная сложность у продактов - что брать за юнит.
Я поделюсь своим подходом.
Есть два главных вопроса.
1. Вы хотите из каждой покупке в продукте выходить в плюсе или готовы зарабатывать на цепочке
из покупок?
2. Что вы масштабируете?
Подробнее по первый вопрос
Если вы продаете регистрацию бизнеса - вы хотите из каждой сделки выходить с плюсом.
В этом случае юнит это проданная квартира рейс самолета, ночь в номере отеля.
Если вы продаете подписку на музыкальный сервис - нормально ждать что пользователь окупится за несколько месяцев.
Тут юнит - почти всегда пользователь.
В большинстве случаев в диджитале - юнит это пользователь.
Второй вопрос сложнее.
Вообще вся юнит экономика имеет смысл в контексте масштабирования. Более менее развитый бизнес хорошо описывается в фреймворках
P&L и категорийного менеджмента. Вот доходы , вот расходы, вот ебитда.
Если бизнес способен заработать на одном юните то есть такое количество юнитов, которое выведет его в плюс.
Чем больше бизнес зарабатывает на одном юните - тем меньше юнитов нужно чтобы оправдать доходность.
Все рассматривается в контексте масштаба.
Но тут возникает еще один важный вопрос. Что именно мы масштабируем.
Хорошо когда модель понятная.Например онлайн магазина, приложения с подпиской на гороскопы.
Онлайн магазин - покупки или пользователь.
Приложения с гороскопом - скорее всего пользователь.
И тут в общем все ясно, что делать. Просто и понятно. Бери с пользователя больше денег, дольше удерживай,
сокращай расходы.
Становится сложнее например когда есть какой -нибудь маркетплейс типо убера.
Пусть юнит пассажир. Очевидное решение - "повышай комиссию сервиса " ведет к снижению количества водителей.
Снижение количества водителей к удорожанию поездки.
Удорожание поездки ведет снижению количества пользователей. И таких петель много.
Система стала сложнее и одной моделью не описывается.
И масштабировать нужно 2 части - пользователя и водителя.
И считать нужно и то и другое. Нужна модель связанных юнит экономик, где одна часть модели ведет к изменению другой.
В итоге, как выбрать юнит.
1. Определится с точкой окупаемости.
2. Определится с тем что вы масштабируете
Почему нельзя брать что угодно?
Потому что так мы теряем в эффективности.
Попытка оправдать затраты на привлечение первой же подпиской - ведет за собой повышение цены и низкую конверсию.
В сервисе про продаже квартир надежда что пользователь придет через 3 года и купит еще одному - не имеет хороших оснований. Надо выходить в плюсе из каждой сделки.
Что нужно делать, если сложно?
Поискать аргументы почему пользователь - это плохо.
В 9 случаях из 10 - для диджитал сервисов нужно брать пользователя.
Обещал про инструменты - рассказал про инструменты
Я системно(за исключением коммуникации) делаю три вещи
Пишу тексты (вот и сейчас)
Рисую схемы
Анализирую данные
Думаю, что делаю это довольно эффективно
Описал чем пользуюсь
https://fintechsamurai.medium.com/инструменты-продакта-699bf497f09a
Если вопросы - в коментах отвечу
Нашел классное видео про CJM.
Расписал собственные мысли - почему реальный рабочий CJM не похож на то что обычно показывают
как CJM
https://telegra.ph/Skorej-vsego-vy-nepravilno-gotovite-CJM-02-19
Cобствено само видео
https://youtu.be/IihhE_QJy8s
про plantUML как инструмент - напишу отдельно)
Растить команду вширь или из сильных людей?
Мета всего диджитал бизнеса прямо сейчас - продуктовая разработка. И вот что интересно.
Начиналась вся идея с очень крутого принципа. Давайте не мешать талантливым и взрослым людям
делать дела. Уберем с них вотрефолл и 10 уровней начальников. И эта штука сработала.
Сейчас главная тема у топов по продукту - как находить людей и растить людей. И команды масштабируются вширь. У ведущих продуктовых компаний - по несколько
десятков если не сотен продактов, и часто в рамках одного продукта.
Есть и другой подход - "raise the bar". Каждый новый входящий человек - должен поднимать планку.
Давление внутри. Давление снаружи. Интелектуальный челлендж. Из известных - Netflix.
Может еще Revolut. Мне честно ближе вторая история.
Интересно смотреть на то какой подход покажет себя лучше и кто вывезет.
Так совпало что у меня сейчас с разных сторон много историй про кешбек
и всякие мотивационные программы для клиентов. И меня несколько удивляет
сложность, к которой приведены большинство из них. Выстраивается сложная
система из противовесов и сдерживающих факторов. Фундамент как мне кажется очень прост
Когда я ввожу программу кешбека- я всегда хочу что бы какое-то действие, от которого банк получает выгоду происходило чаще.
Я готов поступиться экономикой конкретного действия - если понимаем что в итоге - падение экономики будет скомпенсированно объемом действий.
На модельном уровне это может быть выраженно как
Объем действий / ( доход от действия с мотивацией/доход от действия без мотивации)
