Product Management & AI
25.3K subscribers
602 photos
268 videos
8 files
962 links
Product Management & AI Occultism, Philosophy & Logic

YO: @mirvla (c-f 𓇶 Meteoagent.com)

SATOR
AREPO
TE8ET
OPERA
ROTAS
加入频道
Тем, кому лень читать книжку, в предложке на Единороге нашел огненную подборку из 37 выступлений с ProductCamp Пермь 2018, залитых на Ютуб - https://www.youtube.com/playlist?list=PL7qTFvaqsfQiu0zRNWCOrFGoA_VwxGMk2
Разница в 1 цент в ценах дает разницу в конверсии почти в два раза. http://blog.gumroad.com/post/64417917582/a-penny-saved-psychological-pricing via @ruspm
Наглядная пошаговая схема по разработке фичи от гипотезы до продакшена и обратно. Специально для @ruspm
Джоэль Гаскоин (со-владелец и CEO Buffer) взял за привычку делиться в паблике статистикой своего продукта. На мой взгляд, хорошая привычка и хороший шаблон для всех :)
Google вчера запустил в открытую регистрацию домены зоны .APP за $15. Кто давно мечтал регнуть красивый домен, еще можно успеть сделать это на том же Рег.ру
Мозг — это мышца. Мозг надо тренировать, тогда он будет бодрым и сильным. Записывание мыслей оказывает потрясающий эффект на головной мозг человека. Как только мысль записана, в голове освобождается место для новой мысли.
Ничто в этом мире не оригинально, даже логотипы Медиума, Аирбнб, Флипкарта и Битсов. Загуглите, если не верите :)
Абсолютно любой человек стремится получать за свою работу больше

И перед нами всегда выбор: либо сделать работу хорошо и получить вознаграждение, либо наоборот схалтурить (то есть, сделать меньше, а получить столько же)

Но первый путь («сделать лучше») очень рискованный, т.к. вознаграждение зависит не от тебя. Твои старания может быть оценят, а может и нет. И чаще как раз нет. Поэтому большинство выбирают второй вариант: сделать меньше, чем оплачено

Вы с этим регулярно сталкиваетесь в «простых специальностях»: уборщицы, няни, водители, курьеры чаще пытаются не заработать больше, а сделать меньше.

Но как быть руководителю? Как мотивировать людей в команде выбирать именно первый путь: делать лучше, чтобы получать больше?

Самое простое: нанимать тех, для кого «вознаграждение» состоит не только из денег.

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

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

Отмечать хорошую работу важнее, чем наказывать за плохую. Нужно убедить людей, что здесь, в этой компании, вознаграждение будет и все зависит только от тебя: будешь лучше работать, будешь больше получать.
Интересное. Воронка взаимодействия пользователя с продуктом/брендом.
Профессиональный юмор
ТОП 10 ошибок продакт-менеджера

Решил собрать в одном месте ошибки, которые часто совершают продакт-менеджеры. Что-то может показаться прописной истиной, но уверяю, по этим граблям ходит каждый из нас, в том числе и я.

1. Бросаться на всё и сразу. Не стоит лезть сразу в дизайн, смотреть показатели конверсии, устраивать опросы пользователей и менять процесс интеграции фич. Вместо этого сядьте и попробуйте проанализировать и выстроить каждый из этих процессов по отдельности, а после… в часть одного общего процесса.

2. Считать себя самым умным. Нет, продакты не самые умные. И да, всё крутится не вокруг них, несмотря на то, что они в центре всех процессов. Процессы формируются пользователями и их проблемами. Продакт-менеджер занимается именно тем, что слушает пользователей и их проблемы и обрабатывает эту информацию для маркетологов, дизайнеров и разработчиков.

3. «Вот я пришел и щас сделаю ВСЁ охуенно». Отчасти, продолжение прошлой ошибки в более глобальных масштабах. А так, я бы сказал, что, вообще, вся работа продакта сводится к тому, чтобы 1) не поломать то, что уже работает 2) чуть-чуть это улучшить.

4. Не слушать пользователей. Это должна быть ошибка №1, но пусть будет четвертой. Кто не слушает пользователей, того ждет судьба ICQ, Yahoo, Skype и т.п. компаний, менеджеры которых посчитали, что они см. п.2.

