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

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

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

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

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

Ну, а далее, остается только выбрать то, что соответствует целям вашего продукта на текущем этапе 😉

Картинка не влезла, пост с ней выложил на Единороге, висит первым в списке статей о продакт-менеджменте.

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

Вот как это должно работать для вас:

Придумал → Сделал → Настроил процесс → Вышел

Остаешься в не своем процессе, значит выполняешь чью-то работу за него

#grow

Про предстоящее IPO Uber и Lyft на пальцах.

Обе корпорации (важный момент) убыточны. По разным оценкам, за 2017 год у первой чистый убыток в $4 млрд, у второй в четыре раза меньше. То есть обе работают в минус и являются… классическими стартапами.

Что делает стартап? Растит метрики: юзеров, активности, оборотку. Но не доходность. Ни в коем случае не доходность. И обе корпорации с этим успешно справляются. Дак зачем они идут на IPO?

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

А пирамида это потому, что в 80% случаев выигрывают всегда те, кто первым вошел в нее (вложил инвестиции) и первым вышел (перепродал акции). Множество корпораций, в том числе прошедших IPO, до сих пор убыточны и не знают, что с этим делать. Twitter, Snapchat - лишь малая доля примеров.

Сколько привлекли Uber и Lyft инвестиций? Дохера и больше. Что делать их инвесторам? Правильно – по-быстрее окупать свои инвестиции. Как это сделать легко и быстро? Через IPO, которое открывает упрощенную процедуру покупки и продажи акций корпорации.

Печаль в том, что с соверменными корпорациям, единорогами и стартапами никто не думает о бизнесе в его классическом виде. Мало кому важна доходность. Хотя это основа естественного развития и роста бизнеса.

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

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

Будет полезна как продам, так и маркетологам, которым нужно держать перед глазами их ЦА, ее проблемы и методы их решения.

Забрать копию можно тут: http://bit.ly/2Af1DTn

#cusdev Навеяно последним изучением обратной связи от пользователей

В работе над продуктами многие менеджеры используют такую механику как Customer Development, я писал о ней в статье "Customer Development в работающем продукте - https://theunicorn.info/posts/3050/».

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

Как это можно сделать? Кто-то юзает всякие замерители NPS и формы сбора фидбека, но обычно, все используют связку каких-либо рассылок (пуши, email, popup и т.п.) + Google Forms с небольшой анкетой, которую и предлагают заполнить юзеру.

Вам как продакту это кажется простым и понятным, но для пользователей проблема всех подобных анкет лежит на поверхности, ведь им надо:

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