Борода продакта

2022-08-04 18:06:53 Продуктовый митап в Питере

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

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

В следующий четверг (11 августа) совместно с командой приложения «Кошелёк» проведем в Питере продуктовый оффлайн митап.

Общая тема: поиск возможностей в текущих реалиях.

Cпикеры и доклады:

Сергей Тихомиров
Автор Product Architecture Framework и канала «Борода продакта», ex. Яндекс Практикум, eLama.

Тема: Остаётся ли рабочей хоть одна модель управления продуктами в ситуации ТАКИХ изменений рынка?

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

Вячеслав Аскалепов
ex. Head of Product Discovery в Манго Страхование.

Тема: Как в ситуации неопределённости найти ценность продукта при помощи концепции пути героя

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

Анна Чернуха
Product Manager Монетизации в Приложении «Кошелёк».

Тема: B2B исследования: глаза и уши продакта в период изменений

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

Место: Санкт-Петербург, улица Лодейнопольская, дом 5, бизнес-центр Петроконгресс. От метро Чкаловская 6 минут пешком.

11 августа, начало в 19:00.

После докладов соберёмся на небольшое афтепати в офисе команды приложения «Кошелёк». В том же здании, но на пять этажей выше. Будут пицца, фрукты и безалкогольные напитки, можно будет познакомиться и пообщаться со спикерами, другими участниками и продактами «Кошелька».

Участие бесплатное.

Регистрация здесь

Запись сделаем, выложим отдельно. Если вам нужна только запись, регистрироваться не нужно.

Всем питерским быть очно! Открыть/Комментировать

2022-07-27 18:10:54 А еще набираются заявки на открытую стратегическуб бизнес-игру Game of PAF https://productframework.ru/gameofpaf

6 августа в Санкт-Петербурге
13 августа в Москве

А вот тут можно посмотреть отзыв с прошлой игры, которая проходила в офисе ВК https://www.instagram.com/p/Cf0m_vnsQpP/

P.S. Ceterum censeo Carthaginem esse delendam. Открыть/Комментировать

2022-07-27 18:06:22 3. Выбранный критерий для сравнения гипотез не сочетается с целью

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

Некоторые же, используя модель ICE-скоринга, просто от балды указали значение impact, не связав его ни с одним из параметров модели. Это ошибка. Impact не может быть абстрактным. Если вы не понимаете, на что именно (на какое свойство продукта) влияет гипотеза, а просто скорите, чтобы поскорить, кажется, что вы занимаетесь ерундой.

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

Первый способ - это когда для различных гипотез используется одну модель [экономики], и один из параметров берется в качестве импакта. Например, LTV 6 месяца или ROI. Далее, этот показатель нормируется (например, определяется процент роста импакта относительно номинальной модели). Далее минимальный процент роста из списка текущих гипотез обозначается как 1, а максимальный процент роста как 10. Остальные проценты распределяются на шкале с шагом равным (max - min) / 10. Особенностью такого способа является то, что он четко привязан к текущему списку гипотез, поэтому всегда можно определить гипотезу с максимальным и минимальным импактом (по отношению к другим гипотезам в беклоге).

Второй способ хитрее, но он позволяет оценить "мощность" существующих гипотез. В нем также выбранный показатель импакта нормируется (например, тот же процент роста от номинала), но шкала задается не существующими значениями процента роста, а договоренностями команды. Например, "мы считаем, что рост импакта в 35% и более - это 10, а 0% или меньше - это 1". Все остальные проценты располагаются на шкале между. Такое представление позволяет вам понять, насколько "мощные" гипотезы в контексте импакта существуют в вашем беклоге. Например, если окажется, что у всех показатель 2-3-4, то лучше решать задачу не приоритизации текущих гипотез, а задачу генерации более сильных. Открыть/Комментировать

2022-07-27 18:06:03 Продолжение разбора ошибок в тестовом задании. Вторая часть первого задания посвящена решению о том, какая из трех гипотез принесет максимальный импакт по сравнению с другими.

1. Рассуждения без привязки к модели продукта

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

2. Нет аргументации к выбору модели скоринга

Большинство используют для скоринга гипотез модель ICE из-за простоты и популярности. Но мало кто задумывается, почему нужно применять именно её, а не какую-либо другую модель скоринга. Типа вот молоток - давайте применять его ко всему, что угодно. Сказывается недостаток системного образования.

Модель ICE-scoring предложена Шоном Эллисом, отцом Growth Hacking, и заключается в оценке гипотез роста (sic!) по трем параметрам: импакту, простоте проверки и нашей степени уверенности в первых двух показателях. Она хорошо подходит, когда сравниваются друг с другом гипотезы роста прибыли или ценности. Когда она работает плохо - когда вы в одном беклоге пытаетесь отскорить гипотезы роста, задачи оптимизации платформы или запуск новых инициатив (продуктов / фич). То есть когда вы полностью забиваете на понимание контекста вокруг инициатив, и всё превращается в гвозди.

