Чек-лист правильных OKR-целей

1. OKR должны быть компактными. Не более страницы текста, в идеале полстраницы.
2. OKR это не to do-лист и не план работ. Если OKR выглядят таким образом, значит, их нужно переработать.
3. Хотя бы один OKR команды должен быть связан с глобальными целями компании. В противном случае непонятно, какое отношение команда имеет к бизнесу.
4. Приоритеты OKR внутри команды должны увеличивать вероятность достижения целей компании. Ключевая цель бизнеса не должна быть отражена в OKR команды последним пунктом.
5. Связанные инициативы должны быть согласованы. Разработка планирует выпустить продукт Z, а маркетинг обеспечить его продвижение. Если выпуск состоится в самом конце квартала, времени на его продвижение будет недостаточно.
6. Все глобальные обещания команды должны быть включены в ее OKR. Если другая команда предполагает, что отдел работает над целью X, а в действительности ничего такого не происходит — это проблема.
7. Цели не должны определять обычные и регулярные бизнес-задачи. Правда, Эффект Черной Королевы, когда нужно бежать чтобы оставаться на месте, никто не отменял. Если для сохранения достигнутых результатов требуется приложить экстраординарные усилия, в OKR отдела могут быть включены цели и по их штатной деятельности.
8. Достижение цели должно требовать усилий всего отдела или команды. В противном случае штат отдела раздут либо его сотрудники недостаточно мотивированы.
9. Достижение целей должно вести к существенной пользе бизнесу.
10. Определенные результаты должны быть достаточны для достижения цели. Если достижение цели определяется результатами недостаточными для признания ее успеха, это приведет как к реальным задержками в работе по причине отсутствия ресурсов в момент когда неучтенные требования проявятся, так и срыву планируемых сроков вследствие этого.

В чем разница в Проектном и продуктовом подходе? Что отличает продукт и как понять, что продукт получился (KPI, OKR и прочее)? Как менеджеру проекта поставить цели, эффективно управлять процессом и достичь целей в разработке любого IT-продукта?

Об этом и не только практический онлайн-курс «Agile Project Manager в IT» от Otus. И 30 ноября в 20:00 преподаватель курса в Otus и Agile Coach расскажет о ключевых навыках проектного менеджера в IT и проведет обзор рынка вакансий. Также вы познакомитесь с программой и форматом обучения на этом практическом онлайн-курсе. Оставьте заявку, чтобы посетить встречу и задать свои вопросы эксперту в прямом эфире https://otus.pw/

В2b и b2c продукты – в чем особенности разработки?

-Работа продуктовика над b2b-приложением предполагает фокус на макротренды и длинные истории, а не на микротренды, моду, покупку здесь и сейчас, как в b2c. Важно, что для трансформации конкретного продукта можно сменить не только его тип, но и сегмент ЦА, ценообразование и т. д.
-В b2b и до продажи, и во время, и после сохраняется более плотное общение с клиентом, хотя правильнее, если канал коммуникации меняется с продаж на customer success, которые в свою очередь могут вернуть существующего клиента сейлам, но уже для пролонгации или апгрейда. Не надо вести себя, как b2c: забывать про клиента, провоцировать на отток и надеяться на одни новые фичи.
-Для b2b-продукта уже недостаточно просто отгружать товар или лицензию. Этим ничего не заканчивается. Необходимо залезать внутрь текущей базы и предоставлять сервис, то есть убедиться в том, что есть ценность от внедряемых решений, что основной сценарий, который лежит в основе процессов, дает результат.
-В b2b-компаниях в целом не всегда есть понимание своего продукта. Когда продуктовик идет опрашивать коллег, он получает совершенно разные ответы на довольно простые вопросы: кто у нас клиент, что у него болит, что мы ему предлагаем?
Хотите узнать больше трендов и специфики работы с b2b-клиентом? Много полезного расскажут 30 ноября на первом онлайн-митапе для product owner (PO) & product manager (PM) от X5Tech. Там поговорят об отличиях продуктов b2b от b2c, обсудят различия PM & PO, рассмотрят best practice по управлению b2b продуктом на примере используемых фреймворков.
Регистрация по ссылке - https://x5-retail-group-event.timepad.ru/event/1846645/

Частые ошибки при постановке стратегии

Ошибка №1: цели = стратегия
Стратегия — про то, как победить команде. Цели — про то, что такое победа. Например, у шахматиста есть подробный набор шагов (т.е. стратегия) для победы в матче (т.е. достижения цели).
Например, компания говорит: «Наша стратегия – увеличить доход на 20%». Но увеличение дохода – это цель, а не стратегия. Способов увеличения дохода может быть несколько – например, выйти в новый сегмент рынка или увеличить конверсию с бесплатного пробного продукта на платный продукт.

Ошибка №2: достижение целей = выполнение стратегии
Стек продуктовой стратегии помогает командам отслеживать, насколько работа продуктовой команды способствует выполнению задач компании. В большинстве компаний для оценки эффективности используют краткосрочные цели, просто потому что так проще. Но достижение цели не обязательно означает прогресс в реализации стратегии. Цели могли поставить в отрыве от стратегии или исходя из неверных предположений. Кроме того, стратегия зависит от внешних факторов, таких как конкурентные действия и рыночные условия.

Ошибка №3: стратегия продукта = стратегия компании
Это приводит к неправильной оценке той роли, которую играют продажи, маркетинг, поддержка и другие подразделения. Да, продукт важен, но он — не единственная движущая сила стратегии. Важно, чтобы движение было согласованным на всех этапах и уровнях компании.

