Обзор профессии менеджера продуктов на рынке труда

Product Manager (продукт менеджер) и Product Owner (владелец продукта). В чем разница?

В чем разница между владельцем продукта и менеджером продукта?

Начнем издалека: Определим, что такое Scrum и что такое SAFe.

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

SAFe (Scaled Agile Framework) — это гибкий фреймворк для разработки программного обеспечения, позволяющий использовать аgile-методологии в больших командах размером более 50 человек, т.е. это некая надстройка над Scrum. Скрам, экстремальное программирование и другие гибкие методы разработки обычно не выходят за пределы уровня команды (7+-2 человек, т.е. от 3 до 9).

Раскроем определения Product Manager & Product Owner:

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

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

Задачи Product Manager

• Взаимодействие с Рынком/Заказчиками. Определение потребностей рынка. Совместная работа с маркетингом/бизнесом.
• Управление видением продукта, построение дорожной карты продукта (roadmap), составление бэклога продукта, управление ценами, лицензирование продукта, отвечает за ROI
• Управляет целями и выпуск релизов, через приоритезацию фич
• Устанавливает критерии приемки фич

Задачи Product Owner

• Взаимодействие с командой разработки, технологиями и разработка решения, совместно с командой (-ами)
• Отвечает за наполнение и реализацию backlog
• Определяет итерации и пользовательские истории
• Управляет целями итераций и содержанием итераций через приоритезакцию пользовательских историй
• Устанавливает критерии приемки реализации пользовательских историй
• Участвует в процессе расширения команды, найма

Product Owner (владелец продукта) — больше про управление проектом или набором проектов для создания и совершенствования продукта. Product Owner плотно работает с командой проекта (и имеет минимальные технические навыки, чтобы говорить с ними на одном языке, от разработки до UI/UX), решает, каким именно будет продукт, управляет бэклогом, взаимодействует с пользователями на всех этапах (от сбора требований до тестирования и получения обратной связи), иногда – контролирует бюджет на разработку продукта. В общем, основная обязанность Product Owner – получить работающий продукт, отвечающий ожиданиям пользователей, и, в идеале, даже их превышающий, и развивать его. В большинстве случаев этот термин используют при разработке внутренних продуктов, не ориентированных на внешний рынок.

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

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

Product owner — отвечает скорее за реализацию плана развития, сроки-детали. Генеральный директор и технический директор в своем роде.

В чем отличие Product Manager и Project Manager?

Обязанности менеджера проекта:

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

Обязанности менеджера продукта:

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

Product manager занимается продуктом, project manager ведет проекты.

Проект — это процесс, он ограничен в рамках времени и бюджета.

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

Продакт	Проджект
Фокус на цели	Фокус на процессе
«Что» делать	«Как» делать
«Какой продукт» делать	«Когда» делать

Работа продукт менеджер (продакт менеджером)

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

Какие основные обязанности в вакансиях есть? Задачи и обязанности менеджера продукта

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

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

• Сбор и анализ требований к продуктам, а также потребностей, от внутренних и внешних заказчиков
• Управление Продуктом, с целью достижения регулярных и высоких продаж в России и за рубежом
• Достижение стабильно высокого уровня удовлетворенности Клиентов (CSI)
• Разработка и совершенствование Продуктовой стратегии, поиск точек роста, определение четкого позиционирования Продукта в портфеле Компании. Или Построение GTM стратегии (выхода на рынок)
• Работать над улучшением ключевых метрик продукта, генерация идей по улучшению качества продукта
• Анализ рынка, ожиданий и предпочтений Клиентов
• Анализ конкурентной среды, понимание сильных и слабых сторон конкурентов, тенденций рынка
• Совместно с Менеджерами по продажам формирование плана по Продажам
• Совместно с отделом маркетинга: Выстраивание коммуникации в продукте и продуктового email-маркетинга, A/B-тестирование разных форматов
• Проведение и анализ результатов A/B-тестов
• Определение ключевых показателей эффективности и постановка целей, которые двигают команду к успеху
• Регулярная аналитика по направлениям (разработка KPI продукта на краткосрочной и долгосрочной основе, мониторинг исполнения KPI)
• Проверять имеющиеся гипотезы, выдвигать и проверять новые
• Разработка новых продуктов
• Тестирование Продукта на всех этапах, контроль качества.
• Финальная проверка подготовленных релизов
• Участие в профильных выставках/конференция
• Тестирование идеи или прототипа будущего продукта на потенциальных потребителях (custdev)

Продакт-менеджер: основные навыки профессии. Как построить карьеру

Product Manager — это человек, который находится на стыке бизнеса, пользовательских интерфейсов и технологий.

Типы менеджеров:

• Менеджеры по продукту, ориентированные на текущие продукты, отвечают за рост;
• Менеджеры по продукту, работающие над следующим выпуском, занимаются планированием продукта;
• Менеджеры по продукту, работающие над будущими продуктами и рынками, определяют стратегию продукта.

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

Продакт менеджер строит процесс, который проверяет гипотезы
Уровень продакта = количество проверенных гипотез за единицу времени
Основная компетенция — превращать гипотезы в исполнимые тесты

Рассмотрим два типа навыков, которые нужны Product Manager.

Hard skills Product Manager (менеджера продуктов)

• User Experience Design (UX Design) & User Interface Design (UI Design)
• Набор технических навыков
  • Навыки тестирования
  • Навыки программирования
  • Знание актуальных продуктов и интернет-трендов
  • Навыки разработки или знания технической архитектуры продукта
  • Навыки работы с облачными хостингами (cloud computing): AWS, GCP, Azure, DigitalOcean, RackSpace
• Разработка и принятие решений на основе данных
  • Показатели использования продукта потребителями
  • Топовые фичи и неиспользуемый функционал
  • Стадии, на которых потребители склонны бросать продукт
  • SQL & BI (для формирования отчета по продукту)
  • Когортный анализ
  • Расчет ROI
• Знание предметной области бизнеса
• Знание методологий разработки в IT, принципов разработки IT продуктов
• Сбор требований
• Разработка Стратегии Продукта (продуктовая стратегия)
  • анализ целевых аудиторий
  • изучение конкурентов
  • определение продуктовых и ценовых стратегий
  • трекшн-карта
• Экономическая теория
  • Unit economics
  • Финансовое моделирование и расчет бизнес-плана продукта в Excel
  • Теория и практика в Digital Marketing и в Классическом маркетинге
• Исследования
  • Качественные (интервью, опросы и т.д.) и количественные исследования рынка
  • Customer Development / CustDev
  • A/B Тестирование
  • Трекшн-карта
  • Оценка потенциала новой функциональности
  • Проектирование экспериментов и интерпретация результатов по метрикам (Data Driven Product Management)
• Планирование
  • Canvas-методы
  • Концепция бережливого производства
  • Теория ограничений голдратта
  • Канбан доска
  • Scrum
  • Метод критической цепи

Soft skills Product Manager (менеджера продуктов)

• Мотивация команды
• Проведение переговоров и умение наладить контакт с заказчиком, разрешение конфликтов
• Харизма
• Делегирование задач
• Целеполагание
• Расстановка приоритетов
• Тайм-менеджмент и самодисциплина
• Умение убеждать
• Нетворкинг
• Взятие ответственности на себя

Карьерный путь: как прийти к менеджменту продуктов

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

Есть два пути развития:

• Первый — это приход к продакт-менеджменту после множество опробованных IT-профессий: специалист может начинать как разработчик, потом попробовать тимлидинг, далее — перейти к управлению проектами или же сформировать некую собственную идею продукта и попробовать реализовать ее в рамках данной компании. Такой способ является весьма распространенным, ведь менеджер по продукту — это логическое продолжение успешной карьеры толкового, имеющего приличный рабочий опыт специалиста.
• Второй путь — непосредственное обучение. Всё может начаться как со специального высшего образования (управление проектами, менеджмент и пр.) и продолжиться в виде так называемых курсов повышения квалификации, которые длятся от двух дней, в формате семинаров и мастер-классов, до 2-3 месяцев в в виде полноценных учебных дней с сопутствующими теорией и практикой.

Еще один взгляд на трансформацию из других профессий (смежных). Продакт-менеджер может пройти:

• Путь от маркетолога. Такие специалисты знают инструменты продвижения, исследования рынка, продажи. Скорее всего переход будет поэтапным, со сменой нескольких должностей.
  • Обучение: узнать о специфике отрасли и пройти курсы по управлению проектами.
• Путь от разработчика. Вы умеете создавать продукт на физическом уровне. Придется набить немало шишек, чтобы научиться его продвигать как товар, глядя на созданное вами «с обратной стороны» — от потребителя.
  • Обучение: маркетинг. Исследование аудитории и создание продуктовой стратегии.
• Путь от тестировщика. Тестирование — это взгляд со стороны пользователя. Понимания, как клиент видит продукт, недостаточно.
  • Обучение: маркетинг — сегментация аудитории, расчет бизнес-метрик — расчёт прибыльности продукта + возврат инвестиций и т.д.
• Путь от дизайнера. Дизайн — одна из многих граней управления продуктом. Нужно улучшить понимание, как производится продукт и как его массово продавать.
  • Обучение: маркетинг и управление проектами.

Junior & Middle & Senior

Что умеет Junior продукт-менеджер:

• Постановка правильных метрик
• Проектная работа
• Исследование пользователей (опросы, интервью, UX-тесты)
• Проектирование интерфейса
• Коммуникация с разработкой
• Мыслить шире одного сценария на одной платформе

Что умеет Middle продукт-менеджер:

