#tools #exp Ещё один способ приоритизации идей/гипотез/фич без сложных методологий, графиков и прочих умных моделей.

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

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

1. Раз в квартал проводите тематический мозговой штурм с командой маркетинга, продаж и поддержки (и только после своей команды идите за идеями и хотелками к СЕО/инвесторам (помня, что они в другой команде).

Мой совет – лучше вообще к ним не идите, а если сами позовут, то придёте с готовой инфой "от вашей профессиональной команды".

2. Попросите каждого члена этих команд, вне зависимости от их количества и статуса, добавить и отранжировать их идеи/фичи по личной субъективной значимости (да, именно так).

3. Выберите от каждого отдела 3/5/10 самых популярных идеи-фичи и далее уже самостоятельно оцените их по трём критериями:

1) ожидаемое воздействие (метрика);
2) необходимые ресурсы (время);
3) потенциальные профиты и риски (деньги).

4. Следуйте правилу "70/20/10", где:

– 70% ресурсов должны направляться на истории с низким уровнем риска и быстрой отдачей в метрику (развиваем настоящее);

– 20% ресурсов должны идти на рискованные долгосрочные ставки и отдачу (строим задел на будущее);

– 10% ресурсов должно идти на всякие забавы, пасхалки и другие приятные/необычные/wow-вещи, от которых команда и юзеры будут испытывать эмоции (эмоции всегда работают в плюс сквозь время).

5. Если до сих пор не определились с приоритетами, то сделайте третий подход и самостоятельно приоритизируйте оставшиеся идеи на основе:

1) результатов командного голосования (какая история является любимой в команде и почему);

2) стратегической важности (есть ли гипотезы/идеи/фичи, которые продукт должен иметь именно сейчас и почему);

3) простейшей логики и интуиции (что сейчас ощущается важным и почему).

Снова тупняк и сомнения? Снова прогоняйте выбранные идеи по критериям из пункта №3.

Как часто собирать команду? Ежеквартально – оптимальный баланс между актуальностью и частотой. Но если вы или команда в какой-то момент почувствуете, что НЕЧТО в продукте нуждается в своём пересмотрении, просто соберитесь и обсудите именно это.

P.S. И да, если инвестор всё же навязывает вам нечто, кхм... забавное, включите его хотелку в те 10% 😏

Полезное по теме:

– Как НЕ надо работать с бэклогом;
– Инструкция по интуиции для продакт-менеджера
– Как организована приоритизация фичей в SkyEng, Ali, Wrikle
– Приоритизация на основе баллов и скоринга

#tools Отмечайте успех и прогресс пользователя(ей)

Постепенно, интерес пользователей к вашему продукту начнёт ослабевать (а с ним и вовлечение/возврат).

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

Самый яркий и удачный пример – системы наград и ачивок в играх (в mmorpg это еще и эффект социального одобрения-превосходства), механики и концепции которых можно частично перенять и интегрировать в SaaS-продуктах

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

#tools Сбор обратной связи "здорового человека" командой Gamestop.

Меня, как продакта, особенно радует:

– выбран чертовски верный канал для сбора (твиттер, где тусуется вся крипто аудитория и идёт весь nft-движ);

– канал в режиме live, команда может тут же уточнять вопросы, при необходимости;

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

– а значит это сильная прокачка лояльности и формирование лояльного комьюнити вокруг продукта;

– Твиттер – соцсеть (ваш АЯ), а значит сбор фидбека превращается ещё и в шоу (маркетинг).

P.S. Толковое руководство и команда творят с it-компаниями чудеса! God bless Ryan Cohen 🫶

#tools 4 совета по работе с метриками и целями:

1. Разделите метрики/цели на достижимые и амбициозные.

После чего делите их в зависимости от приоритетов и текущих возможностей по этим группам в нужных пропорциях, например, по-классике "80/20".

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

2. Ещё одна распространенная ошибка – перенос старых целей на новый период после их недостижения.

В большинстве случаев, причина падения метрики – объект метрики/цели уменьшил свою значимость для пользователя. Либо кривой UI/UX. Либо плохой трафик. Либо рынок сдувается. Либо бага на сайте. Что угодно.