Ошибка №4: сначала цель, потом план
План развития продукта – ключевое условие для достижения цели.
Многие компании считают, что команда должна сначала поставить цели, а затем прикинуть, как их достичь. Но по факту такой подход побуждает команду достигать краткосрочных целей любыми способами, часто в ущерб целенаправленному набору фич, понятному UX и стратегическому прогрессу в долгосрочной перспективе. Цели должны вытекать из плана развития, составленного таким образом, чтобы приносить пользу пользователям.

Состав иерархии метрик

Это инструмент, в котором метрики выстраиваются в пирамиду.
Строгой структуры у нее нет, так как все меняется и перестраивается в зависимости от целей организации и самого продукта.
Внешне пирамида метрик напоминает пирамиду потребностей Маслоу. Суть та же — чтобы достичь верхней точки, нужно пройти все ступени, начиная с нижней:

⁃ Внизу пирамиды находятся платформенные метрики — это про техническую надежность вашего продукта и его доступность.
⁃ Дальше идут интерфейсные метрики. Это про взаимодействие пользователя с приложением, метрики эффективности рекламы, конверсия форм и кнопок.
⁃ Следующая ступень — непосредственно продуктовые метрики. Это про пользовательские сценарии, проще говоря, поведение людей в продукте. Здесь же средний чек от одного пользователя, время взаимодействия, лояльность, регулярность использования и возвращаемость.
⁃ На верхних уровнях пирамиды метрик находятся бизнес–цели. Доходы инвестиции и все, что связано с экономикой проекта. Здесь используем метрики, которые описывают потоки благ: материальные (конечно, деньги) и нематериальные блага (интерес, польза для людей). Например, из нематериальных это могут быть: время ожидания услуги, взвешенная конверсия покупок.
⁃ И венчает пирамиду метрика Всевластия, роста и она же метрика полярной звезды North Star Metric (NSM). Это выходная метрика, то есть показывает результат от всех остальных действий. Про нее я писал ранее - https://news.1rj.ru/str/FreshProductGo/57

Хотите узнать больше прикладных инструментов по продуктовой аналитике и общаться с аналитиком на одном языке? Приходите на Demo day курса "Продуктовая аналитика", 7 декабря в 20:00. На дне открытых дверей Вы сможете задать интересующие Вас вопросы о продуктовой аналитике.

Готовьте вопросы, оставляйте заявку и присоединяйтесь! https://otus.pw/Eqiv

Когда действительно нужен проджект-менеджер для вашего продукта

Вам стоит нанять PM, если: 
⁃ у вас большой проект со стойкой иерархией, а распоряжения поступают сверху вниз
⁃ продукт, который вы разрабатываете, требует плановой, но несрочной доработки
⁃ у вас большая и разношерстная команда
⁃ вам необходим человек, который будет работать и с продуктом, и с командой, и с вами
Вам стоит нанять Scrum-мастера, если: 
⁃ вы только начинаете внедрять метод Scrum, у вас первые итерации
⁃ ваш проект очень динамичный и требует постоянных изменений, а значит работа спринтами будет более эффективной
⁃ вам необходим человек, который адаптирует гибкие методологии под ваш проект

В чем сильная отсройка проджекта от Scrum Master?

⁃ Менеджер проекта создает, управляет и обновляет все формы документации (краткое описание проекта, PID, бюджет, риски, план проекта, диаграмма Ганта и т. д). Scrum Master не создает, не управляет и не обновляет документацию вообще. 
⁃ Менеджер проекта распределяет работу среди членов команды, учитывая их загрузку и доступное время.
⁃ Менеджер проекта также управляет областью деятельности стейкхолдеров. Scrum Master не имеет никакого  отношения к продукту, он отвечает только за процесс, результат которого — успешный продукт. 
⁃ Роль менеджера проекта достаточно широкая. Она содержит много разных обязанностей, которые иногда не имеют закрепленных описаний. Роль Scrum-мастера более сфокусирована, так как определяется Scrum Framework.
⁃ Одна из причин, по которой многие реализации Scrum терпят неудачу, заключается в том, что необходимый набор ролей не до конца понят организацией. Менеджер проекта может переквалифицироваться как в scrum-мастера, так и в владельца продукта, но это не универсальное решение.

Проектный менеджер больше не нужен? Это бесполезная работа или основа успеха любого проекта? Что считать результатом работы менеджера проектов? Когда без него можно обойтись, а когда — совсем никак? Взвесим все за и против на бесплатной конференции OTUS MeetUp 2 декабря в 18:00!

Кто будет участвовать в дебатах?
1. Проектный менеджер Юлия Белозерова
2. Продуктовый менеджер в Biglion Влас Старцев
3. Agile coach в Почте России Дмитрий Емельянов

Записывайтесь на мероприятие, чтобы не пропустить битву экспертов: https://otus.pw/K775/

Базовые приемы и инструмент для успешного бизнес-нетворкинга

