Ровно 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 и других провели совместный аудиоэфир, главной темой которого стало обучение продактов. Обсуждали, чего не хватает текущим курсам, кому доверяют при найме, где брать…
Про 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 #Продакту
из давно опубликованного
Не суетись
Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...
Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".
Обычно волны суеты накрывают, когда что-то идёт не по плану: срывается срок, вылезла какая-то гадость на проде, сервак лёг, срочный запрос в поддержку и т.д.
Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.
Обычно такая суета никак не ускоряет процесс, а отвлекает на лишние действия и раздражает окружающих. Проще говоря, менеджер задалбывает, а не помогает. Ну и в спешке всегда хромает качество.
Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.
На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.
— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.
— обозначить, каким качеством можно пожертвовать ... и как его потом вернуть. Качество, утерянное в авральном режиме, должно быть зафиксировано и возвращено при выходе из этого режима.
— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.
В общем, менеджер — это оплот спокойствия, а не источник задёрганности.
Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)
#softskills #продакту из давно опубликованного
Если вы смотрели Шрек-2, то вспомните сцену, в которой Шрек, Фиона и осёл ехали в гости к родителям Фионы. Осёл каждые пять минут спрашивал: "Уже приехали?", "Ну что, уже приехали?", "А сейчас приехали?" ...
Излишняя суета порой накрывает менеджеров (всех мастей): "Ну что, доделал?", "Нарисовал?", "Написал?", "Прошла модерация? А когда? А как ускорить?", "А можешь задержаться?", "Пообедаешь поскорее, чтобы успеть?".
Обычно волны суеты накрывают, когда что-то идёт не по плану: срывается срок, вылезла какая-то гадость на проде, сервак лёг, срочный запрос в поддержку и т.д.
Помню, накрытый волной суеты, ходишь вокруг да около программиста и уточняешь, как тот осёл: Нашёл причину ошибки? А скоро найдёшь? Ну ок, скоро вернусь.
Обычно такая суета никак не ускоряет процесс, а отвлекает на лишние действия и раздражает окружающих. Проще говоря, менеджер задалбывает, а не помогает. Ну и в спешке всегда хромает качество.
Вряд ли, рушится Мир и надо дышать в спину программисту (дизайнеру/копирайтеру ...) — у меня Мир не рушился (хотя казалось иное), в 100% случаев можно было меньше суетиться. Твоих коллег на дольше хватит, если они работают в спокойном режиме.
На что можно заменить суету:
— доверие к исполнителю. Обозначить всю важность ситуации и попросить к определённому сроку предоставить статус по проблеме.
— приготовить план "Б". Часто суетиться и дышать в спину уже поздно — надо готовить вторую версию плана: думать, где можно срезать углы; думать, что делать, если всё же не успеем; думать, что сказать заказчику и т.д.
— обозначить, каким качеством можно пожертвовать ... и как его потом вернуть. Качество, утерянное в авральном режиме, должно быть зафиксировано и возвращено при выходе из этого режима.
— успокоиться самому: "Будет ли важна эта проблема через год?" Обычно, такой вопрос снимает волну суеты и помогает думать яснее.
В общем, менеджер — это оплот спокойствия, а не источник задёрганности.
Вокруг шум. Пусть так
Ни кипишуй. Всё ништяк
(Каста)
#softskills #продакту из давно опубликованного
MVP умер?
Если хорошенько подумать над каноническим понятием минимального жизнеспособного продукта (MVP), то можно понять, что он практически не актуален для современных ИТ-реалий. Кто вообще не в теме: MVP — это версия продукта, которая создаётся для тестирования гипотезы востребованности продукта.
Сразу поясню, что в этом посте речь именно об ИТ-продуктах: когда ценность в функциональности продукта, а не об инфотоварах, когда основная ценность в содержимом. Свой ценный курс по продуктовому менеджменту вы можете запустить на чём угодно, не создавая для этого специальную LMS.
Так вот, большинство литературных примеров MVP относятся к древним (по меркам ИТ-развития) временам: доска объявлений через Эксель, Airbnb через факс, потоковая музыка, которая стала Spotify, Zappos, который продавал через интернет магазин чужую обувь и т.п.
Но помимо древности литературные примеры MVP объединяет то, что тестировалась уникальная (новейшая) модель продукта. Нет (или почти нет) примеров MVP, когда продукт выводился на конкурентный рынок.
Но жизнь такова, что сейчас 99,99% продуктов выводятся на конкурентный рынок. Цифровая революция во многих сферах уже прошла. Нельзя прийти к заказчику и предлагать ему нефункциональную CRM (любую другую систему) — он уже видел кучу функциональных CRM.
Если ваш продукт относится к 0,01% уникальных продуктов — вопросов нет: вы придумали что-то совершенно новое и можете это донести в минимальном жизнеспособном виде.
Если у вас продукт относится к 99,99% продуктов, имеющих конкурентов — для вас MVP скорее мёртв (сорян). Надо создать что-то, что будет лучше конкурентов (хотя бы не сильно хуже).
В бытовом плане MVP сейчас спустился на уровень отдельных функций: делаем функцию Х в продукте не сразу на пять, а на троечку и собираем обратную связь. Но это уже не MVP, а обычная итеративная разработка.
В общем, MVP в 99,99% случаев мёртв. Конечно, примерами ИТ-древности можно восхититься, но на практике почти никому они не помогут.
#продакту
Если хорошенько подумать над каноническим понятием минимального жизнеспособного продукта (MVP), то можно понять, что он практически не актуален для современных ИТ-реалий. Кто вообще не в теме: MVP — это версия продукта, которая создаётся для тестирования гипотезы востребованности продукта.
Сразу поясню, что в этом посте речь именно об ИТ-продуктах: когда ценность в функциональности продукта, а не об инфотоварах, когда основная ценность в содержимом. Свой ценный курс по продуктовому менеджменту вы можете запустить на чём угодно, не создавая для этого специальную LMS.
Так вот, большинство литературных примеров MVP относятся к древним (по меркам ИТ-развития) временам: доска объявлений через Эксель, Airbnb через факс, потоковая музыка, которая стала Spotify, Zappos, который продавал через интернет магазин чужую обувь и т.п.
Но помимо древности литературные примеры MVP объединяет то, что тестировалась уникальная (новейшая) модель продукта. Нет (или почти нет) примеров MVP, когда продукт выводился на конкурентный рынок.
Но жизнь такова, что сейчас 99,99% продуктов выводятся на конкурентный рынок. Цифровая революция во многих сферах уже прошла. Нельзя прийти к заказчику и предлагать ему нефункциональную CRM (любую другую систему) — он уже видел кучу функциональных CRM.
Если ваш продукт относится к 0,01% уникальных продуктов — вопросов нет: вы придумали что-то совершенно новое и можете это донести в минимальном жизнеспособном виде.
Если у вас продукт относится к 99,99% продуктов, имеющих конкурентов — для вас MVP скорее мёртв (сорян). Надо создать что-то, что будет лучше конкурентов (хотя бы не сильно хуже).
В бытовом плане MVP сейчас спустился на уровень отдельных функций: делаем функцию Х в продукте не сразу на пять, а на троечку и собираем обратную связь. Но это уже не MVP, а обычная итеративная разработка.
В общем, MVP в 99,99% случаев мёртв. Конечно, примерами ИТ-древности можно восхититься, но на практике почти никому они не помогут.
#продакту
Про УТП
У всего, что хочется продать должно быть УТП (уникальное торговое предложение). Иначе “хочется продать” будет вяло конвертироваться в “по факту продаю”.
Даже когда вы продаёте себя (конечно, речь про выход на рынок труда) должно быть УТП. Краткая фраза о вас, которая сразу говорит о вашей уникальности: “Обеспечиваю кратный рост b2b-продуктам“, “Делаю макеты, в которых никогда не бывает больше двух правок” и т.д.
Обычно УТП исходит от потребительской боли и предлагает её решение. Про саму боль писать не обязательно, даже лучше не писать — решение важнее. Например, УТП у драже m&ms: “Тают во рту, а не в руках”. Джун УТПист написал бы: “Пачкаются руки, когда едите шоколад? m&ms не пачкают руки, потому что тают во рту, а на руках следов не оставляют.”
УТП — это по сути важнейшая деталь, которая может разительно влиять на конверсию: будут смотреть дальше ваш продукт или нет. Я много изучаю новых продуктов и замечаю, что у большинства нет внятного УТП. Нет крючка, за который пользователь (или клиент) должен зацепиться. В b2b часто и вовсе совок какой-то вместо УТП: куча слов, которые не цепляют за больное.
Компании часто ломают голову над названием продукта, а вот над УТП особо не трудятся — хотя всё должно быть наоборот. Для зацепки УТП важнее названия. Вспомните, как вы выбираете бизнес-книги: у 99% книг на обложке помимо названия есть УТП и зачастую именно оно формирует ожидания от книги. Если УТП книги не зацепило, то вы с малой вероятностью пойдёте читать отзывы и изучать фрагменты книги.
Для примера закинул в первом комментарии несколько обложек книг — присмотритесь к УТП.
Пару лет назад мы делали по b2b-продукту для интерпрайза серию встреч по формированию УТП. Но так и не смогли его чётко сформулировать — да, так тоже бывает. В итоге, мы так и не отстроили его продажи по-нормальному и не масштабировали.
В общем, если у вашего продукта нет чёткого УТП, то продать его очень-очень трудно. Если у вас нет чёткого УТП, то найти работу очень-очень трудно. Если сложно сформировать УТП — возможно, вы никакую боль не решаете своим продуктом.
#продакту
У всего, что хочется продать должно быть УТП (уникальное торговое предложение). Иначе “хочется продать” будет вяло конвертироваться в “по факту продаю”.
Даже когда вы продаёте себя (конечно, речь про выход на рынок труда) должно быть УТП. Краткая фраза о вас, которая сразу говорит о вашей уникальности: “Обеспечиваю кратный рост b2b-продуктам“, “Делаю макеты, в которых никогда не бывает больше двух правок” и т.д.
Обычно УТП исходит от потребительской боли и предлагает её решение. Про саму боль писать не обязательно, даже лучше не писать — решение важнее. Например, УТП у драже m&ms: “Тают во рту, а не в руках”. Джун УТПист написал бы: “Пачкаются руки, когда едите шоколад? m&ms не пачкают руки, потому что тают во рту, а на руках следов не оставляют.”
УТП — это по сути важнейшая деталь, которая может разительно влиять на конверсию: будут смотреть дальше ваш продукт или нет. Я много изучаю новых продуктов и замечаю, что у большинства нет внятного УТП. Нет крючка, за который пользователь (или клиент) должен зацепиться. В b2b часто и вовсе совок какой-то вместо УТП: куча слов, которые не цепляют за больное.
Компании часто ломают голову над названием продукта, а вот над УТП особо не трудятся — хотя всё должно быть наоборот. Для зацепки УТП важнее названия. Вспомните, как вы выбираете бизнес-книги: у 99% книг на обложке помимо названия есть УТП и зачастую именно оно формирует ожидания от книги. Если УТП книги не зацепило, то вы с малой вероятностью пойдёте читать отзывы и изучать фрагменты книги.
Для примера закинул в первом комментарии несколько обложек книг — присмотритесь к УТП.
Пару лет назад мы делали по b2b-продукту для интерпрайза серию встреч по формированию УТП. Но так и не смогли его чётко сформулировать — да, так тоже бывает. В итоге, мы так и не отстроили его продажи по-нормальному и не масштабировали.
В общем, если у вашего продукта нет чёткого УТП, то продать его очень-очень трудно. Если у вас нет чёткого УТП, то найти работу очень-очень трудно. Если сложно сформировать УТП — возможно, вы никакую боль не решаете своим продуктом.
#продакту
Как делать эффективно скучные задачи
Вы замечали, что если задача интересная, то на неё и время находится, и соцсети не мешают? Сел делать и не заметил, как время пролетело.
И наоборот, если задача скучная, обыденная, то всё время что-то отвлекает. Сосредоточиться на решении очень сложно — приходится себя заставлять "есть слона по частям", "ставить таймер-помидор", блокировать соцсети, выключать телефон ...
Классный способ продавать воздух — рассказывать о том, что скучные задачи можно делать эффективно. Если делаешь скучную задачу, то ни о какой эффективности говорить не приходится. Просто заставляешь себя её сделать или вечно откладываешь пока не пригорит. Мозг не хочет делать скучные задачи.
Есть только один способ делать скучные задачи эффективно — их надо отдавать тем, для кого они не будут скучными.
Делегировать и перераспределять, короче.
Самый лучший способ поднять эффективность команды — создавать условия профессионального роста, основанные на возможности браться за новые задачи и вызовы. Надо всегда заботиться о том, чтобы в списке задач каждого сотрудника был перевес в пользу интересных задач. Опережая критику — перевес, но не все. Не могут все задачи всегда быть интересными.
Наполеон говорил: "Искусство управления состоит в том, чтобы не позволять людям состариться в своей должности."
В продуктовой команде будет примерно так: "Искусство управления состоит в том, чтобы не позволять людям соскучиться в своей должности".
В общем, менеджерам надо не учить делать эффективно скучные задачи, а учиться находить для каждого участника команды максимально интересные задачи.
#продакту #совет из давно опубликованного
Вы замечали, что если задача интересная, то на неё и время находится, и соцсети не мешают? Сел делать и не заметил, как время пролетело.
И наоборот, если задача скучная, обыденная, то всё время что-то отвлекает. Сосредоточиться на решении очень сложно — приходится себя заставлять "есть слона по частям", "ставить таймер-помидор", блокировать соцсети, выключать телефон ...
Классный способ продавать воздух — рассказывать о том, что скучные задачи можно делать эффективно. Если делаешь скучную задачу, то ни о какой эффективности говорить не приходится. Просто заставляешь себя её сделать или вечно откладываешь пока не пригорит. Мозг не хочет делать скучные задачи.
Есть только один способ делать скучные задачи эффективно — их надо отдавать тем, для кого они не будут скучными.
Делегировать и перераспределять, короче.
Самый лучший способ поднять эффективность команды — создавать условия профессионального роста, основанные на возможности браться за новые задачи и вызовы. Надо всегда заботиться о том, чтобы в списке задач каждого сотрудника был перевес в пользу интересных задач. Опережая критику — перевес, но не все. Не могут все задачи всегда быть интересными.
Наполеон говорил: "Искусство управления состоит в том, чтобы не позволять людям состариться в своей должности."
В продуктовой команде будет примерно так: "Искусство управления состоит в том, чтобы не позволять людям соскучиться в своей должности".
В общем, менеджерам надо не учить делать эффективно скучные задачи, а учиться находить для каждого участника команды максимально интересные задачи.
#продакту #совет из давно опубликованного
Задача: Как отличить мидла от сеньора за один вопрос
Игорь Седачёв, руководитель продуктового направления в Авито, в блоге Avito на VC рассказал про свой опыт найма продактов.
Говорит, что ему достаточно только одного вопроса, чтобы отличить почти мидла, мидла и сеньора.
Можете проверить себя. Вот задача, о которой пишет Игорь:
===
Вводные. Представим, что у нас есть сайт с объявлениями — классифайд, — который умеет только публиковать карточки товаров и показывать номера телефонов продавцов. Потенциальный покупатель должен кликнуть на кнопку «позвонить», чтобы увидеть номер.
Главная метрика компании — количество контактов, одним контактом считается одно нажатие на кнопку «позвонить». Эту метрику растят все команды, она стоит в целях у топ-менеджмента и является корнем дерева метрик.
Команда классифайда решает, что пора начать рассказывать не только о товарах, но и о людях, которые их продают. Так делают конкуренты, об этом просят пользователи, а по рынку ходят отчёты, которые показывают: публикация информации о продавцах растит ретеншн покупателей.
Менеджер продукта, которому досталась эта инициатива, методично разбирается с проблемами пользователей и проводит качественные тесты. Он решает, что оптимальное решение — вывести на карточку товара базовую информацию о продавце: имя, аватарку, активность на площадке, дату регистрации, наличие подтверждённых документов и/или телефона.
Вопрос. Теперь менеджеру продукта нужно провести A/B-тест, чтобы убедиться в качестве решения. Поставьте себя на его место и объясните, как бы вы выбрали критерии успеха: какая метрика должна измениться и каким образом?
===
Подумайте, что вы ответите на такой вопрос?
А потом почитайте правильные ответы в статье: clc.to/VnRakQ
#продакту
Игорь Седачёв, руководитель продуктового направления в Авито, в блоге Avito на VC рассказал про свой опыт найма продактов.
Говорит, что ему достаточно только одного вопроса, чтобы отличить почти мидла, мидла и сеньора.
Можете проверить себя. Вот задача, о которой пишет Игорь:
===
Вводные. Представим, что у нас есть сайт с объявлениями — классифайд, — который умеет только публиковать карточки товаров и показывать номера телефонов продавцов. Потенциальный покупатель должен кликнуть на кнопку «позвонить», чтобы увидеть номер.
Главная метрика компании — количество контактов, одним контактом считается одно нажатие на кнопку «позвонить». Эту метрику растят все команды, она стоит в целях у топ-менеджмента и является корнем дерева метрик.
Команда классифайда решает, что пора начать рассказывать не только о товарах, но и о людях, которые их продают. Так делают конкуренты, об этом просят пользователи, а по рынку ходят отчёты, которые показывают: публикация информации о продавцах растит ретеншн покупателей.
Менеджер продукта, которому досталась эта инициатива, методично разбирается с проблемами пользователей и проводит качественные тесты. Он решает, что оптимальное решение — вывести на карточку товара базовую информацию о продавце: имя, аватарку, активность на площадке, дату регистрации, наличие подтверждённых документов и/или телефона.
Вопрос. Теперь менеджеру продукта нужно провести A/B-тест, чтобы убедиться в качестве решения. Поставьте себя на его место и объясните, как бы вы выбрали критерии успеха: какая метрика должна измениться и каким образом?
===
Подумайте, что вы ответите на такой вопрос?
А потом почитайте правильные ответы в статье: clc.to/VnRakQ
#продакту
Реклама. ООО «Авито Тех».Оптимизируй это немедленно
Прочитал книгу Георгия Нанеишвили “Оптимизируй это немедленно”. Георгий отвечал за развитие партнёрской сети Qlik в России. Кто не в теме Qlik — популярная BI-платформа, которая на рынке РФ входила в большую тройку иностранных BI: Power BI, Tableau и Qlik.
Звезда Клика на рынке РФ закатилась — Qlik покинул рынок России. Но кейсы остались. Собственно, книга построена на кейсах автоматизации разных компаний (в основном крупных). И надо сказать, это самое интересное описание кейсов, которое я до этого встречал.
Понравился кейс с моцареллой. Перескажу своими словами.
Крупному дистрибутору пищевых продуктов показывали BI. Делали в режиме прототипа: подключили систему к боевым данным.
И вот, на показе увидели, что “столбик” сыра моцарелла выбивается относительно других остатков — его дофига. Почти 10 тонн. Директор, которая увидела этот столбик, сказала, что такого быть не может — это дорогущий сыр и его везут напрямую из Италии. Его в месяц от силы 100 кг продают. Внедренцы сказали, что подключены к реальным данным.
Короче, позвонили на склад, и правда — 10 тонн моцареллы. Оказалось, что Итальянцы точку в заказе расценили как разделитель и выставили счёт за 10 тонн. Никого это не смутило (видимо, финансовые дела шли хорошо), счёт оплатили — самолётом привезли 10 тонн.
В итоге, прямо на показе BI-системы компания получила инсайт — побежали распродавать остатки моцареллы хотя бы по себестоимости, чтобы не попасть на убытки. Когда всё распродали — купили BI по полной, так как увидели в этом показе знак судьбы.
И таких кейсов в книге Георгия полно.
В общем, b2b-продактам и маркетологам рекомендую почитать, чтобы поучиться представлять кейсы автоматизации в приличном виде.
#продакту
Прочитал книгу Георгия Нанеишвили “Оптимизируй это немедленно”. Георгий отвечал за развитие партнёрской сети Qlik в России. Кто не в теме Qlik — популярная BI-платформа, которая на рынке РФ входила в большую тройку иностранных BI: Power BI, Tableau и Qlik.
Звезда Клика на рынке РФ закатилась — Qlik покинул рынок России. Но кейсы остались. Собственно, книга построена на кейсах автоматизации разных компаний (в основном крупных). И надо сказать, это самое интересное описание кейсов, которое я до этого встречал.
Понравился кейс с моцареллой. Перескажу своими словами.
Крупному дистрибутору пищевых продуктов показывали BI. Делали в режиме прототипа: подключили систему к боевым данным.
И вот, на показе увидели, что “столбик” сыра моцарелла выбивается относительно других остатков — его дофига. Почти 10 тонн. Директор, которая увидела этот столбик, сказала, что такого быть не может — это дорогущий сыр и его везут напрямую из Италии. Его в месяц от силы 100 кг продают. Внедренцы сказали, что подключены к реальным данным.
Короче, позвонили на склад, и правда — 10 тонн моцареллы. Оказалось, что Итальянцы точку в заказе расценили как разделитель и выставили счёт за 10 тонн. Никого это не смутило (видимо, финансовые дела шли хорошо), счёт оплатили — самолётом привезли 10 тонн.
В итоге, прямо на показе BI-системы компания получила инсайт — побежали распродавать остатки моцареллы хотя бы по себестоимости, чтобы не попасть на убытки. Когда всё распродали — купили BI по полной, так как увидели в этом показе знак судьбы.
И таких кейсов в книге Георгия полно.
В общем, b2b-продактам и маркетологам рекомендую почитать, чтобы поучиться представлять кейсы автоматизации в приличном виде.
#продакту
Пользователи выбирают ...
Самый большой потребительский миф — свобода выбора у покупателей/пользователей.
Никакой 100% свободы нет: выбрать можно только то, что тебе продали.
Продали во всех смыслах. Через рекламу, через сарафанное радио, через друзей и соцсетевых френдов , через поисковую оптимизацию, через новости и т.д. Если продукт, который тебе 100% подходит отсутствует в этом рекламно-поисково-рекомендательном замесе, то шансы его выбрать равны нулю.
Обратное тоже справедливо: шансы, что твой продукт выберут равны нулю, если его нет в рекламно-поисково-рекомендательном замесе. Ноль шансов! Какой бы крутой ни был продукт.
Для карьеры тоже справедливо: каким бы хорошим специалистом ты ни был — тебя не заметят, если ты себя не "продашь". Не заметят.
Собственно вывод. Когда спорят, что важнее в продукте — дизайн или функциональность? Можно смело сказать, что важнее маркетинг. Без него никто не оценит ни дизайн, ни функциональность. Если в команде слабый маркетинг, то всё остальное имеет мало смысла.
#продакту
Самый большой потребительский миф — свобода выбора у покупателей/пользователей.
Никакой 100% свободы нет: выбрать можно только то, что тебе продали.
Продали во всех смыслах. Через рекламу, через сарафанное радио, через друзей и соцсетевых френдов , через поисковую оптимизацию, через новости и т.д. Если продукт, который тебе 100% подходит отсутствует в этом рекламно-поисково-рекомендательном замесе, то шансы его выбрать равны нулю.
Обратное тоже справедливо: шансы, что твой продукт выберут равны нулю, если его нет в рекламно-поисково-рекомендательном замесе. Ноль шансов! Какой бы крутой ни был продукт.
Для карьеры тоже справедливо: каким бы хорошим специалистом ты ни был — тебя не заметят, если ты себя не "продашь". Не заметят.
Собственно вывод. Когда спорят, что важнее в продукте — дизайн или функциональность? Можно смело сказать, что важнее маркетинг. Без него никто не оценит ни дизайн, ни функциональность. Если в команде слабый маркетинг, то всё остальное имеет мало смысла.
#продакту
Вчера хотел написать пост на тему, что MVP, как отдельное понятие, на бытовом уровне был поглощён давно известными понятиями прилаживание и итеративная разработка.
А потом нашёл у себя пост из прошлого лета, в котором уже всё сказал про MVP, поэтому просто его продублирую.
Употребление термина MVP сейчас в основном маркетинг, чтобы продать курсы и экспертизу.
MVP умер?
Если хорошенько подумать над каноническим понятием минимального жизнеспособного продукта (MVP), то можно понять, что он практически не актуален для современных ИТ-реалий. Кто вообще не в теме: MVP — это версия продукта, которая создаётся для тестирования гипотезы востребованности продукта.
Сразу поясню, что в этом посте речь именно об ИТ-продуктах: когда ценность в функциональности продукта, а не об инфотоварах, когда основная ценность в содержимом. Свой ценный курс по продуктовому менеджменту и дизайну вы можете запустить на чём угодно, не создавая для этого специальную LMS.
Так вот, большинство литературных примеров MVP относятся к древним (по меркам ИТ-развития) временам: доска объявлений через Эксель, Airbnb через факс, потоковая музыка, которая стала Spotify, Zappos, который продавал через интернет магазин чужую обувь и т.п.
Но помимо древности литературные примеры MVP объединяет то, что тестировалась уникальная (новейшая) модель продукта. Нет (или почти нет) примеров MVP, когда продукт выводился на конкурентный рынок.
Но жизнь такова, что сейчас 99,99% продуктов выводятся на конкурентный рынок. Цифровая революция во многих сферах уже прошла. Нельзя прийти к заказчику и предлагать ему нефункциональную CRM (любую другую систему) — он уже видел кучу функциональных CRM.
Если ваш продукт относится к 0,01% уникальных продуктов — вопросов нет: вы придумали что-то совершенно новое и можете это донести в минимальном жизнеспособном виде.
Если у вас продукт относится к 99,99% продуктов, имеющих конкурентов — для вас MVP скорее мёртв (сорян). Надо создать что-то, что будет лучше конкурентов (хотя бы не сильно хуже).
В бытовом плане MVP сейчас спустился на уровень отдельных функций: делаем функцию Х в продукте не сразу на пять, а на троечку и собираем обратную связь. Но это уже не MVP, а обычная итеративная разработка.
В общем, MVP в 99,99% случаев мёртв. Конечно, примерами ИТ-древности можно восхититься, но на практике почти никому они не помогут.
#продакту
А потом нашёл у себя пост из прошлого лета, в котором уже всё сказал про MVP, поэтому просто его продублирую.
Употребление термина MVP сейчас в основном маркетинг, чтобы продать курсы и экспертизу.
MVP умер?
Если хорошенько подумать над каноническим понятием минимального жизнеспособного продукта (MVP), то можно понять, что он практически не актуален для современных ИТ-реалий. Кто вообще не в теме: MVP — это версия продукта, которая создаётся для тестирования гипотезы востребованности продукта.
Сразу поясню, что в этом посте речь именно об ИТ-продуктах: когда ценность в функциональности продукта, а не об инфотоварах, когда основная ценность в содержимом. Свой ценный курс по продуктовому менеджменту и дизайну вы можете запустить на чём угодно, не создавая для этого специальную LMS.
Так вот, большинство литературных примеров MVP относятся к древним (по меркам ИТ-развития) временам: доска объявлений через Эксель, Airbnb через факс, потоковая музыка, которая стала Spotify, Zappos, который продавал через интернет магазин чужую обувь и т.п.
Но помимо древности литературные примеры MVP объединяет то, что тестировалась уникальная (новейшая) модель продукта. Нет (или почти нет) примеров MVP, когда продукт выводился на конкурентный рынок.
Но жизнь такова, что сейчас 99,99% продуктов выводятся на конкурентный рынок. Цифровая революция во многих сферах уже прошла. Нельзя прийти к заказчику и предлагать ему нефункциональную CRM (любую другую систему) — он уже видел кучу функциональных CRM.
Если ваш продукт относится к 0,01% уникальных продуктов — вопросов нет: вы придумали что-то совершенно новое и можете это донести в минимальном жизнеспособном виде.
Если у вас продукт относится к 99,99% продуктов, имеющих конкурентов — для вас MVP скорее мёртв (сорян). Надо создать что-то, что будет лучше конкурентов (хотя бы не сильно хуже).
В бытовом плане MVP сейчас спустился на уровень отдельных функций: делаем функцию Х в продукте не сразу на пять, а на троечку и собираем обратную связь. Но это уже не MVP, а обычная итеративная разработка.
В общем, MVP в 99,99% случаев мёртв. Конечно, примерами ИТ-древности можно восхититься, но на практике почти никому они не помогут.
#продакту