Типы стратегий роста
⁃ Стратегия концентрированного роста. Момент создания нового продукта, расширение доли рынка без перехода в другую отрасль. Для анализа удобно использовать матрицу БКГ (заполняем объем продаж и объемы роста рынка), когда происходит оценка предоставляемых вами товаров, их рост и доля на рынке. Важно приложить усилия для поиска новых возможностей, сохранения текущей доли рынка “хорошего” продукта, грамотного управления ценовой политикой, а также гармоничной работы внутри компании, чтобы выпуск нового продукта был безболезненным для текущей работы всего предприятия.
⁃ Стратегия диверсификации. В таком векторе развития достаточно много рисков: рынок, на который компания выходит, не прогнозируемый, его необходимо качественно проанализировать, оценить инвестиции в выпускаемый продукт, не забывая о поддержании текущих процессов. Важно помнить о барьерах выхода на новый рынок — без хорошего маркетинга, анализа пользователей и ценовой политики закрепиться в нише будет тяжело. Расширяться будет и база поставщиков, штат сотрудников.
⁃ Голубой океан. Суть голубого океана в том, чтобы создать новый рынок на основе существующего. Стратегия строится на оценке факторов, присущих конкретному рынку, после чего мы стремимся упразднить факторы, которые не столь важны для потребителя или бизнеса, снизить влияние уже принятых факторов и повысить влияние новых. Таким образом, мы выйдем в новый “океан”, где меньше конкурентов, меньше “крови”.
⁃ Стратегия лидерства в издержках. Главная цель данной стратегии заключается в том, чтобы поддерживать преимущества перед конкурентами по затратам и получать за счет этого больше прибыли. Здесь также может иметь место сокращение издержек текущего продукта: уменьшение затрат на маркетинг, на исследования, персонал, т.е. конкурентоспособность достигается путем снижения качества продукта.
⁃ Стратегия фокусирования. Концентрация на определенном небольшом сегменте пользователей, услуге, регионе. Такая стратегия подходит для небольшого рынка (например, исторически Wildberries целился на выход в регионы, несмотря на убеждение сосредоточенности денег в больших городах вроде Москвы и Питера).
⁃ Стратегия первопроходца. Выход на новые рынки с новой технологией. Такая стратегия чаще всего используется крупными компаниями, имеющими достаточное количество необходимых (иногда редких) ресурсов и готовыми к рискам.
Согласно исследованиям, каждый третий продакт-менеджер хочет прокачать навык работы со стратегией развития продукта. Мы с этим полностью согласны: без работающей стратегии продукт всё дальше отдаляется от видения, а фокус и согласованность действий теряются.
⁃ Стратегия концентрированного роста. Момент создания нового продукта, расширение доли рынка без перехода в другую отрасль. Для анализа удобно использовать матрицу БКГ (заполняем объем продаж и объемы роста рынка), когда происходит оценка предоставляемых вами товаров, их рост и доля на рынке. Важно приложить усилия для поиска новых возможностей, сохранения текущей доли рынка “хорошего” продукта, грамотного управления ценовой политикой, а также гармоничной работы внутри компании, чтобы выпуск нового продукта был безболезненным для текущей работы всего предприятия.
⁃ Стратегия диверсификации. В таком векторе развития достаточно много рисков: рынок, на который компания выходит, не прогнозируемый, его необходимо качественно проанализировать, оценить инвестиции в выпускаемый продукт, не забывая о поддержании текущих процессов. Важно помнить о барьерах выхода на новый рынок — без хорошего маркетинга, анализа пользователей и ценовой политики закрепиться в нише будет тяжело. Расширяться будет и база поставщиков, штат сотрудников.
⁃ Голубой океан. Суть голубого океана в том, чтобы создать новый рынок на основе существующего. Стратегия строится на оценке факторов, присущих конкретному рынку, после чего мы стремимся упразднить факторы, которые не столь важны для потребителя или бизнеса, снизить влияние уже принятых факторов и повысить влияние новых. Таким образом, мы выйдем в новый “океан”, где меньше конкурентов, меньше “крови”.
⁃ Стратегия лидерства в издержках. Главная цель данной стратегии заключается в том, чтобы поддерживать преимущества перед конкурентами по затратам и получать за счет этого больше прибыли. Здесь также может иметь место сокращение издержек текущего продукта: уменьшение затрат на маркетинг, на исследования, персонал, т.е. конкурентоспособность достигается путем снижения качества продукта.
⁃ Стратегия фокусирования. Концентрация на определенном небольшом сегменте пользователей, услуге, регионе. Такая стратегия подходит для небольшого рынка (например, исторически Wildberries целился на выход в регионы, несмотря на убеждение сосредоточенности денег в больших городах вроде Москвы и Питера).
⁃ Стратегия первопроходца. Выход на новые рынки с новой технологией. Такая стратегия чаще всего используется крупными компаниями, имеющими достаточное количество необходимых (иногда редких) ресурсов и готовыми к рискам.
Согласно исследованиям, каждый третий продакт-менеджер хочет прокачать навык работы со стратегией развития продукта. Мы с этим полностью согласны: без работающей стратегии продукт всё дальше отдаляется от видения, а фокус и согласованность действий теряются.
10 полезных советов по работе с HADI-циклами
1. Анализировать бизнес, используя цикл HADI, можно только в правильной последовательности. Для начала нужно выделить ряд гипотез, а затем каждую из них проверять, изучая полученные данные и деля выводы.
2. Не выносите на проверку очевидные гипотезы по типу «если мы нальем воды в стакан, то он станет изнутри мокрым».
3. Каждая озвучиваемая гипотеза должна иметь влияние на финальный результат. Нет никакого смысла выдвигать предположения, проверка которых недостаточно эффективна.
4. Для HADI цикла важно, чтобы предлагаемые гипотезы были конкретными, их эффект был измерим, а поставленные цели были реально достижимы.
5. Факт — это не гипотеза. Если в компании существует отлаженный процесс, приносящий конверсию, то не выдвигайте предположение о том, что если продолжить этот процесс, то у компании будет конверсия. Это уже состоявшееся событие, факт, который в принципе не требует проверки. Гипотеза в этой ситуации может гласить, что «если мы каким-либо образом изменим процесс, то это повлечет за собой изменение уровня конверсии». Это утверждение уже можно подвергнуть проверке.
6. Заранее спланируйте процесс сбора и оценки данных, это нужно сделать до запуска тестирования, чтобы понять, как правильно оценивать полученные изменения.
7. Не пренебрегайте делегированием задач. Если вы тестируете сразу несколько гипотез, возложите обязанности по сбору и анализу данных на других сотрудников фирмы.
8. Если гипотеза была подтверждена в ходе проверки, то следует развивать ее более масштабно, чтобы она отыграла максимально эффективно.
9. Можно смело обращаться к опыту других компаний, когда кончаются мысли для постановки собственных гипотез. Вы можете пользоваться предположениями своих конкурентов или перенять что-то от компаний из иных ниш.
10. Вы представили гипотезу, следует сразу же заняться ее проверкой по HADI-циклу. Если упустить время, то анализ может показать неправильные результаты. HADI-циклы в маркетинге и в бизнесе приносят огромную пользу, ведь с их помощью можно протестировать что угодно. Это и классический новый бизнес, и стартап, и даже направление деятельности уже существующей фирмы. Важно сформировать гипотезу и внимательно, в правильном порядке пройти все четыре этапа процесса.
1. Анализировать бизнес, используя цикл HADI, можно только в правильной последовательности. Для начала нужно выделить ряд гипотез, а затем каждую из них проверять, изучая полученные данные и деля выводы.
2. Не выносите на проверку очевидные гипотезы по типу «если мы нальем воды в стакан, то он станет изнутри мокрым».
3. Каждая озвучиваемая гипотеза должна иметь влияние на финальный результат. Нет никакого смысла выдвигать предположения, проверка которых недостаточно эффективна.
4. Для HADI цикла важно, чтобы предлагаемые гипотезы были конкретными, их эффект был измерим, а поставленные цели были реально достижимы.
5. Факт — это не гипотеза. Если в компании существует отлаженный процесс, приносящий конверсию, то не выдвигайте предположение о том, что если продолжить этот процесс, то у компании будет конверсия. Это уже состоявшееся событие, факт, который в принципе не требует проверки. Гипотеза в этой ситуации может гласить, что «если мы каким-либо образом изменим процесс, то это повлечет за собой изменение уровня конверсии». Это утверждение уже можно подвергнуть проверке.
6. Заранее спланируйте процесс сбора и оценки данных, это нужно сделать до запуска тестирования, чтобы понять, как правильно оценивать полученные изменения.
7. Не пренебрегайте делегированием задач. Если вы тестируете сразу несколько гипотез, возложите обязанности по сбору и анализу данных на других сотрудников фирмы.
8. Если гипотеза была подтверждена в ходе проверки, то следует развивать ее более масштабно, чтобы она отыграла максимально эффективно.
9. Можно смело обращаться к опыту других компаний, когда кончаются мысли для постановки собственных гипотез. Вы можете пользоваться предположениями своих конкурентов или перенять что-то от компаний из иных ниш.
10. Вы представили гипотезу, следует сразу же заняться ее проверкой по HADI-циклу. Если упустить время, то анализ может показать неправильные результаты. HADI-циклы в маркетинге и в бизнесе приносят огромную пользу, ведь с их помощью можно протестировать что угодно. Это и классический новый бизнес, и стартап, и даже направление деятельности уже существующей фирмы. Важно сформировать гипотезу и внимательно, в правильном порядке пройти все четыре этапа процесса.
Как настроить onsite-персонализацию в e-commerce
Совместно с коллегами из Flocktory подготовили кейс-лист, что сможет помочь в персонализации:
1. Инструменты лидогенерации: сбор email на сайте
Собирать контакты релевантной аудитории, которая уже пришла к вам на сайт — крайне важная задача, чтобы потом не платить за привлечение этого же пользователя дополнительный бюджет. С помощью наших инструментов onsite-персонализации мы можем собирать различные контакты: email, телефонные номера, push-подписки:
* Pop-up по сбору email;
* Фиксированная подсказка по сбору email;
* Встроенные блоки на лендингах.
Результаты:
25% — совокупная конверсия в собранные email через кампании Flocktory.
В рамках инструментов лидогенерации можно использовать различные текстовые коммуникации, офферы, а также геймифицированные элементы, например, колесо фортуны.
2. Продуктовые подсказки с просмотренными на сайте товарами
Один из инструментов onsite-персонализации, который вдохновит пользователя быстрее совершить целевое действие — продуктовая подсказка. Вы можете подсказать релевантные для клиента продукты или продуктовые категории в соответствии с его покупательской способностью и интересами, о которых мы знаем благодаря нашим смарт-сегментам, предиктивной аналитике и накопленным о клиенте данным.
Как работают подсказки:
Если мы видим, что пользователь на сайте выполнил следующие триггерные действия:
* просмотрел четыре или более товаров на сайте;
* находится на странице категории;
* еще не добавил товары в корзину;
* не находится на главной странице, на странице корзины и на страницах оформления заказа.
Мы ненавязчиво, но при этом достаточно заметно показываем пользователю виджет с просмотренными пользователем товарами (в рамках этой сессии или товары, которые интересовали его в рамках прошлых сессий) — для упрощения навигации пользователя и повышения вероятности конверсии.
Визуализация виджета:
Результаты:
21% — рост конверсии при использовании подсказок.
+1,2% — к среднему чеку при показе виджета.
Уровень статистической значимости более 97% (данный показатель мы вычисляем с помощью математической формулы, и он должен быть выше 95%, что позволяет нам говорить, что результаты теста не случайные).
3. Сбор NPS у пользователей на сайте
NPS (Net Promoter Score) — это индекс потребительской лояльности. Благодаря этому индексу вы можете понимать мнение ваших покупателей о полученном опыте, продукте, услугах, о вас с помощью опросов. Это поможет вам в дальнейшем еще более точно персонализировать коммуникацию с вашим клиентом.
Cобирать инсайты поведения пользователя можно как на сайте, так и позднее через push-уведомления или email.
Как это работает:
Если мы видим, что пользователь на сайте выполнил следующие триггерные действия:
* положил товар в корзину;
* не находится на главной странице/странице корзины/страницах оформления заказа.
Система показываем ему форму для сбора обратной связи с соответствующими сценарию вопросами в целях улучшения опыта пользователя на сайте и положительного влияния на ключевые бизнес-показатели.
Результаты:
9.4% — рост конверсии на десктопах.
9.5% — рост конверсии на мобильных устройствах.
Хотите больше таких практических кейсов? Рекомендую следить за блогами от ребят из Flocktory.
Днем ребята решают бизнес-задачи известных компаний с помощью автоматизации маркетинга, а по ночам спасают город рассказывают о своих успехах и трудностях без купюр. Команда анализирует огромные объемы данных и прослеживает тренды на их основе, а также делится опытом партнеров. Всё это — на понятном языке и без шелухи.
А недавно ребята опубликовали большое исследование поведения потребителей в ключевых категориях e-commerce: электроника, бытовая техника, продукты, товары для животных, одежда и аксессуары, товары для дома, авто и другие — полезный и интересный материал.
Совместно с коллегами из Flocktory подготовили кейс-лист, что сможет помочь в персонализации:
1. Инструменты лидогенерации: сбор email на сайте
Собирать контакты релевантной аудитории, которая уже пришла к вам на сайт — крайне важная задача, чтобы потом не платить за привлечение этого же пользователя дополнительный бюджет. С помощью наших инструментов onsite-персонализации мы можем собирать различные контакты: email, телефонные номера, push-подписки:
* Pop-up по сбору email;
* Фиксированная подсказка по сбору email;
* Встроенные блоки на лендингах.
Результаты:
25% — совокупная конверсия в собранные email через кампании Flocktory.
В рамках инструментов лидогенерации можно использовать различные текстовые коммуникации, офферы, а также геймифицированные элементы, например, колесо фортуны.
2. Продуктовые подсказки с просмотренными на сайте товарами
Один из инструментов onsite-персонализации, который вдохновит пользователя быстрее совершить целевое действие — продуктовая подсказка. Вы можете подсказать релевантные для клиента продукты или продуктовые категории в соответствии с его покупательской способностью и интересами, о которых мы знаем благодаря нашим смарт-сегментам, предиктивной аналитике и накопленным о клиенте данным.
Как работают подсказки:
Если мы видим, что пользователь на сайте выполнил следующие триггерные действия:
* просмотрел четыре или более товаров на сайте;
* находится на странице категории;
* еще не добавил товары в корзину;
* не находится на главной странице, на странице корзины и на страницах оформления заказа.
Мы ненавязчиво, но при этом достаточно заметно показываем пользователю виджет с просмотренными пользователем товарами (в рамках этой сессии или товары, которые интересовали его в рамках прошлых сессий) — для упрощения навигации пользователя и повышения вероятности конверсии.
Визуализация виджета:
Результаты:
21% — рост конверсии при использовании подсказок.
+1,2% — к среднему чеку при показе виджета.
Уровень статистической значимости более 97% (данный показатель мы вычисляем с помощью математической формулы, и он должен быть выше 95%, что позволяет нам говорить, что результаты теста не случайные).
3. Сбор NPS у пользователей на сайте
NPS (Net Promoter Score) — это индекс потребительской лояльности. Благодаря этому индексу вы можете понимать мнение ваших покупателей о полученном опыте, продукте, услугах, о вас с помощью опросов. Это поможет вам в дальнейшем еще более точно персонализировать коммуникацию с вашим клиентом.
Cобирать инсайты поведения пользователя можно как на сайте, так и позднее через push-уведомления или email.
Как это работает:
Если мы видим, что пользователь на сайте выполнил следующие триггерные действия:
* положил товар в корзину;
* не находится на главной странице/странице корзины/страницах оформления заказа.
Система показываем ему форму для сбора обратной связи с соответствующими сценарию вопросами в целях улучшения опыта пользователя на сайте и положительного влияния на ключевые бизнес-показатели.
Результаты:
9.4% — рост конверсии на десктопах.
9.5% — рост конверсии на мобильных устройствах.
Хотите больше таких практических кейсов? Рекомендую следить за блогами от ребят из Flocktory.
Днем ребята решают бизнес-задачи известных компаний с помощью автоматизации маркетинга, а по ночам спасают город рассказывают о своих успехах и трудностях без купюр. Команда анализирует огромные объемы данных и прослеживает тренды на их основе, а также делится опытом партнеров. Всё это — на понятном языке и без шелухи.
А недавно ребята опубликовали большое исследование поведения потребителей в ключевых категориях e-commerce: электроника, бытовая техника, продукты, товары для животных, одежда и аксессуары, товары для дома, авто и другие — полезный и интересный материал.
Какие принципы надо помнить продактам при разработке архитектуры решения?
SRP - Принцип единой ответственности (The Single Responsibility Principle). Соберите воедино то, что меняется по одним и тем же причинам. Разделяйте вещи, которые меняются по разным причинам. Мы не смешиваем бизнес-правила с кодом графического интерфейса. Мы не смешиваем SQL-запросы с протоколами связи. Мы храним код, который изменяется по разным причинам, отдельно, чтобы изменения одной части не нарушали работу других частей. Мы следим за тем, чтобы модули, которые изменяются по разным причинам, не имели запутывающих их зависимостей.
OCP - Принцип открытости-закрытости (The Open-Closed Principle). Модуль должен быть открыт для расширения, но закрыт для модификации. Из всех принципов, мысль о том, что кто-то поставит под сомнение этот, наполняет меня страхом за будущее нашей отрасли. Конечно, мы хотим создавать модули, которые можно расширять, не изменяя их. Можете ли вы представить себе работу в системе, в которой отсутствует независимость от устройств, где запись в файл на диск принципиально отличается от записи на принтер, экран или канал? Хотим ли мы увидеть, рассредоточен ли оператор по нашему коду, чтобы иметь дело со всеми мелкими деталями?
LSP - Принцип подстановки Лисков (The Liskov Substitution Principle). Программа, использующая интерфейс, не должна быть сбита с толку реализацией этого интерфейса.
Люди (в том числе и я) совершили ошибку, сказав, что речь идет о наследовании. Все реализации интерфейсов являются подтипами интерфейса. Каждый пользователь базового интерфейса, заявленный или подразумеваемый, должен согласовать значение этого интерфейса. Если реализация вводит в заблуждение пользователя базового типа, тогда операторы if / switch будут распространяться по коду.
ISP - Принцип разделения интерфейса (The Interface Segregation Principle). Делайте интерфейсы небольшими, чтобы пользователи не зависели от ненужных вещей. Клиенты действительно зависят от методов, которые они не вызывают, если их нужно перекомпилировать и повторно развернуть при изменении одного из этих методов.
DIP - Принцип инверсии зависимостей (The Dependency Inversion Principle). Модули высокого уровня не должны зависеть от деталей низкого уровня. Мы не хотим, чтобы наши бизнес-правила высокого уровня зависели от деталей низкого уровня. Мы не хотим, чтобы вычисления, приносящие нам деньги, были загрязнены SQL, низкоуровневыми проверками или проблемами форматирования. Мы хотим изолировать абстракции высокого уровня от деталей низкого уровня.
SRP - Принцип единой ответственности (The Single Responsibility Principle). Соберите воедино то, что меняется по одним и тем же причинам. Разделяйте вещи, которые меняются по разным причинам. Мы не смешиваем бизнес-правила с кодом графического интерфейса. Мы не смешиваем SQL-запросы с протоколами связи. Мы храним код, который изменяется по разным причинам, отдельно, чтобы изменения одной части не нарушали работу других частей. Мы следим за тем, чтобы модули, которые изменяются по разным причинам, не имели запутывающих их зависимостей.
OCP - Принцип открытости-закрытости (The Open-Closed Principle). Модуль должен быть открыт для расширения, но закрыт для модификации. Из всех принципов, мысль о том, что кто-то поставит под сомнение этот, наполняет меня страхом за будущее нашей отрасли. Конечно, мы хотим создавать модули, которые можно расширять, не изменяя их. Можете ли вы представить себе работу в системе, в которой отсутствует независимость от устройств, где запись в файл на диск принципиально отличается от записи на принтер, экран или канал? Хотим ли мы увидеть, рассредоточен ли оператор по нашему коду, чтобы иметь дело со всеми мелкими деталями?
LSP - Принцип подстановки Лисков (The Liskov Substitution Principle). Программа, использующая интерфейс, не должна быть сбита с толку реализацией этого интерфейса.
Люди (в том числе и я) совершили ошибку, сказав, что речь идет о наследовании. Все реализации интерфейсов являются подтипами интерфейса. Каждый пользователь базового интерфейса, заявленный или подразумеваемый, должен согласовать значение этого интерфейса. Если реализация вводит в заблуждение пользователя базового типа, тогда операторы if / switch будут распространяться по коду.
ISP - Принцип разделения интерфейса (The Interface Segregation Principle). Делайте интерфейсы небольшими, чтобы пользователи не зависели от ненужных вещей. Клиенты действительно зависят от методов, которые они не вызывают, если их нужно перекомпилировать и повторно развернуть при изменении одного из этих методов.
DIP - Принцип инверсии зависимостей (The Dependency Inversion Principle). Модули высокого уровня не должны зависеть от деталей низкого уровня. Мы не хотим, чтобы наши бизнес-правила высокого уровня зависели от деталей низкого уровня. Мы не хотим, чтобы вычисления, приносящие нам деньги, были загрязнены SQL, низкоуровневыми проверками или проблемами форматирования. Мы хотим изолировать абстракции высокого уровня от деталей низкого уровня.
Про ограничения А/В-тестов
⁃ Когда нужно использовать AБ тестирование?
Чаще всего AБ тестирование проваливается из-за нечеткости поставленных целей, так что вы и не знаете, что собираетесь тестировать. Вы можете использовать AБ тестирование для проверки, к примеру, теории, приведет ли к увеличению посещаемости целевой страницы добавление изображения на нее? Что произойдет, если изменить заголовок, чтобы подчеркнуть временный характер предложения?
⁃ Как и когда я могу интерпретировать результаты сплит-тестирования?
Тестирование начинается. Начинают накапливаться первые результаты. И вы уже рветесь проверить, какой же из вариантов эффективнее. Но ранние этапы тестирования – не самое лучшее время для того, чтобы начинать интерпретировать результаты. Подождите того момента, когда тестирование достигнет статистической значимости и затем вернитесь к исходной гипотезе. При анализе теста, старайтесь остаться беспристрастны, соотнося полученные результаты с конкретными изменениями. Убедитесь, что существуют четкие связи между внесенными изменениями и результатом, а также, что на него не повлияли никакие сторонние силы.
⁃ А можно проводить несколько экспериментов параллельно?
Да, можно. Но с ограничениями. Выборки двух параллельных тестов не должны смешиваться. В противном случае одно изменение может повлиять на восприятие второго. Параллельные тесты можно настроить на стороне фронтенда, разметив события разными тегами для разных версий интерфейса.
⁃ Чем можно заменить А/В-тестирование?
Юзабилити-тестирование. Этим методом проверяют, насколько интерфейс удобен для пользователей.
Для исследования не нужно привлекать разработчиков, как в случае с A/B-тестом. Нужно создать новый интерфейс на уровне макетов, собрать интерактивный прототип и пронаблюдать, как пользователи с ним взаимодействуют. Потом выявить возможные проблемы и найти решение.
Fake door тест. Когда разработать фичу — сложно и долго, этим методом можно проверить, нужна ли она пользователям.
Для этого в интерфейс добавляется кнопка, за которой ничего нет, — fake door — и отслеживается, какой процент пользователей ее нажмет. За fake door обычно размещают сообщение о том, что раздел в разработке. Можно также добавить ссылку на опрос и таким образом собрать дополнительные данные для будущего продукта.
Релиз нового продукта на ограниченную аудиторию. Если есть достаточно времени, то вместо теста можно запустить продукт на один город, район или другую выделенную часть пользователей.
⁃ Когда нужно использовать AБ тестирование?
Чаще всего AБ тестирование проваливается из-за нечеткости поставленных целей, так что вы и не знаете, что собираетесь тестировать. Вы можете использовать AБ тестирование для проверки, к примеру, теории, приведет ли к увеличению посещаемости целевой страницы добавление изображения на нее? Что произойдет, если изменить заголовок, чтобы подчеркнуть временный характер предложения?
⁃ Как и когда я могу интерпретировать результаты сплит-тестирования?
Тестирование начинается. Начинают накапливаться первые результаты. И вы уже рветесь проверить, какой же из вариантов эффективнее. Но ранние этапы тестирования – не самое лучшее время для того, чтобы начинать интерпретировать результаты. Подождите того момента, когда тестирование достигнет статистической значимости и затем вернитесь к исходной гипотезе. При анализе теста, старайтесь остаться беспристрастны, соотнося полученные результаты с конкретными изменениями. Убедитесь, что существуют четкие связи между внесенными изменениями и результатом, а также, что на него не повлияли никакие сторонние силы.
⁃ А можно проводить несколько экспериментов параллельно?
Да, можно. Но с ограничениями. Выборки двух параллельных тестов не должны смешиваться. В противном случае одно изменение может повлиять на восприятие второго. Параллельные тесты можно настроить на стороне фронтенда, разметив события разными тегами для разных версий интерфейса.
⁃ Чем можно заменить А/В-тестирование?
Юзабилити-тестирование. Этим методом проверяют, насколько интерфейс удобен для пользователей.
Для исследования не нужно привлекать разработчиков, как в случае с A/B-тестом. Нужно создать новый интерфейс на уровне макетов, собрать интерактивный прототип и пронаблюдать, как пользователи с ним взаимодействуют. Потом выявить возможные проблемы и найти решение.
Fake door тест. Когда разработать фичу — сложно и долго, этим методом можно проверить, нужна ли она пользователям.
Для этого в интерфейс добавляется кнопка, за которой ничего нет, — fake door — и отслеживается, какой процент пользователей ее нажмет. За fake door обычно размещают сообщение о том, что раздел в разработке. Можно также добавить ссылку на опрос и таким образом собрать дополнительные данные для будущего продукта.
Релиз нового продукта на ограниченную аудиторию. Если есть достаточно времени, то вместо теста можно запустить продукт на один город, район или другую выделенную часть пользователей.
Важные подходы к планированию ИТ-проектов
1. Планировать сроки должны программисты, а не менеджеры.
Частая ошибка, когда руководитель проекта, не понимающий должным образом объем и специфику задач, устанавливает сроки проекта не в соответствии с опытом, возможностями и компетенциями команды, а опираясь на собственные представления, желания или запросы клиента. Расхождения запланированных и реальных сроков составляет 40-80%.
2. Необходимо заранее определять примерные сроки сдачи всего проекта и реальное время решения задачи.
Игнорирование процедуры планирования приводит к расхлябанности, низкой мотивации разработчиков в предшествующие дедлайну периоды, к непониманию командой, что делать, куда двигаться и что нужно получить в итоге. В объединениях, где примерные сроки сдачи проекта не определяются, желательно задуматься о том, что подобный хаос до добра не доведет.
3. Проект разбивайте на мелкие этапы с четкими целями и обязательным обсуждением результатов.
Применение принципа необходимо для противодействия закону Паркинсона, определяющему, что общий объём работы всегда будет увеличиваться, чтобы заполнить всё выделенное на работу время. Следуя совету, можно избежать желания усердно трудиться лишь незадолго до срока сдачи проекта.
4. Члены команды должны максимально плотно взаимодействовать друг с другом.
Прежде всего повышается сплоченность коллектива и стимулируется оказание взаимопомощи. При недостаточном общении между членами объединения отсутствует «командный дух», обеспечивающий слаженную работу. Совместная продуктивная деятельность удовлетворяет социальные потребности человека в ощущении значимости выполняемого труда.
5. Включайте резерв времени для покрытия форс-мажора, новых требований заказчика, отпусков и праздников, на интеграцию и тестирование.
На первоначальном этапе планирования нельзя предусмотреть все ситуации. Поэтому нужно зарезервировать время про запас, чтобы команде не пришлось торопиться и, как следствие, совершать ошибки. Не стоит игнорировать необходимость отладки и доведения ПО до уровня стабильной работы и приемлемого количества багов.
6. Нельзя торопиться, нарушать план и уменьшать время разработки ПО.
Частая ошибка менеджеров, думающих, что программисты смогут потянуть любые сроки. Завышенный темп приводит к увеличению количества ошибок в коде. На отладку и исправление в будущем потребуется значительно больше времени, чем получится сэкономить подобным образом.
7. Расставляйте приоритеты задачам и концентрируйтесь на главном.
Старайтесь в первую очередь реализовывать наиболее важный функционал. Имейте ввиду, что какими-то фичами в процессе разработки придется пожертвовать, равно как и реализацией части идей. А расставить приоритеты возможно исключительно через общение и обмен мнениями.
1. Планировать сроки должны программисты, а не менеджеры.
Частая ошибка, когда руководитель проекта, не понимающий должным образом объем и специфику задач, устанавливает сроки проекта не в соответствии с опытом, возможностями и компетенциями команды, а опираясь на собственные представления, желания или запросы клиента. Расхождения запланированных и реальных сроков составляет 40-80%.
2. Необходимо заранее определять примерные сроки сдачи всего проекта и реальное время решения задачи.
Игнорирование процедуры планирования приводит к расхлябанности, низкой мотивации разработчиков в предшествующие дедлайну периоды, к непониманию командой, что делать, куда двигаться и что нужно получить в итоге. В объединениях, где примерные сроки сдачи проекта не определяются, желательно задуматься о том, что подобный хаос до добра не доведет.
3. Проект разбивайте на мелкие этапы с четкими целями и обязательным обсуждением результатов.
Применение принципа необходимо для противодействия закону Паркинсона, определяющему, что общий объём работы всегда будет увеличиваться, чтобы заполнить всё выделенное на работу время. Следуя совету, можно избежать желания усердно трудиться лишь незадолго до срока сдачи проекта.
4. Члены команды должны максимально плотно взаимодействовать друг с другом.
Прежде всего повышается сплоченность коллектива и стимулируется оказание взаимопомощи. При недостаточном общении между членами объединения отсутствует «командный дух», обеспечивающий слаженную работу. Совместная продуктивная деятельность удовлетворяет социальные потребности человека в ощущении значимости выполняемого труда.
5. Включайте резерв времени для покрытия форс-мажора, новых требований заказчика, отпусков и праздников, на интеграцию и тестирование.
На первоначальном этапе планирования нельзя предусмотреть все ситуации. Поэтому нужно зарезервировать время про запас, чтобы команде не пришлось торопиться и, как следствие, совершать ошибки. Не стоит игнорировать необходимость отладки и доведения ПО до уровня стабильной работы и приемлемого количества багов.
6. Нельзя торопиться, нарушать план и уменьшать время разработки ПО.
Частая ошибка менеджеров, думающих, что программисты смогут потянуть любые сроки. Завышенный темп приводит к увеличению количества ошибок в коде. На отладку и исправление в будущем потребуется значительно больше времени, чем получится сэкономить подобным образом.
7. Расставляйте приоритеты задачам и концентрируйтесь на главном.
Старайтесь в первую очередь реализовывать наиболее важный функционал. Имейте ввиду, что какими-то фичами в процессе разработки придется пожертвовать, равно как и реализацией части идей. А расставить приоритеты возможно исключительно через общение и обмен мнениями.
Вредные советы для продактов и их решения
1. Когда хочется общаться, а не работать — используйте фокус-группы из своих друзей и знакомых. Не бойтесь: Groupthink (по-русски: стадное мышление) с вами просто не может случиться.
Нет! : если у вас нет возможности проводить полноценное интервью, работать с фокус-группой можно. Однако не стоит набирать её из своих друзей. Лучше всего пригласить независимых представителей потенциальной аудитории. Приглашайте разных людей, ведь пользователи тоже будут отличаться. Так у вас получится собрать максимум информации.
2. Не воспринимайте фидбек серьёзно. Обидеть менеджера по продукту может каждый. Позже, когда продукт будет уже запущен, клиент увидит, что всё работает. А результат — именно то, что он на самом деле хотел.
Нет!: Воспринимайте фидбек серьёзно. Даже если он кажется вам глупым, подобное может написать технически неграмотный пользователь в дальнейшем. Конечно, если отзыв неадекватный, это следует обсудить с заказчиком. Однако постарайтесь найти причину такого фидбека в любом случае. Определите истинную проблему клиента.
3. Тестируйте все проблемы на полноценном MVP. Только полная реализация в железе и коде, только хардкор. Ручной режим не покажет всех ошибок, а вы ведь проводите тесты наверняка.
Нет!: тестируйте мелкие добавления вручную. Это сэкономит время и силы команды намного больше, чем создание MVP каждый раз. Нужно только найти в команду нормального тестировщика, тогда проблем не возникнет.
4. Лайфхак для тех, кто работает с B2B-продуктами. За успешное тестирование гипотезы о востребованности разработки всегда можно выдать продажи через «откат».
Нет!: никогда не подавайте результаты от продаж через «откат» как успехи в тестировании. Это непрофессионально и незаконно. Когда-нибудь всё раскроется, в лучшем случае — вылетите с работы.
5. Ставьте акценты правильно. Продавайте фичи, а не ценности. В конце концов, зря вы их что ли придумывали? Не объясняйте смысл, не всем дано понять гениальное. Повезёт — разберутся на практике.
Нет!: За каждой фичей должна стоять какая-то ценность. Важно делать акцент именно на второе. Вы предлагаете не просто функционал, код или дизайн, а решение какой-то проблемы. Заказчику не всегда очевидно, для чего нужна кнопка, скрипт и т. д., поэтому объясняйте ему с помощью таких понятий, как ценность, проблема, решение и действие.
6. Даже не начинайте считать экономическую модель. Рассчитывать unit-экономику сложно и, вообще, вы не математик. Если случится так, что стоимость приложения в итоге превысит доход от него — проблема в клиенте.
Нет!: считать unit-экономику нужно. К вам обращаются за услугой и доверяют проект, поэтому невнимательно относиться к нему нельзя. Особенно — к финансовой части. Важно рассчитать потенциальную прибыль, доход от одного пользователя или продажи. Это поможет правильно распределить ресурсы команде и грамотно вложить средства клиенту.
7. Дайте полную свободу команде. Хватит названивать и писать разработчикам. Уже не маленькие, сами справятся. Команду, вообще, можно не беспокоить вплоть до дня сдачи продукта. Да, вы ответственный за проект, но всегда может быть человеческий фактор.
Нет!: продукт-менеджер обязан контролировать команду. Для этого не обязательно стоять с палкой возле двери (хотя, если ваши вкусы специфичны…), можно использовать Jira, рабочие столы на общем сервере или флипчарты. Это необходимо, чтобы координировать каждого члена команды в рамках спринтов: не давать зарабатываться, опаздывать, делать что-то не то.
На этот пост вдохновил доклад руководителя разработки из X5 Tech. В подкасте описываются любимые (и не всегда очевидные) способы, которыми технические специалисты способны сильно испортить жизнь себе и коллегам, и которыми они наверняка продолжат пользоваться в 2023 году. В основе — собственный практический опыт, наблюдения и полезные кейсы других команд. Рекомендую к прослушиванию.
1. Когда хочется общаться, а не работать — используйте фокус-группы из своих друзей и знакомых. Не бойтесь: Groupthink (по-русски: стадное мышление) с вами просто не может случиться.
Нет! : если у вас нет возможности проводить полноценное интервью, работать с фокус-группой можно. Однако не стоит набирать её из своих друзей. Лучше всего пригласить независимых представителей потенциальной аудитории. Приглашайте разных людей, ведь пользователи тоже будут отличаться. Так у вас получится собрать максимум информации.
2. Не воспринимайте фидбек серьёзно. Обидеть менеджера по продукту может каждый. Позже, когда продукт будет уже запущен, клиент увидит, что всё работает. А результат — именно то, что он на самом деле хотел.
Нет!: Воспринимайте фидбек серьёзно. Даже если он кажется вам глупым, подобное может написать технически неграмотный пользователь в дальнейшем. Конечно, если отзыв неадекватный, это следует обсудить с заказчиком. Однако постарайтесь найти причину такого фидбека в любом случае. Определите истинную проблему клиента.
3. Тестируйте все проблемы на полноценном MVP. Только полная реализация в железе и коде, только хардкор. Ручной режим не покажет всех ошибок, а вы ведь проводите тесты наверняка.
Нет!: тестируйте мелкие добавления вручную. Это сэкономит время и силы команды намного больше, чем создание MVP каждый раз. Нужно только найти в команду нормального тестировщика, тогда проблем не возникнет.
4. Лайфхак для тех, кто работает с B2B-продуктами. За успешное тестирование гипотезы о востребованности разработки всегда можно выдать продажи через «откат».
Нет!: никогда не подавайте результаты от продаж через «откат» как успехи в тестировании. Это непрофессионально и незаконно. Когда-нибудь всё раскроется, в лучшем случае — вылетите с работы.
5. Ставьте акценты правильно. Продавайте фичи, а не ценности. В конце концов, зря вы их что ли придумывали? Не объясняйте смысл, не всем дано понять гениальное. Повезёт — разберутся на практике.
Нет!: За каждой фичей должна стоять какая-то ценность. Важно делать акцент именно на второе. Вы предлагаете не просто функционал, код или дизайн, а решение какой-то проблемы. Заказчику не всегда очевидно, для чего нужна кнопка, скрипт и т. д., поэтому объясняйте ему с помощью таких понятий, как ценность, проблема, решение и действие.
6. Даже не начинайте считать экономическую модель. Рассчитывать unit-экономику сложно и, вообще, вы не математик. Если случится так, что стоимость приложения в итоге превысит доход от него — проблема в клиенте.
Нет!: считать unit-экономику нужно. К вам обращаются за услугой и доверяют проект, поэтому невнимательно относиться к нему нельзя. Особенно — к финансовой части. Важно рассчитать потенциальную прибыль, доход от одного пользователя или продажи. Это поможет правильно распределить ресурсы команде и грамотно вложить средства клиенту.
7. Дайте полную свободу команде. Хватит названивать и писать разработчикам. Уже не маленькие, сами справятся. Команду, вообще, можно не беспокоить вплоть до дня сдачи продукта. Да, вы ответственный за проект, но всегда может быть человеческий фактор.
Нет!: продукт-менеджер обязан контролировать команду. Для этого не обязательно стоять с палкой возле двери (хотя, если ваши вкусы специфичны…), можно использовать Jira, рабочие столы на общем сервере или флипчарты. Это необходимо, чтобы координировать каждого члена команды в рамках спринтов: не давать зарабатываться, опаздывать, делать что-то не то.
На этот пост вдохновил доклад руководителя разработки из X5 Tech. В подкасте описываются любимые (и не всегда очевидные) способы, которыми технические специалисты способны сильно испортить жизнь себе и коллегам, и которыми они наверняка продолжат пользоваться в 2023 году. В основе — собственный практический опыт, наблюдения и полезные кейсы других команд. Рекомендую к прослушиванию.
Яндекс Музыка
YaTalks 2022: Владимир Маслов - Вредные советы д...
YaTalks: ReRun • Подкаст • 9371 подписчик • Сезон 2
Как рассказать про стратегию продукта на английском?
1. Определите проблему
Во-первых, определите болевую точку вашего потенциального клиента. Когда вы разрабатываете свою презентацию о продажах, ориентируйтесь на проблему, с которой в данный момент сталкивается ваша аудитория, и подкрепляйте свои утверждения данными:
“This is also the challenge that you plan to solve with your offering”
2. Сформулируйте свое ценностное предложение
Затем сформулируйте свое ценностное предложение. Ценностное предложение, также известное как уникальное торговое предложение, - это заявление, подчеркивающее ценность, которую ваш бизнес, продукт или услуга могут предоставить своим клиентам.
In your value proposition, mention how your offering can help solve the problem you’ve identified in step one. Be sure to share the features of the offering and its benefits.
For example, your value proposition could look like this:
Our [Company Name] assists [audience] with [pain point] in order to help achieve [benefits].
3. Vision
Итак, все идет отлично и у вас интересуются, каким вы видите свое будущее либо будущее вашего проекта. Здесь уже время не историй, а фактов, подсчетов и прогнозов.
“Our estimations tell us that we may be able to scale faster than any other web app company did before us.”
“At this rate, we will hit and exceed our numbers by March.”
“Provided we maintain current growth, we’ll be able to maximize our profit enough to open 5 new locations globally.”
“Our market research has proven that there will most likely be more demand for this service in the future 3 years.”
4. Предлагайте решения
Выделив проблему (ы), подумайте о том, как ваш продукт или услуга могут предложить вашей аудитории решение. Чтобы сделать это, разбейте свое ценностное предложение на решения, связанные с преимуществами, такие как:
X helps Y save time and money
X helps Y grow business by Z amount
Tip: Make sure your solutions are easy to understand and don’t offer too many choices.
5. Покажите social proof
Воспользуйтесь социальными доказательствами, предоставив отзывы, рекомендации и истории клиентов, которые показывают, как ваш продукт или услуга помогли аналогичным компаниям добиться успеха.
Showcase the data behind why your offering is beneficial to your audience and support your solutions listed in step four.
6. Заканчивайте с CTA и будьте открыты для вопросов
Продолжайте разговор, задавая открытые вопросы. Затем переведите потенциального клиента к следующему шагу с четким CTA, например: “Sounds like we’re on the same page. Are you free for another follow-up call next Tuesday after you’ve had time to look at the numbers?”
“I got to go, but I don’t wanna lose you. Could we exchange contact info?”
“What would be the best way to contact you?”
“Feel free to message me on LinkedIn.
“Hit me up on Facebook with any questions you may have.”
“I’ll follow up with you in an email with my resume/presentation/ the details regarding our future partnership.”
Хотите обучиться пичтингу стратегии продукта и самопрезентации? Для вас запустился курс «Английский для продакт-менеджеров» Яндекс Практикума. Обучение построено вокруг рабочих ситуаций и полезных для карьеры навыков:
Самопрезентация. Демонстрация лидерских качеств на встречах. Рассказ о себе на собеседовании и при знакомстве с командой.
Питч стратегии продукта. Ответы на product sense questions на собеседовании. Защита дорожной карты перед стэйкхолдерами.
Навигация в спорных ситуациях. Переговоры о ресурсах и сроках со стейкхолдерами. Работа с немотивированными командами. Обсуждение проблем и идей на ретро.
Питчинг локальных и глобальных трендов. Обсуждение ценностей, которые вызывают доверие пользователей, на собеседовании и во время нетворкинга.
Запишитесь на бесплатную консультацию. Кураторы определят ваш уровень языка и расскажут подробнее про обучение.
1. Определите проблему
Во-первых, определите болевую точку вашего потенциального клиента. Когда вы разрабатываете свою презентацию о продажах, ориентируйтесь на проблему, с которой в данный момент сталкивается ваша аудитория, и подкрепляйте свои утверждения данными:
“This is also the challenge that you plan to solve with your offering”
2. Сформулируйте свое ценностное предложение
Затем сформулируйте свое ценностное предложение. Ценностное предложение, также известное как уникальное торговое предложение, - это заявление, подчеркивающее ценность, которую ваш бизнес, продукт или услуга могут предоставить своим клиентам.
In your value proposition, mention how your offering can help solve the problem you’ve identified in step one. Be sure to share the features of the offering and its benefits.
For example, your value proposition could look like this:
Our [Company Name] assists [audience] with [pain point] in order to help achieve [benefits].
3. Vision
Итак, все идет отлично и у вас интересуются, каким вы видите свое будущее либо будущее вашего проекта. Здесь уже время не историй, а фактов, подсчетов и прогнозов.
“Our estimations tell us that we may be able to scale faster than any other web app company did before us.”
“At this rate, we will hit and exceed our numbers by March.”
“Provided we maintain current growth, we’ll be able to maximize our profit enough to open 5 new locations globally.”
“Our market research has proven that there will most likely be more demand for this service in the future 3 years.”
4. Предлагайте решения
Выделив проблему (ы), подумайте о том, как ваш продукт или услуга могут предложить вашей аудитории решение. Чтобы сделать это, разбейте свое ценностное предложение на решения, связанные с преимуществами, такие как:
X helps Y save time and money
X helps Y grow business by Z amount
Tip: Make sure your solutions are easy to understand and don’t offer too many choices.
5. Покажите social proof
Воспользуйтесь социальными доказательствами, предоставив отзывы, рекомендации и истории клиентов, которые показывают, как ваш продукт или услуга помогли аналогичным компаниям добиться успеха.
Showcase the data behind why your offering is beneficial to your audience and support your solutions listed in step four.
6. Заканчивайте с CTA и будьте открыты для вопросов
Продолжайте разговор, задавая открытые вопросы. Затем переведите потенциального клиента к следующему шагу с четким CTA, например: “Sounds like we’re on the same page. Are you free for another follow-up call next Tuesday after you’ve had time to look at the numbers?”
“I got to go, but I don’t wanna lose you. Could we exchange contact info?”
“What would be the best way to contact you?”
“Feel free to message me on LinkedIn.
“Hit me up on Facebook with any questions you may have.”
“I’ll follow up with you in an email with my resume/presentation/ the details regarding our future partnership.”
Хотите обучиться пичтингу стратегии продукта и самопрезентации? Для вас запустился курс «Английский для продакт-менеджеров» Яндекс Практикума. Обучение построено вокруг рабочих ситуаций и полезных для карьеры навыков:
Самопрезентация. Демонстрация лидерских качеств на встречах. Рассказ о себе на собеседовании и при знакомстве с командой.
Питч стратегии продукта. Ответы на product sense questions на собеседовании. Защита дорожной карты перед стэйкхолдерами.
Навигация в спорных ситуациях. Переговоры о ресурсах и сроках со стейкхолдерами. Работа с немотивированными командами. Обсуждение проблем и идей на ретро.
Питчинг локальных и глобальных трендов. Обсуждение ценностей, которые вызывают доверие пользователей, на собеседовании и во время нетворкинга.
Запишитесь на бесплатную консультацию. Кураторы определят ваш уровень языка и расскажут подробнее про обучение.
practicum.yandex.ru
Английский для IT-специалистов
Курсы от Яндекс Практикума
Как собрать рабочую команду по модели Белбина
Порядок отбора участников напрямую зависит от задачи компании и начинать отбор рекомендуется с наиболее значимых командных ролей для определённой цели. А дальше, под характеристики ведущих ролей, подбираются остальные члены команды, которые дополнят и сбалансируют первых участников. Разберём на примерах:
- Если стоит задача «вывод нового продукта на рынок» или «разработка антикризисной стратегии», то первыми скрипками выступят интеллектуальные роли: Генератор идей, Аналитик-стратег и Специалист. Генератор выдвинет идею, Аналитик проанализирует рынок и предоставит заключение, насколько идея Генератора жизнеспособна, а Специалист даст свои рекомендации по реализации задуманного.
- Для задач «поиск новых партнёров/поставщиков» или «открытие нового магазина/филиала» незаменимыми будут социальные роли: Исследователь ресурсов, Координатор и Душа команды, ведь как раз они ориентированы на налаживание контактов между людьми и выстраивание долгосрочных деловых отношений.
Лайфхаки модели
1. Если несколько человек в рабочей команде дублируют друг друга по ролям и функциям — возникает неэффективное распределение ресурсов внутри группы, снижается общая результативность. Теория Белбина о командных ролях создана, чтобы решить эту проблему;
2. Модель Белбина состоит из 9-ти типов и поделена на 3 группы: интеллектуальные роли — Генератор идей, Аналитик-стратег, Специалист; социальные роли — Душа команды, Исследователь ресурсов, Координатор; роли действия — Мотиватор, Реализатор, Педант;
3. Для того чтобы выявить командные роли у сотрудников, рекомендуется использовать тестовую оценку персонала. Для разных ролей важны разные факторы, поэтому оценка должна быть комплексной и рассматривать человека по трём направлениям: мотивация, интеллект, личность;
4. После оценки можно формировать команду. Начинайте с самой важной роли для проекта, а затем подбирайте остальных участников так, чтобы они дополняли качества друг друга и нейтрализовали недостатки. Здесь важен баланс сил всей команды;
5. Модель командных ролей Белбина поможет сформировать органичную рабочую команду, которая будет способна эффективно справляться с поставленными задачами и регулярно приносить пользу компании.
Порядок отбора участников напрямую зависит от задачи компании и начинать отбор рекомендуется с наиболее значимых командных ролей для определённой цели. А дальше, под характеристики ведущих ролей, подбираются остальные члены команды, которые дополнят и сбалансируют первых участников. Разберём на примерах:
- Если стоит задача «вывод нового продукта на рынок» или «разработка антикризисной стратегии», то первыми скрипками выступят интеллектуальные роли: Генератор идей, Аналитик-стратег и Специалист. Генератор выдвинет идею, Аналитик проанализирует рынок и предоставит заключение, насколько идея Генератора жизнеспособна, а Специалист даст свои рекомендации по реализации задуманного.
- Для задач «поиск новых партнёров/поставщиков» или «открытие нового магазина/филиала» незаменимыми будут социальные роли: Исследователь ресурсов, Координатор и Душа команды, ведь как раз они ориентированы на налаживание контактов между людьми и выстраивание долгосрочных деловых отношений.
Лайфхаки модели
1. Если несколько человек в рабочей команде дублируют друг друга по ролям и функциям — возникает неэффективное распределение ресурсов внутри группы, снижается общая результативность. Теория Белбина о командных ролях создана, чтобы решить эту проблему;
2. Модель Белбина состоит из 9-ти типов и поделена на 3 группы: интеллектуальные роли — Генератор идей, Аналитик-стратег, Специалист; социальные роли — Душа команды, Исследователь ресурсов, Координатор; роли действия — Мотиватор, Реализатор, Педант;
3. Для того чтобы выявить командные роли у сотрудников, рекомендуется использовать тестовую оценку персонала. Для разных ролей важны разные факторы, поэтому оценка должна быть комплексной и рассматривать человека по трём направлениям: мотивация, интеллект, личность;
4. После оценки можно формировать команду. Начинайте с самой важной роли для проекта, а затем подбирайте остальных участников так, чтобы они дополняли качества друг друга и нейтрализовали недостатки. Здесь важен баланс сил всей команды;
5. Модель командных ролей Белбина поможет сформировать органичную рабочую команду, которая будет способна эффективно справляться с поставленными задачами и регулярно приносить пользу компании.
Дайджест событий от меня
Много ссылок, хочется поделиться всем:
1. Начал вести блог на vc и поделился первым кейсом от себя по разделу Избранное в интернет-магазине (3500+ посмотров). В день публикации статья на какое-то время попала в ТОП-2. Там я постарался увлекательно описать, как продуктовый подход может реально повлиять на выручку даже в таком разделе, как Избранное - читайте по ссылке. А больше кейсов и эфиров будет на канале @sergeyproduct, приходите за консультациями и инсайтами, стоимость первой консультации можете определить вы.
2. У проекта Product well done очень хороший отклик, есть первые отзывы, которые говорят о пользе наших экспресс-прожарок (например, вот). Также идем в сторону подкастов и развиваем YouTube направление (есть 1,2К просмотров всего), уже есть первые запросы на платные аудиты. Я все больше верю в этот формат и буду внедрять его в свою работу и образовательные проекты.
3. Собрал концентрированный мини-курс по прайс-интервью и механикам ценообразования. Много пишу про это на своих каналах также. Если кому-то тема интересна и вы хотите стать первым слушателем курса (за донат после изучения), пишите в личку.
Делитесь знаниями и ссылкой на канал!
Много ссылок, хочется поделиться всем:
1. Начал вести блог на vc и поделился первым кейсом от себя по разделу Избранное в интернет-магазине (3500+ посмотров). В день публикации статья на какое-то время попала в ТОП-2. Там я постарался увлекательно описать, как продуктовый подход может реально повлиять на выручку даже в таком разделе, как Избранное - читайте по ссылке. А больше кейсов и эфиров будет на канале @sergeyproduct, приходите за консультациями и инсайтами, стоимость первой консультации можете определить вы.
2. У проекта Product well done очень хороший отклик, есть первые отзывы, которые говорят о пользе наших экспресс-прожарок (например, вот). Также идем в сторону подкастов и развиваем YouTube направление (есть 1,2К просмотров всего), уже есть первые запросы на платные аудиты. Я все больше верю в этот формат и буду внедрять его в свою работу и образовательные проекты.
3. Собрал концентрированный мини-курс по прайс-интервью и механикам ценообразования. Много пишу про это на своих каналах также. Если кому-то тема интересна и вы хотите стать первым слушателем курса (за донат после изучения), пишите в личку.
Делитесь знаниями и ссылкой на канал!
Как оптимизировать процесс проверки гипотез
Ресурсы продакт-менеджера ограничены — он не сможет проверить все гипотезы из бэклога. Поэтому важно научиться оценивать влияние гипотезы на ключевую метрику ещё до тестов — так можно выбрать самые перспективные и не тратить время на проверку слабых идей.
Как это сделать:
⁃ Углубитесь в проблемы. Прежде чем брать гипотезу в тест, проверьте, существует ли проблема, на которой она основана. Часто для этого нужно провести дополнительное исследование: это отнимет ресурсы, но выйдет дешевле, чем тестировать бесперспективную гипотезу.
⁃ Опирайтесь на бенчмарки. Попросите ориентир у более опытных коллег, смотрите выступления продактов с кейсами, гуглите, общайтесь с людьми из других компаний. Если бенчмарк выглядит нереалистичным, адаптируйте его на основе своего опыта.
- Делайте допущения: лучше посчитать верхнеуровнево, чем вовсе не считать. У вас получатся примерные расчёты, но даже их часто хватает, чтобы трезво взглянуть на гипотезу и сравнить её потенциал с другими.
⁃ Приоритезируйте гипотезы по важности и лёгкости внедрения. Регулярно сравнивайте гипотезы между собой, чтобы рационально расходовать ресурсы.
Если гипотеза сложная, тестируйте её MVP. Выделите главную сутевую часть гипотезы — то изменение, которое она привнесёт в продукт — и тестируйте только его. Это позволит получить более точную оценку потенциала гипотезы.
⁃ Прикинуть влияние гипотезы на метрику, чтобы не тратить ресурсы на слабые идеи. Например, когда из десятков гипотез в бэклоге нужно выбрать всего одну–две, которые принесут максимум результата за короткий промежуток времени. На доскональную проверку сразу всех нет времени и ресурсов.
Ресурсы продакт-менеджера ограничены — он не сможет проверить все гипотезы из бэклога. Поэтому важно научиться оценивать влияние гипотезы на ключевую метрику ещё до тестов — так можно выбрать самые перспективные и не тратить время на проверку слабых идей.
Как это сделать:
⁃ Углубитесь в проблемы. Прежде чем брать гипотезу в тест, проверьте, существует ли проблема, на которой она основана. Часто для этого нужно провести дополнительное исследование: это отнимет ресурсы, но выйдет дешевле, чем тестировать бесперспективную гипотезу.
⁃ Опирайтесь на бенчмарки. Попросите ориентир у более опытных коллег, смотрите выступления продактов с кейсами, гуглите, общайтесь с людьми из других компаний. Если бенчмарк выглядит нереалистичным, адаптируйте его на основе своего опыта.
- Делайте допущения: лучше посчитать верхнеуровнево, чем вовсе не считать. У вас получатся примерные расчёты, но даже их часто хватает, чтобы трезво взглянуть на гипотезу и сравнить её потенциал с другими.
⁃ Приоритезируйте гипотезы по важности и лёгкости внедрения. Регулярно сравнивайте гипотезы между собой, чтобы рационально расходовать ресурсы.
Если гипотеза сложная, тестируйте её MVP. Выделите главную сутевую часть гипотезы — то изменение, которое она привнесёт в продукт — и тестируйте только его. Это позволит получить более точную оценку потенциала гипотезы.
⁃ Прикинуть влияние гипотезы на метрику, чтобы не тратить ресурсы на слабые идеи. Например, когда из десятков гипотез в бэклоге нужно выбрать всего одну–две, которые принесут максимум результата за короткий промежуток времени. На доскональную проверку сразу всех нет времени и ресурсов.
Как бороться с усталостью от принятия решений
1. Избегайте ненужных решений
Марк Цукерберг носит одинаковую одежду каждый день, чтобы не думать, что надеть и не тратить на новые решения время и силы. Звучит немного экстремально (сам я так не делаю), но смысл понятен — если вы и так ставите себе цели каждый день, тратьте как можно меньше ресурсов на неважные. Заранее откажитесь от выбора, где это возможно. Я стараюсь использовать инструменты с меньшим количеством опций/настроек/примочек.
2. Приоритезируйте список задач
Выбрать самую важную цель на данный момент — это тоже решение и не самое простое. Причем не откладывайте ее. В моем списке на каждый день заранее есть одна ключевая задача — и мне не нужно решать, делать её или нет.
3. Приступайте к сложной задаче как можно раньше
От сложного решения вы постараетесь убежать в любом случае. Сопротивляться этому легче утром, когда усталости еще нет. Спланируйте день так, чтобы сложные задачи были первыми в списке. Мне не зависать на незапланированных задачах помогает схема: Просмотреть почту “по диагонали” на предмет срочных писем → Ответить на пару вопросов в почте и устно → Приступить к самому важному.
4. Скажите себе "стоп"
Тянетесь к телефону посмотреть Инстаграм? Открываете почту каждые десять минут? Ищете простую задачу, позволяющую быстро поставить галочку “Сделано” в списке задач? Вы устали и уходите от принятия сложных решений. Остановитесь. Идите попейте чай. Или выйдите из офиса и прогуляйтесь. Помните о технике УПРЛС : Устал Принимать Решения — Ложись Спать.
5. Уделите время своему well-being, даже если некогда
Сфокусироваться на самом важном хорошо помогают wellness-практики — особенно, если ими заниматься постоянно. Многие компании сейчас внедряют в корпоративную культуру частного психолога или закупают абонементы в фитнес-клубы. Но это все звучит как утопия, когда у вас переговоры в 10 часов вечера или рабочие выходные.
Поэтому очень важно уметь перезаряжаться самому. Есть ряд SOS-упражнений, которые не займут более 15-20 минут. Например, можно помедитировать. Я уже писал: медитации прокачивают внимательность, а еще они помогают перестать осуждать себя и повышают стрессоустойчивость.
1. Избегайте ненужных решений
Марк Цукерберг носит одинаковую одежду каждый день, чтобы не думать, что надеть и не тратить на новые решения время и силы. Звучит немного экстремально (сам я так не делаю), но смысл понятен — если вы и так ставите себе цели каждый день, тратьте как можно меньше ресурсов на неважные. Заранее откажитесь от выбора, где это возможно. Я стараюсь использовать инструменты с меньшим количеством опций/настроек/примочек.
2. Приоритезируйте список задач
Выбрать самую важную цель на данный момент — это тоже решение и не самое простое. Причем не откладывайте ее. В моем списке на каждый день заранее есть одна ключевая задача — и мне не нужно решать, делать её или нет.
3. Приступайте к сложной задаче как можно раньше
От сложного решения вы постараетесь убежать в любом случае. Сопротивляться этому легче утром, когда усталости еще нет. Спланируйте день так, чтобы сложные задачи были первыми в списке. Мне не зависать на незапланированных задачах помогает схема: Просмотреть почту “по диагонали” на предмет срочных писем → Ответить на пару вопросов в почте и устно → Приступить к самому важному.
4. Скажите себе "стоп"
Тянетесь к телефону посмотреть Инстаграм? Открываете почту каждые десять минут? Ищете простую задачу, позволяющую быстро поставить галочку “Сделано” в списке задач? Вы устали и уходите от принятия сложных решений. Остановитесь. Идите попейте чай. Или выйдите из офиса и прогуляйтесь. Помните о технике УПРЛС : Устал Принимать Решения — Ложись Спать.
5. Уделите время своему well-being, даже если некогда
Сфокусироваться на самом важном хорошо помогают wellness-практики — особенно, если ими заниматься постоянно. Многие компании сейчас внедряют в корпоративную культуру частного психолога или закупают абонементы в фитнес-клубы. Но это все звучит как утопия, когда у вас переговоры в 10 часов вечера или рабочие выходные.
Поэтому очень важно уметь перезаряжаться самому. Есть ряд SOS-упражнений, которые не займут более 15-20 минут. Например, можно помедитировать. Я уже писал: медитации прокачивают внимательность, а еще они помогают перестать осуждать себя и повышают стрессоустойчивость.
Чек-лист правил супероффера
⁃ Откажитесь от формального языка. Tone of voice — это голос вашей компании, бренда и он обязательно должен быть единым во всех элементах коммуникации, в том числе и в деловых переписках. Только есть важный нюанс — за красивой историей не потеряйте основной посыл и не сильно выходите за рамки формата джоб оффера. Ваша цель — не просто интересно подать предложение о работе, но и рассказать всю важную информацию. Поэтому желательно соединить текст, написанный в формате истории, с официальными данными. Идеально, если оффер будет более-менее стандартным с креативными деталями, а сторителлинг использован для презентации или видеоряда.
⁃ Учитывайте потребности, цели и желания кандидата, обязательно прописывайте задачи на адаптацию (в идеале 3-6-12 месяцев). При описании используйте именно те слова, которыми говорил с вами кандидат.
⁃ Ставьте дедлайн. Здесь срабатывает то, что в маркетинге называют триггером дефицита — жесткое ограничение во времени, которое мотивирует принять решение здесь и сейчас, в нашем случае — согласиться на оффер и подписать его. Для этого в конце письма напишите конкретные дату и время, до которых предложение будет актуальным.
⁃ Сделайте корпоративный шаблон оффера: это работает по такой формуле: красивое оформление + продающий вопрос = новый, счастливый сотрудник. И неважно, идет сотрудник на административную должность или креативно-творческую, ведь всем приятнее видеть яркую картинку с информацией, чем просто текст.
⁃ Не забывайте прописывать преимущества компании/продукта/команды, не забывайте главного — это презентация для соискателя, а не клиента или партнера. Добавлять в нее десятки показателей, аналитику, сложные термины — не лучшее решение. В крайнем случае используйте для этого только самые важные параметры и оформите всё в виде понятной инфографики. фото офиса, фото рабочего места кандидата (можно сделать это мило — с табличкой «Мы ждем тебя», «Это твой рабочий дом», «Тут не хватает тебя», если такое отношение принято в вашей компании), забавный рассказ о коллегах (кто чем отличился, кто что любит, кто чем занимается), смешные рабочие моменты в виде коротких видео, рассказ о ценностях, миссии компании, целях сотрудников;
⁃ Выгоды сотрудника — это материальная и нематериальная мотивация. Важно рассказать сразу о двух, но больше внимания уделить именно Total Rewards, которые еще называют бенефитами и плюшками. Ведь часто человек готов работать за оплату на 10-15% ниже рыночной при условии, что в компании хорошо развита корпоративная культура и система нематериальной мотивации.
IT — рынок кандидатов с большим опытом и хорошим портфолио. Компании борются за кандидатов, предлагая им все более и более выгодные условия. Как в этой гонке за сильными специалистами сделать оффер, который примут, не выходя за рамки бюджета?
⁃ Откажитесь от формального языка. Tone of voice — это голос вашей компании, бренда и он обязательно должен быть единым во всех элементах коммуникации, в том числе и в деловых переписках. Только есть важный нюанс — за красивой историей не потеряйте основной посыл и не сильно выходите за рамки формата джоб оффера. Ваша цель — не просто интересно подать предложение о работе, но и рассказать всю важную информацию. Поэтому желательно соединить текст, написанный в формате истории, с официальными данными. Идеально, если оффер будет более-менее стандартным с креативными деталями, а сторителлинг использован для презентации или видеоряда.
⁃ Учитывайте потребности, цели и желания кандидата, обязательно прописывайте задачи на адаптацию (в идеале 3-6-12 месяцев). При описании используйте именно те слова, которыми говорил с вами кандидат.
⁃ Ставьте дедлайн. Здесь срабатывает то, что в маркетинге называют триггером дефицита — жесткое ограничение во времени, которое мотивирует принять решение здесь и сейчас, в нашем случае — согласиться на оффер и подписать его. Для этого в конце письма напишите конкретные дату и время, до которых предложение будет актуальным.
⁃ Сделайте корпоративный шаблон оффера: это работает по такой формуле: красивое оформление + продающий вопрос = новый, счастливый сотрудник. И неважно, идет сотрудник на административную должность или креативно-творческую, ведь всем приятнее видеть яркую картинку с информацией, чем просто текст.
⁃ Не забывайте прописывать преимущества компании/продукта/команды, не забывайте главного — это презентация для соискателя, а не клиента или партнера. Добавлять в нее десятки показателей, аналитику, сложные термины — не лучшее решение. В крайнем случае используйте для этого только самые важные параметры и оформите всё в виде понятной инфографики. фото офиса, фото рабочего места кандидата (можно сделать это мило — с табличкой «Мы ждем тебя», «Это твой рабочий дом», «Тут не хватает тебя», если такое отношение принято в вашей компании), забавный рассказ о коллегах (кто чем отличился, кто что любит, кто чем занимается), смешные рабочие моменты в виде коротких видео, рассказ о ценностях, миссии компании, целях сотрудников;
⁃ Выгоды сотрудника — это материальная и нематериальная мотивация. Важно рассказать сразу о двух, но больше внимания уделить именно Total Rewards, которые еще называют бенефитами и плюшками. Ведь часто человек готов работать за оплату на 10-15% ниже рыночной при условии, что в компании хорошо развита корпоративная культура и система нематериальной мотивации.
IT — рынок кандидатов с большим опытом и хорошим портфолио. Компании борются за кандидатов, предлагая им все более и более выгодные условия. Как в этой гонке за сильными специалистами сделать оффер, который примут, не выходя за рамки бюджета?
Какой должен быть аналог Jira?
В основе Jira — канбан‑ и скрам‑доски, дополненные множеством вспомогательных средств. Все задачи в рамках проекта делятся на несколько общих функциональных групп: front‑end, back‑end, QA, mobile, web, и т. д. Затем таски систематизируются в порядке работы над ними: Например, общий список поставленных задач, находящиеся в работе, требующие согласования, завершенные.
Отличительная черта Jira — необходимость предварительной настройки проекта: организация продуктовых команд, определение ролей участников, взаимозависимостей подпроектов и задач. Впрочем, все эти настройки легко меняются и в процессе работы.
Это и многое другое делает Jira основным рабочим пространством, в котором каждый, от руководителя до рядового исполнителя, может получить всю текущую информацию о задачах, которые предстоит выполнить.
Проанализировав несколько новых российских решений, могу заключить, что TeamStorm, пожалуй, удобнее всего подошла к подходу, реализованному в Jira. Это не просто система управления проектами и задачами, а решение класса Collaborative Work Management, ориентированное на организацию совместной работы в рамках проектов.
Важное отличие TeamStorm в том, что это решение on‑premise. Размещается оно на собственных серверах компании. Каждый проект в системе уникален в части бизнес‑процессов, типов задач и этапов их выполнения, вложенности, определения сроков и состава команд. Проекты можно настраивать под нужды конкретного отдела в соответствии с его спецификой и бизнес‑процессами, используя:
⁃ Настройку любых типов задач под нужды команды
⁃ Встроенную поддержку Agile-методологий Scrum и Kanban
⁃ Возможность анализировать любые параметры выполнения задачи или проекта
⁃ Интеграцию с внешними системами и расширяемость
⁃ Учет рабочего времени и управление ресурсами
В результате задачи по мере их постановки сразу попадают в иерархию проекта, которую можно представить и в виде таблицы, и как канбан‑доску. Доступно и управление по методологии agile, с формированием спринтов и ведением бэк‑логов.
Также инструмент помогает автоматизировать предсказуемые процессы, сделать коммуникацию между участниками команд прозрачной и структурированной и расставлять приоритеты, не терять фокус и успешно завершать проекты.
В основе Jira — канбан‑ и скрам‑доски, дополненные множеством вспомогательных средств. Все задачи в рамках проекта делятся на несколько общих функциональных групп: front‑end, back‑end, QA, mobile, web, и т. д. Затем таски систематизируются в порядке работы над ними: Например, общий список поставленных задач, находящиеся в работе, требующие согласования, завершенные.
Отличительная черта Jira — необходимость предварительной настройки проекта: организация продуктовых команд, определение ролей участников, взаимозависимостей подпроектов и задач. Впрочем, все эти настройки легко меняются и в процессе работы.
Это и многое другое делает Jira основным рабочим пространством, в котором каждый, от руководителя до рядового исполнителя, может получить всю текущую информацию о задачах, которые предстоит выполнить.
Проанализировав несколько новых российских решений, могу заключить, что TeamStorm, пожалуй, удобнее всего подошла к подходу, реализованному в Jira. Это не просто система управления проектами и задачами, а решение класса Collaborative Work Management, ориентированное на организацию совместной работы в рамках проектов.
Важное отличие TeamStorm в том, что это решение on‑premise. Размещается оно на собственных серверах компании. Каждый проект в системе уникален в части бизнес‑процессов, типов задач и этапов их выполнения, вложенности, определения сроков и состава команд. Проекты можно настраивать под нужды конкретного отдела в соответствии с его спецификой и бизнес‑процессами, используя:
⁃ Настройку любых типов задач под нужды команды
⁃ Встроенную поддержку Agile-методологий Scrum и Kanban
⁃ Возможность анализировать любые параметры выполнения задачи или проекта
⁃ Интеграцию с внешними системами и расширяемость
⁃ Учет рабочего времени и управление ресурсами
В результате задачи по мере их постановки сразу попадают в иерархию проекта, которую можно представить и в виде таблицы, и как канбан‑доску. Доступно и управление по методологии agile, с формированием спринтов и ведением бэк‑логов.
Также инструмент помогает автоматизировать предсказуемые процессы, сделать коммуникацию между участниками команд прозрачной и структурированной и расставлять приоритеты, не терять фокус и успешно завершать проекты.
Про интервью Миши Карпова у Котелова
В январе по сути я открыл рубрику продактов на подкасте Котелов, а сейчас уже могу посмотреть интервью с Мишей Карповым. Захотел добавить из своего интервью с Мишей пару вопрос-ответов:
Какие метрики в образовательном курсе самые важные?
Тут, конечно, зависит от стадии компании — т.к. набор метрик на ранних этапах и в моменты стабилизации и роста будут меняться.
1) сначала важны метрики market-fit: найти свою аудиторию, понять какой формат продукта им лучше подходит — тут стоит смотреть на переход от занятию к занятию и выполнение ДЗ (как опережающий показатель), на LTV, на повторные оплаты, на фидбэк и на реферальность
2) на более поздних этапах вы уже лучше понимаете ваш продукт и важны операционные метрики роста — что при масштабировании не проседает качество услуги, что низкий % возвратов, что рост выручки идёт с нужно скоростью
3) если мы говорим про расширение бизнеса — то тут часто снова идёт откат к поиску новых ниш-направлений и метрик market-fit для них
Таким образом, в компании должен быть баланс RUN-метрик (операционных) и CHANGE-метрик (более стартаперских).
Если бы ты делал рейтинг продакт-менеджеров, то по каким критериям бы ранжировал?
Конечно, запросы и челленджи продактов очень разные и сильно зависят от компании (от стадии роста компании, от сферы, от b2b/b2c)
Поэтому, если делать рейтинг, то можно подойти с 2 сторон:
1) делить по "доказанным достижениям" в разрезе разных сегментов-категорий (b2b/b2c, стартапы/корпорации, рф/зарубежка), когда ребята как-то описывают их кейсы, а дальше решают либо жюри, либо голосование, либо микс этих оценок (тут может быть много нюансов, тк на стороне продактов из известных компаний может быть "сила бренда", хотя ребята из малых компаний могут быть не менее крутыми)
2) делать какой-то соревновательный формат (как у программистов) — когда нужно за определённое время прорешать N бизнес-кейсов и на основе их делать рейтинг.
Какие стартапстори для тебя самые любимые и почему?
Мне нравятся истории про зарубежку и про малые команды. Мне близка история быть "гражданином мира", чтобы не быть зависимым от проживания или бизнеса в какой-то конкретной стране, поэтому мне близки истории про зарубежку — поэтому мы активно развиваем ProductStar не только в РФ, но и зарубежом. Пожив в Китае, я интересую в целом бизнесом в Азии, из полезных ресурсов с историями команд посоветую портал TechInAsia. С интересом общаюсь с российскими командами, которые вышли на зарубежку, например, Miro. Малые команды драйвят меня скоростью и сплочённостью команды — думаю это отголоски VK, когда там было ещё до 100 человек.
В январе по сути я открыл рубрику продактов на подкасте Котелов, а сейчас уже могу посмотреть интервью с Мишей Карповым. Захотел добавить из своего интервью с Мишей пару вопрос-ответов:
Какие метрики в образовательном курсе самые важные?
Тут, конечно, зависит от стадии компании — т.к. набор метрик на ранних этапах и в моменты стабилизации и роста будут меняться.
1) сначала важны метрики market-fit: найти свою аудиторию, понять какой формат продукта им лучше подходит — тут стоит смотреть на переход от занятию к занятию и выполнение ДЗ (как опережающий показатель), на LTV, на повторные оплаты, на фидбэк и на реферальность
2) на более поздних этапах вы уже лучше понимаете ваш продукт и важны операционные метрики роста — что при масштабировании не проседает качество услуги, что низкий % возвратов, что рост выручки идёт с нужно скоростью
3) если мы говорим про расширение бизнеса — то тут часто снова идёт откат к поиску новых ниш-направлений и метрик market-fit для них
Таким образом, в компании должен быть баланс RUN-метрик (операционных) и CHANGE-метрик (более стартаперских).
Если бы ты делал рейтинг продакт-менеджеров, то по каким критериям бы ранжировал?
Конечно, запросы и челленджи продактов очень разные и сильно зависят от компании (от стадии роста компании, от сферы, от b2b/b2c)
Поэтому, если делать рейтинг, то можно подойти с 2 сторон:
1) делить по "доказанным достижениям" в разрезе разных сегментов-категорий (b2b/b2c, стартапы/корпорации, рф/зарубежка), когда ребята как-то описывают их кейсы, а дальше решают либо жюри, либо голосование, либо микс этих оценок (тут может быть много нюансов, тк на стороне продактов из известных компаний может быть "сила бренда", хотя ребята из малых компаний могут быть не менее крутыми)
2) делать какой-то соревновательный формат (как у программистов) — когда нужно за определённое время прорешать N бизнес-кейсов и на основе их делать рейтинг.
Какие стартапстори для тебя самые любимые и почему?
Мне нравятся истории про зарубежку и про малые команды. Мне близка история быть "гражданином мира", чтобы не быть зависимым от проживания или бизнеса в какой-то конкретной стране, поэтому мне близки истории про зарубежку — поэтому мы активно развиваем ProductStar не только в РФ, но и зарубежом. Пожив в Китае, я интересую в целом бизнесом в Азии, из полезных ресурсов с историями команд посоветую портал TechInAsia. С интересом общаюсь с российскими командами, которые вышли на зарубежку, например, Miro. Малые команды драйвят меня скоростью и сплочённостью команды — думаю это отголоски VK, когда там было ещё до 100 человек.
Как продуктовый подход помог при разработке сервиса «Европротокол онлайн»
Мне очень нравятся статьи с кейсами. Далее будет кейс от разработчиков Госуслуг с продуктовым подходом для сервиса «Европротокол онлайн».
1. Из-за сложности оформления европротокола и необходимости организации взаимодействия между разными независимыми организациями было несколько подходов к реализации сервиса. В итоге было принято решение собрать команду, по-новому взглянуть на то, что сделано, и уже после этого довести сервис до конечного пользователя.
2. Продуктовый подход подразумевает, что во главе угла ставится реальная польза продукта, сервиса, услуги. Разработчик наравне с заказчиком разделяет ответственность за финальный результат. Мы изучаем рынок, формулируем и валидируем гипотезы через эксперименты, прорабатываем пользовательские пути и готовим решение с учётом минимальных сроков и бюджетов.
3. Ключевой момент — польза: проведение исследований. Нам важно было получить ответы на следующие вопросы:
• Есть ли у пользователей потребность в электронном европротоколе в приложении «Госуслуги Авто»?
• На какую долю рынка (количество оформленных европротоколов) мы можем рассчитывать?
• Что мотивирует/демотивирует водителей использовать электронный европротокол?
• Какое время потребуется водителю для заполнения европротокола в нашем приложении?
• Какой формат оформления удобен: когда два пользователя, каждый со своего устройства, заполняют бланк, или когда один заполняет, а второй подтверждает?
4. Использованный подход дал нам ряд важных преимуществ:
• экономию бюджета за счёт раннего выявления слабых мест и реализации более удобного варианта сервиса;
• быструю разработку и скорый time to market за счёт полного понимания требований к продукту и конкретно к каждому члену команды;
• целевое позиционирование сервиса и быстрый рост его востребованности за счёт точного выявления ключевых потребностей пользователей и прямого, неискажённого восприятия их в процессе разработки.
Рекомендую посмотреть полный текст новой статьи на Хабре, где Наталья Рудометова, старший менеджер по продукту РТЛабс, рассказывыет и показывает, что стоит за тем, чтобы упросить такой, чаще всего неприятный, процесс?
Какие грабли собрала команда, чему научилась и что получилось в конце? Читайте по ссылке.
Информация предоставлена АО "РТ Лабс"
Мне очень нравятся статьи с кейсами. Далее будет кейс от разработчиков Госуслуг с продуктовым подходом для сервиса «Европротокол онлайн».
1. Из-за сложности оформления европротокола и необходимости организации взаимодействия между разными независимыми организациями было несколько подходов к реализации сервиса. В итоге было принято решение собрать команду, по-новому взглянуть на то, что сделано, и уже после этого довести сервис до конечного пользователя.
2. Продуктовый подход подразумевает, что во главе угла ставится реальная польза продукта, сервиса, услуги. Разработчик наравне с заказчиком разделяет ответственность за финальный результат. Мы изучаем рынок, формулируем и валидируем гипотезы через эксперименты, прорабатываем пользовательские пути и готовим решение с учётом минимальных сроков и бюджетов.
3. Ключевой момент — польза: проведение исследований. Нам важно было получить ответы на следующие вопросы:
• Есть ли у пользователей потребность в электронном европротоколе в приложении «Госуслуги Авто»?
• На какую долю рынка (количество оформленных европротоколов) мы можем рассчитывать?
• Что мотивирует/демотивирует водителей использовать электронный европротокол?
• Какое время потребуется водителю для заполнения европротокола в нашем приложении?
• Какой формат оформления удобен: когда два пользователя, каждый со своего устройства, заполняют бланк, или когда один заполняет, а второй подтверждает?
4. Использованный подход дал нам ряд важных преимуществ:
• экономию бюджета за счёт раннего выявления слабых мест и реализации более удобного варианта сервиса;
• быструю разработку и скорый time to market за счёт полного понимания требований к продукту и конкретно к каждому члену команды;
• целевое позиционирование сервиса и быстрый рост его востребованности за счёт точного выявления ключевых потребностей пользователей и прямого, неискажённого восприятия их в процессе разработки.
Рекомендую посмотреть полный текст новой статьи на Хабре, где Наталья Рудометова, старший менеджер по продукту РТЛабс, рассказывыет и показывает, что стоит за тем, чтобы упросить такой, чаще всего неприятный, процесс?
Какие грабли собрала команда, чему научилась и что получилось в конце? Читайте по ссылке.
Информация предоставлена АО "РТ Лабс"
Кому подходит Scrum, а кому Kanban?
- Scrum хорошо подходит в условиях неопределенности. Когда у вас есть только гипотезы, и вы еще не знаете верны они или нет. Акцент на скорости, метриках продукта и обратной связи от пользователей. Задача сформировать гипотезы в виде User Stories (US) и как можно быстрее запустить спринт. Мы тратим время на ресурсоемкие ритуалы Scrum. Именно они помогают сырую US как-то оценить, вовремя подправить и быстро обновить на проде, что позволяет своевременно собрать метрики, и сделать выводы.
Без настройки продуктовых метрик и без интервью с пользователями не обойтись. Чем быстрее и качественнее мы будем собирать данные, тем быстрее и правильнее будут наши решения. Ритуалы: Poker планирование и замер скорости путем закрытия Story Points на ежедневных встречах (Stand Up). Анализируем Burn Down Chart на ретроспективе.
- Kanban лучше подходит когда задачи расписаны на месяцы и каждый шаг необходимо согласовывать. Мы растягиваем процесс, но в итоге имеем согласованный и качественный релиз. Подробная доска поможет вам и ЗЛ увидеть узкие места. Установите WIP-лимиты (Work In Progress), например: больше одной задачи разработчикам в работу не брать.
Процесс закрытия задач последовательный, согласованный и поэтому требует больше времени. Вы можете параллельно запускать в работу несколько US, возвращать задачу на предыдущий этап и добавлять в любое время новую. Постоянно настраивать и улучшать доску под себя и свои нужды, устраняя узкие места и обеспечивая непрерывный поток. Мы знаем кто, что и когда делает и видим все этапы конвейера.
Если вас замучали «эджайлом» или вы сами мучаете им вашу команду, то этот выпуск подкаста «Магнитное Поле» – для вас! Потому что в нем Всеволод Сыров (Agile lead Магнита) как раз объясняет, нужен ли в каждой команде agile, как собрать идеальную команду и выстроить в ней процессы, как найти ее проблемы и решить, а также каким образом все-таки убедить всех «стейкхолдеров» договориться.
Это уже пятый выпуск подкаста «Магнитное Поле», который совместно записывают Завтракаст и IT-команда ритейлера Магнит. В предыдущих выпусках обсуждали Data Governance, современные облачные решения и микросервисы, IT HR, ecom и многое другое, так что стоит обратить внимание.
Ссылка в подкаст-сервисе и на YouTube-канале Завтракаста.
- Scrum хорошо подходит в условиях неопределенности. Когда у вас есть только гипотезы, и вы еще не знаете верны они или нет. Акцент на скорости, метриках продукта и обратной связи от пользователей. Задача сформировать гипотезы в виде User Stories (US) и как можно быстрее запустить спринт. Мы тратим время на ресурсоемкие ритуалы Scrum. Именно они помогают сырую US как-то оценить, вовремя подправить и быстро обновить на проде, что позволяет своевременно собрать метрики, и сделать выводы.
Без настройки продуктовых метрик и без интервью с пользователями не обойтись. Чем быстрее и качественнее мы будем собирать данные, тем быстрее и правильнее будут наши решения. Ритуалы: Poker планирование и замер скорости путем закрытия Story Points на ежедневных встречах (Stand Up). Анализируем Burn Down Chart на ретроспективе.
- Kanban лучше подходит когда задачи расписаны на месяцы и каждый шаг необходимо согласовывать. Мы растягиваем процесс, но в итоге имеем согласованный и качественный релиз. Подробная доска поможет вам и ЗЛ увидеть узкие места. Установите WIP-лимиты (Work In Progress), например: больше одной задачи разработчикам в работу не брать.
Процесс закрытия задач последовательный, согласованный и поэтому требует больше времени. Вы можете параллельно запускать в работу несколько US, возвращать задачу на предыдущий этап и добавлять в любое время новую. Постоянно настраивать и улучшать доску под себя и свои нужды, устраняя узкие места и обеспечивая непрерывный поток. Мы знаем кто, что и когда делает и видим все этапы конвейера.
Если вас замучали «эджайлом» или вы сами мучаете им вашу команду, то этот выпуск подкаста «Магнитное Поле» – для вас! Потому что в нем Всеволод Сыров (Agile lead Магнита) как раз объясняет, нужен ли в каждой команде agile, как собрать идеальную команду и выстроить в ней процессы, как найти ее проблемы и решить, а также каким образом все-таки убедить всех «стейкхолдеров» договориться.
Это уже пятый выпуск подкаста «Магнитное Поле», который совместно записывают Завтракаст и IT-команда ритейлера Магнит. В предыдущих выпусках обсуждали Data Governance, современные облачные решения и микросервисы, IT HR, ecom и многое другое, так что стоит обратить внимание.
Ссылка в подкаст-сервисе и на YouTube-канале Завтракаста.
Дизайн-аутсорсинг в тренде
Вот важные инсайты:
— Актуальность аутсорсинга на рынке растет. Особенно это касается крупного бизнеса с развитой офлайн и диджитал-коммуникацией в разных каналах и сформировавшейся дизайн-системой.
— Внешнюю команду привлекают, когда нужен быстрый и качественный результат, когда нет необходимости расширять свой штат или самостоятельно искать подходящих специалистов.
— Выбирая сотрудников на аутсорс, компании обращают внимание на их умение планировать бюджет наперед, грамотно выстраивать все процессы.
— Среди студий набирает популярность тренд на сближение с клиентом: общение на равных и персональный мэтч.
Также благодаря исследованию, появился пилот — тестовый формат взаимодействия для новых клиентов. Это демо-версия будущей работы, которая позволяет реализовать небольшой объем задач на коротком отрезке времени и почувствовать коннект с подрядчиком.
Еще больше инсайтов читайте в статье на vc.
Вот важные инсайты:
— Актуальность аутсорсинга на рынке растет. Особенно это касается крупного бизнеса с развитой офлайн и диджитал-коммуникацией в разных каналах и сформировавшейся дизайн-системой.
— Внешнюю команду привлекают, когда нужен быстрый и качественный результат, когда нет необходимости расширять свой штат или самостоятельно искать подходящих специалистов.
— Выбирая сотрудников на аутсорс, компании обращают внимание на их умение планировать бюджет наперед, грамотно выстраивать все процессы.
— Среди студий набирает популярность тренд на сближение с клиентом: общение на равных и персональный мэтч.
Также благодаря исследованию, появился пилот — тестовый формат взаимодействия для новых клиентов. Это демо-версия будущей работы, которая позволяет реализовать небольшой объем задач на коротком отрезке времени и почувствовать коннект с подрядчиком.
Еще больше инсайтов читайте в статье на vc.
vc.ru
Аутсорсинг в дизайне: как устроена и кому подходит дизайн-поддержка? — Дизайн на vc.ru
Наша студия дизайна maryco взяла интервью у крупных игроков рынка Skillhunt, «Сравни», TRASSIR Cloud, «Анабар», Training Data, а ключевыми инсайтами поделилась в этой статье.
Пять стратегических причин, по которым действительно стоит создавать новую бизнес-модель
⁃ Когда есть шанс за счет инновационного продукта удовлетворить нужды большой группы потенциальных потребителей, рынка для которых пока нет — существующие предложения слишком дороги или сложны для них. Речь идет, скажем, о возможности «демократизировать» продукт на развивающихся рынках, примером чего служит автомобиль Nano компании Tata Motors.
⁃ Когда есть шанс хорошо заработать на принципиально новой технологии, создав для нее новую бизнес-модель (Apple и плееры mp3), или выгодно воспользоваться опробованной технологией на совершенно новом рынке (скажем, применив военные технологии в «гражданских» товарах или наоборот).
⁃ Когда есть шанс создать продукт/услугу для выполнения «работы», которую прежде никто не пытался выполнять вообще или выполнять именно таким образом. Чаще всего такая возможность выпадает в отраслях, которые чересчур увлекаются сегментацией товаров и потребителей. Из-за этого компаниям приходится постоянно совершенствовать свои продукты, и в результате то, что еще недавно было новым и престижным, становится стандартным. Предназначая свои продукты для выполнения той или иной «работы», компания может изменить рентабельность отрасли.
⁃ Когда бизнесу угрожают инноваторы, нацеленные на нижний ценовой сегмент. Если автомобиль Nano, как и задумано, окажется по карману рядовым индийцам, это сильно усложнит жизнь другим автопроизводителям. Похоже, тогда события будут развиваться по сценарию 30-летней давности: тогда металлургические мини-заводы, производившие дешевую и поначалу не слишком качественную сталь, начали вытеснять комбинаты с полным циклом.
⁃ Когда смещается «центр тяжести» конкурентной борьбы. Со временем, и это неизбежно, изменяются сами представления о приемлемом качестве продукта, то есть о стандартах для того или иного рынка. В результате продукция основных игроков отрасли «подтягивается» к этим стандартам и вся она становится более или менее одинаковой. Компании Hilti нужно было изменить бизнес-модель отчасти потому, что на глобальный рынок вышли «дешевые» производители; со своей продукцией нижнего ценового диапазона, но приемлемого при такой стоимости качества они начали потихоньку оттеснять в сторону производителей дорогого высококлассного оборудования.
⁃ Когда есть шанс за счет инновационного продукта удовлетворить нужды большой группы потенциальных потребителей, рынка для которых пока нет — существующие предложения слишком дороги или сложны для них. Речь идет, скажем, о возможности «демократизировать» продукт на развивающихся рынках, примером чего служит автомобиль Nano компании Tata Motors.
⁃ Когда есть шанс хорошо заработать на принципиально новой технологии, создав для нее новую бизнес-модель (Apple и плееры mp3), или выгодно воспользоваться опробованной технологией на совершенно новом рынке (скажем, применив военные технологии в «гражданских» товарах или наоборот).
⁃ Когда есть шанс создать продукт/услугу для выполнения «работы», которую прежде никто не пытался выполнять вообще или выполнять именно таким образом. Чаще всего такая возможность выпадает в отраслях, которые чересчур увлекаются сегментацией товаров и потребителей. Из-за этого компаниям приходится постоянно совершенствовать свои продукты, и в результате то, что еще недавно было новым и престижным, становится стандартным. Предназначая свои продукты для выполнения той или иной «работы», компания может изменить рентабельность отрасли.
⁃ Когда бизнесу угрожают инноваторы, нацеленные на нижний ценовой сегмент. Если автомобиль Nano, как и задумано, окажется по карману рядовым индийцам, это сильно усложнит жизнь другим автопроизводителям. Похоже, тогда события будут развиваться по сценарию 30-летней давности: тогда металлургические мини-заводы, производившие дешевую и поначалу не слишком качественную сталь, начали вытеснять комбинаты с полным циклом.
⁃ Когда смещается «центр тяжести» конкурентной борьбы. Со временем, и это неизбежно, изменяются сами представления о приемлемом качестве продукта, то есть о стандартах для того или иного рынка. В результате продукция основных игроков отрасли «подтягивается» к этим стандартам и вся она становится более или менее одинаковой. Компании Hilti нужно было изменить бизнес-модель отчасти потому, что на глобальный рынок вышли «дешевые» производители; со своей продукцией нижнего ценового диапазона, но приемлемого при такой стоимости качества они начали потихоньку оттеснять в сторону производителей дорогого высококлассного оборудования.
Какие фразы помогают донести точку зрения и инсайты
I suppose (that) — Я полагаю (считаю, думаю) - По сути, то же самое, что и «I think».
I suppose, you have a back-up plan. — Я так думаю, у тебя есть запасной план.
I belive (that) — Я думаю, полагаю, считаю (букв.: «Я верю»)
belive that some of your calculations might be slightly incorrect. — Я полагаю, что некоторые из ваших подсчетов могут быть немножко неверны.
I suspect (that) — Я подозреваю
I guess (that) — Я думаю. «Guess» буквально значит «догадываться», но в современном английском, особенно, американском варианте, это выражение очень часто используют как синоним «I think».
I reckon (that) — Думаю, что. Выражение «I reckon» (букв. «я считаю, полагаю») используется как синоним «I think», «I guess», но оно характерно для южных штатов США (хотя встречается и за их пределами).
I’m sure (that) — Я уверен
I have no doubt (that) — Я не сомневаюсь, что. Еще один способ выразить уверенность, пожалуй, даже более твердую, чем «I’m sure».
I am positive (that) — Я твердо уверен, что
In my opinion — По моему мнению. «Opinion» — это мнение, точка зрения. Вы также можете сказать «In my humble opinion» — «По моему скромному мнению».
From my point of view (perspective) — С моей точки зрения. «Point of view» — это точка зрения, а «perspective» — подход к рассмотрению какого-то вопроса. В контексте выражения мнения эти слова — синонимы.
As for me — Как по мне / Что касается меня; «As for me» — это простой неформальный способ выразить мнение.
To my mind — По-моему, по моему мнению. «Mind» — это буквально «разум, ум». Другими словами, «to my mind» значит «по моему мнению», «по-моему».
My impression is (that) — У меня такое впечатление, что. Используется, когда мы делимся мнением, своей точкой зрения.
To my knowledge — Насколько я знаю. Несмотря на то, что «mind» и «knowlege» значат похожие вещи (ум и знание), выражение «to my knowledge» имеет несколько другое значение, чем «to my mind». Оно значит «насколько я знаю».
As far as I know — Насколько я знаю
As far as I remember — Насколько я помню
As far as I can see — Насколько я вижу
It seems to me (that) — Мне кажется, что
appears to me (that) — Кажется / Похоже на то, что / Мне представляется, что
«It appears» и «It seems» близки по смыслу, но не идентичны. «It seems» — это просто «кажется», а «it appears» — это когда у вас сложилось некое впечатление на основе чего-то увиденного, услышанного, на основе догадки или информации.
It looks like — Похоже, что. «It looks like» или просто «Looks like» — очень употребительное в повседневной речи выражение. Разумеется, ему не место в официальной речи или тексте.
With all due respect — При всем моем уважении; Как и его аналог в русском языке, это выражение — вежливый способ возразить, не согласиться. Часто за ним следует «I think/suppose/believe that».
Язык — основной инструмент продакта. Даже на русском непросто выразить свои мысли так, чтобы всё было понятно и никого не задело. А если продакт общается с командой на английском, дело становится ещё сложнее.
В карточках собрали пять ситуаций, где продакту важно точно и аккуратно донести свою мысль, чтобы всё заработало. А ещё — рассказали о том, как получить скидку 20% на курс английского для продактов. Если вам такое интересно — добро пожаловать на сайт.
→ Курс «Продакт-менеджер».
→ Курс «Английский для менеджеров продукта».
→ Правила акции.
I suppose (that) — Я полагаю (считаю, думаю) - По сути, то же самое, что и «I think».
I suppose, you have a back-up plan. — Я так думаю, у тебя есть запасной план.
I belive (that) — Я думаю, полагаю, считаю (букв.: «Я верю»)
belive that some of your calculations might be slightly incorrect. — Я полагаю, что некоторые из ваших подсчетов могут быть немножко неверны.
I suspect (that) — Я подозреваю
I guess (that) — Я думаю. «Guess» буквально значит «догадываться», но в современном английском, особенно, американском варианте, это выражение очень часто используют как синоним «I think».
I reckon (that) — Думаю, что. Выражение «I reckon» (букв. «я считаю, полагаю») используется как синоним «I think», «I guess», но оно характерно для южных штатов США (хотя встречается и за их пределами).
I’m sure (that) — Я уверен
I have no doubt (that) — Я не сомневаюсь, что. Еще один способ выразить уверенность, пожалуй, даже более твердую, чем «I’m sure».
I am positive (that) — Я твердо уверен, что
In my opinion — По моему мнению. «Opinion» — это мнение, точка зрения. Вы также можете сказать «In my humble opinion» — «По моему скромному мнению».
From my point of view (perspective) — С моей точки зрения. «Point of view» — это точка зрения, а «perspective» — подход к рассмотрению какого-то вопроса. В контексте выражения мнения эти слова — синонимы.
As for me — Как по мне / Что касается меня; «As for me» — это простой неформальный способ выразить мнение.
To my mind — По-моему, по моему мнению. «Mind» — это буквально «разум, ум». Другими словами, «to my mind» значит «по моему мнению», «по-моему».
My impression is (that) — У меня такое впечатление, что. Используется, когда мы делимся мнением, своей точкой зрения.
To my knowledge — Насколько я знаю. Несмотря на то, что «mind» и «knowlege» значат похожие вещи (ум и знание), выражение «to my knowledge» имеет несколько другое значение, чем «to my mind». Оно значит «насколько я знаю».
As far as I know — Насколько я знаю
As far as I remember — Насколько я помню
As far as I can see — Насколько я вижу
It seems to me (that) — Мне кажется, что
appears to me (that) — Кажется / Похоже на то, что / Мне представляется, что
«It appears» и «It seems» близки по смыслу, но не идентичны. «It seems» — это просто «кажется», а «it appears» — это когда у вас сложилось некое впечатление на основе чего-то увиденного, услышанного, на основе догадки или информации.
It looks like — Похоже, что. «It looks like» или просто «Looks like» — очень употребительное в повседневной речи выражение. Разумеется, ему не место в официальной речи или тексте.
With all due respect — При всем моем уважении; Как и его аналог в русском языке, это выражение — вежливый способ возразить, не согласиться. Часто за ним следует «I think/suppose/believe that».
Язык — основной инструмент продакта. Даже на русском непросто выразить свои мысли так, чтобы всё было понятно и никого не задело. А если продакт общается с командой на английском, дело становится ещё сложнее.
В карточках собрали пять ситуаций, где продакту важно точно и аккуратно донести свою мысль, чтобы всё заработало. А ещё — рассказали о том, как получить скидку 20% на курс английского для продактов. Если вам такое интересно — добро пожаловать на сайт.
→ Курс «Продакт-менеджер».
→ Курс «Английский для менеджеров продукта».
→ Правила акции.
Telegram
Sergey Koloskov in Better write product manager