• Нетворкинг строится на доверии и на осознании взаимной выгоды.
• Необходимо определить цели в участии в целевых мероприятиях и выбрать группы, которые помогут получить необходимое. Некоторые встречи основаны больше на обучении, установлении контактов, а не на исключительно деловых связях.
• Стоит посетить столько мероприятий, сколько возможно. Нужно обратить внимание на тон и отношение группы. Стремятся ли люди поддерживать друг друга? Является ли руководство компетентным? Многие группы придется посетить несколько раз, прежде чем станет понятно, подходят ли они.
• На встречах следует задавать вопросы, предполагающие развернутый ответ. Такие вопросы приводят к началу дискуссии, и собеседник осознаёт заинтересованность.
• Необходимо понять свою ценность в глазах других. Когда люди признают кого-то в качестве авторитета, то постоянно обращаются за советами, контактами людей и так далее. Это поможет всегда быть на виду.
• Стоит сформировать четкое понимание того, в чём состоит деятельность, почему, для кого и что отличает от конкурентов.
• Зачастую люди в разговоре спрашивают: «Чем я могу помочь?». Необходимо понять, в чём ценность других. Ответ приходит не сразу.
• Обязательно прислушиваться к обратной связи и быстро реагировать на нее. Уважать такие отзывы, ведь они могут показать недостатки, которые стоит исправить.
• Стоит определить тех, кому можно принести выгоду своей деятельностью, и связаться с  ними, назначить встречу, на которой можно обсудить идеи.
• Активно наращивать деловые связи для нетворкинга в соцсети TenChat (русский LinkedIn). В несколько свайпов можно познакомиться с топ-менеджерами крупнейших компаний и банков РФ, а ещё найти бизнес-партнёров для запуска собственного стартап-проекта или просто прокачать скиллы изучая кейсы роста коллег в Ленте новостей. Вместо сотен тысяч классических и ненужных сервисов, главный фокус на миниаппах для заработка (в стиле WeChat) и все это бесплатно!

Очень рекомендую провести вечер пятницы с пользой для своего будущего и скачать прямо сейчас это мобильное приложение. Вперед: https://tenchat.app/
И, конечно, мой профиль там - https://tenchat.ru/SergeyKoloskov

Блоги на английском языке для продактов

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

Hiten Shah blog - Блог от создателя трёх SaaS компаний: Crazy Egg, KISSmetrics, Quick Sprout. Делится подборкой интересных статей в еженедельных письмах.
Продуктовые процессы, практики, кейсы

Roman Pichler — эксперт в продуктовом менеджменте, специализирующийся на диджитал-продуктах. У него более 15 лет опыта в обучении продуктовых менеджеров и владельцев продуктов и в помощи компаниям в построении успешного продуктового менеджмента. Пишет на разные темы, в том числе про построение продуктов, Scrum и Agile.
Продуктовые процессы, практики, Scrum и Agile

David Skok - Отличная коллекция по SaaS в целом, метрикам, росту и масштабированию бизнеса. SaaS, рост, масштабирование бизнеса

Jason Fried - Блог генерального директора Basecamp, соавтора Getting Real, Remote, REWORK. Хорошая подборка эссе о No bullshit подходе к продукту и командной работе.
Лидерство, стартап-мышление, производительность, командная работа

Brian Balfour and Reforge - Отличные статьи о росте продукта от генерального директора Reforge и бывшего вице-президента по росту в Hubspot.

Marty Cagan an SVPG - Блог пионера продуктового управления в Силиконовой долине.
Стартапы, продуктовое мышление

Product talk - Тереза, автор Product Talk и тренер по поиску продуктов, помогает командам получать ценную информацию из клиентских интервью, проводить эффективные продуктовые эксперименты и управлять результатами, которые создают ценность для клиентов и бизнеса. Она учит команды связывать исследовательскую деятельность и продуктовые решения, внушая уверенность, что они на правильном пути. Среди последних клиентов: CarMax, Snagajob, Spotify и Tesco.
Управление продуктами, развитие клиентов

Ken Norton - Кен — старший операционный партнер в GV, он руководит инвестиционными операциями и оказывает продуктовую и техническую поддержку портфельным компаниям GV. Компания GV, созданная в 2009 году как Google Ventures, является венчурным подразделением Alphabet, Inc. Кен тесно сотрудничал с сотнями портфельных компаний GV, включая Uber, Nest, Slack, Stripe, Gusto, Foundation Medicine и Flatiron Health.

Andrew Chen - Подробные эссе о стартапах, росте, метриках и сетевых эффектах.
Nir Eyal - Понимание поведения клиентов, рассылка. Психология
Product coalition - Крупнейшее в мире бесплатное PdM сообщество. Более 250 000 читателей. 2000+ статей. 300+ авторов. 3000+ участников в Slack.

Хотите выучить язык быстро, без зубрежки и узнавать все новости, фишки конкурентов в области продакт-менеджеров и из блогов ТОПов?
Это можно сделать на бесплатном марафоне English O’Clock за 7 дней вы поймёте, где также можно
научиться думать на языке и получить возможность приобрести новый опыт в англоязычной деловой среде и узнать, как преодолеть языковой барьер и без проблем коммуницировать с партнерами из разных стран

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

Протестировать эффективность вы можете на марафоне English O’Clock Зарегистрируйтесь сейчас и получите 15-минутный урок с преподавателем бонусом - https://clck.ru/Yvqhn

Chief Product Officer (CPO): цель, роль и ключевые обязанности

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

Роль CPO в компаниях различного типа
В стартапах численностью до 25 человек CPO может управлять 1-3 продуктовыми командами. Как правило, он является сооснователем компании, и его цель — создать продукт, который нужен рынку «здесь и сейчас».
В растущих компаниях, где численность сотрудников от 25 до 500 человек, в подчинении у CPO до 10 команд. Цель — совершенствование продукта.
В корпорациях, в которых работает свыше 500 человек, CPO руководит 10+ командами. Главная цель — инновации и создание новых продуктов.