• Приоритизировать задачи в рамках своего подпродукта
• Собирать, анализировать данные: понимает, что собирать и как проверять успешность измерений
• Отвечать за приоритеты собственных задач и планировать загрузку сам
• Декомпозировать цели подпродукта на задачи и релизы

Что умеет Senior продукт-менеджер:

• Создавать и защищать видение и стратегию продукта
• Обучать Middle и Junior
• Выстраивать продуктовые процессы
• Управлять командой продукта
• Прогнозировать финансовые результаты, считать ROI

Что можно считать продуктом

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

Продуктовая разработка — это постоянное углубление в какую-то одну тему.

Продукт:

• Состоит из проектов. Сервис заказа такси Uber — продукт.
• Не ограничен во времени. «У нашего стартапа планы на 150 лет вперед. И вообще мы не планируем закрываться никогда, а постоянно развиваться и расти».
• Делаем сами. Работу над продуктом обычно не доверяют «на сторону», в команду набираются люди на долгую перспективу. У «Яндекс.Пробок» своя продуктовая команда, у Tesla Motors — тоже.
• Результат. Интернет-магазин, с помощью которого вы планируете зарабатывать 1 миллион долларов в год — ваш продукт.

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

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

Признаки продукта:

• Есть пользователи
• Решает проблему
• Имеет систему показателей — хорошо работает или нет
• Генерирует прибыль
• Даже если продукт не генерирует прибыль самостоятельно, он делает вклад в имидж компании/разработчика/лояльность пользователей.

Проект vs Продукт

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

У менеджера продукта 2 основные цели:

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

Генерация идей и гипотез

Идеализированный процесс работы над продуктом

Идеализированный процесс работы над продуктом выглядит следующим образом:

1. Продуктовая гипотеза. Поиск нерешенных проблем пользователей, которые мог бы закрыть наш продукт, чтобы увеличить показатели бизнеса.
2. Предварительная валидация. Аналитическая оценка того, насколько востребованным и коммерчески оправданным может быть такой продукт.
3. Дизайн и разработка. Производство продукта или функциональности в нужные сроки и качество.
4. Тестирование решения. Предварительная оценка того, насколько продукт подходит целевой аудитории.
5. Дистрибьюция продукта. Привлечение пользователей по разным каналам и рынкам, возможно с разными посылами и ценностями. Плюс организация бесшовного перехода пользователя между каналами.
6. Обратная связь от рынка и пользователей. Реальная оценка продукта и внесение изменений в него, будь то детали реализации, возможности или концепция/целевая аудитория в целом.
7. Поддержка пользователей. Решение проблем, возникающих при использовании продукта, с которыми пользователи обращаются в службу поддержки, социальные сети и другие каналы связи с компанией.

Способы генерации идей и гипотез

Генерация идей — поиск возможностей создания новых товаров (услуг). Он включает определение источников новых идей и методов их генерации.

Источниками новых идей являются:

• Потребители
• Товары конкурентов
• Мнение торговых работников
• Публикации правительства
• Научно-исследовательские и опытно-конструкторские работы.

На этапе выработки идеи изучаются источники новых идей с использованием специальных методов выработки идеи и методов творческого решения проблем (например, с использованием ТРИЗ), вырабатывается идея (сущность) проекта.

Методами выработки идей и творческого решения проблем являются:

1. Метод «мозговой атаки/мозговой штурм/brainstorming» (спонтанное генерирование участниками множества идей по поставленной проблеме);
2. Метод «мозгового штурма наоборот» (выявление недостатков предлагаемых идей и определение путей их устранения);
3. Метод Гордона (сначала излагаются концепции к решению проблемы с дальнейшим обсуждением идей по этому вопросу. Затем после уточнения исходной концепции раскрывается искомая проблема с высказыванием конкретных предложений и идей об их реализации);
4. Метод вопросника (составляется в произвольной форме перечень вопросов, направленных на выявление возможностей изменения существующего товара);
5. Метод вмененных связей (поэтапный анализ элементов проблемы, связанной с товаром и определение закономерностей между элементами, с целью выявления новых идей, вытекающих из этих закономерностей);
6. Метод записной книжки (фиксирование в специальной книге всех известных фактов, имеющих отношение к решению исследуемой проблемы и результатов обдумывания проблемы и возможных путей ее решения);
7. Эвристический метод (умение строить догадки, используя логические рассуждения, интуицию и прошлый опыт, с дальнейшим выявлением всех концепций, которые имеют отношение к изучаемому товару, и выработка на их основе всех возможных комбинаций и идей);
8. Научный метод (сбор данных в ходе наблюдений или экспериментов и проверка на основании этих данных различных гипотез с целью выбора наилучшего из всех допустимых решений);
9. Метод стоимостного анализа (максимизация выгоды для предпринимателя и предприятия);
10. Метод матричных структур (систематизация поиска новых идей путем построения матрицы, столбцы которой соответствуют обсуждаемым вариантам товаров, а строки — рыночным показателям этих товаров);
11. Параметрический анализ (идентификация параметров и творческий синтез).

Портрет целевой аудитории

Для генерации гипотез нам необходимо выделить возможные целевые аудитории (возможные потенциальные потребители).

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

Методика Марка Шеррингтона или 5W

С помощью методики 5W Марка Шеррингтона можно определить целевую аудиторию и её психологические характеристики, которыми обладают потенциальные потребители. В основе методики лежат пять вопросов:

• Что? (What?) — Какой продукт вы предлагаете? Поможет сегментировать аудиторию по типу товаров: что вы предлагаете потребительской группе? какие товары/услуги?
• Кто? (Who?) — Кто приобретает продукт/услугу? Сегментация по типу аудитории: пол, возраст, геоположение, семейный статус и др. характеристики.
• Почему? (Why?) — Почему пользователи должны купить именно у вас? Сегментация по типу мотивации: какова потребность, что движет клиентом? какую проблему решает товар/услуга?
• Когда? (When?) — Когда ваш продукт понадобится клиентам? Сегментация по ситуации в которой приобретается продукт: когда потребители хотят приобрести товар/услугу?
• Где? (Where?) — Где люди решают купить у вас и где покупают? Сегментация по месту покупок: в каком месте происходит принятие решения о покупке и сама покупка? Какие могут быть точки контакта с клиентом, где можно повлиять на решение.

Где взять данные для составления портрета ЦА

• Анализ Яндекс.Метрики и Google Analytics существующих сайтов
• Email опросы
• Опросы в группах социальных сетей
• Анкетирование существующих клиентов
• Мониторинг отзывов
• Изучение подписчиков групп в социальных сетях
• Анализ истории поиска по сайту
• Опросная форма на сайте
• Данные из CRM-системы
• Запросы в поисковиках
• Тематические форумы
• Различные блог площадки (с вопросами, яндекс район, чаты telegram)
• Анализ конкурентов
• Тематические блоги и комментарии к постам
• Профильные СМИ

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

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

Портрет ЦА — точная характеристика яркого представителя определенной аудитории.

1. Социальные характеристики (пол, возраст, семейный статус, доход)
2. Данные о времяпровождении (форумы, сайты, социальные сети)
3. Какие проблемы потенциальному покупателю поможет решить ваш товар?
4. Какие чувства у потенциального покупателя вызовет ваш товар/услуга?
5. Почему клиент должен купить именно ваш товар, а не перейти по ссылке конкурентов?

Цель портрета ЦА — дать полученным данным лицо и характер.

Общее описание процесса работы над гипотезами Построение гипотез

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

1. Сформируйте перечень гипотез
2. Проранжируйте их
3. Выбрать три гипотезы для проверки
4. Берем гипотезу и начинаем ее развивать. Строим дерево гипотез
5. Выбираем гипотезы для тестирования
6. Разрабатываем сценарий интервью
7. Формируем список респондентов
8. После каждого интервью фиксируем результат, уточняем сценарий
9. Ищем паттерны. Паттерны — это схожие проблемы

Пример

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

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

Берем гипотезу «Покупка продуктов занимает более двух часов времени, клиенты хотят сократить время покупок»

Составляем вопросы для интервью:

1. Как часто ходите в магазин?
2. Что вас больше всего раздражает при походе в магазин?
3. Какие у вас любимые блюда? Какие обычно готовите? Почему так?
4. Вы ходите в рестораны ужинать? А пробовали заказать еду ранее на дом? Почему?

Выбираем респондентов

• Молодые семьи

Фиксируем все разговоры (видео, аудио с согласия респондентов)

Анализируем результат и делаем выводы

Формирование гипотез. Генерация гипотез

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

Гипотезы можно разделить на два типа:

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

Сначала необходимо определить гипотезы ценности, а затем переходить к работе с гипотезами роста.

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

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

Хорошая гипотеза …

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

Целевая группа для гипотезы

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

Структура гипотезы (шаблон гипотезы):

Если [Изменение в продукте/Действие] -> то [Влияние (т.е. что произойдет)] -> на что повлияет [Объект изменения] -> вычисляем изменение [На сколько] -> за какой период [срок]

Самым сложным в формировании гипотезы по такому шаблону является ответ на вопрос «На сколько»? Ответ на этот вопрос даёт понять, какую отдачу вы ожидаете получить после валидации гипотезы.

Примеры гипотез:

1. Дизайн x [Изменение в продукте/Действие] увеличит конверсию [влияние] на трафик в поисковой кампании [объект изменения] на 10% [на сколько] через 7 дней [срок].
2. Сокращение количества шагов регистрации с 3 до 1 увеличит количество зарегистрированных пользователей на 25% после 1000 посещений страницы регистрации.
3. Эта тема будет увеличивать открытые ставки для подписчиков ежедневного дайджеста на 15% через 3 дня.

Зачем формулировать гипотезы?

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

