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

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

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

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

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

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

#книги Прочитал книгу "Бизнес против правил" Андрея Трубникова, основателя Natura Siberica, Planeta Organica, Organic Shop, «Рецепты бабушки Агафьи».

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

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

Слушать людей. Постоянно фиксировать свои или чужие идеи. Записывать, даже если идея пришла ночью, во сне. Проснуться и записать.

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

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

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

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

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

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

Быть быстрым. Лучше всего проверять новый продукт прямо с ходу, на людях. Прийти в магазин, поставить на полку и следить за их реакцией. Потом спрашивать: что понравилось, а что не понравилось. Как говорил Наполеон, надо ввязаться в бой — а там посмотрим.

Хороший продукт сам себя продает. Усилия при разработке продукта — залог успеха на полке. Не нужно никаких миллионных затрат на рекламу. Лучшая реклама — сарафанное радио. Один твит популярной блогерши даст больший эффект, чем сто роликов по Первому каналу.

Команда — все, ты — ничто. Настоящий лидер собирает команду как волк стаю. Необходимо удерживать ее всеми силами. Такая команда порвет любого конкурента. Даже если сейчас нет работы — платить людям деньги, чтобы они не уходили. Собрать новую команду будет гораздо затратнее.

Добиваться идеала. Если запускается совершенно новый бренд, он должен быть готов до мелочей. Пока вы не убедитесь, что он идеален, — нельзя выходить на рынок. Лучше потерять время, но не покупателей. Я часто нарушал это правило — потом жалел.

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

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

Быть актером. Руководитель должен все время играть разные роли. Сейчас я художник, а через час — жесткий менеджер.

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

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

Как не распыляться и, в тоже время, успевать много дел?

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

Например, у меня сейчас такой порядок:

1) Эта задача помогает достичь стоящие сейчас цели?
2) От решения этой задачи зависят решения/действия других членов команды?
3) Эта задача имеет быстрое или долгое решение?

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

Михаил Токовинин поделился правильной мыслью.

Должен ли создатель продукта слушать пользователей? Кто-то верит, что только пользователи знают как надо, кто-то вспоминает Форда, который утверждал, что пользователи попросили бы у него не автомобиль, а более быструю лошадь.

Я думаю, правда посередине. Общение продукт-менеджера и пользователя должно быть похоже на общение доктора с пациентом. Да, доктор внимательно слушает пациента, но назначает не то что просят, а то что нужно.

Невозможно сделать хороший продукт, если не слушать пользователей. Невозможно сделать хороший продукт, если делать то, что пользователи просят.

Как идея становится фичей: пошаговая инструкция

Очень часто (на самом деле, постоянно) перед продакт-менеджером возникает потребность в том, чтобы его детище расширялось функционалом для своих пользователей. Как сделать так, чтобы эти фичи оказывались максимально а) востребованными б) быстрыми в разработке?

1. Сформулировать идею в формате мини-истории. Мы в EPICSTARS используем короткий шаблон, который стараемся заполнять под каждую идею:

1 - Какую проблему решает ваша идея
2 - В чем недостатки текущего решения?
3 - За счет какого действия/особенности она будет решена
4 - Варианты реализации идеи (не обязательный для стадии формулирования идеи пункт)

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

Я рассказывал ранее, что использую простой подход к определению того, на что влияет будущая фича: 1) лояльность и(или) активность пользователей; 2) деньги пользователей. Зная какие цели перед вами и вашим продуктом сейчас стоят, вы можете на начальном этапе отфильтровать те, которые уже не нужны.

Можно использовать скоринговый подход, описывал его в этом посте: http://yangx.top/ruspm/201

3. Второй этап фильтрации на уровне одноцелевых фич. На этом этапе нужно определить приоритет конкретной фичи по сравнению с аналогичными фичами, которые стоят в одной группе и преследуют одни цели.

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

4. Выбираем фичу. Исходя из а) этих оценок б) внутренного голоса (да-да) сделать выбор идеи, с которой дальше пойдет работа.

5. Начинаем созидать. Далее начинается кропотливая работа, вариации которой разнятся от продукта к продукту, от команды к команде. В нашем случае, мы расширяем описание сторис и ставим метрики, на которые ее реализация или изменение должны повлиять.

6. Далее эта сторис уходит на прототипирование. Обычно, проходит не более 3-х интераций, в результате которых становится понятна механика, по которой эта фича может работать.

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

7. Получаем апрувы. На этом же этапе бэкэнд и фронтэнд дают свое "добро" на этот вариант реализации и апрувят его понимание.

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

9. Верстка. Далее снова зависит от текущего положения ролей в команде. У нас версткой макетов (и-за наличия единого стиля и готовых блоков интерфейса) в 80% случаев занимается фронтэнд-разработчик. В этом есть плюс когда команда не занимается креативом и не фигачит лендосы, где нужно изворачиваться и постоянно придумывать что-то новое. Макет верстается.

10. Включение в бэклог. Полдела сделано - теперь у нас есть готовая к разработке фича, сформулированная в сторис и содержащая ВСЮ необходимую и понятную для всех участников процесса/команды информацию, которую можно смело включать в бэклог, а потом и в спринт.

11. Разработка. Далее фича идет в разработку теми, кто включен тимлидом в этот процесс. У нас тимлид пишет отдельную техническую стори в которой описывает то, что написано в продуктовой стори на языке архитектуры, связей объектов и другой тарабарщине, которую не всегда нужно понимать ))

Обычно в процессе задействованы перечисленные выше фронт и бэкенд-разработчики (или целые команды), которые по традициям старой школы ведут разработку на тестовом сервере с приставкой DEV, о наличии которого знает только ваша команда.

12. Тестовый релиз. Когда фича готова, она идет в релиз на этом сервере, где по все тем же традициям ее работоспособность и соответствие требованиям тех/ сторис проверяет QA-инженер. Если что-то не так - фича переделывается. Рекомендую проверять фичи на дев-сервере на соответствие вашим ожиданиям и сторис, чтобы потом не переделывать их на проде.

13. О - ожидание. Ура, QA проверил и дал зеленый свет! Но фича ждет остальные фичи, которые были включены вами в спринт...

14. С днем рождения! День релиза на продакшен-сервере (который боевой с публичным продуктом и для пользователей) для продакт-менеджера как день рождения для ребенка, с той лишь разницей, что такие дни рождения можно устраивать каждый месяц!

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

16. Проверка. Обычно, в день релиза я как продакт иду и проверяю соответствие выкаченной фичи ее описанию из сторис и макетам. Если все ок - день рождения удался! Если нет - ох... лучше не думать об этом и именно поэтому читай п. №14.

17. Движение вперед. Фича работает, активность идет, метрики начали двигаться. В зависимости от фичи, к ее релизу можно привязать какие-либо маркетинговые активности (новость на сайте, рассылка, промо).

18. Пост-аналитика. Настало время считать цыплят, а именно правильно ли вы выбрали фичу и то, как она решает поставленные перед ней задачи. Снимаем метрики и делаем выводы о том, все ли вы правильно сделали. Нет - возвращайся к п.№1

Статья написана для раздела статей о продакт-менеджменте сайта 🦄 Единорог