Ключевые обязанности
⁃ Управление несколькими продуктами (пользователи продуктом - малый и средний бизнес) с целью увеличения доходности по их направлениям. Например: платежные системы, интеграция с банком, ЭДО, 1С
⁃ Анализ рынка, выявление потребности рынка (взаимодействие с отделом маркетинга)
⁃ Формирование продукта (взаимодействие с разработчиками, тестировщиками, бизнес-аналитиками)
⁃ Продвижение продукта на рынок среди клиентов (существующих, потенциальных)

Вы - СРО, Head of product, руководитель направления в крупной компании или CEO стартапа? Поделитесь своим опытом с Практикумом.
Сейчас коллеги проводят исследование аудитории, чтобы создать проект, который будет действительно полезен рынку. Это нужно, чтобы понять, как видят образование состоявшиеся специалисты, где они смотрят и читают материалы о профессиональной деятельности.
Если вы не против поделиться с нами информацией, пройдите опрос, перейдя по ссылке.
В благодарность мы поделимся с вами результатами исследования, и вышлем самый ранний анонс программы вам на почту.

Тонкости подходов при управлении сроками релизов

1. Большие релизы или долгострои
Стабильность. Каждое обновление существующей функциональности — небольшое потрясение для обычных пользователей, большинство из которых не желает перемен. Для них проще пережить стресс пару раз в год, чем серию мелких изменений, происходящих постоянно.
Управляемость. У большого релиза есть запланированная дата, к которой он должен быть выпущен. Отставание от нее показывает, насколько плохо обстоят дела. При необходимости из большого релиза можно выкидывать отдельные функции, которые мешают его готовности, но в целом само наличие плановой даты дисциплинирует.
PR-эффект. Большое обновление — это событие и отличный инфоповод.
Задержки. На практике постоянно сталкиваются с тем, что реализация одной-двух сложных функций растягивалась на непредсказуемое время. Из-за этого приходится задерживать весь релиз, в котором могли быть десятки готовых опций и багфиксов.
Неконтролируемая сложность. Одновременный выпуск нескольких новых функций приводит к тому, что сразу после релиза можно получить большое количество сообщений об ошибках. Работа над ними останавливает нормальный процесс разработки на одну-две недели.
Медленная реакция. После выхода новой функции почти всегда получаем обратную связь — информацию о том, что нужно улучшить в реализации. В результате пользователи получают исправление только через пару месяцев.

2. Непрерывные релизы
Функции не ждут друг друга. Как только протестирован новый функционал, он попадает на продакшн. Ему не приходится ждать готовности управления правами пользователей и еще нескольких десятков изменений.
Оперативная реакция. Если мы выпускаем новую функцию и сразу понимаем, как ее нужно улучшить, изменения выходят на следующий день. Этот процесс намного лучше подходит для модели lean startup и концепции постоянных экспериментов с изменением продукта.
Обновления четко делятся на платформенные и функциональные. При платформенных изменениях, когда меняется какая-то технология или внутренняя архитектура, нужно откатиться к предыдущей версии, чтобы потом спокойно разобраться. При непрерывном выпуске обновлений у не возникает задачи сделать один релиз платформенным, а другой — с новыми функциями.
Больше ресурсов на тестирование и выпуск релизов. Вполне реально полностью протестировать продукт вручную два раза в год, но делать это каждый день уже невозможно. Решение уже давно найдено и отлично работает — это автоматические тесты.
Сползание графика. Теперь у релизов нет плановых дат, поскольку по факту нет и самих релизов. Вместо одного большого проекта «выпустить релиз к 25 мая», мы получаем сотню мини- и микропроектов в виде отдельных тикетов.

Главная боль в обоих подходах разработки остается ответ на вопрос «Когда будет готово?». Хотите прокачаться в этой дисциплине?
14 декабря в 20:00 пройдет вебинар «Как уточнять статусы задач и подружиться с соседями» с Юлией Белозеровой, Technical Program Manager. Юлия расскажет, как проактивно делиться новостями о проекте и задачах, чтобы всем было комфортно.

На открытом уроке мы разберем, как:
- Коммуницировать так, чтобы вас не переспрашивали, даже если вы не знаете, сколько времени займет задача
- Рассказывать о проектных проблемах, чтобы в вас не кидались помидорами
- Выстраивать и чинить отношения с соседними командами, если вы инженер
- Задавать вопрос: «Когда будет готово?», чтобы не злить команду

Вебинар пройдет в рамках онлайн-курса «Agile Project Manager» и будет полезен инженерам, тимлидам и проектным менеджерам. Чтобы попасть на мероприятие, нужно зарегистрироваться https://otus.pw/ylC9/

Занимательные числа в работе продакт-менеджера

При поддержке канала Венчур в картинках - https://news.1rj.ru/str/ventureinpics

⁃ Разработчики тратят до 50% времени на переделывание проектов. Ключевая причина - изначально плохая продуктовая проработка.

⁃ 60% пользователей откажутся от любимого продукта, если 2-3 раза получат негативный опыт использования. 15% откажутся после одного случая.

⁃ 70% товаров остаются брошенными в корзинах пользователей. Лишь 7% из них могут быть выкуплены в течение полугода

⁃ Около 60% пользователей предпочитает мобильные приложения для первой и последующих покупок, а не сайт.

⁃ В течение первых трех дней после установки приложение для В2С клиентов теряет в среднем 75% пользователей. Через 30 дней оно теряет 90% пользователей, а через 90 дней — более 95%.

⁃ Привлечение 1% новых пользователей повысит доход лишь на 3%. Повышение ARPU на 1% в 4.3 раза более выгодно, а снижение оттока пользователей на 1% в 2.3 раза более выгодно.