Цель – разобраться и найти истинную причину спада, а не слепо долечивать и гнаться за поставленной ранее метрикой уже в новом квартале.

3. Не упрощайте метрики/цели

«Уменьшить задержку загрузки страницы на x%» – написано красиво.

«Уменьшить задержку загрузки страницы на x%, чтобы повысить % конверсии в Y» — лучшее описание цели, которая будет понятна и вам, команде и даже пользователям.

4. Не забывайте про пост-анализ метрик/целей

Какие метрики и цели продукт/команда достигли без сильного напряжения, а над какими пришлось попотеть? Ответы на эти вопросы дадут вам понимание того, насколько верно вы приоритизировали цели в п.1 и с каким темпом вы к ним идёте.

– Как держать в голове кучу метрик и следить за ними
– Приоритизация по модели "Матрица влияния/усилий"
– Приоритизации без сложных методологий

#tools #exp Lenny Rachitsky вчера поделился новым фреймворком для развития продукта под названием The Racecar Growth Framework.

Пост закрыт за paywall, но и без него понятно, как оно всё может работать.

P.S. Оч клёвая визуализация, есть чему поучиться.

#tools Делаем фичу или новый суб-продукт?

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

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

– Фича предлагает новое решение новой проблемы (суб-продукт) или улучшенное решение старой проблемы (внутр. фича)?

– Объём рынка новой фичи по отношению к объёму рынка основного решения продукта станет больше (суб-продукт) или он меньше и не изменится (внутр. фича)?

– Фича влияет на удержание/прилипание пользователей (внутренняя фича) или способствует росту новых пользователей (суб-продукт)?

– Фича способна влиять на одно пользовательское действие/метрику (внутренняя фича) или может сразу на несколько (суб-продукт)?

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

– Готовы ли юзеры платить за фичу отдельно (её способность продаваться автономно от основного продукта/проблемы) или только в комплекте с основным продуктом (внутренняя фича)?

– Сможет ли фича в одиночку выдержать отток/снижение продаж (суб-продукт) или не сможет, т.к. юзерам нужна фича-механика-якорь, за которую они смогут удержаться как в основном продукте (внутр. фича)?

– Фичу и даже её mvp сложно/долго/дорого интегрировать в нынешний продукт и легче протестить это отдельно (суб-продукт) или же её легко встроить в него (внутр. фича)?

– Нужны ли новые люди/деньги/процессы на поддержание и развитие фичи (суб-продукт) или она способна работать в текущих (внутр. фича)?

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

#tools #best #team Как команде генерировать рабочие гипотезы, а не рандомно фантазировать?

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

Несколько моментов:

1. Поля заполняются в порядке нумерации.
2. Фокус на проблеме, ориентация на результат.
3. Коммуникации 1:1 рулят, в шаблоне есть обратная связь от продакта к автору идеи.

👉 Ссылка на шаблон в Notion.

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

P.S. Для копирования шаблона в свой проект, скопируйте ссылку на нужную страницу с ним, вставьте в свой проект как linked и потом просто сделайте Duplicate.

Для назначения шаблона зайдите в нужную вам доску, нажмите создать новую таску и в пустом поле её описания выберите or create a template, в который и нужно вставить эти поля с формой.

Полезное по теме:

– Самая полезная обратная связь — негативная
– Повышаем качество выдаваемых комндой гипотез/идей/фич

#tools #metrics Измерение NPS - пустая трата времени.

Уверен, вы не раз цепляли форму опроса и спрашивали своих активированных юзеров «Достаточно ли вы удовлетворены сейчас, чтобы бла-бла в будущем?».

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

Вместо этого задавайте вопрос:

«Что делают довольные клиенты в нашем продукте?»

и адресуйте его... своей команде.

Ответы, которые найдёте вы и ваша команда и будут следствием удовлетворенности юзеров.

И именно они будут теми показателями, которые вы должны замерять для оценки удовлетворенности вместо NPS.

Вот некоторые примеры:

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