• Беспристрастные решения. Гипотезы уменьшают влияние предрассудков на процесс принятия решений.
• Ориентация на команду: Подобно общему видению, гипотеза усиливает командное мышление и предотвращает конфликты на экспериментальной стадии.
• Фокус: Тестирование без гипотезы — это как плавание без цели. Гипотеза помогает сфокусировать и контролировать дизайн эксперимента.

Гипотеза – это то, что можно пойти и проверить

1. Очень часто продуктовые гипотезы формулируются на слишком отдаленную перспективу и в терминах абстрактных людей и рынков. «Люди хотят вот этого», «На этом рынке есть такая-то проблема», «Чтобы занять столько-то процентов этого рынка, мы предполагаем сделать вот это», «Наше решение даст людям возможность делать это», «Мы видим тренд вот в этом», «Этот рынок развивается, поэтому мы делаем вот это», «Люди начинают делать это» и т.д. Это все красиво, но слишком абстрактно.
2. Гораздо более конструктивная формулировка гипотезы можем выглядеть так: «Если я сегодня достучусь до N людей, которых я найду вот так, и предложу им вот это, то Y% согласится». Ключевые моменты:
   • «Сегодня». Если вы сегодня не можете пойти и проверить это – значит это не гипотеза, а рассуждения на тему.
   • «Которых я найду вот так». Таргетинг по формальным параметрам. Нет таргетинга – невозможно прикинуть стоимость привлечения покупателя (следовательно, и экономику в целом) и объем достижимого рынка.
   • «Y% согласятся». Конверсия – это ключ к планомерному росту. Наложив ее на объем достижимого рынка из предыдущего пункта, мы получим оценку достижимого количества клиентов.
3. В общем, гипотеза должна быть не «догмой, а руководством к действию»

Для проверки гипотезы используйте аналитику:

1. Сформулируйте гипотезы
2. Структурируйте их в виде дерева или пирамиды
3. «Оцифруйте» гипотезы: добавьте измеряемые цели и параметры
4. Соберите данные для проверки гипотезы
5. Уточните гипотезу на основе полученных данных
6. Примите решение о целесообразности реализации

Lean Startup

Основная мысль Lean Startup:

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

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

Как выглядит цикл разработки?

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

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

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

Способы дешево проверить гипотезы разнятся в зависимости от проекта. Например, в «Яндекс.Недвижимость» ты можешь либо подать объявление для аренды квартиры, либо поискать обновление для покупки или съема. Мы подумали: а давайте сделаем ипотечный калькулятор. Как проверить, крутая ли это идея? Решили сделать кнопку с большой подписью «рассчитать ипотеку». По нажатию уходим на статью в википедии или на сайт банка, куда угодно, на этом этапе не важно. Если пользователи часто на нее нажимают — разрабатываем. Если нет — идея не стоит вложений.

Принципы проверки продуктовых гипотез

• Идем от дешевых гипотез с низкой степенью точности к дорогой проверке гипотез (Сплит-тестирование или А/В тестирование)
• Проверка 1 гипотезы через множество HADI-циклов
• Убийство гипотез (например, из 100 входных гипотез получаем 1 гипотезу для A/B тестирования)
• Принимаем решения на основе данных.

HADI-цикл

• Гипотеза (Hypothesis). Записываем гипотезы, то есть изменения (ваши действия), которые могут улучшить показатели вашей экономики. Например: «изменение заголовка увеличит конверсию в регистрацию на лендинге на 5%». В первую очередь, нужно генерировать гипотезы по тем показателям, изменение которых важно в ближайшее время. Это значит, что если есть проблема с конверсией в регистрацию, то необходимо генерировать те идеи, которые напрямую повлияют на этот показатель.
• Действие (Action). В начале каждого цикла (у нас это каждая неделя) берем несколько гипотез и начинаем их воплощать в жизнь. Например, мы переписываем заголовки, и добавляем туда выгоду для клиента. Главная формула — делать быстро. Если изменение принесет пользу, улучшить его и масштабировать будет несложно. Главное в HADI — это оперативная проверка.
• Сбор данных (Data). Начинаем сбор данных о показателях, на которые повлияет изменение. В нашем примере это конверсия в регистрацию. Чтобы показатели отражали реальные изменения, выборка (количество посетителей за время тестирования) должна быть репрезентативной. Об этом подробнее поговорим дальше.
• Выводы (Insights). Анализируем, сработала ли гипотеза. Если да, то планируем ее улучшение, масштабируем.

Валидация продуктовых гипотез

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

Рассмотрим какие существуют подходы для валидации продуктовых гипотез.

• A/B тестирование (A/B testing). Это сравнение двух вариантов друг с другом для того, чтобы понять, какой вариант больше повлияет на вашу целевую метрику.
• Интервью с пользователем (User interview). Пользовательское интервью даёт отличную возможность получить качественные данные от существующих либо потенциальных пользователей. Выделяют две группы пользовательских интервью: Usability и Discovery. Usability помогает понять, смогут ли вообще юзеры использовать продукт и достичь своей цели. Discovery-интервью позволяет детальнее вникнуть в самого пользователя и ответить на вопросы: «Кто? Где? Зачем? Как?».
• Сортировка карт (Card sorting). Card sorting — это метод для структурирования информации, построения лучшей навигации и создания информационной архитектуры. Сортировка карточек — это метод исследования UX, при котором участники исследования группируют индивидуальные ярлыки, написанные на карточках, в соответствии с критериями, которые им понятны. Этот метод раскрывает, как структурированы знания предметной области целевой аудитории, и он служит для создания информационной архитектуры, которая соответствует ожиданиям пользователей.
• Опрос (Card Sorting). Простой способ проверки гипотез, но для того, чтобы получить хорошие результаты, нужно задавать правильные вопросы в нужной последовательности.

Валидация рискованных предположений

Riskiest Assumption Test — это фреймворк выбора высокоуровневого фокуса команды на самом рискованном предположении, из которого команда исходит, создавая новый стартап/продукт. Фреймворк постулирует, что в каждом продукте, который мы делаем есть как минимум одно рискованное предположение, которое мы по-умолчанию подразумеваем и не осознаём ИЛИ осознаём.

Процесс валидации рискованных предположений:

1. Выписываем все рискованные предположения, которые могут убить наш стартап/продукт
2. Ранжируем по рискованности (вероятность выстрелить, последствия от неподтверждения)
3. Берём первое рискованное предположение и проверяем
4. По появлению новых вводных/проверке наиболее рискованного предположения — возвращаемся к п.1

Рассмотрим подробно виды интервью

• Глубинное интервью (глубинка, интервью, customer interview, user interview): один на один [иногда 2-3 участника на 1] интервью с человеком, в котором мы стараемся глубоко погрузиться в потребности, контекст и боли клиента. Длится от 30 минут до 1 часа 30 минут.
• Проблемное интервью: Глубинное интервью, в котором мы фокусируемся на проблемах клиента. Идёт по строгому скрипту.
• Решенческое интервью: Интервью, в котором мы фокусируемся на том, чтобы получить обратную связь на гипотезу нашего продукта И попытке продать: «Готовы купить прямо сейчас?»
• JTBD-интервью: Интервью, в котором мы узнаём у каких сегментов клиентов какие Big Job, Small Jobs, в каких контекстах, с чем мы конкурируем, как выглядит процесс принятия решения о покупке. Есть скрипт.
• Контекстное интервью: Интервью, в котором мы фокусируемся на том, чтобы узнать как сейчас человек решает свою потребность. В каких контекстах, какими способами. Обычно, предшествует проблемным и тем более решенческим интервью. Устаревший способ доставания контекста из человека, рекомендую использовать JTBD-интервью
• Коридорное тестирование (UX-test): Простейшее юзабилити-тестирование, которое проводится БЕЗ специальной подготовки и по-умолчанию на неподготовленных людях. В большинстве случаев, не клиентах, а коллегах. Отсюда и название: «Коридорное тестирование»—для того, чтобы найти косяки в своих макетах/прототипе, достаточно выйти в коридор и показать макеты/прототип коллеге. Есть скрипт.

Что дает интервью?

1. Непосредственный контакт с пользователем
2. Реальные факты с рынка, а не догадки
3. Формулировку «боли» словами пользователей
4. Валидацию «своих» клиентских сегментов

Приоритизация продуктовых гипотез

Список сформулированных гипотез может получиться очень большим, поэтому он требует приоритизации и определения периодов запуска экспериментов. Для ранжирования гипотез существует несколько методов, среди них — PIE, CXC и другие.

Критерии успешности проверки гипотез

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

Пример: 10% потенциальных клиентов, но не менее 10 клиентов, согласятся на покупку без триала.

Видео по разделу

Что такое Customer Development (custdev, касдев, кастдев)

Customer Development (custdev, касдев, кастдев) — это методология создания новых стартапов/продуктов/услуг, постулирующая, что у нового стартапа/продукта/услуги есть непроверенная бизнес-модель. Эта методология описывает как эту гипотезу нужно проверять.

Гипотеза бизнес-модели бьётся на под-гипотезы:

1. Есть ли рынок для продукта?
2. Есть ли клиент с потребностью для продукта?
3. Какой продукт им нужен?
4. Какие каналы привлечения использовать для их привлечения?
5. Какая будет модель монетизации?

Каждую под-гипотезу тестируем научным методом:

• Высказываем гипотезу,
• Дизайним эксперимент,
• Проводим эксперимент,
• И в конце пути:
  • либо убиваем гипотезу,
  • либо корректируем,
  • либо подтверждаем гипотезу.