⁃ Для среднего продукта с аудиторией от 200 000 в день, DAU/MAU — 10-20%, для высокоэффективных продуктов — 50%.

⁃ Вероятность, что пользователи iOS купят что-то в приложении выше на 50% по сравнению с пользователями Android.

⁃ Видео помогает убедить 70% пользователей купить продукт или услугу.

Цифры помогают продактам принимать решения. Рекомендую крутой источник - канал Венчур в картинках. Ныряйте в статистику - https://news.1rj.ru/str/ventureinpics

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

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

Сужение групп:
-С общей датой первого посещения.
-Общей датой оформления заявки.
-Общей датой первой оплаты.
-Сколько лет клиентам.
-Мужчины это или женщины.
-Где проживают.
-Кем работают.
-Откуда о вас узнали.
-На каком этапе сделки находятся.
-Имеют ли специальный купон или скидку.
-Почему не завершили сделку.
-Что стало причиной возврата.

Хотите научить эффективно применять когортный анализ? Приходите на Demo-урок "Когортный анализ и сегментация", 14 декабря в 20:00. На занятии вы узнаете о, пожалуй, основных рабочих инструментах аналитика - когортный анализ и сегментация. На примерах реальных компаний поймем почему и когда нужны эти виды анализа и к каким ошибкам может привести отсутствие практики их применения. По ходу занятия вы научитесь использовать эти аналитические подходы, а также будете знать какие самые распространенные варианты сегментов и когорт используются в продуктовой аналитике.

По ссылке - https://otus.pw/D5oM/

3 критерия для быстрой оценки работы Скрам-мастера

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

1. Обратная связь от Владельца продукта и команды — основных «клиентов» Скрам-мастера. Как он помогает решать проблемы, возникающие у членов команды? Насколько им комфортно работать со Скрам-мастером. И главное — в чем они видят пользу от совместной работы?
Чтобы обратная связь получилась измеряемой, вы можете попросить коллег заполнить радарную диаграмму или опросник. Мы рекомендуем включить в него параметры по каждой из четырех ролей Скрам-мастера: фасилитатор, коуч, учитель, наставник.

2. Насколько Скрам-мастер является проводником Agile в команде.
Прямые обязанности Скрам-мастера — помогать команде и всем заинтересованным лицам понять теорию Scrum и наладить его правильное применение, способствовать внедрению Scrum в организации, поддерживать мотивацию людей. Поэтому проведение скрам-мастером митапов, внутреннего обучения и других активностей по привнесению новых знаний весьма показательно.

3. Насколько эффективно организован процесс в команде.
Проводятся все предусмотренные scrum-гайдом встречи — дейли, планирование, backlog refinement, демо, ретроспектива, — бэклог поддерживается в актуальном состоянии, размер спринта фиксирован и тд.
Основные моменты, на которые важно обратить внимание:
- Митинги проводятся эффективно: например, стендап укладывается в 15 минут и он действительно полезен всем участникам команды.
- Команда непрерывно улучшает свой процесс: выявляются и анализируются проблемы, находятся и внедряются их решения.
- Скорость команды стабильна или увеличивается. Объем ценности, который команда поставляет в конце спринта, постепенно растет.

На рынке труда нет однозначного ответа на вопрос, кто такой скрам-мастер, за что он отвечает и как стоит оценивать эффективность его работы. 23 декабря в 20:00 можно во всем разобраться! В OTUS пройдет вебинар «За что отвечает скрам-мастер и как померить его эффективность?».

На demo-занятии мы обсудим и постараемся прийти к общему знаменателю в вопросе о том, какие способы могут навредить при попытке оценить эффективность, а какие могут способствовать росту его как профессионала, его команды, продакта и организации в целом.
Проведет урок Дмитрий Емельянов, руководитель курса Agile Project Manager, первый в России Certified Team Coach (CTC by Scrum Alliance). Присоединяйтесь! https://otus.pw/WpCO/

Как создать zero-code команду и настроить ее работу

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

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

• Если проект предполагает возникновение новых задач в процессе, гораздо комфортнее и для клиента, и для команды работать по спринтам.

• Чтобы настроить прозрачность с клиентом, можно использовать еженедельные отчеты, планирования и meeting reports.

• Будущее за теми, кто сможет показывать результат в метриках. Поэтому на проектах надо фокусироваться на acquisition и awareness и развивать соответствующую экспертизу внутри команды.

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

Чтобы познакомиться с no-code — прочитайте статью основателя Method Zero. Он рассказал, как изменилась студия за 9 месяцев, зачем ему в команду нужны разработчики и какие навыки есть в pdp его дизайнеров. Собственно, заметки выше основываются на его опыте.

Читать: https://vc.ru/design/333348-rozhdenie-no-code-studii-k-chemu-my-prishli-za-9-mesyacev-sushchestvovaniya-method-zero

Метрики и стадии SaaS-продукта

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

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

Метрика №1: Качественная Обратная Связь. Для реальных данных еще слишком рано, так что вам нужно сделать все для того, что вы пока что можете получить — обратную связь. Прямо сейчас у вас есть только одна цель: построить правильный продукт для своего рынка. И самый быстрый способ сделать это — это начать говорить с вашими клиентами.
Метрика №2: Измерение соответствия продукта рынку (product/market fit). Действительно ли люди заинтересованы в нашем продукте? Или вы отмечаете только положительные отзывы и пренебрегаете ролью отрицательной обратной связи? Какой ответ на вопрос “Что вы почувствуете, если больше не сможешь использовать [ваш продукт]?”

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

