Про 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 и других провели совместный аудиоэфир, главной темой которого стало обучение продактов. Обсуждали, чего не хватает текущим курсам, кому доверяют при найме, где брать…
Про 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% случаев мёртв. Конечно, примерами ИТ-древности можно восхититься, но на практике почти никому они не помогут.
#продакту