Принимать решения на основе данных
Куда ни плюнь, а сейчас требуется уметь "принимать решения на основе данных". А на основе чьих данных? Глобальная вера в правильность исследований мне частенько кажется попыткой переложить ответственность за принятие решения на исследования.
В своём втором канале Продуктовошная (@suda_smotri) я недавно провёл опрос для такой ситуации:
- - -
Вы решили запустить в продукте изменение Х с формой оплаты и уверены, что оно положительно скажется на конверсии в оплату. Но не решаетесь запустить, а пишете в паблик: "Есть ли исследования, про изменения Х в форме оплаты?"
Вам кидают ссылку на два исследования: итальянское и немецкое. В обоих случаях подобные вашему изменения Х не привели к росту конверсии, а порой даже снизили её.
Что вы будете делать?
- - -
И знаете какие итоги?
23% — откажутся от эксперимента, так как есть данные исследований.
37% — плюнут на эти исследования и сделают эксперимент.
40% — попытаются найти исследования, которые всё же подтвердят гипотезу.
Меня волнуют эти 40%. Если им не понравились одни данные, то они хотят всё же найти те, которые понравятся, чтобы переложить на них ответственность за решение. Ценность данных нулевая.
Опрос не теоретический — ежедневно в пабликах появляются вопросы типа: народ, подскажите есть ли исследования, как картинки в тексте влияют на читабельность (или цвета кнопок, расположение надписей для полей и т.п.) ?
А исследования есть и, как правило, эти исследования рассказывают о какой-то средней ситуации. Мы изучили 5000 сайтов и поняли, что в основном читают контент по модели пинг-понг, поэтому надо делать контент таким-то.
Если полагаться на эти исследования, то ты сделаешь свой ресурс средним.
Но среди 5000 сайтов были же разные: на одних сайтах вообще не читали, на других читали всё подряд, а в среднем — пинг-понг. Зависит не от того, как читают, а от того, что читают — ценный контент или мусор. Все знают шутку, что средняя температура по больнице равна 36.6. Но в ловушку средних данных всё равно попадают многие.
Принимать решения на основе данных = принимать решения на основе своих данных, а не усреднённых чужих. Если своих данных нет, то можно взять чужие данные во внимание, но не более.
В общем, если эксперимент рассказывает о неких средних выводах, то можно смело его не читать даже. Через 2 года проведут ещё один эксперимент и новые средние данные покажут новые результаты.
#совет #продакту
- - -
Найди себе ментора: itkadr.ru
Куда ни плюнь, а сейчас требуется уметь "принимать решения на основе данных". А на основе чьих данных? Глобальная вера в правильность исследований мне частенько кажется попыткой переложить ответственность за принятие решения на исследования.
В своём втором канале Продуктовошная (@suda_smotri) я недавно провёл опрос для такой ситуации:
- - -
Вы решили запустить в продукте изменение Х с формой оплаты и уверены, что оно положительно скажется на конверсии в оплату. Но не решаетесь запустить, а пишете в паблик: "Есть ли исследования, про изменения Х в форме оплаты?"
Вам кидают ссылку на два исследования: итальянское и немецкое. В обоих случаях подобные вашему изменения Х не привели к росту конверсии, а порой даже снизили её.
Что вы будете делать?
- - -
И знаете какие итоги?
23% — откажутся от эксперимента, так как есть данные исследований.
37% — плюнут на эти исследования и сделают эксперимент.
40% — попытаются найти исследования, которые всё же подтвердят гипотезу.
Меня волнуют эти 40%. Если им не понравились одни данные, то они хотят всё же найти те, которые понравятся, чтобы переложить на них ответственность за решение. Ценность данных нулевая.
Опрос не теоретический — ежедневно в пабликах появляются вопросы типа: народ, подскажите есть ли исследования, как картинки в тексте влияют на читабельность (или цвета кнопок, расположение надписей для полей и т.п.) ?
А исследования есть и, как правило, эти исследования рассказывают о какой-то средней ситуации. Мы изучили 5000 сайтов и поняли, что в основном читают контент по модели пинг-понг, поэтому надо делать контент таким-то.
Если полагаться на эти исследования, то ты сделаешь свой ресурс средним.
Но среди 5000 сайтов были же разные: на одних сайтах вообще не читали, на других читали всё подряд, а в среднем — пинг-понг. Зависит не от того, как читают, а от того, что читают — ценный контент или мусор. Все знают шутку, что средняя температура по больнице равна 36.6. Но в ловушку средних данных всё равно попадают многие.
Принимать решения на основе данных = принимать решения на основе своих данных, а не усреднённых чужих. Если своих данных нет, то можно взять чужие данные во внимание, но не более.
В общем, если эксперимент рассказывает о неких средних выводах, то можно смело его не читать даже. Через 2 года проведут ещё один эксперимент и новые средние данные покажут новые результаты.
#совет #продакту
- - -
Найди себе ментора: itkadr.ru
Про Завязкина
— Как там твой макет?
— Жду обратной связи от Петровича. Вторую неделю уже!
— Ого, это же была срочная задача ...
— Да! Чтобы успеть, я на выходных даже работал. А оказывается не так и срочно.
— Может и срочно. Когда обратную связь даст, попросит побыстрее поправить.
— Это запросто. Вот же козлина.
Менеджеры и руководители, что проектные, что продуктовые, что дизайн-менеджеры, часто завязывают на себя лишние заботы и являются бутылочным горлышком. Менеджер-Завязкин, не умея делегировать и доверять, считает, что через него должно проходить всё: он согласовывает письма, макеты, обещает сам что-то дописать или нарисовать и т.д. Но у Завязкина есть и другие дела — менеджерские, которые он решает в первом приоритете, откладывая согласования дальше и дальше.
В итоге Завязкин частенько возвращает материалы с согласований без конструктивной обратной связи: бегло глянул (если глянул) и вернул, понимая, что уже сильно затянул. Не помог, а просто срок затянул.
В общем, вывод какой: если вы завязали на себя часть процесса и вас ждут, то это первый приоритет. Если не можете сделать ожидающих первым приоритетом — не завязывайте. Как только менеджер начинает сам "забивать" на сроки, то у него пропадает моральное право требовать соблюдения сроков от команды. Это право пропадает в глазах команды.
#совет #продакту
- - -
Выбрать ИТ-ментора: itkadr.ru
— Как там твой макет?
— Жду обратной связи от Петровича. Вторую неделю уже!
— Ого, это же была срочная задача ...
— Да! Чтобы успеть, я на выходных даже работал. А оказывается не так и срочно.
— Может и срочно. Когда обратную связь даст, попросит побыстрее поправить.
— Это запросто. Вот же козлина.
Менеджеры и руководители, что проектные, что продуктовые, что дизайн-менеджеры, часто завязывают на себя лишние заботы и являются бутылочным горлышком. Менеджер-Завязкин, не умея делегировать и доверять, считает, что через него должно проходить всё: он согласовывает письма, макеты, обещает сам что-то дописать или нарисовать и т.д. Но у Завязкина есть и другие дела — менеджерские, которые он решает в первом приоритете, откладывая согласования дальше и дальше.
В итоге Завязкин частенько возвращает материалы с согласований без конструктивной обратной связи: бегло глянул (если глянул) и вернул, понимая, что уже сильно затянул. Не помог, а просто срок затянул.
В общем, вывод какой: если вы завязали на себя часть процесса и вас ждут, то это первый приоритет. Если не можете сделать ожидающих первым приоритетом — не завязывайте. Как только менеджер начинает сам "забивать" на сроки, то у него пропадает моральное право требовать соблюдения сроков от команды. Это право пропадает в глазах команды.
#совет #продакту
- - -
Выбрать ИТ-ментора: itkadr.ru
Принимать решения вопреки данным
Очень сильный тренд в HR продуктовых команд — "умение принимать решения на основе данных". Эту строчку, как мантру, пишут в описание любой вакансии: программистам, дизайнерам, продактам ... всем.
Но есть и другие истории и этих историй не мало. Истории успеха и прорыва, в которых было так: "Чуйка: умение принимать решение вопреки данным". От Форда и его высказывания: "Если бы я спросил людей, чего они хотят, то они хотели бы более быстрых лошадей." До Джеффа Безоса и запуска Amazone Prime. Про Prime чуть подробнее.
Prime — это подписка для покупателей Amazone на скоростную доставку. Платишь определённую сумму в месяц и тебе доставляют любые товары быстро и бесплатно.
Внедрение Prime увеличило средний чек покупателя примерно в 2 раза + конечно, вырос LTV (доход от покупателя за всё его время).
Но в 2005, когда Prime внедряли, ситуация была такая (фрагмент из книги Брэда Стоуна "The Everything Store. Джефф Безос и эра Amazon"):
=====
Создание программы подписки на сервис ускоренной доставки Prime было во многих отношениях рискованным предприятием. Компания не имела точного представления о том, как программа повлияет на количество совершаемых покупок или изменит спрос на товары
различных категорий.
Если скоростная транспортировка одного заказа стоила компании 8 долларов, и если клиент, подписавшийся на данную услугу, осуществлял 20 заказов ежегодно, это обходилось Amazon в 160 долл. транспортных расходов, что значительно превышало сумму взноса, равную 79 долл.
Услуга дорого обходилась компании, и никакого ясного способа достижения уровня безубыточности здесь не существовало. «Мы приняли это решение вопреки выводам, полученным при анализе финансовых аспектов, которые подтверждали, что мы сошли с ума, решив бесплатно оказывать услугу двухдневной транспортировки», – говорил Диего Пьячентини (управляющий в Amazone).
Безос, однако, продолжал полагаться на свою интуицию и опыт.
=====
Прошёл бы Безос тестовое задание на продакта: Вы запустили услугу, оказание которой приводит к убыткам компании, а влияние этой услуги на поведение покупателей неизвестно. Ваши действия?
Вот такие выбросы.
#продакту
Очень сильный тренд в HR продуктовых команд — "умение принимать решения на основе данных". Эту строчку, как мантру, пишут в описание любой вакансии: программистам, дизайнерам, продактам ... всем.
Но есть и другие истории и этих историй не мало. Истории успеха и прорыва, в которых было так: "Чуйка: умение принимать решение вопреки данным". От Форда и его высказывания: "Если бы я спросил людей, чего они хотят, то они хотели бы более быстрых лошадей." До Джеффа Безоса и запуска Amazone Prime. Про Prime чуть подробнее.
Prime — это подписка для покупателей Amazone на скоростную доставку. Платишь определённую сумму в месяц и тебе доставляют любые товары быстро и бесплатно.
Внедрение Prime увеличило средний чек покупателя примерно в 2 раза + конечно, вырос LTV (доход от покупателя за всё его время).
Но в 2005, когда Prime внедряли, ситуация была такая (фрагмент из книги Брэда Стоуна "The Everything Store. Джефф Безос и эра Amazon"):
=====
Создание программы подписки на сервис ускоренной доставки Prime было во многих отношениях рискованным предприятием. Компания не имела точного представления о том, как программа повлияет на количество совершаемых покупок или изменит спрос на товары
различных категорий.
Если скоростная транспортировка одного заказа стоила компании 8 долларов, и если клиент, подписавшийся на данную услугу, осуществлял 20 заказов ежегодно, это обходилось Amazon в 160 долл. транспортных расходов, что значительно превышало сумму взноса, равную 79 долл.
Услуга дорого обходилась компании, и никакого ясного способа достижения уровня безубыточности здесь не существовало. «Мы приняли это решение вопреки выводам, полученным при анализе финансовых аспектов, которые подтверждали, что мы сошли с ума, решив бесплатно оказывать услугу двухдневной транспортировки», – говорил Диего Пьячентини (управляющий в Amazone).
Безос, однако, продолжал полагаться на свою интуицию и опыт.
=====
Прошёл бы Безос тестовое задание на продакта: Вы запустили услугу, оказание которой приводит к убыткам компании, а влияние этой услуги на поведение покупателей неизвестно. Ваши действия?
Вот такие выбросы.
#продакту
Про User Story
В требованиях к Менеджерам продуктов/проектов и UX-ерам периодически пишут: умение писать User Story (US). Так вот, писать US — это не ахти какая грамота и не надо путать User Story и Use Case.
User Story — это ожидания пользователей, записанные в компактном твиттер-формате, понятном всем (моё вольное определение).
Обычно их пишут в таком виде: Как РОЛЬ я хочу ЧТО ИМЕННО ХОЧЕТ, чтобы ЗАЧЕМ Я ЭТО ХОЧУ.
Например, Как подписчик канала Про удобство, я хочу, чтобы автор делился знаниями полезными для меня здесь и сейчас, чтобы я мог применять эти знания на практике.
Вместо, "Я хочу" могут быть и другие варианты: Мне важно, От меня требуется, Я вынужден.
Я обычно пишу US в таблицу со столбцами:
▫️User Story
▫️Роль
▫️Как учесть
На более-менее масштабные требования (обычно в проектной работе) приходится не 1-2 US, а целая пачка: может быть и 100, и больше. Поэтому роль я выношу за пределы US в отдельный столбец, чтобы не было 20-30 записей подряд с одним и тем же началом, да к тому же сортировать по ролям удобно.
В столбец "Как учесть" одним предложением пишу, как можно удовлетворить этой US в продукте.
В чём прелесть US
Они всем понятны. Это не прямые требования к продукту, это способ зафиксировать ожидания пользователей. К US удобно возвращаться, чтобы проверить, а соответствуем ли мы этому ожиданию или нет.
Не надо
▪️Привязывать US к интерфейсу. "Я хочу нажать на кнопку "Поиск", чтобы найти всё что мне надо" — это не US, а фантазия того, кто сформулировал ожидание в таком виде :)
▪️Описывать ожидания пользователей, не общаясь с пользователями. Правильный порядок такой: Интервью → Фиксация User Story.
Вот и всё.
В общем, самое сложное "доставать" User Story — интервью вам в руки. На практике могут быть нюансы в работе с US: проектная/продуктовая деятельность, госуха или b2b/b2с, способ планирования работы команды и т.п. Но сам формат US одинаков.
#UX #Продакту
В требованиях к Менеджерам продуктов/проектов и UX-ерам периодически пишут: умение писать User Story (US). Так вот, писать US — это не ахти какая грамота и не надо путать User Story и Use Case.
User Story — это ожидания пользователей, записанные в компактном твиттер-формате, понятном всем (моё вольное определение).
Обычно их пишут в таком виде: Как РОЛЬ я хочу ЧТО ИМЕННО ХОЧЕТ, чтобы ЗАЧЕМ Я ЭТО ХОЧУ.
Например, Как подписчик канала Про удобство, я хочу, чтобы автор делился знаниями полезными для меня здесь и сейчас, чтобы я мог применять эти знания на практике.
Вместо, "Я хочу" могут быть и другие варианты: Мне важно, От меня требуется, Я вынужден.
Я обычно пишу US в таблицу со столбцами:
▫️User Story
▫️Роль
▫️Как учесть
На более-менее масштабные требования (обычно в проектной работе) приходится не 1-2 US, а целая пачка: может быть и 100, и больше. Поэтому роль я выношу за пределы US в отдельный столбец, чтобы не было 20-30 записей подряд с одним и тем же началом, да к тому же сортировать по ролям удобно.
В столбец "Как учесть" одним предложением пишу, как можно удовлетворить этой US в продукте.
В чём прелесть US
Они всем понятны. Это не прямые требования к продукту, это способ зафиксировать ожидания пользователей. К US удобно возвращаться, чтобы проверить, а соответствуем ли мы этому ожиданию или нет.
Не надо
▪️Привязывать US к интерфейсу. "Я хочу нажать на кнопку "Поиск", чтобы найти всё что мне надо" — это не US, а фантазия того, кто сформулировал ожидание в таком виде :)
▪️Описывать ожидания пользователей, не общаясь с пользователями. Правильный порядок такой: Интервью → Фиксация User Story.
Вот и всё.
В общем, самое сложное "доставать" User Story — интервью вам в руки. На практике могут быть нюансы в работе с US: проектная/продуктовая деятельность, госуха или b2b/b2с, способ планирования работы команды и т.п. Но сам формат US одинаков.
#UX #Продакту
Data-driven облом
В конце 90-х по телеку показывали рестлинг, который комментировал Николай Фоменко. Многие смотрели именно из-за этих комментариев: "Обосратушки, мои!" — кричал Николай, и это было ново. Но не о рестлинге сегодня, а именно об обосратушках.
Интересная история провала бренда Coca‑Cola, которая произошла в 1985 году. Многие считают это самым крупным провалом в маркетинге 20 века.
Дело было так. Coca‑Cola всегда выигрывала у Pepsi и была (да и есть) напитком №1 во всём Мире. Но в 70-80-х стали падать продажи Колы, а Пепси при этом запустила крупную акцию: Pepsi Challenge и на слепых тестах стала выигрывать у колы по вкусу. Да, Пепси вкуснее на слепых тестах. Слепой тест, это когда тебе дают попробовать продукт, но не называют бренд.
Кола расстроилась на фоне всего этого и приняла решение поменять рецептуру: нам надо стать ещё вкуснее. И у них получилось — химики придумали новый рецепт, который на слепых тестах был вкуснее и оригинальной Колы, и новой Пепси. В общем, фокус-группы на (внимание на цифру!) 200 000 человек подтвердили, что новая рецептура вкуснее.
Радостная Кола запустила масштабную акцию: потратила миллионы на рекламу и дистрибуцию и стала ждать результатов. Банка осталась почти та же, только с ярлычком "Новая". Производство прежней колы было (внимание ещё раз!) остановлено.
И тут началось что-то, похожее на "Дуров, верни стену!", но в большем масштабе:
По всей стране возникали протестные группы, такие как «Общество сохранения настоящих ценностей» и «Сообщество американских любителей старой Coca‑Cola». Последние заявляли, что в их ряды вступили 100 тысяч человек, жаждущих возвращения прежней формулы. В честь старого вкуса сочинялись песни. А перед офисом Coca‑Cola появились демонстранты с плакатами, на которых было написано «Наши дети никогда не узнают, что такое чувство настоящей свежести».
Компания получала по 1500 звонков в день от покупателей — до появления новой Колы среднее ежедневное количество звонков не превышало 400. Глава совета директоров Колы, Роберто Гойзуэта, получал гневные письма. В одном из писем отправитель просил об автографе: «Однажды подпись самого тупого топ-менеджера в истории американского бизнеса будет стоить целое состояние!». Даже Фидель Кастро высказался о новой Коле, сказав, что изменение рецептуры — это признак упадка Америки. Короче, обосратушки.
В итоге, через 3 месяца Кола сдалась и вернула классическую рецептуру. Эта новость стала главной для новостных телеканалов и появилась на первых полосах всех общенациональных газет. Покупатели выдохнули с облегчением — "Дуров вернул стену".
В общем, что мы видим: данные показывали — вот хороший рецепт он лучше прежнего, бери его. Покупатели сказали: мы не хотим, чтобы наш любимый напиток меняли и лезли в наши ценности. Как говорит сама Кола — мы не тот вопрос задавали: вместо того, чтобы спрашивать людей, что вкуснее, надо было просто поинтересоваться: "Стоит ли нам менять вкус Coca-Cola?" В итоге всё обошлось: шумиха подстегнула новый интерес к бренду, но так не хотели.
#продакту
В конце 90-х по телеку показывали рестлинг, который комментировал Николай Фоменко. Многие смотрели именно из-за этих комментариев: "Обосратушки, мои!" — кричал Николай, и это было ново. Но не о рестлинге сегодня, а именно об обосратушках.
Интересная история провала бренда Coca‑Cola, которая произошла в 1985 году. Многие считают это самым крупным провалом в маркетинге 20 века.
Дело было так. Coca‑Cola всегда выигрывала у Pepsi и была (да и есть) напитком №1 во всём Мире. Но в 70-80-х стали падать продажи Колы, а Пепси при этом запустила крупную акцию: Pepsi Challenge и на слепых тестах стала выигрывать у колы по вкусу. Да, Пепси вкуснее на слепых тестах. Слепой тест, это когда тебе дают попробовать продукт, но не называют бренд.
Кола расстроилась на фоне всего этого и приняла решение поменять рецептуру: нам надо стать ещё вкуснее. И у них получилось — химики придумали новый рецепт, который на слепых тестах был вкуснее и оригинальной Колы, и новой Пепси. В общем, фокус-группы на (внимание на цифру!) 200 000 человек подтвердили, что новая рецептура вкуснее.
Радостная Кола запустила масштабную акцию: потратила миллионы на рекламу и дистрибуцию и стала ждать результатов. Банка осталась почти та же, только с ярлычком "Новая". Производство прежней колы было (внимание ещё раз!) остановлено.
И тут началось что-то, похожее на "Дуров, верни стену!", но в большем масштабе:
По всей стране возникали протестные группы, такие как «Общество сохранения настоящих ценностей» и «Сообщество американских любителей старой Coca‑Cola». Последние заявляли, что в их ряды вступили 100 тысяч человек, жаждущих возвращения прежней формулы. В честь старого вкуса сочинялись песни. А перед офисом Coca‑Cola появились демонстранты с плакатами, на которых было написано «Наши дети никогда не узнают, что такое чувство настоящей свежести».
Компания получала по 1500 звонков в день от покупателей — до появления новой Колы среднее ежедневное количество звонков не превышало 400. Глава совета директоров Колы, Роберто Гойзуэта, получал гневные письма. В одном из писем отправитель просил об автографе: «Однажды подпись самого тупого топ-менеджера в истории американского бизнеса будет стоить целое состояние!». Даже Фидель Кастро высказался о новой Коле, сказав, что изменение рецептуры — это признак упадка Америки. Короче, обосратушки.
В итоге, через 3 месяца Кола сдалась и вернула классическую рецептуру. Эта новость стала главной для новостных телеканалов и появилась на первых полосах всех общенациональных газет. Покупатели выдохнули с облегчением — "Дуров вернул стену".
В общем, что мы видим: данные показывали — вот хороший рецепт он лучше прежнего, бери его. Покупатели сказали: мы не хотим, чтобы наш любимый напиток меняли и лезли в наши ценности. Как говорит сама Кола — мы не тот вопрос задавали: вместо того, чтобы спрашивать людей, что вкуснее, надо было просто поинтересоваться: "Стоит ли нам менять вкус Coca-Cola?" В итоге всё обошлось: шумиха подстегнула новый интерес к бренду, но так не хотели.
#продакту
Про команду
Сын слушал Фиксиков, а там всякие истории познавательные рассказывают. Я прислушался и услышал историю про отличную командную работу.
Оказывается, некоторые перелётные птицы дремлют во время длительного перелёта. Как? Команда помогает. Устала птица и понимает, что пора бы и отдохнуть — перемещается в центр косяка и летит в спящем режиме: еле-еле крыльями помахивает. А команда ей помогает: птицы рядом сильнее крыльями машут, чтобы поток воздуха поддерживал отдыхающую. А те что впереди летят — кричат, чтобы дремлющая могла лететь в сторону звука.
Передохнула немного — уступает место другой. Так и летят, так и выживают.
Загуглил — действительно, есть такое.
Хорошая команда помогает уставшим. Приболел Валера — его отправляют отдохнуть и подлечиться со словами: "Лечись, мы подхватим!"
А ведь бывает же не так, а вот так: "Точно на больничный надо? Сможешь из дома доделать?"
Или так: "Ай-яй-яй! Нам проект сдавать, а ты заболел. Как же так, Валера?"
И Валера чувствует себя виноватым — команду же подводит: таблетки глотает, на ногах переносит и т.п. Героизм, высушивающий командность. А после Валеры так же себя ведёт Костя, а после Кости — Петя: не оставшиеся плечо подставляют, а больные. Команда в итоге — не команда.
В общем, иногда надо сильнее крылышками помахать, чтобы другие отдохнули. А потом ты отдохнёшь. Так дальше улететь можно.
- - -
К слову: 20 февраля будет Конференция о человеко-ориентированном подходе в работе с командами "PeopleSense LIVE". Она бесплатная — советую посмотреть тем, кто строит команды: https://peoplesense.ru/
В повестке: как делать разные команды эффективными и вовлеченными, как наладить коммуникацию и процессы на удаленке, как бороться с токсичность и конфликтами.
#продакту #кактотак
Сын слушал Фиксиков, а там всякие истории познавательные рассказывают. Я прислушался и услышал историю про отличную командную работу.
Оказывается, некоторые перелётные птицы дремлют во время длительного перелёта. Как? Команда помогает. Устала птица и понимает, что пора бы и отдохнуть — перемещается в центр косяка и летит в спящем режиме: еле-еле крыльями помахивает. А команда ей помогает: птицы рядом сильнее крыльями машут, чтобы поток воздуха поддерживал отдыхающую. А те что впереди летят — кричат, чтобы дремлющая могла лететь в сторону звука.
Передохнула немного — уступает место другой. Так и летят, так и выживают.
Загуглил — действительно, есть такое.
Хорошая команда помогает уставшим. Приболел Валера — его отправляют отдохнуть и подлечиться со словами: "Лечись, мы подхватим!"
А ведь бывает же не так, а вот так: "Точно на больничный надо? Сможешь из дома доделать?"
Или так: "Ай-яй-яй! Нам проект сдавать, а ты заболел. Как же так, Валера?"
И Валера чувствует себя виноватым — команду же подводит: таблетки глотает, на ногах переносит и т.п. Героизм, высушивающий командность. А после Валеры так же себя ведёт Костя, а после Кости — Петя: не оставшиеся плечо подставляют, а больные. Команда в итоге — не команда.
В общем, иногда надо сильнее крылышками помахать, чтобы другие отдохнули. А потом ты отдохнёшь. Так дальше улететь можно.
- - -
К слову: 20 февраля будет Конференция о человеко-ориентированном подходе в работе с командами "PeopleSense LIVE". Она бесплатная — советую посмотреть тем, кто строит команды: https://peoplesense.ru/
В повестке: как делать разные команды эффективными и вовлеченными, как наладить коммуникацию и процессы на удаленке, как бороться с токсичность и конфликтами.
#продакту #кактотак
Главный вопрос любого ре*
Многие очень любят предлагать ре* (редизайн, рефакторинг, ребрендинг, реструктуризацию). При этом мотивация обычно весьма тривиальная: некрасиво, несовременно, неудобно.
Красота, современность и удобство очень субъективные и нематериальные понятия. На сколько красивее станет? На сколько современнее станет?
Поэтому основной вопрос, который надо решить перед любым ре*: КАКИЕ ПОКАЗАТЕЛИ СТАНУТ ЛУЧШЕ?
Красивее станет дизайн? Ок, сколько наград на конкурсах мы получим? Как улучшится конверсия?
Красивее станет код? Ок, на сколько быстрее новый сотрудник в него погрузится по сравнению со страшным кодом?
Удобнее станет продукт? Ок, как мы это проверим?
Хороший специалист на запрос о необходимости ре* — задаёт самый важный вопрос: "Какие показатели вы хотите улучшить?"
— Нам нужен редизайн, сколько стоит?
— Хорспец: Какие показатели вы хотите улучшить?
— Плохспец: Да, я глянул на ваш сайт — он очень несовременный. Сделаем современным за ХХХ р.
Когда известны показатели, тогда проще принять решение: делать ре* или не делать— улучшаемые показатели должны принести эффект, который окупает затраты на ре*.
Если не задаваться этими вопросами в продуктовой разработке, то можно сбиться с курса и бессмысленно тратить силы.
Если не задавать эти вопросы в проектной работе, то есть риск, что заказчик разочаруется в ре* и в вас, так как он ожидал иного.
#продакту #совет из давно опубликованного
Многие очень любят предлагать ре* (редизайн, рефакторинг, ребрендинг, реструктуризацию). При этом мотивация обычно весьма тривиальная: некрасиво, несовременно, неудобно.
Красота, современность и удобство очень субъективные и нематериальные понятия. На сколько красивее станет? На сколько современнее станет?
Поэтому основной вопрос, который надо решить перед любым ре*: КАКИЕ ПОКАЗАТЕЛИ СТАНУТ ЛУЧШЕ?
Красивее станет дизайн? Ок, сколько наград на конкурсах мы получим? Как улучшится конверсия?
Красивее станет код? Ок, на сколько быстрее новый сотрудник в него погрузится по сравнению со страшным кодом?
Удобнее станет продукт? Ок, как мы это проверим?
Хороший специалист на запрос о необходимости ре* — задаёт самый важный вопрос: "Какие показатели вы хотите улучшить?"
— Нам нужен редизайн, сколько стоит?
— Хорспец: Какие показатели вы хотите улучшить?
— Плохспец: Да, я глянул на ваш сайт — он очень несовременный. Сделаем современным за ХХХ р.
Когда известны показатели, тогда проще принять решение: делать ре* или не делать— улучшаемые показатели должны принести эффект, который окупает затраты на ре*.
Если не задаваться этими вопросами в продуктовой разработке, то можно сбиться с курса и бессмысленно тратить силы.
Если не задавать эти вопросы в проектной работе, то есть риск, что заказчик разочаруется в ре* и в вас, так как он ожидал иного.
#продакту #совет из давно опубликованного
Вдохновляющая обратная связь
11 лет я проработал в заказной разработке. Это конвейер: взял проект — сдал проект, взял — сдал, взял — сдал ... Конечно, между взял и сдал куча всего происходит, включая провалы и грабли в лоб, но после сдачи обычно отсутствует обратная связь с миром пользователей. Максимум, клиент закажет поддержку решения и этой поддержкой займутся другие люди.
В итоге, у команды теряется важная связь: я сделал → этим пользуются. Самая плачевная ситуация на госпроектах, заказанных из-за приказа сверху — такие проекты могут делаться для галочки и мир пользователей там вообще отсутствует. Если бы можно было выделить крупно, то я бы выделил: Нет ничего хуже, чем ощущение "работа в стол".
Вся соль в том, что обратная связь с миром пользователей очень важна для командного духа и сплочения. Именно истории реальных пользователей влияют на эмпатию и на огонь в глазах.
Я люблю продукты, люблю проекты с внедрением именно за возможность общаться с конечными пользователями.
Видеть, как мои решения помогают людям — именно в этом кайф и вдохновение.
Госпроект с хорошим бюджетом принесёт в разы меньше кайфа, чем создание любого продукта, которым будут пользоваться реальные люди.
Связь с миром пользователей — это командный клей. Не только UX-исследователи и менеджеры должны сталкиваться с этим миром — обратная связь должна доходить до каждого участника команды.
Транслировать обратную связь внутрь команды можно и нужно разными способами:
👉 рассылать отзывы,
👉 публиковать метрики: мы вчера сделали фичу, а уже сегодня её используют 4К человек.
👉 рассказывать интересные кейсы использования продукта, пользовательские истории.
По Айти Кадр все эти кейсы я с удовольствием отправляю команде — круто же знать, что сегодня кто-то устроился на работу после скрининг-интервью или кто-то начал заниматься с наставником.
Наличие обратной связи позволяет каждому ощутить причастность к общему полезному делу.
Обратной связью и живыми историями люди будут гордиться, вдохновляться и рассказывать близким на кухне.
Даже негативная обратная связь полезна и её не надо скрывать от команды.
Я уже писал про душевные письма, которые вкладываются в упаковки зубной пасты Splat.
Так вот, все эти письма написаны гендиректором Splat и заканчиваются фразой:
"Спасибо вам за живые и теплые письма, вопросы и благодарности. По понедельникам я собираю ваши письма и рассылаю всем в компании, чтобы каждый человек помнил, для каких прекрасных людей мы трудимся каждый день!"
Это очень круто — так и надо делать продукты для людей!
В общем, если ещё не все в команде знают, для каких прекрасных людей они трудятся, то самое время им об этом рассказать.
#совет #продакту
из давно опубликованного
11 лет я проработал в заказной разработке. Это конвейер: взял проект — сдал проект, взял — сдал, взял — сдал ... Конечно, между взял и сдал куча всего происходит, включая провалы и грабли в лоб, но после сдачи обычно отсутствует обратная связь с миром пользователей. Максимум, клиент закажет поддержку решения и этой поддержкой займутся другие люди.
В итоге, у команды теряется важная связь: я сделал → этим пользуются. Самая плачевная ситуация на госпроектах, заказанных из-за приказа сверху — такие проекты могут делаться для галочки и мир пользователей там вообще отсутствует. Если бы можно было выделить крупно, то я бы выделил: Нет ничего хуже, чем ощущение "работа в стол".
Вся соль в том, что обратная связь с миром пользователей очень важна для командного духа и сплочения. Именно истории реальных пользователей влияют на эмпатию и на огонь в глазах.
Я люблю продукты, люблю проекты с внедрением именно за возможность общаться с конечными пользователями.
Видеть, как мои решения помогают людям — именно в этом кайф и вдохновение.
Госпроект с хорошим бюджетом принесёт в разы меньше кайфа, чем создание любого продукта, которым будут пользоваться реальные люди.
Связь с миром пользователей — это командный клей. Не только UX-исследователи и менеджеры должны сталкиваться с этим миром — обратная связь должна доходить до каждого участника команды.
Транслировать обратную связь внутрь команды можно и нужно разными способами:
👉 рассылать отзывы,
👉 публиковать метрики: мы вчера сделали фичу, а уже сегодня её используют 4К человек.
👉 рассказывать интересные кейсы использования продукта, пользовательские истории.
По Айти Кадр все эти кейсы я с удовольствием отправляю команде — круто же знать, что сегодня кто-то устроился на работу после скрининг-интервью или кто-то начал заниматься с наставником.
Наличие обратной связи позволяет каждому ощутить причастность к общему полезному делу.
Обратной связью и живыми историями люди будут гордиться, вдохновляться и рассказывать близким на кухне.
Даже негативная обратная связь полезна и её не надо скрывать от команды.
Я уже писал про душевные письма, которые вкладываются в упаковки зубной пасты Splat.
Так вот, все эти письма написаны гендиректором Splat и заканчиваются фразой:
"Спасибо вам за живые и теплые письма, вопросы и благодарности. По понедельникам я собираю ваши письма и рассылаю всем в компании, чтобы каждый человек помнил, для каких прекрасных людей мы трудимся каждый день!"
Это очень круто — так и надо делать продукты для людей!
В общем, если ещё не все в команде знают, для каких прекрасных людей они трудятся, то самое время им об этом рассказать.
#совет #продакту
из давно опубликованного
Пользователи выбирают ...
Самый большой потребительский миф — свобода выбора у покупателей/пользователей.
Никакой 100% свободы нет: выбрать можно только то, что тебе продали.
Продали во всех смыслах. Через рекламу, через сарафанное радио, через друзей и соцсетевых френдов , через поисковую оптимизацию, через новости и т.д. Если продукт, который тебе 100% подходит отсутствует в этом рекламно-поисково-рекомендательном замесе, то шансы его выбрать равны нулю.
Обратное тоже справедливо: шансы, что твой продукт выберут равны нулю, если его нет в рекламно-поисково-рекомендательном замесе. Ноль шансов! Какой бы крутой ни был продукт.
Для карьеры тоже справедливо: каким бы хорошим специалистом ты ни был — тебя не заметят, если ты себя не "продашь". Не заметят.
Собственно вывод. Когда спорят, что важнее в продукте — дизайн или функциональность? Можно смело сказать, что важнее маркетинг. Без него никто не оценит ни дизайн, ни функциональность. Если в команде слабый маркетинг, то всё остальное имеет мало смысла.
#продакту
Самый большой потребительский миф — свобода выбора у покупателей/пользователей.
Никакой 100% свободы нет: выбрать можно только то, что тебе продали.
Продали во всех смыслах. Через рекламу, через сарафанное радио, через друзей и соцсетевых френдов , через поисковую оптимизацию, через новости и т.д. Если продукт, который тебе 100% подходит отсутствует в этом рекламно-поисково-рекомендательном замесе, то шансы его выбрать равны нулю.
Обратное тоже справедливо: шансы, что твой продукт выберут равны нулю, если его нет в рекламно-поисково-рекомендательном замесе. Ноль шансов! Какой бы крутой ни был продукт.
Для карьеры тоже справедливо: каким бы хорошим специалистом ты ни был — тебя не заметят, если ты себя не "продашь". Не заметят.
Собственно вывод. Когда спорят, что важнее в продукте — дизайн или функциональность? Можно смело сказать, что важнее маркетинг. Без него никто не оценит ни дизайн, ни функциональность. Если в команде слабый маркетинг, то всё остальное имеет мало смысла.
#продакту
Не суетись
Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...
Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".
Обычно волны суеты накрывают, когда что-то идёт не по плану: срывается срок, вылезла какая-то гадость на проде, сервак лёг, срочный запрос в поддержку и т.д.
Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.
Обычно такая суета никак не ускоряет процесс, а отвлекает на лишние действия и раздражает окружающих. Проще говоря, менеджер задалбывает, а не помогает. Ну и в спешке всегда хромает качество.
Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.
На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.
— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.
— обозначить, каким качеством можно пожертвовать ... и как его потом вернуть. Качество, утерянное в авральном режиме, должно быть зафиксировано и возвращено при выходе из этого режима.
— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.
В общем, менеджер — это оплот спокойствия, а не источник задёрганности.
Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)
#softskills #продакту
Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...
Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".
Обычно волны суеты накрывают, когда что-то идёт не по плану: срывается срок, вылезла какая-то гадость на проде, сервак лёг, срочный запрос в поддержку и т.д.
Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.
Обычно такая суета никак не ускоряет процесс, а отвлекает на лишние действия и раздражает окружающих. Проще говоря, менеджер задалбывает, а не помогает. Ну и в спешке всегда хромает качество.
Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.
На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.
— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.
— обозначить, каким качеством можно пожертвовать ... и как его потом вернуть. Качество, утерянное в авральном режиме, должно быть зафиксировано и возвращено при выходе из этого режима.
— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.
В общем, менеджер — это оплот спокойствия, а не источник задёрганности.
Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)
#softskills #продакту
Уязвимости DD-подхода
В книге "Стратегическое сафари. Экскурсия по дебрям стратегического менеджмента" понравилась заметка про уязвимые места обработки данных. Заметка от 1994 года, но многое в ней актуально и для Data Driven подхода в 2021 году
Итак, уязвимости (сжато):
1. Обработанная информация, как правило, ограничена рамками — ей не хватает полноты. Дашборды не в состоянии уловить важные внеэкономические или неподдающиеся количественному выражению факторы: выражение лица покупателя, настроения на производстве (в команде), тон голоса государственного чиновника — все это может стать информацией для менеджера, но не представляет никакой ценности для формальной системы.
2. Большая часть информации носит обобщенный характер. Наиболее очевидное решение для перегруженного информацией и действующего при постоянной нехватке времени менеджера — обобщение информации. При этом неочевидные точки роста часто находятся в штучной информации.
3. Обработанная информация на самом деле не является столь уж надежной. Этот пункт благодаря современным технологиям сбора информации несколько утратил актуальность, но всё же: вера в непогрешимость собранных данных может сыграть злую шутку. Особенно, если данные собирали не вы: отчёты консалтеров, бенчмарки (ориентиры) и т.п.
В общем, на данные надейся, а сам не плошай. Количественные показатели должны обогащаться качественными — только так можно получать максимально объёмную картинку по продукту или компании.
Книгу, кстати, рекомендую тем, кто хочет погрузиться в стратегический менеджмент — в ней по сути обзор и разбор разных подходов к подготовке стратегии.
#совет #продакту
В книге "Стратегическое сафари. Экскурсия по дебрям стратегического менеджмента" понравилась заметка про уязвимые места обработки данных. Заметка от 1994 года, но многое в ней актуально и для Data Driven подхода в 2021 году
Итак, уязвимости (сжато):
1. Обработанная информация, как правило, ограничена рамками — ей не хватает полноты. Дашборды не в состоянии уловить важные внеэкономические или неподдающиеся количественному выражению факторы: выражение лица покупателя, настроения на производстве (в команде), тон голоса государственного чиновника — все это может стать информацией для менеджера, но не представляет никакой ценности для формальной системы.
2. Большая часть информации носит обобщенный характер. Наиболее очевидное решение для перегруженного информацией и действующего при постоянной нехватке времени менеджера — обобщение информации. При этом неочевидные точки роста часто находятся в штучной информации.
3. Обработанная информация на самом деле не является столь уж надежной. Этот пункт благодаря современным технологиям сбора информации несколько утратил актуальность, но всё же: вера в непогрешимость собранных данных может сыграть злую шутку. Особенно, если данные собирали не вы: отчёты консалтеров, бенчмарки (ориентиры) и т.п.
В общем, на данные надейся, а сам не плошай. Количественные показатели должны обогащаться качественными — только так можно получать максимально объёмную картинку по продукту или компании.
Книгу, кстати, рекомендую тем, кто хочет погрузиться в стратегический менеджмент — в ней по сути обзор и разбор разных подходов к подготовке стратегии.
#совет #продакту
Агентская проблема менеджера продукта
Когда предприниматель открывает своё семейное кафе, то он хочет, чтобы в перспективе у него накопилась лояльная клиентская база: он старается для них, реализуя себя и свою идею, получая на этом прибыль.
Когда предприниматель нанимает менеджера управлять его кафе, то менеджер прежде всего думает о своей выгоде: нравиться предпринимателю, чтобы получать зарплату и иметь стабильную работу.
Это называется агентской проблемой: менеджер (агент) прежде всего действует в своих локальных интересах, а не в долгосрочных интересах основателя.
По-моему, на рынке продуктового менеджмента агентская проблема стоит сейчас довольно остро. Особенно в условиях культа метрик и быстрой смены мест работы. Менеджеру важно вырастить метрики (часто любой ценой), потому что:
1. От этого зависит его зарплата здесь и сейчас.
2. От этого зависит его трудоустройство дальше: на собеседованиях любят спрашивать про то, какие метрики и как сильно ты растил.
3. Про это можно рассказывать на конференциях/курсах/менторинге.
Менеджеры видят в пользователях не людей, а трафик. Трафик растят, направляют куда надо, им манипулируют с помощью эксплуатации когнитивных искажений и тёмных паттернов.
Ситуация немного компенсируется противоположными метриками (например, отток = churn). Но отток часто не столь оперативен: пользователь потерпит подольше — менеджер к тому времени две работы сменит. Да и на отток так же влияют: скидку дадут, усложнят отписку и прочее.
Забота о пользователе часто имеет номинальный характер — её заявляют все, но при этом никто не теряет возможности манипульнуть пользователем (трафиком!) ради метрики.
Самые крутые и реально заботливые продукты — это те, которыми управляет основатель: например, Zappos ранних стадий (Тони Шея). Или продукты в которых удалось синхронизировать менеджеров с миссией продукта: например, ВкуссВилл.
Или продукты, в которых удалось уйти от фанатичного преклонения перед метриками: например, в b2b секторе у продуктов больше реальной заботы о пользователях.
А самые тёмно-паттерные и истыканные агентской проблемой — это крупные продукты-монополии, у которых и основателя уже нет по сути (интересы акционеров): facebook, instagram, всё чаще Яндекс, многие массовые edtech и т.п.
Выводов пока нет.
#ux #продакту
Когда предприниматель открывает своё семейное кафе, то он хочет, чтобы в перспективе у него накопилась лояльная клиентская база: он старается для них, реализуя себя и свою идею, получая на этом прибыль.
Когда предприниматель нанимает менеджера управлять его кафе, то менеджер прежде всего думает о своей выгоде: нравиться предпринимателю, чтобы получать зарплату и иметь стабильную работу.
Это называется агентской проблемой: менеджер (агент) прежде всего действует в своих локальных интересах, а не в долгосрочных интересах основателя.
По-моему, на рынке продуктового менеджмента агентская проблема стоит сейчас довольно остро. Особенно в условиях культа метрик и быстрой смены мест работы. Менеджеру важно вырастить метрики (часто любой ценой), потому что:
1. От этого зависит его зарплата здесь и сейчас.
2. От этого зависит его трудоустройство дальше: на собеседованиях любят спрашивать про то, какие метрики и как сильно ты растил.
3. Про это можно рассказывать на конференциях/курсах/менторинге.
Менеджеры видят в пользователях не людей, а трафик. Трафик растят, направляют куда надо, им манипулируют с помощью эксплуатации когнитивных искажений и тёмных паттернов.
Ситуация немного компенсируется противоположными метриками (например, отток = churn). Но отток часто не столь оперативен: пользователь потерпит подольше — менеджер к тому времени две работы сменит. Да и на отток так же влияют: скидку дадут, усложнят отписку и прочее.
Забота о пользователе часто имеет номинальный характер — её заявляют все, но при этом никто не теряет возможности манипульнуть пользователем (трафиком!) ради метрики.
Самые крутые и реально заботливые продукты — это те, которыми управляет основатель: например, Zappos ранних стадий (Тони Шея). Или продукты в которых удалось синхронизировать менеджеров с миссией продукта: например, ВкуссВилл.
Или продукты, в которых удалось уйти от фанатичного преклонения перед метриками: например, в b2b секторе у продуктов больше реальной заботы о пользователях.
А самые тёмно-паттерные и истыканные агентской проблемой — это крупные продукты-монополии, у которых и основателя уже нет по сути (интересы акционеров): facebook, instagram, всё чаще Яндекс, многие массовые edtech и т.п.
Выводов пока нет.
#ux #продакту
— Какой навык самый важный для менеджера продукта?
— Мы живём в продуктовом изобилии: на практически любой запрос есть продукт. Нагуглить можно всё что угодно. Благодаря интернету изобилие стало глобальным. Продукт, интересный локально, может превратиться в глобального игрока.
— Значит, важно уметь создавать уникальные продукты?
— Не так важно насколько уникален ваш продукт (скорее всего, он не будет уникален). Уникальность мимолётна. Навык создавать продукты не самый важный — создать могут многие. Это самый простой этап в жизни продукта, особенно, когда есть ноукод сервисы для быстрого создания продукта или его первой версии.
— Что же тогда самое важное?
— Важно уметь привлечь пользователей и создать условия, при которых им максимально длительное время захочется с вами остаться. Навык продавать продукт — вот навык, который надо качать продактам в приоритете. Продавать в широком смысле: привлекать пользователей (маркетинг и продвижение), удерживать пользователей (UX), делать из пользователей продавцов (виральность).
#продакту
— Мы живём в продуктовом изобилии: на практически любой запрос есть продукт. Нагуглить можно всё что угодно. Благодаря интернету изобилие стало глобальным. Продукт, интересный локально, может превратиться в глобального игрока.
— Значит, важно уметь создавать уникальные продукты?
— Не так важно насколько уникален ваш продукт (скорее всего, он не будет уникален). Уникальность мимолётна. Навык создавать продукты не самый важный — создать могут многие. Это самый простой этап в жизни продукта, особенно, когда есть ноукод сервисы для быстрого создания продукта или его первой версии.
— Что же тогда самое важное?
— Важно уметь привлечь пользователей и создать условия, при которых им максимально длительное время захочется с вами остаться. Навык продавать продукт — вот навык, который надо качать продактам в приоритете. Продавать в широком смысле: привлекать пользователей (маркетинг и продвижение), удерживать пользователей (UX), делать из пользователей продавцов (виральность).
#продакту
Ровно 3 месяца назад был аудиоэфир в канале Epic Growth на тему "Продуктовый EdTech: как учить продактов, чтобы получалось хорошо". Здорово поговорили и ... в итоге сегодня вышла статья по итогам этого эфира.
Собрали в ней основное из эфира, добавили примеров — https://vc.ru/hr/314408-produktovyy-edtech-kak-uchit-prodaktov-chtoby-poluchalos-horosho
Внутри: чего не хватает текущим курсам, кому доверяют при найме, где брать практику, если ты новичок, зачем и в каком случае нанимать джунов, какой скиллсет нужен продакту и где его прокачивать.
#продакту
Собрали в ней основное из эфира, добавили примеров — https://vc.ru/hr/314408-produktovyy-edtech-kak-uchit-prodaktov-chtoby-poluchalos-horosho
Внутри: чего не хватает текущим курсам, кому доверяют при найме, где брать практику, если ты новичок, зачем и в каком случае нанимать джунов, какой скиллсет нужен продакту и где его прокачивать.
#продакту
vc.ru
Продуктовый EdTech: как учить продактов, чтобы получалось хорошо — Карьера на vc.ru
11 продактов, основателей и сооснователей IT-компаний, таких как Epic Growth, Avito, Skyeng и других провели совместный аудиоэфир, главной темой которого стало обучение продактов. Обсуждали, чего не хватает текущим курсам, кому доверяют при найме, где брать…