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

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

#философияPM Все чаще задумываюсь о том, что работа продакта это постоянный поиск компромиссов, а не решений.

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

Минутка продуктовой философии закончена.

«Вначале, определимся с терминами и понятиями».

Периодически использую эту фразу как вводный раздел при написании документации по сторис или какой-либо механики работы фичи.

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

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

Благодаря этому небольшому разделу вы можете быть уверены, что общаетесь с дизайнером/разработчиком/маркетологом на понятном для вас всех языке и оперируете теми объектами, понимание которых 100% есть у всех членов команды.

Более того, это очередная формализация, которая может подтолкнуть вас или других на что-то полезное и интересное.

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

Многие спрашивают в личке о том, как привести продукт к успеху? Вопрос немного наивный и в духе "как раскрутить интернет-магазин", но постараюсь на него ответить.

Успех продукта зависит от вашего умения чувствовать целевую аудиторию и видения её потребностей.

Успех это то, как вы реализуете своё видение в продукте и то, какой отклик оно находит в действиях вашей ЦА при решении своих проблем вашим продуктом.

Как вы поняли, успех продукта напрямую зависит от вашего подхода к решению проблем. Любых.

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

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

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

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

Успех это возврат пользователей, когда они сделали всё, что вы просили и бесплатно возвращаются к вам снова через _ дней.

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

Успех продукта — команда. Профессиональная, гибкая, масштабируемая, заменяемая и незаменимая одновременно.

Проще сказать, что успех продукта это как парад планет видения, дизайна, разработки, маркетинга и сапорта. Как часто такое встречается? Как и в астрономии — это очень редкое явление.

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

Просто потому, что это легче и не требует от них никаких умственных затрат.

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

Кампания Apple под название «Я Mac» была чрезвычайно успешной. Она подчеркивала слабые места Windows, демонстрировала, насколько крутым был Mac, показывала, насколько легко было переключиться на него и изображала тех, кто не переключится, в качестве клоунов.

Поистине, Стив был не только крутым продакт овнером, но и не менее крутым психологом и рекламщиком.

https://youtu.be/qfv6Ah_MVJU

«Мы знаем нашу целевую аудиторию, их проблемы и то, что им нужно» – говорили они. #fun

Вот бы распечатать и повесить на стену в каждой компании.

Продакт-менеджер в стартапе?

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

Начинай маркетинг сразу же после MVP. Лучше - до запуска. Нет трафика - нет пользователей - нет продукта. Кому ты тогда нужен?

Отбрось A/B-тестирования. У тебя еще нет денег и юзеров - какие изменения ты собрался отслеживать?

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

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

Забей на личную жизнь. Продакт-менеджер стартапа работает 24/7 с редким перерывом на сон, прогулки и созвоны. Всё остальное неважно до тех пор, пока продукт __ нужное дописать.

Сделай первую продажу как можно быстрее. Или убей продукт.

#cusdev Customer Development в работающем продукте

Что делать, когда продукт уже едет и вроде как более менее успешен по ряду показателей/KPI, но всё равно не дотягивает до каких-то целей или метрик? Поделюсь своим опытом.

Читать на ⚡️ Экспе: https://ruspm.exp.fm/posts/21 #cusdev