Стив Бланк впервые описал эту методологию в книге The Four Steps to Epiphany, затем её развил Эрик Рис в методологию Lean Startup—дешёвых итеративных экспериментов и описал в книге The Lean Startup. Актуальное описание методологии Lean Startup можно найти у Эша Маруйи в книгах Running Lean и Scaling Lean.

Фреймворк Customer Development и в срезе изучения потребности клиента и валидации идей продукта [что сейчас преимущественно имеют в виду, говоря Customer Development], и в срезе «на чём сейчас высокоуровнево фокусироваться» объективно устарел и ему на смену пришли:

• Jobs To Be Done как всеохватывающий способ изучения потребностей сегментов клиентов
• Lean как методология процессного фокусирования
• Riskiest Assumption Test как способ выбора высокоуровневого фокуса.

В 99% случаев в России под термином «надо показдевить» подразумевают «надо, наконец, поговорить с клиентами», а под «каздев» подразумевают «глубинные интервью».

Что такое развитие потребителей (Customer Development)?

Потребители — это люди, от которых зависит успех продукта. Customer Development — методика, которая позволяет снизить бизнес-риски за счет знания потребителей, их потребностей и факторов, влияющих на принятие решений о покупке.

Развитие потребителей — основанный на предположениях подход к пониманию следующих вещей:

• Кто ваши потребители?
• Каковы их проблемы и потребности?
• От чего сегодня зависит их поведение?
• За какие новые продуты (даже незаконченные или пока несуществующие) они готовы платить?
• Как при принятии решений вами следует учитывать то, как принимают решения ваши клиенты: как они совершают покупки, находят поставщиков, выбирают товар и потребляют его?

Развитие потребителей — не что иное, как оценка обоснованности ваших гипотез.

Развитие потребителей включает пять составляющих:

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

Развитие потребителей — это не развитие продукта

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

Особенности процесса развития продукта в значительной степени зависят от методов работы конкретной организации — например, от того,какая методика используется для организации разработки программного обеспечения — каскадная, гибкая или скрам (scrum). Но как бы ни различались процессы, они всегда нацелены на одно — получение конечного продукта, который будут покупать.

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

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

Самое важное про Customer Development

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

Проектирование MVP

Что такое MVP (Минимальный работоспособный продукт)

Термин MVP был придуман и определен Фрэнком Робинсоном и популяризирован Стивом Бланком и Эриком Рисом.

Популярное определение следующее:

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

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

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

Что означает MVP

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

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

Три основных компонента MVP

1. MVP Предоставляет достаточно функций

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

Каковы будут критерии для расстановки приоритетов? И сколько из наиболее важных функций достаточно, чтобы обеспечить ценность для ваших первых клиентов?

Критериями для ранжирования ваших функций должны быть:

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

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

2. MVP Удовлетворяет первых клиентов

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

Ваши первые клиенты должны быть настолько довольны вашим продуктом, чтобы выступать в качестве промоутеров — рекомендовать его другим и публично делиться своим удовлетворением (если не волнением).

3. MVP Обеспечивает обратную связь для будущего развития

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

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

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

Вы также можете рассмотреть возможность использования механизмов удовлетворенности клиентов, таких как NPS — Net Promoter Score, как способ получения удовлетворенности пользователей стандартизированным способом.

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

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

Идея создания MVP делится на две основные части:

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

Пошаговое руководство по созданию минимально жизнеспособного продукта (MVP)

Пример MVP

Год был 1990, был молодой парень, который хотел иметь определенную пару обуви. Он пошел в торговый центр недалеко от своего места, но, к сожалению, он не смог найти пару.

Разочарованный, он предложил идею продавать обувь онлайн. И вот тут все и началось.

MVP родился.

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

Хотя он терял деньги на каждой продаже, это был невероятный способ проверить бизнес-идею. Как только он предположил, что клиенты готовы покупать обувь онлайн, он начал превращать свою идею в полностью функционирующий бизнес.

Так Ник Суинмурн создал компанию Zappos, которая впоследствии была приобретена Amazon за 1,2 миллиарда долларов.

Да, подход, который использовал Ник, — это то, что мы называем MVP Development в наше время.

От идеи к MVP

Если у вас есть идея, то вам следует начать со следующего процесса, прежде чем приступить к созданию «продукта», который никому не нужен:

1. Опишите вашего клиента и сформулируйте гипотезу проблемы.
2. Проведите интервью с людьми (из ЦА), которые соответствуют этой гипотезе, и попытайтесь уточнить/подтвердить/убить гипотезу проблемы.
3. Повторяйте шаги 1. и 2. до тех пор, пока не сможете предсказать ответы следующих.
4. Затем представьте целевой группе решение в интервью-решении.
5. Итерируйте, пока не убедитесь, что ваше предложение могло бы решить их проблему.
6. И тогда вы можете перейти к построению своего первого MVP.

Необходимые шаги для создания MVP

Шаг 1: Исследуйте рынок

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

«Недостаточно сделать все возможное; ты должен знать, что делать, а потом делать все возможное».
У. Эдвардс Деминг

Исследование, проведенное CB Insights показало, что частой причиной отказа стартапа (с долей 42%) является «отсутствие потребности рынка». Короче говоря, если ваш продукт не решает проблему, клиенты не будут его покупать для решения своих проблем.

Шаг 2: Сформулируйте свою идею

Какую ценность ваш продукт предлагает своим пользователям? Какую пользу принесет потребителям ваши продукт или услуга? Зачем им покупать ваш продукт? Это важные вопросы, которые нужно учитывать, чтобы лучше сформулировать свою идею.

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

Шаг 3: Рассмотрим процесс проектирования

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

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

Шаг 4. Перечислите функции MVP

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

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

Затем классифицируйте все остальные функции MVP на основе приоритета: высокий приоритет, средний приоритет и низкий приоритет. Когда вы упорядочили все функции, вы можете определить их область применения для первой версии продукта и перейти к созданию MVP. Если вы хотите посмотреть, как будет выглядеть ваш будущий продукт, вы даже можете создать прототип MVP .

Помните: Стив Джобс остался без работы из-за того, что избегал стадии прототипирования при создании Apple Lisa. Результатом стала катастрофа, так как не удалось добиться благоприятного количества продаж.

Шаг 5: Создайте свой MVP

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

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

Шаг 6: Разработайте MVP, протестируйте и оцените качество

Все является частью процесса: сначала определите объем работ, а затем переведите продукт на этап разработки. После завершения разработки продукта, продукт должен быть протестирован.

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

Как делать MVP

1. Презентация / Макет / Видео / Сайт на Tilda – проведение продажи и аналитика
2. Рабочий прототип – стоимость – сделка – аналитика
3. Имитация полноценного рабочего продукта методом «маленьких человечков»
4. Не забываем про критерии измеримости и адаптации

Что тестируют с помощью MVP?

Минимально жизнеспособный продукт – это процесс, с помощью которого вы тестируете:

• Нужно ли кому-то то, что вы делаете? Кому именно это нужно?
• Готовы ли люди за это платить?
• Укладывается ли стоимость привлечения покупателя (CAC, Customer Acquisition Cost) в рамки вашей финансовой модели?

5 китов на которых держится MVP

1. MVP – это не прототип сервиса, а прототип воронки продаж
2. MVP – это не один шаг проверки одной гипотезы, а цикл, который продолжается до тех пор, пока либо у вас не закончатся гипотезы, либо вы на нащупаете гипотезу, которая сработала. Чем больше у вас гипотез, тем больше шанс, что какая-то из них сработает.
3. Основное внимание уделяйте не тем людям, которые успешно прошли всю воронку продаж до кнопки «Купить», а тем, кто не «засосался» в воронку или вывалился из нее по дороге. Их всегда будет больше, чем дошедших – резерв повышения эффективности воронки продаж скрыт в анализе их отказов.
4. Не используйте MVP для проверки того, что и так очевидно. На каждом цикле проверяйте только самую рискованную и невероятную на данный момент гипотезу.
5. MVP – это не просто способ найти подтверждение своей правоты. Чаще всего – это способ найти, в чем вы ошибаетесь, чтобы суметь сгенерировать новую гипотезу.

8 (восемь) характеристик качества продукта

1. Производительность. Основные рабочие характеристики продукта.
2. Дополнения. Все, что дополняет базовый функционал.
3. Надежность. Вероятность возникновения неисправности в течение определенного промежутка времени (этот фактор лучше оценивать как вероятность отсутствия неполадок).
4. Соответствие. Степень соответствия дизайна и производительности установленным стандартам.
5. Долговечность. Продолжительность жизнеспособности (с учетом экономической составляющей) оффера.
6. Простота ремонта. Осуществимость, скорость, удобство и простота ремонта.
7. Эстетика. Оценка продукта органами чувств.
8. Восприятие качества. Имидж/репутация оффера.

Продуктовая аналитика

Что такое продуктовая аналитика и почему она важна

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

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

Как осуществляется сбор данных по продукту?

• Менеджер описывает какие данные и где в приложении/программе нужно собирать данные.
• В продукт встраивается специальный SDK, который позволяет отправлять события в хранилище данных для дальнейшего использования их аналитической системой.
• После разработчик добавляет отправку событий в нужные места приложения/программы (открытие/закрытие приложения, нажатие на кнопки, вызов тех или иных команд, отправка сообщений и т.д.).
• Стремитесь всегда размечать только те события, из которых можно впоследствии достать какие-то полезные знания.

Немного теории: среднее арифметическое, медиана, корреляция

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

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

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

Продуктовые метрики

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

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

Дневная аудитория (DAU) — количество уникальных пользователей, которые зашли в приложение в течение суток.

Средняя дневная аудитория — среднее арифметическое дневной аудитории за определенный период.