Метрика №1: Стабильно растить регулярный ежемесячный доход (MRR — Monthly Recurring Revenue), контролируя отток.
Метрика №2: Не допускать ежемесячного оттока клиентов более 1–2%. Если он выше 5%, игнорируйте все остальное, пока не опустите его.

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

Метрика №1: Сохранить ваши затраты на привлечение (CPA — cost per action) на уровне 1/3 от LTV.
Метрика №2: Окупаемость клиента должна происходить в первые 12 месяцев.

Хотите лучше разобраться в стадиях и метриках? Приходите на Demo-урок OTUS "Метрики для жизненного цикла продукта", 21 декабря в 20:00. На занятии мы поговорим о взаимосвязи продуктового термина жизненного цикла с аналитическими метриками. Уже в рамках занятия вы сможете разобраться, какие отличительные черты характерны для каждого жизненного цикла продукта/компании и какие метрики необходимо замерять на каждом этапе, а на какие можно обратить чуть меньше внимания и приложить чуть меньше усилий аналитика. - https://otus.pw/FUBh/

С какими задачами тимлид должен помогать продакту?

Научить команду самостоятельности
Задача тимлида — сделать так, чтобы команда работала самостоятельно даже при его уходе/отсутствии. Эта функция руководителя группы напрямую зависит от того, как построены процессы работы внутри компании.
Если культура компании иерархична, то члены команды не будут отличаться самостоятельностью и будут тяготеть к постоянному согласованию. Если речь идет о бирюзовых организациях, то задача тимлида — задавать направления. А люди, руководствуясь принципами и ценностями компании, будут понимать, что нужно делать для достижения целей.
Методология Scrum с помощью конкретных инструментов позволяет достичь максимального следования принципам Agile. Это достигается за счёт того, что при принятии решений человек руководствуется прежде всего принципами.

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

Определить правила игры
Я предпочитаю в первую очередь ориентироваться на потребности пользователей и клиентов, а уже потом на сроки и бюджеты, в управлении командой разработки я использую принципы и ценности Agile. Важно, чтобы продукт приносил реальную пользу, и при этом был использован оптимальный объём ресурсов. Сперва нужно разбить зоны функциональности. А впоследствии фиксировать контракты. Если говорить о внутрикомандной работе, то должны преобладать горизонтальные взаимодействия. К тимлиду должны приходить как к эксперту за советом, рекомендацией, но не за готовым решением.

Хотите развиваться в качестве тимлида или узнать, как лучше с ним взаимодействовать?
Все правила управления и софт скиллы можно отработать на практике онлайн-курса «Team Lead». Вас ждут 5 месяцев лайфхаков опытных руководителей, разбор типичных ошибок и возможность поуправлять командой разработчиков, даже если пока нет своей.

Оставьте заявку, чтобы зарезервировать место в группе по спец.цене https://otus.pw/xf3R/

KPI и подходы в работе продакта

Работа менеджера про продукту центрируется вокруг ключевых характеристик:
- Общая результативность бизнеса в плане прибыли (Business Perfomance): корреляция развития продукта и счастья бизнеса
- Опыт использования продукта (Product Usage): корреляция развития продукта и счастья пользователя
- Качество продукта (Product Quality): корреляция развития продукта и счастья платформы и технологии

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

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

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

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

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

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

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

Хотите обсудить, что входит в зону ответственности product-менеджера, кто его самые главные коллеги и партнеры, поговорим о том как построить отношения с командой: дизайнером, аналитиком и руководителем? А также что product-менеджера должен уметь делать руками, а что – грамотно делегировать. Какие нужно освоить хард и софт скиллы, и какие специализации бывают у продактов. Приходите на встречу со мной “Роль product-менеджера в команде” от Otus 20 января 2022 года в 20.00 - https://otus.pw/fUDM/
Все обсудим!

Про концепцию Run-Change-Disrupt

Порассуждали совместно с каналом Лешей Подклетновым, автором канала https://news.1rj.ru/str/disruptors_only

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

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

Решения предлагают несколько управленческих концепций. Например, та же ambidextrous organization. Но сегодня остановимся на более практически кристаллизованной Run-Change-Disrupt.

Если кратко, то суть заключается в совмещении 3 компонент деятельности компании:
1. Run - про процесс. Выстроить процессы в основном бизнесе, обеспечить их повторяемость, не допускать просадки качества. Чтобы ваша корова хорошо доилась
2. Change - про проект. Регулярно запускать инициативы по улучшению основного бизнеса, дабы не утратить его конкурентоспособность. Иначе ваша корова станет хуже, чем у фермера-соседа
3. Disrupt - тоже проекты, но за пределами core-бизнеса. Поиск новых направлений, тестирование рискованных гипотез на будущее. Чтобы не остаться только с коровой, когда все станут пить альтернативное молоко

Считается, что распределение ресурсов, как это часто бывает в подобных концепциях, должно быть 70%-20%-10%. Однако, если вы выделяете на Disrupt хотя бы 3-5%, то вы уже в авангарде.

Чтобы реализовать подход на практике, нужно помнить две вещи:

1. Disrupt должен строиться на компетенциях, наработанных в Run (в core-бизнесе). В таком случае гораздо выше вероятность, что из множества тестируемых гипотез окажутся хотя бы несколько рабочих, которые окупят вложения. К тому же, возможна синергия и экосистемность с основным бизнесом, который никто не отменял. Это как UGC повышает конверсию в покупку в интернет-магазине.

2. Ваш core-бизнес должен иметь достаточный масштаб и прибыльность, чтобы существенная часть ресурсов отвлекалась "на будущее".