5. Сначала делать/говорить, вместо того чтобы слушать/общаться. Продолжение прошлой ошибки, которая распространяется не только на пользователей, но и на команду. «Меньше делай, больше думай» — я бы вообще сделал лозунгом продакт-менеджеров.

6. Пообещать что-то пользователям и не cделать этого. Пообещайте своей половинке подарок на день рождения и не подарите его. Боюсь подумать что будет. Дак вот пользователи вашего продукта воспринимают ваши невыполненные обещания примерно также.

7. Полагаться на память. «Даа я запомню!». Ага, как же. Запомни простое правило «Услышал/увидел — записал». Не устану говорить, что Google Keep и Asana должен стать священным хранилищем ваших мыслей и задач. Быстро, удобно, всегда под рукой.

8. Не развиваться. Какую последнюю книгу вы читали по своей специальности? Или, может, вы запускали еще один проект и получали знания через практику? Тоже нет? Тогда сделайте что-то, пока не поздно.

9. Не менять себя. Я про привычки, процессы, инструменты, подход, мышление и т.п. вещи. Окружающий мир меняется, а вы нет? Моя 7-летняя дочь уже называет меня стариком, а мне всего 31 год. Или уже не всего…

10. Десятой ошибкой я хотел бы попросить поделиться вас (просто напишите мне @mirvla), после чего сделаю из них отдельную подборку.
Советы по работе с прототипами:

Думайте. Прототип - отличное место, чтобы остаться один на один с будущим продуктом и подумать о его настоящем и будущем. Без преувеличения скажу, что именно прототип является 50% залогом успеха запуска продукта. Да-да, остальные 50% это сама идея и маркетинг. Продумайте пользовательские механики и пути по сайту и постарайтесь их МАКСИМАЛЬНО сократить? Сократили? А теперь проверьте и сократите еще раз.

Не торопитесь. Я руководствуюсь правилом "Подожди два дня". Придумали что-то клевое, что кажется вам киллер-фичей ну и "очень важной/клевой/правильной" штукой, которую точно нужно включать в релиз? Нарисуйте в прототипе/дизайне, остыньте, подождите пару дней и снова проверьте, так ли эта штука крута. Уверен, что через пару дней ваше мнение может измениться. Вы потеряете два дня, но можете сэкономить недели/месяцы разработки ненужной фичи, решение о которой могли принять под впечатлением и эмоциями.

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

Заимствуйте. Юзайте бесплатные картинки, иконки и сеты из открытых библиотек (FlatIcon, FontAwesome, Boostrap в помощь). Не надо делать больше, чем нужно для проверки гипотезы. Не надо рисовать модные нынче иллюстрации, проводить а/б тесты, коридорные тестирования и делать т.п. вещи. Это нужно делать после запуска продукта.

Упрощайте. Прототип должен быть легко и быстро изменяемым. Прототипируйте его в Figma - они позволяют использовать готовые для прототипирования наборы (presets / layout). Для теста базовой пользовательской механики не стоит добавлять сразу все фичи. Если в прототипе есть куча характеристик/дропдаунов/фильтров - исключайте их. Оставляйте только то, что нужно.

Экономьте. Время, место, клики. Как своё, так и пользователей. Вообще, время, это самое ценное, что у всех нас сейчас есть...
Мало кто знает, но перед тем, как уйти в продакты, я... два года работал в собственной веб-студии, которая занималась узкоспециализированной разработкой в сфере e-commerce. Если проще - пилил интернет-магазины. Сайт давно умер, но веб-архив всё помнит - http://bit.ly/2AdfL1W.

Опыт, который я получил в то время, я до сих пор считаю самый полезным и ценным. Я научился разбираться в потребностях заказчика и его бизнеса, писать на основании них документацию, проектировать интерфейсы, строить спринты и коммуницировать с разработчиками и дизайнерами и сводить их действия в единую цепочку.

Паре заказчиков мы даже оказывали услуги по маркетингу: сеошка, контекст, смм - в 2012 году всё было стандартно. Определение ЦА, проблем, маркетинговых посылов, каналов, CTR, вовлечение, конверсии - именно тогда я и познакомился со всеми этими терминами.

Я это к чему. Всё то, чем я занимался заложило хорошую базу знаний и навыков, которые я до сих пор использую будучи продактом, т.к. на 80% в продукте приходится делать практически тоже самое.
Привет! На прошлой неделе я публиковал пост с ТОП-10 ошибками продакт-менеджеров, по которым мы все ходим. Как вы помните, десятый пункт я оставил для вас и предложил вам поделиться своим собственным опытом.