Это не говоря уже о субъективности определения каждого параметра модели: impact, ease, confidence. То есть для двух разных "оценивателей" одного и того же беклога в значении скора могут оказаться разные результаты. Соответственно, и приоритизация будет отличаться. Чтобы снизить фактор субъективности используются "договоренности" о значениях. Например, что 1 в Ease - это полгода, а 10 - это один час (соответственно для остальных чисел - всё, что между). Или что такое 10 в значении impact? 3? 6? Непонятно. И уж совсем мало кто знает, что Итамар Гилад предложил "колесо" для определения confidence level (https://miro.medium.com/max/1400/1*AwSnjz4xNlxY0f-rkUJ8oA.png)

Или кто-то выбирал модель скоринга RICE, предложенную Intercom (и от которой отказались по слухам). Но блин, тогда почему RICE, а не ICE? И как принять решение о показателях reach, не имея вводных? RICE используется, когда ваш продукт достаточно большой, чтобы в нем появились сегменты пользователей, которые не используют все фичи продукта. Поэтому важно указать объем аудитории, на который повлияют эти изменения. Открыть/Комментировать

2022-07-25 21:37:04 Да, только у одного человека среди 15 приславших готовое тестовое не было НИ одной ошибки в юнит-экономике согласно системе ассесмента. Саша, привет.

P.S. Ceterum censeo Carthaginem esse delendam. Открыть/Комментировать

2022-07-25 21:24:06 4. Другие "мелкие" вещи

Некоторые путают понятие юнита и среднего количества сделок за период (average payment count). Не сказать, что здесь все очевидно - иногда не сразу удается понять, что именно должно быть юнитом в модели. Например, в каком-нибудь ecommerce типа Яндекс.Лавки юнитом может быть клиент, который совершает n сделок за период. А для салонов автомобилей юнитом может быть машина. А может быть и клиент, который совершает только одну сделку за все время его жизни. Или в каком-нибудь saas для smb юнитом может быть клиент, а сделкой один месяц подписки. А может быть сделкой и каждый отдельный день этой подписки (например, в финансовых инструментах). Или в ресурсных моделях юнитом может быть клиент, а количеством сделок - количество потребляемых (покупаемых) ресурсов. А может быть юнитом и какая-то аккумулятивная часть ресурсов, например, как инстанс в Амазоне (особенно, если подразумевается, что вы привлекаете клиента в покупку каждого такого инстанса). Короче, важно четко осознавать разницу между юнитом и сделкой, которая совершается в рамках бизнес-модели.

Еще одной удивительной для меня ошибкой стал неверный расчет ROI. Как показатель окупаемости он рассчитывается на основе LTV и CAC, но кандидаты кто как только ни делал: вычитал из объемных валовых показателей прибыли показатель расходов, просто брал ARPU - CPA, или ARPC делил на CAC. Хотя формула в интернете есть. Открыть/Комментировать

2022-07-25 21:23:51 3. Неверный расчет LTV

Практически все совершили эту ошибку - вместо Life Time когорты берут Life Time отдельного человека в итоге получается неверно рассчитанный LTV.

Например, в задании было сказано, что life time когорты = 4 месяцам. Это не значит, что все клиенты когорты будут жить 4 месяца. Это значит, что все пользователи этой когорты уйдут из неё к концу 4 месяца. И уходить они будут не сразу, а постепенно.

Например, в первый период пришло 180 покупателей - на конец четвертого периода останутся 0. Это не значит, что все 180 будут покупать все 4 периода. Это значит, что в первый купят 180, во второй 120, в третий 60, в четвертый 20, начало пятого - ноль. Соответственно и LTV не будет равно 4*arppu*margin (это ошибочная формула). Он будет намного меньше.

Вот здесь показана симуляция этой логики https://fintechsamurai.medium.com/%D1%83%D1%81%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B2-ltv-5badcc27e9d5 Открыть/Комментировать

2022-07-25 21:23:32 2. Смешение разных моделей в одну

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

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

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

2022-07-25 21:23:02 Итак, продолжаю серию постов о разборе ошибок при выполнении тестовых заданий. Сегодня о модели экономики.

1. Отсутствие модели

Самое главное, что проверяет первое задание - это умение продакта думать "моделью" того, чем именно он управляет. Продукт, бизнес-модель, компания, рынок и т.д. могут быть выражены в виде некоторой системы, состоящей из взаимосвязанных компонентов. Например, модель юнит-экономики, отображает взаимосвязь некоторых частей бизнес-модели и является точкой зрения на систему в контексте одного юнита. Взаимосвязь компонентов в этой модели явная: например, увеличьте конверсию и увидите, каким образом изменится CAC. Или сократите среднее количество сделок за период на клиента и посмотрите, как это отобразится в LTV. Сама "динамика" реализована через представление модели при помощи влияющих друг на друга математических формул в Excel или Google Sheet. Хотя, модель юнит-экономики - это не единственная модель, которой можно думать о продукте, хоть и самая популярная количественная.

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

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

В первом задании тестового требовалось показать модель юнит-экономики. Но часть кандидатов просто привела расчеты или общие формулы, например, ARPPU. А кто-то вообще сделал модель экономики в Miro (!!!). К сожалению, в этом не видна ни структура продаж, ни то, как генерируется прибыль, ни то, как клиенты остаются в продукте и к чему это всё приводит.

https://www.meme-arsenal.com/memes/8cb8c962f49601789e0409522a93dace.jpg Открыть/Комментировать

2022-07-20 14:49:04 Всем привет. Ребята из команды Английского от Практикума хотят сделать самый полезный и современный продукт по обучению английскому языку для взрослых (я им немножко помогаю в этом). Для этого нужна помощь тех, кто сейчас учит английский язык или находится в активном поиске продукта.

Если вы неравнодушны к этой цели, пожалуйста, заполните небольшую анкету https://forms.yandex.ru/surveys/13457126.94271c751900ccf82cc6d914d9e278c04ff34792/ и мы пригласим вас на интервью.

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

Большое спасибо! Открыть/Комментировать