Месячная аудитория (MAU) — количество уникальных пользователей, которые зашли в приложение в течение месяца. По отношению средней дневной аудитории к месячной можно понимать частоту использования продукта.

Retention Rate (коэффициент удержания) показывает, как новые пользователи возвращаются к использованию продукта.

Retention N-го дня — метрика, которая показывает сколько пользователей первого дня вернулось в продукт на N-ый день. Определение справедливо для недель, месяцев.
Когда говорят про Retention Rate, то обычно подразумевают Retention N-го дня.

Customer Retension Rate (Коэффициент удержания клиентов) = 100% * (Кол-во клиентов на конец периода — Кол-во новых клиентов за период)/Количество клиентов в начале периода

Churn Rate (Отток клиентов) = 100% * Кол-во клиентов, ушедших к концу месяца / Кол-во клиентов, оплативших следующий месяц

Churn Rate = 1 — Customer Retension Rate

Конверсия (Conversion Rate, CR) — метрика, показывающая отношение числа пользователей, которые выполнили какое-либо целевое действие к общему числу пользователей.

NPS (Net Promoter Score) — метрика уровня лояльности пользователей. Измеряется с помощью опросников, отражается в процентах. Этот показатель измеряет количество постоянных клиентов, которые могут порекомендовать продукт (промоутеры), и тех клиентов, которые его ненавидят (хулители). Чтобы рассчитать NPS, попросите пользователей оценить ваш продукт от 0 до 10. Дракторы дадут ему от 0 до 6 баллов, пользователи с 7-8 баллами являются нейтральными, а те, кто дал 9-10 баллов, являются промоутерами.

NPS = % of promoters – % of detractors

Высокий NPS приводит к 20-60 процентам органического роста. То же самое касается отрицательного NPS — большое количество хулителей приводит к экономическим штрафам. Осведомленность о NPS во всей организации мотивирует сотрудников повышать ценность, быстрее реагировать на проблемы и разбираться в проблемах хулителей. Кроме того, любая информация, полученная о хулителях, должна быть распространена среди всех отделов.

Оценка удовлетворенности клиентов (Customer Satisfaction Score, CSAT) — измеряет общий уровень контента или недовольства пользователя по поводу определенного продукта или функции. Обычно пользователей просят оценить продукт или услугу по шкале 1-3, 1-5 или 1-10. Он рассчитывается путем суммирования балла и деления его на количество респондентов. В отличие от NPS, CSAT направлен на оценку удовлетворенности определенной функцией. Спрашивайте отзывы пользователей в нескольких точках пути клиента и делайте это до очередного продления подписки, чтобы у вас было время внести улучшения. Кроме того, используйте этот показатель в качестве отраслевого ориентира.

Cost Per Acquisition (CPA) или Customer Acquisition Cost (CAC) — показывает цену привлечения пользователя. Этот показатель показывает все затраты, приходящиеся на привлечение 1 клиента: расходы на маркетинг, работу отдела продаж, рекламу. Иногда в эти расходы входят зарплаты специалистов по маркетингу и продажам. Обычно стоимость привлечения клиентов включает в себя установление определенного периода времени и общего дохода. Существует несколько формул для расчета CAC, но самая простая из них:

CAC = Расходы на продажи и маркетинг за период времени / Общее количество клиентов, пришедших за период времени

Ежемесячный периодический доход (Monthly recurring revenue, MRR) — показатель, с помощью которого измеряют общий доход продукта за один месяц. Чтобы рассчитать показатель, возьмите MRR в начале месяца, добавьте полученную прибыль от новых подписок и вычтите полученную прибыль от потерянных клиентов.

MRR = MRR на начало месяца + MRR от новых клиентов за месяц + MRR за счет повышения тарифного плана клиентов — MRR за счет снижения тарифного плана — MRR за счет оттока клиентов

Годовой периодический доход (Annual Recurring Revenue, ARR) = MRR * 12

Средний доход на пользователя (Average Revenue Per User, ARPU) — средний доход, который вы получаете от каждого активного пользователя за период. Эта метрика позволяет подсчитывать доход, генерируемый на 1 пользователя ежемесячно или ежегодно. Этот показатель необходим для определения будущего дохода от услуг, если вы собираетесь изменить тарифный план или провести рекламную акцию.

ARPU= Общий доход за период / Число активных пользователей за период

В расчёте учитывается все активные пользователи: и платящие, и неплатящие. Т.е. ARPU – это показатель монетизационной эффективности проекта: чем он выше, тем больше денег приносит один активный пользователь за период.

Средний доход на платящего пользователя (Average Revenue Per Paying User, ARPPU) — в расчёт попадают только те пользователи, которые совершали платежи в течение периода (Paying Users).

ARPPU = Общий доход за период / Число пользователей за период, внесших оплату

LTV (LifeTime Value) — показатель, который отображает среднюю прибыль от одного пользователя до того, как он отменит подписку. Смысл этого KPI состоит в том, чтобы показать вам, сколько вы можете потратить на привлечение нового клиента на ранней стадии, в отношении вероятной прибыли от одного человека. Чтобы рассчитать его, установите среднюю продолжительность жизни клиента (сколько времени клиент использует продукт до остановки) и средний доход на пользователя.

Пожизненная стоимость клиента (CLTV или LTV) = Средний доход на пользователя (ARPU) * Средняя продолжительность жизни клиента

ROI (Return Over Investment) — метрика для оценки окупаемости.

Продолжительность сеанса — самый простой способ отслеживать использование цифрового продукта. Лучший способ измерить его — взять общее время, затраченное пользователями на ваш продукт, разделить его на количество пользователей. Google Analytics и Yandex Metrika рассчитает этот показатель по умолчанию.

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

Количество сеансов на пользователя (Number of sessions per user) — этот показатель помогает понять поведение ключевых пользователей: как часто пользователи возвращаются и используют сайт. Это можно отслеживать с помощью статистики, которая отображает количество входов в систему или посещений сайта. Этот KPI показывает популярность продукта — если аудитория привлекает его снова и снова. В отличие от трафика или продолжительности сеансов, число сеансов на пользователя показывает среднее значение для определенной группы людей за определенный период времени.

Количество действий пользователя за сеанс (Number of sessions per user) — этот KPI кажется похожим на предыдущий, но он отслеживает не только то, сколько раз пользователь открывал приложение. Он отображает, какие действия сделал пользователь и какие функции он использовал при использовании приложения. Этот показатель используется для понимания популярности определенной функции с момента ее появления и сравнения с конкретным периодом времени. Кроме того, вы можете сравнить эти показатели у новых и постоянных клиентов и получить представление о том, что заинтересовало пользователей в вашем продукте.

Сегментация пользователей

Продуктовая аналитика позволяет собрать

• Демографические данные (пол, возраст, геолокация, платформа, устройство)
• Поведенческие данные (колличество сессий, совершение определенных действий, пользовательские данные)

С помощью этих данных можно:

• Выявить целевой сегмент на рынке
• Таргетировать фичи на определенную группу пользователей
• Изучать как изменения в продукте влияют на перераспределение сегментов

Зачем нужны эксперименты и что такое статистическая значимость?

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

Инструменты и дашборд

Инструменты для визуализации данных (если есть доступ к базе данных):

• Excel
• Python Dash & Plotty
• Power BI
• Tableau

Сервисы событийной аналитики:

• Firebase — бесплатный инструмент от Google, но не гибкий.
• Amplitude — лучше всего подходит для детального поведения пользователя. Инструмент платный, дорого.
• Mixpanel — отличное комплексное аналитическое решение, помогающее компаниям с мобильной и веб-аналитикой. Анализ продуктов компании дает ответ на вопрос, как именно пользователи взаимодействуют с ними. У компаний появляется возможность лучше понять путь пользователя и получить больше данных о каждом пользователе. Достаточно сложный и дорогой, подходит скорее для профессионалов с большими бюджетами.
• Appsee — это уникальная платформа, сочетающая в себе традиционную количественную и качественную аналитику. Благодаря тепловым картам кликов и записям пользовательских сеансов разработчики получают визуальные данные — слой, дополняющий цифровые данные и позволяющий понять, что стоит за цифрами.
• Amazon Mobile Analytics позволяет получить количественные данные об использовании приложений и доходах. Кроме того, можно отслеживать ключевые тенденции, удержание пользователей и настраиваемые события, связанные с поведением пользователей внутри приложения. Благодаря Amazon Pinpoint на основе собственной аналитики можно проводить целевые кампании для повышения активности пользователей.
• Localytics предлагает целый ряд аналитических инструментов, начиная от традиционной аналитики и заканчивая умным таргетингом и автоматизацией маркетинга. Инструменты Localytics позволяют лучше понять поведение пользователей и их взаимодействие с системой. Далее разработчик может, делая правильные шаги, повышать степень вовлеченности пользователей в течение всего их жизненного цикла.
• Countly дает возможность увидеть всю аналитическую картину по веб-приложениям и мобильными приложениям полностью, включая путь клиента. Также можно увидеть, на каких пользователей сильнее всего влияют сбои, и при необходимости внести изменения. Еще одна уникальная особенность Countly — приложение для мобильной аналитики с открытым кодом в режиме реального времени, которое разработчики могут разместить у себя на серверах.

Дашборд — это набор визуализаций (графики, диаграммы, KPI) для отслеживания ряда показателей по продукту.

Для разных целей и разных команд требуются разные dashboards:

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

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

• https://gopractice.ru/ — Блог про продакт менеджмент, продуктовую аналитику и рост мобильных приложений и интернет сервисов
• https://simulator.gopractice.ru/ — Симулятор работы в продуктовой компании. Вы получите реальный опыт, развивая амбициозный продукт, анализируя реальные данные в системах аналитики, принимая решения.