Поэтому, встречайте продолжение - 13 ошибок продакт-менеджеров по версии читателей канала @ruspm.

@vladimir3v - Очень большую ошибку продактов вижу в боязни принимать решения в сложной ситуации. Из моего опыта, затягивание и откладывание, чаще всего гораздо хуже, чем неэффективное, но приятное решение. А иногда это просто упущенная возможность. Вторая большая ошибка - не быть откровенным со стейкхолдерами.

@x6750km - вижу ошибку в замыкании всех процессов на себя. А потом продакты удивляются, почему это они все время сидят за компом до ночи и не могут уехать в отпуск или заболеть без ущерба для проекта.

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

+ слишком редко отходить от мольберта или не отходить вообще. Когда продукт активно развивается, очень легко закопаться в операционной деятельности и перестать развивать продукт по-настоящему.

@yalugin - Вообще ничего не понимать в программировании. Писать ТЗ без понимания того, как и какими силами это будет делаться - херовая затея. Хорошая аналогия - задать прочитать за лето Войну и Мир в пятом классе.

@v0lad0res - Не иметь концепции и стратегии развития продукта. Приводит к реагированию на запросы и лишает возможности создать действительно что-то ценное и новое.

@elsemka Сам большая ошибка - боязнь ошибок :)

@evgenymedvedev - Заниматься микроменеджментом. Вылизывая форму регистрации и страницу FAQ, в тоже время, не замечая глобальных продуктовых проблем и задач.

+ Слушать пользователей, но не слышать их: не искать в их реквестах и фидбеке настоящих проблем и реализовывать все подряд потому что «пользователи просят».

+ Не смотреть на деньги. Вижн, миссия, ценности это все очень хорошо, но если в. PnL убытки то в консерватории что-то не так.

@pr0kopenko - Не следить за миром за пределами продукта. Если не смотреть на законы, смежные рынки и то, что происходит в технологиях, можно упустить момент, когда твой продукт перестаёт быть нужным. Нужно всегда смотреть на то, что творится вокруг проблем твоих пользователей и как меняются их жизненные ситуации. На этом многие, кажется, прокололись.

@ivanodigital - Устроиться продуктом в компанию, которая не является продуктовой

@hedgehoney - держать всё в себе, т.е. не давать команде понимания конечного результата, не учить их думать о клиенте (а только о выполнении своей конкретной задачи)
Скоринговая модель выбора фич для разработки

Для подсчета скоринга собирается список фич-кандидатов на разработку и по каждой из них проставляется оценка от 1 до 10 (где 10 - самое высокое) по следующим категориям:

— Упрощение работы поддержки: насколько уменьшиться количество обращений от пользователей в поддержку.

— Популярность у пользователей: субъективно, на основе числа тикетов, комментариев в соцсетях, устных запросов.

— Простота реализации: от мегапроекта на год до доработки на один день.

— Маркетинг-эффект: насколько возрастет количество новых лидов.

— Монетизация: насколько возрастут платежи за что-либо.

После того, как все оценки проставлены, считается общий скоринг, фичи сортируются по набранным очкам, вычеркиваются неподходящие под основное направление роадмапа.

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

Результаты:

1) Соблюдение формального процесса помогает не делать откровенно бесполезную работу.

2) Сам процесс планирования не отлит в граните и постоянно меняется. Уже через год процесс в нашей компании будет сильно отличаться от текущего.

3) Наличие понятной логики, по которой развивается продукт, помогает работать и команде, и пользователям.
Не так давно писал про скоринговую модель определения фич для разработки. На самом деле, ее корни берут свое начало из отделов продаж, когда будущих клиентов компании оценивали по аналогичной модели (Кирилл, привет!)

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

Эти критерии сортировались по важности для вашего бизнеса и каждому критерию присваивался свой "вес" (коэффициент, например x1 или x2), если ценность критериев сильно разнилась друг между другом.

Далее по классической схеме каждой компании по каждому критерию проставлялся балл от 1 до 10, где 10 самый высокий.

На выходе получался общий балл. У какой компании больше балл (а, значит ценности для вас как бизнеса) — та для продажника считалась более приоритетной/доходной и с ней начинали работать первой.