Затраты серьезные, но результаты могут окупиться сполна. Red bull делал такой сильный фокус на продвижение своего энергетика через спортивные мероприятия, что накопил колоссальные компетенции в спортивном менеджменте. Сейчас спортивная империя Red bull - отдельный большой и прибыльный бизнес. В начале 2000-х Amazon осознал, что его торговым партнёрам не так просто построить собственную IT-инфраструктуру для хранения данных и самостоятельного выхода в онлайн. Вероятно, именно тогда была сформирована гипотеза, из которой в результате вырос AWS.
Не у всех вложения в Disrupt выходит: есть ряд примеров на рынке из банкинга или энергетики, когда экосистемность нарушена. Просто выкуп и интеграция продукта приживается реже, чем экосистемное развитие продукта, основанное на развитии основы.

Если ваша компания хороша в Run и успешна в Change, то не пора ли задуматься про новые дали? Но не забудьте четко определить компетенции (или хотя бы unfair advantage), на которых вы будете базировать ваш Disrupt. А то можно и без коровы остаться.

Не забудьте подписаться на канал коллеги! https://news.1rj.ru/str/disruptors_only

Как определить цену продукта в интервью?

Совместно с Константином Ефимовым, соавтором канала @postpostresearch сделали чек-лист по исследованию ценовых ожиданий.

Как определить цену, когда вы выходите с продуктом, у которого нет аналогов на рынке? Что взять за отправную точку?

1. Определитесь с ожидаемым доходом вашей ЦА. Сколько денег в месяц получает человек, который купит ваш продукт? При этом, считать надо доход на члена семьи, поскольку человек без пары, получающий 100 000 рублей и тот же человек с двумя детьми и неработающим партнером – несут разные расходы.
«У нас в Орле средняя зарплата 16 тыщ, где я вам возьму лишние 300 рублей на подписку в месяц?»
Если продукт предполагает широкую аудиторию, лучше поговорить с людьми с разным доходом – например – средний и средний+. Ценовые ожидания у людей разные, и зависят от многих факторов – личных особенностей, монетарного поведения, опыта и стереотипов.

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

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

4. Сколько денег/ресурсов вы сэкономите, если решить проблему новым способом? Проверьте ожидания.

5. Обсуждая продукт, после того как вы подтвердили его ценность для клиента, можно спросить – за сколько они купили бы его? Важно: спонтанный ответ не означает, что цена должна быть именно такой, поэтому обязательно нужно спросить:
Почему именно такая цена? С чем вы сравнивали эту цену, когда ее назвали?
А та цена на другой продукт, которую вы назвали, почему она вам кажется адекватной?

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

7. Помните, что интервью недостаточно, чтобы определить цену продукта. В силу неслучайности выборки и небольшого объема, вы можете довольно сильно промахнуться. Используйте валидацию на количественном исследовании.
Если у вас моно-продукт, не предполагающий разных функций – используйте PSM (метод Ван Вестендорпа)
Если вам нужно определить цену сложного продукта, у которого могут быть разные комбинации функций и стоимости – используйте ConJoint Analysis.

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

Метрики внутренних инструментов и продуктов

Совместно с автором канала @revealthedata и Head of BI в Яндекс Go Ромой Буниным провели небольшие исследования по метрикам внутренних продуктов. Как правило, они сильно обделены вниманием бизнеса, но, если копнуть, то и там есть как помочь бизнесу на предельно прозрачных метриках. Как по аналогии с метриками для B2C-продуктам
Особенность таких продуктов заключается в том, что чаще всего они не генерируют прибыль напрямую и было интересно как оценивать успех или неуспех продукта. Обсудили какие группы метрик подходят для внутренних продуктов. Сошлись на том, что хороши те метрики, которые комплексно показывают состояние дел и отвечают на задачи стейкхолдеров продукта. Если важен рост — концентрируемся на DAU/MAU, если важна непрерывная работа системы — на uptime системы и т. п. То есть какой-то универсальной и полной системы метрик нет и над формировать её под каждый кейс.

1. ERP-система.

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

1.1. За оборачиваемость в части метрик: 
Уменьшение уровня неснижаемых остатков на складах - до 40%
Уменьшение складских площадей - до 25%
Увеличение поставок точно в срок - до 80%
Снижение производственного брака - до 35%
Снижение задержек с отгрузкой готовой продукции - до 45%

1.2. За счастье покупателей в части метрик:
Улучшение послепродажного обслуживания - рост счастья покупателей на 60%, которое сейлз-менеджеры измеряют своими опросами 
Увеличение точности учета затрат - на 30%
Сокращение цикла разработки новых продуктов - до 60% по времени
Снижение транспортно-заготовительных расходов - на 60%

1.3. За счастье сотрудников:
Уменьшение сроков закрытия учетного периода - до 500% 
Уменьшение затрат на административно-управленческий аппарат - до 30%
Устранение рутинной подготовки и сопро­вождения документов - до 90%
Сокращение производственного цикла - до 50%
Сокращение времени составления бюджета - до 70%

2. BI-платформа

Рома написал статью в блог, про то какие метрики он применяет у себя для отслеживания работы BI-системы и привел примеры целевых значений: «Главная задача BI-платформы помогать бизнесу быстро принимать решения, без рисков связанных с утечкой данных и ошибок из-за неправильных данных. Поэтому идеальная метрикой могли бы быть Time to Insight или денежная выгода от принятых решений. Но я не придумал, как измерить это «по-честному» без аппроксимации в виде опросов «оцените сколько времени сэкономило вам внедрение дашборда». Поэтому я выделяю группы метрик, которые, я верю, являются прокси к этим двум true north метрикам. Эти группы следующие:
— Качество отчетности
— Скорость
— Вовлеченность
— Инфраструктура.»
Подробнее - на его канале - https://news.1rj.ru/str/revealthedata и в блоге Ромы.
Всем роста метрик!

