via @ruspm

Тем, кому лень читать книжку, в предложке на Единороге нашел огненную подборку из 37 выступлений с ProductCamp Пермь 2018, залитых на Ютуб - https://www.youtube.com/playlist?list=PL7qTFvaqsfQiu0zRNWCOrFGoA_VwxGMk2

#монетизация Глубокий разбор категории пользователей и их монетизации музыкального сервиса Spotify: https://lpgenerator.ru/blog/2018/04/06/cenoobrazovanie-razbor-tarifnoj-stranicy-spotify/

Разница в 1 цент в ценах дает разницу в конверсии почти в два раза. http://blog.gumroad.com/post/64417917582/a-penny-saved-psychological-pricing via @ruspm

Наглядная пошаговая схема по разработке фичи от гипотезы до продакшена и обратно. Специально для @ruspm

PDF для любителей пдф прилагается

Джоэль Гаскоин (со-владелец и CEO Buffer) взял за привычку делиться в паблике статистикой своего продукта. На мой взгляд, хорошая привычка и хороший шаблон для всех :)

Google вчера запустил в открытую регистрацию домены зоны .APP за $15. Кто давно мечтал регнуть красивый домен, еще можно успеть сделать это на том же Рег.ру

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

Иван Серебренников, автор @uxboost хорошо расписал как можно формировать и работать с value proposition (ценностью) - http://telegra.ph/Kak-poluchait-spisok-ehkranov-i-funkcionala-iz-Value-Proposition-04-13

Ничто в этом мире не оригинально, даже логотипы Медиума, Аирбнб, Флипкарта и Битсов. Загуглите, если не верите :)

Абсолютно любой человек стремится получать за свою работу больше

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

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

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

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

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

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

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

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

На Хабре вышла неплохая статья по must read книжкам для продактов с моим участием - https://habr.com/company/netologyru/blog/413405/

Интересное. Воронка взаимодействия пользователя с продуктом/брендом.

На Ноже интересная статья, рассказывающая о том, как запускались крупнейшие соц. сети мира, как они устроены и за счет чего выстреливают и гаснут

http://telegra.ph/Hroniki-cifrovogo-fashizma-chto-zhdet-Facebook-gde-sidit-pokolenie-Z-i-kakimi-stanut-socseti-budushchego-07-07

Профессиональный юмор

ТОП 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) Наличие понятной логики, по которой развивается продукт, помогает работать и команде, и пользователям.