Типичные задачи продуктового аналитика

• Анализировать поведение пользователей с целью поиска «точек роста» и «узких мест» в продукте; Искать точки роста в Customer Journey Map;
• Проверка аналитических гипотез и проведение root-cause анализа;
• Работать с Big Data;
• ML в продуктовой аналитике;
• Проводить A/B эксперименты;
• Правильно доносить результаты анализа до продуктовых менеджеров (Executive Summary);
• Разрабатывать новые продуктовые метрики и анализировать динамику;
• Работать над увеличением эффективности процесса сбора данных, добавление новых кликстрим-событий в продукт (Event Streaming Processing, ESP);
• Создавать дашборды для мониторинга и анализа ключевых метрик продукта (Power BI, Tableau, Qlik Sense, Metabase, Grafana);
• Решать нетривиальные задачи в условиях неполных данных;
• Выбирать нужный способ оценки данных – аналитика, исследования или использование внешних данных;
• Строить аналитические отчеты по продукту, воронке, LTV, оттоку базы, сегментации юзеров;
• Анализ инкрементального эффекта от введения/разработки новых продуктов/фичей;
• Создание экономических моделей/юнит экономики программы лояльности и сценариев удержания пользователей;
• Анализ рынка и спроса, анализ конкурентов.

KPI и показатели продуктов

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

Рост метрик, обеспечивает в конечном итоге достижение KPI и, соответственно, по метрикам мы можем определить как мы продвигаемся к бизнес-целям. Рассмотрим пример бизнес-метрик электронной коммерции:

Видео по разделу

Основы Юнит-экономики в продукте

Что такое Юнит-экономика?

Юнит-экономика (Unit-economics) — это создание бизнес-модели через призму одной транзакции или одного клиента. Позволяет быстро и на неполных данных понять, прибыльна или убыточна бизнес-модель.

Что нужно знать, чтобы рассчитать unit экономику?

Средние показатели доходов и расходов

• В доходах учитываем выручку, полученную в среднем от одного покупателя.
• В расходах — переменные расходы, которые нужны для выполнения заказа клиента (при этом постоянные расходы не считаются).

Юнит-экономика позволяет ответить на вопросы:

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

Где применима Юнит–экономика?

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

Небольшой пример расчета юнит-экономики

Показатели и направления деятельности