В чем эффективность тимлида отличается от техлида?

Texлид опpeдeляeт тexнoлoгичecкий cтeк пoд кaждyю зaдaчy или кoнкpeтный пpoeкт:
- Koнтpoлиpyeт coблюдeниe cтaндapтoв кaчecтвa и пpиopитeтoв
-Bыcтpaивaeт, внeдpяeт и paзвивaeт инжeнepныe пpoцeccы и пpaктики
-Paзвивaeт тexничecкиe нaвыки cвoиx кoллeг

Texлид дoлжeн ocтaвaтьcя в фopмe и coвepшeнcтвoвaть cвoи нaвыки и знaния, чтoбы быть нeпpepeкaeмым aвтopитeтoм для ocтaльныx coтpyдникoв. Жeлaтeльнo иcкpeннe любить тexнoлoгии – тaк paбoтa и пoмoщь ocтaльным бyдyт в paдocть. Тимлиду обязательно нужны технические знания, но они могут быть не настолько глубокими, как у техлида. А вот техлид в обязательном порядке должен быть экспертом во всех технологиях, которые используются в проекте, за который он отвечает.

Tимлид оpгaнизyeт кoмaнднyю paбoтy:
-Фopмyлиpyeт cтpaтeгию тexнoлoгичecкoгo paзвития пpoeктa, paбoтaя нa пepcпeктивy Ocyщecтвляeт кoммyникaцию c клиeнтoм и pyкoвoдcтвoм, гapaнтиpyя пoнимaниe зaдaч и пpoблeм пpoeктa c тoчки зpeния бизнeca
-Bнeдpяeт пpoцeccы и мeтoдoлoгии, пoлeзныe для пpoeктa
-Peшaeт зaдaчи, нeдocтyпныe дpyгим члeнaм кoмaнды Pacпpeдeляeт зoны oтвeтcтвeннocти в кoмaндe и cлeдит зa диcциплинoй
-Пoдaeт пpимep coблюдeния ycтaнoвлeнныx пpaвил и пpинципoв

Tимлидy oбязaтeльнo oблaдaть xopoшими нaвыкaми yпpaвлeнцa и oднoвpeмeннo paзбиpaтьcя в тexничecкиx вoпpocax, инaчe дoбитьcя pacпoлoжeния кoмaнды «тexнapeй» бyдeт нeпpocтo. Чтoбы кoмaндa эффeктивнo paбoтaлa, кaждый ee члeн дoлжeн быть нa cвoeм мecтe. Heлoгичнo дoвepять джyнy пpoвepкy кoдa, a фpoнтeндepy – paзpaбoткy cepвepнoй чacти пpoeктa. Kpoмe тoгo, y кaждoгo cпeциaлиcтa мoгyт быть бoлee индивидyaльныe cильныe и cлaбыe cтopoны, и кoмaндный лидep oбязaн иx yчитывaть. 

Хотите узнать, что влияет на эффективность тимлида и как правильно нанять тимлида в продуктовую команду? Приходите 19 января ждем вас на встрече с Александром Пряхиным, техническим директором в CityAds Media. Александр проведет обзор вакансий и требований на должности тимлида, поделится своим карьерным опытом и представит программу онлайн-курса «Team Lead» от OTUS. Вы познакомитесь с преподавательским составом, форматом обучения в OTUS и узнаете, как организована практика.

Регистрируйтесь на вебинар https://otus.pw/pLkW/

Как достичь максимума c помощью Manual Viable Product

• Не увлекайтесь глубинными интервью с клиентами. Часто десяти интервью достаточно, чтобы выявить проблему и перейти к подготовке ручного MVP. Из-за длительных интервью можно потерять мотивацию и темп. Лучше быстрее переходить к прайс-интервью (исследованию ценников и стоимости в глазах потребителя) и офферам, чтобы получить раннюю и более объективную обратную связь.

• Для ручного MVP используйте комбинацию сервисов и инструментов, которыми  пользуются ваши клиенты. Если ваши клиенты собирают подарки через Telegram, не надо создавать прототип на базе WhatsApp. Не нужно усложнять людям жизнь — они этого не оценят.

• Используйте подход мягких продаж вашего ручного MVP. Ручной MVP нужен, чтобы лучше понять проблему клиента и ценность продукта. Важно не продать решение любой ценой, а понять клиента: задавайте больше вопросов, говорите о ситуации клиента. Слово «нет» — это возможность понять клиента лучше через вопросы, а не сигнал к убеждению через монолог.

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

Вот уже 4 года в консультировании и 2 в преподавании я помогаю запускаю продукты в e-comm, ed-tech, hr-tech, fin-tech, crm и других сферах. И всегда готов обсудить новые продукты и задачи, а также поделиться опытом.

25 января в 20.00 проведу Открытый урок "Как проверить гипотезу без кода?" в рамках подготовки к запуску уже 9го потока курса Product Manager IT-проектов. Поговорим про - применимость интервью, опросов и других инструментов проверки, как запускать минимально жизнеспособные продукты (MVP), какие MVP можно запустить для реальных продуктов и как можно развивать MVP?

Регистрация по ссылке - https://otus.pw/JiHd/