Еще одна карта юнит-экономики (источник https://vc.ru/finance/61504-vsya-yunit-ekonomika-v-odnoy-infografike)

Customer Profitability

Юнит и бизнес-модель

Юнит – минимальный атом ценности, который продаем. Имеет цену и единицу измерения

Пример
Суть идеи: uber для выгула собак
Юнит1 — кому продаем: 10 прогулок с собакой за $100/месяц, по часу
Юнит2 — у кого покупаем: время выгульщиков собак, $5/час

В зависимости от юнитов — 5 базовых типов бизнес-моделей

1. «Прямая продажа». Покупаем и продаем тот же самый юнит без изменений. Покупаешь готовый продукт/услугу дешевле, продаешь дороже.
2. «Производство». Покупаем одни юниты, преобразовываем – продаем другие. Покупаешь сырье/информацию – преобразовываешь, применяешь технологии и т.п., производишь и далее продаешь.
3. «Реклама». Юниты – показы/клики/заявки/аудитория. Привлекаем аудиторию и дальше, зарабатываем на рекламодателях, по схемам: плата за размещение или плата за клики или плата за заявки и т.п.
4. «Площадка» — сводим покупателей с продавцами и зарабатываем на комиссии с продаж, либо берем деньги за размещение.
5. «Сообщество» — собираешь сообщество/базу клиентов, людей и дальше ее разными способами монетизируешь, рекламой, продажей продуктов и т.п. Продаешь разные юниты – одной и той же базе людей.

Цель расчета юнит экономики понять что мы масштабируем: прибыль или убыток?

(«Операционная прибыль на 1 клиента» — «Затраты на привлечение 1 клиента») > 0

Операционная прибыль на 1 клиента

(Средний чек — Затраты на реализацию) * Среднее число продаж на одного клиента — Затраты на первую продажу

или

(AvPrice — COGS) * APC — 1sCOGS

• Cost of Good Sold (COGS) — Себестоимость продажи, показывает наши затраты, которые мы несем на каждой продаже. Важно отделять постоянные расходы, которые мы несем независимо от того есть у нас продажи или нет, от обязательных расходов, которые мы несем именно на каждой продаже. Например, если мы продаем товар, то COGS будет включать в себя затраты на покупку товара. Для b2b продаж, COGS может включать премию, которую мы выплачиваем с каждой продажи нашему менеджеру по продажам.
• Average Payment Count (APC)/Retention — среднее число продаж на одного клиента, как раз это число включает в себя повторные сделки, которые совершают наши клиенты, чем выше это число — тем лучше. Это означает, что клиенты готовы платить снова и снова.
• First sale COGS (1sCOGS) — особенные затраты на первую сделку, причем такие, которые не включены в COGS. Например, издержки на подключение клиента к сервису, тестовые периоды, выплата повышенной комиссии нашему агенту по продажам и т.п.

Затраты на привлечение 1 клиента

Затраты на привлечение 1 клиента = Стоимость посетителя / ( Конверсия в контакт * Конверсия в продажу )

или

CAC = CPC или CPA / (CR1 * CR2)

Составляющие формулы:

• Customer Acquisition Cost (CAC) — Стоимость привлечения клиента. Учитывает все затраты, которые мы понесли на получения клиента, например, мы делите весь ваш маркетинговый бюджет на всех полученных клиентов.
• Cost per Click (CPC)/Cost Per Acquisition (CPA) — Стоимость привлечения одного пользователя (посетителя). Рассчитывается путем деления всего маркетингового бюджета на всех пользователей. В отличие от CAC, CPA является метрикой принятия решения, так как не зависит от других метрик, таких как конверсия или величина потока пользователей.
• Conversion Rate (CR) — конверсия из чего-то в что-либо. Из посетителя в регистрацию, из регистрации в оплату. Из посетителя в корзину, из корзины в заказ, из заказа в оплату.
  • CR1 — конверсия в заявку, показывает на сколько целевой трафик и хорошее юзабилити
  • CR2 -конверсия в покупку, показывает как вы умеете дожимать клиента

Видео и ссылки к разделу

• https://1va.vc/webinars/yunitekonomika-i-kak-ee-poschitat.html
• https://medium.com/@ivan_matveev/конспект-видео-юнит-экономика-или-поиск-точек-кратного-роста-илья-красинский-da6c7e5c6bcb

A/B Тестирование. Что это такое? Обзор инструментов

Что такое A/B Тестирование

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

Зачем нужны А/Б тесты?

Улучшить поведенческие факторы сайта
• Показатель отказов;
• Время пребывания на сайте;
• Количество просмотренных страниц.
Увеличить % конверсии сайта
Увеличить средний чек сайта
Увеличить объем продаж с сайта

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

Когда А/Б тест проводить не стоит?

Недостаточно трафика (Если конверсий в месяц меньше чем 1000, то вы еще не доросли до А/Б тестирования. Посетителей сайта будет недостаточно, чтобы провести его и получить достоверный результат.) С помощью веб-калькулятора https://tools.driveback.ru/ можно рассчитать размер выборки в каждую ветку A/B теста. Расчет необходимо производить до начала A/B теста. А также определить статистическую значимость результата A/B теста. Расчет необходимо производить после окончания A/B теста. Еще один полезный сервис: Калькулятор значимости A/B-теста https://www.evanmiller.org/ab-testing/chi-squared.html

Что имеет смысл тестировать?

Правило: 1 ГИПОТЕЗА = 1 ТЕСТ!
Заголовки
СТА (call to action — призывы к действию) на кнопках
Цвета
Формы ввода данных
Изображения, видео
Цену товара

Где проводить A/B тест?

Optimizely.com
VWO.com
Google Analytics Content Experiment
Google Optimize

Процесс A/B тестирования

Ниже приведена структура A/B-тестирования, которую можно использовать для запуска тестов:

1. Сбор данных: ваша аналитика часто дает представление о том, где вы можете начать оптимизацию. Это помогает начать с областей с большим трафиком на вашем сайте или в приложении, так как это позволит вам быстрее собирать данные. Ищите страницы с низким коэффициентом конверсии или высоким коэффициентом возврата, которые можно улучшить.
2. Определите цели. Целями конверсии являются показатели, которые вы используете, чтобы определить, является ли вариант более успешным, чем исходная версия. Цели могут быть любыми: от нажатия кнопки или ссылки до покупки продукта и регистрации по электронной почте.
3. Создайте гипотезу: Как только вы определили цель, вы можете начать генерировать идеи A/B тестирования и гипотезы: почему вы думаете, что они будут лучше, чем текущая версия. Как только у вас будет список идей, расставьте их приоритеты с точки зрения ожидаемого воздействия и сложности реализации.
4. Создайте варианты. С помощью программного обеспечения A/B-тестирования (например, Optimizely) внесите необходимые изменения в элемент своего веб-сайта или приложения для мобильных устройств. Это может быть изменение цвета кнопки, изменение порядка элементов на странице, скрытие элементов навигации или что-то совершенно другое. Многие ведущие инструменты A/B-тестирования имеют визуальный редактор, который облегчит эти изменения. Обязательно проверьте свой эксперимент, чтобы убедиться, что он работает как положено.
5. Запустите эксперимент: начните свой эксперимент и ждите посетителей! На этом этапе посетители вашего сайта или приложения будут случайным образом назначены для контроля или изменения вашего опыта. Их взаимодействие с каждым опытом измеряется, подсчитывается и сравнивается, чтобы определить, как каждый из них выполняет.
6. Анализ результатов. После завершения эксперимента самое время проанализировать результаты. Ваше программное обеспечение A/B-тестирования представит данные эксперимента и покажет разницу между двумя версиями вашей страницы и наличием статистически значимых различий.

Ошибки A/B-тестирования

• Ошибка 1: Рано делаем выводы на небольшом количестве данных
  Как решить проблему: заранее рассчитать, сколько наблюдений нужно собрать, чтобы получить достоверный результат
• Ошибка 2: Не учитываем разнородность выборок, либо незнаем, что она существует
  Как решить проблему: перед запуском А/Б-теста провести А/А-тестирование – не должно быть статистически значимой разницы в результатах
• Ошибка 3: Запуск нескольких тестов на одну и ту же аудиторию
  Как решить проблему: Проводим тесты последовательно друг за другом. Не даем аудитории пересекаться

Работа с продуктовой командой

Методологии управления проектами

• Гибкие методологии разработки (Agile) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.
• Scrum — фреймворк, который описывает права, роли и мероприятия, при это опирается на принципы, помогающие людям выполнять свои задачи при наличии минимума правил и ограничений.
• Waterfall model — модель процесса разработки программного обеспечения, в которой он выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
• Модель Кеневин — система, которая помогает принять решение при коллективных обсуждениях, особенно в тех случаях, когда необходимо учесть сложные аспекты проблемы. В основе модели лежит распределение проблем по четырем областям: сложность, упорядоченность, хаос, порядок.
• Фича — русифицированный вариант произношения английского слова feature (произносится «фиче», ударение на «и»). Это слово можно перевести как «особенность, характерная черта».
• Процесс — совокупность взаимосвязанных действий, преобразующих входящие данные в исходящие.
• Бизнес — в контексте лекции речь идет о заказчике продукта.
• Релиз — этап публичного выпуска программного обеспечения называется релизом. После выпуска программное обеспечение обычно называется «стабильным выпуском». Формальный термин часто зависит от метода выпуска: физических носителей, онлайн-версии или веб-приложения.
• Фреймворк — программная оболочка, позволяющая упростить и ускорить решение типовых задач, характерных для данного языка программирования.
• Программное обеспечение — программа или множество программ, используемых для управления компьютером.
• Требования к продукту — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.

Требования могут выражаться в виде текстовых утверждений и графических моделей.

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

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

Предпосылки появления гибких методологий

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

Проблемы разработки:

• Сложность задач. Процессы и задачи постепенно усложняются.
• Ненужные задачи. Команда делает фичи, которые не нужны заказчику или не используются конечными пользователями.
• Стоимость внедрения изменений. Если внесение изменений в продукт стоит дорого, вам определенно нужен Agile.
• Непрозрачный процесс. Если вы не понимаете, насколько укладываетесь в график разработки продукта или на разных уровнях нет единого понимания, что вы делаете, вам определенно нужен Agile.
• Постоянные изменения требований. Большинство продуктов доходят до стадии релиза не в том виде, в котором описывались изначально. Часто на различных этапах разработки команда или бизнес осознают, что нужно что-то добавить, изменить или убрать. Если в вашем проекте всё именно так — внедряйте Agile.

Принципы Agile

1. Наивысший приоритет — удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения, чтобы обеспечить заказчику конкурентное преимущество.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение — наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота (искусство минимизации лишней работы) крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль работы.

Agile — культура, основанная на доверии. Его можно только принять и понять. Нельзя его внедрить, как нельзя внедрить любовь к музыке, искусству или спорту.

Как это работает?

1. Получаем требования от заказчика.
2. Выделяем небольшую часть задач и делаем их.
3. Получаем обратную связь по проделанной работе.
4. Повторяем процесс.

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

Зачем внедрять Agile?

Если в проекте много неизвестных, вам определенно нужен Agile.

Разобраться в необходимых фреймворках, подходах и инструментах вам поможет модель Кеневин.

Модель Кеневин (Cynefin Framework)

Модель Кеневин — система, помогающая нам выбрать методологию, особенно когда необходимо учесть сложные составляющие проблемы. Систем всего 4.

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

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

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

Хаотичная система
Разработка решения в экстренной ситуации, нестабильные системы. Нужно применять быстрые решения, которые обычно выходят за привычные рамки. Данные системы — большое поле для прорывных решений.

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

• Упорядоченные простые системы. Сюда больше всего подойдет Waterfall model.
• Упорядоченные сложные системы. Тут лучше всего ляжет PMI, Prince2 и PMBoK (его мы не будем касаться в нашем курсе).
• Хаотичные системы. Любые методологии разработки, методы и процессы.
• Запутанные системы. Гибкие методологии.

Мотивация команды

Типы команд

Что мотивирует

Типы задач

Управление проектами на принципах бережливости (Lean PM)

Бережливое производство (lean production/manufacturing) — концепция управления, основанная на постоянном стремлении к устранению всех видов потерь.

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

Потери (wastes) – любые действия или бездействие, которые не создают конечной ценности для клиента

Бережливость в проектной работе

Бережливость – это улучшение качества путем устранения потерь на всех фазах управления жизненным циклом проекта:

• Инициации
• Планирования
• Исполнения
• Мониторинга и контроля
• Завершения

Принципы бережливости для проектов

• Выделение и устранение потерь
• Развитие и обучение
• Своевременное принятие решений
• Быстрая реализация
• Делегирование подчиненным
• Опора на профессиональную этику
• Решения на основе целостной картины

Основы kanban

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

Основы Kanban

• Визуализируется процесс выполнения задач (канбан доска)
• Задаются ограничения на WIP/НЗР (work in progress/незавершенная работа) на каждом этапе рабочего процесса
• Замеряется среднее время выполнения задачи на каждом этапе и оно оптимизируется для повышения эффективности всего процесса
• Нет лимита времени по итерациям
• Нет оценок трудоемкости
• Нет ролей

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

• Как только попадает обращение, ей присваивается статус «Новая» и она попадает в самую левую колонку.
• Далее первая линия занимается приемом и оформлением обращений (стикер или электронное обращение перемещается правее в колонку «1ая линия»). WIP первой линии — количество доступных сотрудников на линии, если обращение оформляется вручную операторами.
• На второй линии находятся специалисты (эксперты, аналитики, технологи), кто может оказать экспертную поддержку (колонка «2ая линия»). WIP второй линии — количество доступных сотрудников-специалистов.
• Если вторая линия не может решить проблему, то обращение переводится на 3ю линию (колонка «3я линия»), на которой работают технические специалисты (разработчики, администраторы, тестировщики). WIP третей линии — количество доступных разработчиков.
• После того, как обращение закрыто, оно переводится в «Завершено».

Scrum vs Kanban

У Kanban’а нет обязательных ролей, ритуалов, артефактов (кроме Kanban-доски). Длительность итераций в Kanban не ограничена. Когда выпускать очередной релиз решает релиз-менеджер. Результат итерации — не обязательно инкремент, то есть конечный продукт, который выполняет определенную бизнес-функцию.

Этапы создания продукта

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

Осознание потребностей

Рассмотрим пирамиду стратегии продукта:

Миссия описывает бизнес компании, ее цели и подход к достижению этих целей.
Видение описывает желаемую будущую позицию компании. Видение продукта должно являться для команды разработки продукта «северной звездой», ориентиром.

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

Самой известной является миссия Google
«Организовать мировую информацию и сделать ее общедоступной и полезной»

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

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

Кратко:

Видение обрисовывает в общих чертах цель и преимущества, которые должен принести продукт и служит «северной звездой» — стабильной в течение многих лет и направляющей всю разработку продукта.
Стратегия фокусируется на ценности клиента / пользователя, конкурентной позиции (дифференциация и конкурентное преимущество) и на том, как создается ценность для бизнеса (бизнес-модель и циклы роста).
Цели высокого уровня, вытекающие непосредственно из стратегии, устанавливаются и пересматриваются в ежеквартальном процессе ОКР.
Метод OKR – это агрессивная техника целеполагания и планирования. Суть в том, что для каждой заданной цели должен существовать ряд измеряемых результатов (метрик), которые бы показывали, насколько достигнута цель. Ключевая особенность метода состоит в том, что эти цели должны быть принципиально недостижимы. Если цели достигнуты на 100%, они считаются недостаточно амбициозно поставленными, и в планировании на следующий период нужно это учесть. Оптимальным будет выполнение 60-75% результатов из каждой цели.
Тематические дорожные карты полезны, потому что они помогают сохранить ваш продукт от ползучести функций, когда заинтересованные стороны постоянно хотят добавлять новые функции. Использование тем позволяет решить, добавлять ли функцию, исходя из того, связана ли она с темой. Если это не так, вы можете отложить его до более поздней версии.

Метод «Модель Кано»

Модель Кано — это теория разработки продукта и оценки удовлетворенности клиентов, разработанная в 1980-х годах профессором Норияки Кано. Он классифицировал потребительские предпочтения в пять категорий. Модель используется для оценки влияния качеств продукта на удовлетворенность потребителей. А также для упрощения и оптимизации процесса потребления.

Назначение метода

Применяется для выработки стратегии организации и решения задач обеспечения удовлетворенности потребителей. Модель Кано — один из инструментов управления качеством.

Цель метода

Определение и распределение всего диапазона потребностей (требований) потребителей по приоритетам.
Разделение требований потребителей по составляющим профиля качества.

Суть метода

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

Помогает выявить приоритетные потребности.

5 категорий модели Кано

Определение категории, в которую попадет та или иная функция продукта, зависит от уровня ее функциональности и той удовлетворенности, которую ощущают пользователи при наличии этого свойства в продукте.

В зависимости от двух параметров (функциональность и удовлетворенность), атрибут продукта будет помещен в одну из следующих категорий:

• Обязательные (Must-be, M): пользователи считают необходимыми для того, чтобы продукт работал так, как от него ожидается;
• Одномерные (One-Dimensional, O): атрибуты производительности;
• Привлекательные (Attractive, A): эти атрибуты не являются существенными для выполнения продуктом своей основной функции, но они определенно добавляют ему ценности;
• Неважные (Indifferent, I): Это те функции и атрибуты продукта, которые, проще говоря, пользователя мало волнуют или не волнуют вовсе; функционал, который никак не влияет на уровень удовлетворенности клиента продуктом;
• Нежелательные (Reverse, R): свойства продукта, которые по мере роста своего количества уменьшают удовлетворенность пользователя продуктом.

Что такое управление продуктом?

«Работа менеджера заключается в поиске ценного, удобного в использовании и целесообразного продукта»
Марти Каган, партнер-основатель Silicon Valley Product Group

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

Управление продуктом с точки зрения Бизнеса

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

Управление продуктом с точки зрения  Опыта пользователя (UX)

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

Управление продуктом с точки зрения Технологий

Невозможно дать определение тому, что создаешь, не зная, как это делается. Конечно, от продакт-менеджера не требуется знание программирования, но для принятия правильных решений важно, чтобы он понимал технологии, а главное – трудозатраты. В Agile это обязательно, в этом случае продакт-менеджер больше времени проводит с разработчиками, чем с кем-либо еще: надо говорить с ними на одном языке.

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

Роль продакт-менеджера

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

Зачем продакт-менеджеру разбираться в бизнесе, пользовательском опыте и технологиях?

Найлан Пейрис, вице-президент по продукту и развитию Transferwise, считает, что продакт-менеджер должен «делать все необходимое».

Таня Кордри, бывший директор по цифровым технологиям Guardian, добавляет: «Лучшее в позиции продакт-менеджера – многофункциональность, но от нее и больше всего беспокойства. Приходится разбираться в стратегиях, вдохновлять людей и видеть долгосрочные перспективы. В то же время надо добиваться результатов».

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

Готовую идею продакт-менеджер доносит до коллектива. Люди должны поверить в продукт и буквально влюбиться в него. Если энтузиазма не возникло, то концепция неинтересная. В худшем случае это означает неясную связь между видением и продуктом или то, что менеджер занимает не свое место. Распространение видения – первая общая функция менеджера и лидера. Задача лидера – создать чувство причастности и повести за собой, а менеджера – обеспечить коммуникацию и необходимые ресурсы. Команда должна понимать концепцию лидера и действия менеджера. Успех менеджера, следовательно, и продукта зависит от каждого члена команды – от сотрудников отдела продаж до разработчиков.

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

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

Когда это наконец происходит, менеджер тщательно изучает данные, лично опрашивая клиентов об их пользовательском опыте. Решил ли продукт их проблемы? Очевидна ли пользователям ценность продукта? Готовы ли они за него платить? Ответы получены – и все начинается сначала.

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

Эллен Чиза, вице-президент по продукту в Lola, подчеркивает важность переключения контекста: «Менеджер продукта всегда попеременно смотрит то на общую картину, то на частности».

Мина Радхакришнан, первый директор по продукту Uber, говорит: «Многие думают, что продакт-менеджер – кто-то вроде генерального директора или капитана корабля. Создается впечатление, что он принимает решения и приводит все в действие. Но продакт-менеджер сообщает всем остальным: “Вот как это должно работать и вот почему”».

«Как связующее звено, менеджер удерживает вместе все функции и роли сотрудников, говорящих на разных языках, – добавляет Кен Нортон, партнер по продукту в GV (бывшая Google Ventures). – Он, как универсальный переводчик из “Стартрек”, обеспечивает коммуникацию между всеми группами. Если команды действуют несогласованно, то продукт не станет успешным». Это лишний раз напоминает о главной сложности этой профессии: не столько важны технические навыки, сколько умение убеждать, вести переговоры, внятно излагать концепцию и общаться.

Это важный навык для лидера вообще и лидера в сфере продукта в частности, но о нем иногда забывают. Предприниматель и автор бестселлеров Сет Годин отмечал, что навык общения часто недооценивают: «Считается, что это черта характера. Но лидеру без нее никуда. Обаяние, усердие и вовлеченность – все это навыки. И, хотя их отделяют от профессиональных, за которые принимают на работу и выдают диплом об образовании, давайте все же называть все это “навыки”».

Ценообразование продуктов

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

Взято отсюда https://t.me/temno

1. Free Trial Pricing. Бесплатные пробные версии. Бесплатность нужна не для того, чтобы хоть как-то втюхать свой продукт — а чтобы дать ему войти во вкус его использования. Высший пилотаж — сделать так, чтобы он накопил в сервисе какие-то свои данные или наработки, которые жалко будет терять или геморройно переносить. Пример — Dropbox.
2. Prestige Pricing. Премиальная цена. Намеренно установить цену выше рынка, чтобы подчеркнуть его качество и эксклюзивность. Объем продаж может оказаться и не таким большим, но маржа принесет радость. Пример — айфоны, в которых Эппл имеет примерно 12% рынка в штуках, 50% рынка в выручке и 70% в прибыли.
3. Cost-plus pricing. Когда вы просто добавляете к бюджету на создание и продажи фиксированную маржу. Этот способ гораздо лучше, чем продавать себе в убыток, боясь не попасть в рынок. Распространенная ошибка — не закладывать в косты стоимость продаж (включая маркетинг и обслуживание продаж). Пример — студии заказной разработки.
4. Value-based Pricing. Устанавливать цену на продукт в зависимости от то ценности, которую вы даете потребителю. Проблема в том, что ценность продукта в глазах создателей обычно сильно завышена. Но это, по крайней мере, хороший способ проверить гипотезу ценности в бою. Хороший вариант для начинающих стартапов — либо получить холодный душ, либо сорвать джекпот.
5. Captive Pricing. Основной продукт предлагается по цене ниже рынка. Но обновления и дополнения стоят отдельных денег. Хорошая, но опасная стратегия. Если урезать возможности базового продукта, то им не будут пользоваться. Если сделать его приемлемо функциональным — платные дополнения могут и не понадобиться.
6. Skim Pricing. Начальная цена устанавливается высокой, но с течением времени она снижается. Пример — компьютерные игры, книги, фильмы.
7. Underbidding pricing. Поставить такую цену на свой продукт, чтобы вышибить с рынка конкурентов. «Немного дешевле» тут не работает. Например, купонные сервисы знают, что скидки меньше 50% не дают взрывного эффекта. Нужно либо кардинально снижать цену, либо делать это бесплатным и зарабатывать на другом. Пример — Robin Hood, установивший нулевые комисси при торговле акциями или Revolut с нулевыми комиссиями за обмен валюты.
8. Flank pricing. Обход конкурента с флангов. Одновременный выпуск двух продуктов — один дешевле конкурента, другой — дороже. Заботящиеся о цене выбирают более дешевый продукт, о престиже — более дорогой. Конкурент со средней ценой попадает в искусственно созданную черную дыру спроса. Пример — Johnnie Walker с черной и красной этикеткой.

В общем, выставление цены на свой продукт — это вопрос стратегический. Обычные для стартапов игры — «давайте поставим такую же цену, как у конкурента» или «давайте будем на 10% дешевле» — тут не работают.

Что советую почитать и посмотреть

• https://medium.com/product-design/10-фишек-разработки-продуктов-которым-я-научился-у-джейсона-фрайда-6e32bc33a0b0
• https://byndyusoft.com/productanalysis
• https://spark.ru/startup/546dae36cfa4a/blog/12070/7-instrumentov-masshtabirovaniya-startapa
• https://www.youtube.com/playlist?list=PLEs8EuAPI73Bs0R9bcWYtPJ94aWVrPYqd — Управление продуктом. Школа менеджеров Яндекс

Список используемых источников для подготовки статьи

1. https://netology.ru/blog/product-or-project
2. https://habr.com/ru/company/hygger/blog/427537/
3. https://tceh.com/post/product-in-a-hay/
4. https://spark.ru/startup/adn-digital-studio/blog/30355/razrabotka-proekta-vs-razrabotka-produkta-v-chem-raznitsa
5. https://vc.ru/life/95844-kak-zapustit-it-produkt-za-dve-nedeli-bez-golovnoy-boli
6. https://www.producttalk.org/2014/11/the-5-components-of-a-good-hypothesis/
7. https://t.me/temno
8. https://medium.com/@memus/5-приёмов-консультантов-mckinsey-которые-помогут-менеджеру-продукта-e2c7474122cf
9. https://news.itmo.ru/ru/news/7992/
10. https://vc.ru/flood/8728-hadi-growth
11. https://dou.ua/lenta/articles/how-to-validate-hypotheses/
12. https://habr.com/en/post/326448/
13. https://vc.ru/flood/28728-formirovanie-gipotez-zapusk-a-b-testa-i-analiz-ego-rezultatov
14. https://zen.yandex.ru/media/id/5be962b991763e00a9cc755a/9-iz-10-uspeshnyh-startapov-ispolzuiut-etu-proryvnuiu-tehnologiiu-5bec05d0fa8aae00abb5b0e1
15. https://medium.com/@mobileanalytics6/11-лучших-инструментов-для-аналитики-приложений-ios-в-2017-году-8ad874e2232d