Создание продукта должно идти от простого к сложному. Поэтому отчасти аджайл стал так популярен. Вы не можете сразу спроектировать сложную систему, потому что такая попытка обречена на провал. Аджайл это путь мелких провалов, когда вы пробуете что-то и учитесь. Каждый новый проект или «фичу» вы делаете чуть лучше чем предыдущий, просто потому что вы уже совершили сотни ошибок.
Так с чего начинается продукт? С идеи? Нет. Продукт начинается с проблемы.
Вы должны чётко понимать проблему, которую хотите решить. Потому что вы нанимаете «цифровой продукт» для решения проблем.
Есть проблемы бизнеса, есть проблемы пользователей. И именно проблемы, расположенные в таком порядке, определяют дизайн продукта.
Сформулировав проблемы, вы создаете краткое описание проекта, с которым должны ознакомиться все заинтересованные лица (люди, принимающие финансовые риски проекта).
В кратком описании проекта вы должны описать то, для чего проект вообще нужно создавать: какие проблемы он должен решить, и какие бизнес-цели ставятся перед проектом, какие меры для этого следует предпринять, то есть стратегию продукта.
Исследование проблемы
Изучение бизнес-модели клиента
Определение чего «клиент» хочет достигнуть - каких финансовых показателей.
Определение того, что мешает ему достигнуть этих показателей сейчас? Какие болевые точки есть в процессе?
Выработка решения, которое может устранить эти проблемы с учетом ограничений — сроков, бюджета клиента
Реализация решения
Разработка продукта — сайта или приложения.
Запуск продукта
То есть, клиент приходит с неоформленной идей и на выходе получает итеративно
Определение проблемы, краткое описание решения (результат исследовательской фазы)
Готовое решение — результат разработки и запуска решения.
Целью деятельности коммерческой организации — делать деньги. То, как организация зарабатывает деньги показывает ее денежный поток. Поэтому изучение денежного потока является критически важным этапом исследования. Без понимания того, что и почему приносит фирме деньги, не возможна эффективная разработка программных продуктов и разработка стратегий и инициатив.
Итогом данного исследования этапа является модель денежного потока организации. Модель денежного потока может дать экономист, отвечающий за финансовые результаты. Модель денежного потока даст ответы на то, что и почему приносит прибыль организации. Лучше, если это будет «вариативная» модель в табличном процессоре, куда вы сможете подставлять различные входные значения, моделируя различные результаты.
Следующим этапом после получения модели денежного потока является формулирование метрик. Вы должны понимать, какие финансовые показатели имеют значения для клиента. Как правило, ключевой метрикой денежного потока является Чистая приведенная стоимость (NPV). Данный показатель учитывает временную стоимость денег и показывает объем валовой прибыли, приведенный к сегодняшнему дню. Метрики не обязательно могут быть привязаны к денежному потоку. В деятельности различных подразделений бизнеса могут быть иные метрики — уровень отклика в деятельности контакт-центра, уровень просрочки и т. д. Все они в итоге влияют на итоговый денежный поток, но могут быть промоделированы независимо для последующего включения в общую картину.
От формулирования метрик мы переходим к формулированию гипотез относительно того, что является узким местом в денежном потоке клиента. Понимание узких мест клиента критически важно для формулирования гипотез.
Для первичного определения узких мест вы можете запросить качественный опрос «менеджеров» фирмы. Менеджеры фирмы могут иметь собственные гипотезы относительно узких мест в продажах или обслуживании. Это могут быть сведения о определенных сегментах клиентов, вызывающие опасения, существенные проблемы обслуживания и т. д.
После первичной диагностики проблем мы переходим к статистической проверке гипотез. Данный этап выполняется аналитиками данных, в ходе которого строятся линейные регрессии, проводится оценка статистической значимости факторов и применяются иные «продвинутые» методы исследования.
Данный пример демонстрирует совместную деятельность команды по диагностике и решению экономических проблем
Роли:
PO - Владелец продукта
PM - Менеджер продукта
DS - Аналитик данных
EC - Экономист
PO: Сегмент таксистов не рентабельный. Как нам решить эту проблему? Если мы не найдем решение, мы будем вынуждены прекратить кредитование данного сегмента та.
PM: Давайте проверим эту гипотезу. Для начала мы должны удостовериться, что дефолтность таксистов отличается от аналогичной выборки клиентов не-таксистов.
DS: (жонглирует цифрами) Нам нужна репрезентативная выборка из допустим...N клиентов.
PM: К сожалению, нас нет признака "таксист" в данных. Могут ли менеджеры заполнить данный признак ретроспективно по предоставленной выборке?
PO: Думаю это возможно. Должны ли менеджеры фиксировать собственное суждение или лучше воспользоваться сервисом X и Y для определения сегмента таксист?
PM: Лучше заполнить все варианты, чтобы определить статистическую значимость различных вариантов идентификации
Спустя некоторое время
DS: На выборке размером N все факты больше похожи на шум. Можем ли вы увеличить выборку до размера M?
PO: Да, менедежры могут заполнить и такую выборку.
Спустя еще некоторое время
DS: Мы сформировали 2 бизнес-правила, позволяющие уменьшить просрочку по сегменту таксист (перечисляет условия)
PM: Как мы можем выбрать из двух правил лучшее?
EC: Я построил денежные потоки с учетом правила А и Б. При ставке дисконтирования Z правило А экономит X млн рублей по ретро-расчетам.
PM: Применяем бизнес-правило A и открываем кредитования сегмента таксисты?
PO: Согласовано.
В данном примере, менеджер продукта формулирует нулевую гипотезу о том, исходная предпосылка (дефолность таксистов выше по сравнению с аналогичной выборкой не таксистов) не верна и использует статистический аппарат для ее опровержения на фактических данных. Если нулевую гипотезу не удается опровергнуть статистически, она считается верной и проблема не требует «решения». Если подозрения не исчерпываются проведенным анализом, возможно следует взглянуть на проблему под другим углом, поискать иные данные.
Для проверки гипотезы о равенстве долей «просрочников» в двух совокупностях (таксисты и не таксисты) аналитик данных (DS) использовал z-критерий. См. Раздел «Параметрические критерии» в книге «Статобработка экспериментальных данных в MS Excel» (Томск, 2018).
Здесь мы проводим аналогию с методиками «доказательной медицины», где данный подход используется повсеместно. В приведенном примере, в виду опровержения нулевой гипотезы и необходимости выбора из двух конкурирующих решений, менеджер продукта переходит к задаче поиска решения с учетом максимизации эффекта на денежный поток.
Разумеется, ретро-тест, приведенный в данном примере имеет некоторые ограничения, и может не учитывать существую структуру продаж.
В некоторых случаях, когда эффект принимаемых решений можно оценить в перспективе нескольких месяцев, можно использовать разные конкурирующие стратегии, для того чтобы оценить финансовые результаты по текущей структуре продаж и таким образом определить наилучшую стратегию.
Одним из наиболее простых вариантов решения является доработка бизнес-правил (правил, зарабатывающих или экономящих бизнесу деньги). Однако за видимой простотой бизнес-правила могут крыться сложности получения данных для его применения.
Например, итогом построения линейной регрессии может стать понимание того, как вариационные параметры сделки (или иной сущности моделирования) влияют на итоговые показатели бизнеса.
Данные исследования могут послужить основой для формулирования стратегий продаж (коммуникаций, проверок и иных видов исследуемых действий), эффективность которых также должна подтверждаться статистическими тестами (например, z-тест)
Таким образом, основываясь на знаниях денежного потока клиента, знаниях вариационных параметров, влияющих на итоговые результаты, на выходе вы формулируете набор стратегий, эффективность — статистическую и практическую значимость которых вам предстоит подтвердить ретро-тестами и практически.
Как правило, разработка новых решений - это не разработка всего бизнес-процесса заново. За одну итерацию можно изменить лишь небольшую часть бизнес-процесса. Поэтому вы начинаете с описания существующего бизнес-процесса, используя методики пользовательских историй или нотацию бизнес-процессов, что по большому счету одно и то же. И там и там вы описываете «этапы» и последовательность выполнения работ, просто называете это историями или активностями.
Именуя активности, вы должны придерживаться стиля CTA (Call-to-action). Именно это название пользователь увидит у себя в рабочем листе или оповещении. Это может быть задача «Загрузить ПТС» (где пользователь видит элемент управления для загрузки и просмотра файла), «Подписать договор» и т.д.
Следующим этапом после описания процесса является определение места «врезки» нового продукта. Вы меняете наиболее существенную часть, «MVP продукта» — минимальную часть процесса, которую можно запустить, чтобы получить обратную связь от пользователей процесса или экономический эффект.
Каждой активности процесса соответствует некоторый интерфейс, или сервис. Вы не должны беспокоиться о том, где и как это будет реализовано, сейчас это не важно. Ваш процесс будет разбит на изолированные предметные области инженерами.
Для того, чтобы они могли это сделать, вы должны описать действия с точки зрения пользователя. Это можно сделать:
Черновиками интерфейсов и прототипированием совместно с фронт-разработчиком, например в https://uniforms.tools/
Написанием критериев приемки.
Ядро стратегии (см. книгу «Хорошая стратегия, плохая стратегия») состоит из 3 ключевых пунктов:
1. Постановка диагноза, определяющего либо объясняющего природу проблемы.
При помощи исследований пользователей и анализа данных вы распознаете те аспекты ситуации, которые критически важны для решения задачи, что во много раз упрощает невероятно сложную реальность.
2. Направляющая политика для решения проблем
Общий подход, выбранный для преодоления препятствий, выявленных в процессе диагностики. Должен описывать общие детали реализации продукта.
3. Согласованные меры, необходимые для реализации направляющей политики.
Дорожная карта, последовательное выполнение которой приводит к результату.
Жизненный цикл продукта, согласно Хенрику Книбергу:
Самый ранний продукт, доступный для тестирования
Самый ранний продукт, который можно использовать
Самый ранний продукт, который нравится пользователям
Подход MVP - это подход, основанный на гипотезах . Вместо того, чтобы думать о своем MVP как о продукте, лучше думать об этом как о обучающем упражнении. У вас есть гипотеза, и ваш MVP (самый ранний тестируемый продукт) - это один из способов (но не единственный) проверить эту гипотезу.
Создание MVP — не единственный способ проверки гипотезы. Иногда может быть достаточно визуального прототипа.
Одной из ошибок, допускаемых при создании продукта, является создание продуктов и услуг на основе прототипа.
Как напомнил нам Фредерик Брукс-младший более 35 лет назад в своей основополагающей книге «Мифический человеко-месяц»:
«В большинстве проектов первая построенная система практически не используется. Она может быть слишком медленной, слишком большой, неудобной в использовании или всеми тремя. Нет альтернативы, кроме как начать сначала, умнее, но умнее, создать переработанную версию, в которой эти проблемы решены. Утилизация и переделка могут быть выполнены за один раз или по частям. Но опыт работы с большими системами показывает, что это будет сделано. Когда используется новая концепция системы или новая технология, нужно построить систему, которую можно выбросить, потому что даже самое лучшее планирование не настолько всесторонне, чтобы сделать все правильно с первого раза».
Это так же верно сейчас, как и тогда, когда Фредерик впервые написал это в 1970-х годах. Подобно строительству дома на песке, создание продукта на основе MVP, скрепленного веревкой, липкой лентой и достаточным объемом технического долга, чтобы потопить Титаник, никогда не является хорошей идеей. Относитесь к своему MVP как к учебному упражнению и откажитесь от кода, как только вы узнаете достаточно, чтобы двигаться дальше.
Гипотеза - это в основном предположение. То, что кто-то считает правдой. Гипотеза помогает вам подтвердить или опровергнуть предположение. Они либо доказаны, либо опровергнуты исследованиями и экспериментами.
Результаты этих экспериментов говорят вам, действительно ли вы понимаете поведение своего пользователя и насколько точно вы понимаете потенциал или подводные камни своей концепции.
Каждая проверенная гипотеза может дать новое понимание для будущих этапов разработки вашего продукта. Вот почему мы считаем, что их формирование на основе исследований и доказательств имеет основополагающее значение для дизайна продукта, ориентированного на клиента.
Цель проверки гипотез — верификация любых, даже труднодостижимых решений, на которые невозможно положиться сразу.
Достоинства проектирования на основе гипотез:
Получить поддержку команды
Каждый может участвовать в написании гипотез, поэтому каждый чувствует ответственность и вовлеченность. Это означает, что идеи не нужно «продавать» или «оправдывать» в дальнейшем, поскольку все настроены на одну и ту же волну.
Меньше бумажной работы
Поскольку вы обсуждаете гипотезы вместе, вам нужно будет создавать меньше документации.
Приоритетная дорожная карта
Проектирование, основанное на гипотезах, означает, что ваша дорожная карта будет сформирована на основе доказательств.
Постоянное обучение
Даже после того, как была выпущена новая функция, вы можете использовать свои предположения для дальнейшего исследования и открытия новых идей. Легко найти проблемы с дизайном, которые было бы трудно обнаружить одним только «дизайнерским глазом».
Функции, которые нужны пользователю.
Проектирование, основанное на гипотезах, означает, что пользователи получают функции, которые соответствуют назначению и решают реальные потребности.
Для написание проектной гипотезы вы начинаете с простого утверждения и помещаете его в структуру, например в такую:
В первой части гипотезы «Мы считаем, что…» вы делаете обоснованное предположение о поведении пользователя.
Следующая часть «Итак, если мы…» - это действие, то, что мы хотим, чтобы пользователь сделал или думаем, что пользователь собирается сделать.
«Тогда мы увидим…» - вот где указывается ваш ожидаемый результат или мера успеха.
Далее следует выбрать наиболее подходящий тест для вашей гипотезы.
Мост Миллениум в Лондоне был первоначально открыт в 2000 году, и за один день по нему пересекли 90 000 человек, причем 2000 человек переходили по нему одновременно.
По мере того, как все больше людей переходили мост, он начал резко раскачиваться. Это движение стало хуже, поскольку все начали дружно противостоять направлению колебания. Это та же самая наука, по которой солдаты ломают ступеньку при переходе моста (см. Бротонский подвесной мост ).
Позже выяснилось, что инженеры, стоящие за проектированием моста Миллениум, представили и испытали только 160 человек, идущих по нему в любой момент времени.
Это отличный пример того, когда установка правильных критериев тестирования и проведение соответствующих экспериментов для вашей гипотезы так важны и в конечном итоге могут стоить вам больших денег (исправление этого стоит еще 5 миллионов фунтов стерлингов), если все сделано неправильно.
Первый важный шаг - решить, какой тип обратной связи вам нужен, чтобы подтвердить или опровергнуть вашу гипотезу.
Если вы тестируете новую концепцию и ваша мера успеха связана с реакцией людей, вы можете провести качественное исследование. Количественные методы исследования идеально подходят, если вам нужна обратная связь, связанная с измеримыми результатами, например, если ваша гипотеза связана с процессом регистрации или воронкой продаж.
Для приоритизации задач / бэклога продукта следует понимать проблемы, решаемые задачей и желаемые цели.
Решаемые проблемы должны соответствовать текущей стратегии компании.
Любая проблема имеет две характеристики
Вероятность/частота возникновения
Степень воздействия / масштаб последствий (с учетом обратимости)
В зависимости от данных характеристик, проблема может требовать различного уровня проработки.
Частая проблема, приводящая к необратимым последствиям требует повышенного анализа.
Редкая или обратимая проблема требует меньшего времени для анализа и проработки.
Есть всего несколько целей бизнеса верхнего уровня, и они не меняются, меняются только инструменты:
Увеличение прибыли/рентабельности
Снижение рисков
Увеличение продаж/конверсии
Снижение расходов/кол-ва человек/времени
Для приоритизации задач может быть полезным размещение их виде матрицы (см. книгу Intercom on Product Management)
Высокая стоимость Низкая ценность (крупные внутренние доработки) |
Высокая стоимость Высокая ценность (обычные элементы дорожной карты) |
Низкая стоимость Низкая ценность (небольшие внутренние доработки) |
Низкая стоимость Высокая ценность (quick wins) |
В фазе исследования продукта важную часть занимает исследование пользователей. Для того, чтобы определить рамки продукта, может быть полезным описать текущий бизнес-процесс в виде последовательности шагов или JTDB. Однако то, как пользователи выполняют задачи в текущем процессе не означает того, что ваш продукт должен механически позволять делать то же самое. Назначение процесса описания задач — понять цель выполняемых задач и найти болевые точки процесса с точки зрения пользователя.
Работа продукта начинается с того момента, когда действие пользователя переходит в его предметную область.
Продукт, который вы создаете, решает проблему пользователя — «выполняет работу». Бизнес или пользователи покупают, то есть «нанимают на работу» ваш продукт, чтобы он сделал свою работу.
Начинающий менеджер продукта может задать вопрос: что первично — требования бизнеса к продукту или цели бизнеса? Цели первичны, они не меняются от продукта к продукту - это увеличение прибыли, снижение риска и т. д. Бизнес покупает не "выполненные требования", а достигнутые цели. Если требования бизнеса не ведут к достижению целей или ведут не эффективно, этот вопрос должен решаться в форме диалога.
Не достаточно провести опрос пользователей о выполняемых им работах и дать им инструмент для выполнения работ. Менеджер продукта должен дойти до первопричины выполняемых работ. Одним из инструментов фиксирования причин выполняемых работ является Job To Be Done.
Суть подхода JTBD: Фокусироваться на том, чего стремится достичь бизнес или пользователь в определенных обстоятельствах. Это и называется job to be done — «работа, которую надо выполнить».
Job To Be Done = задача + контекст.
Контекст задачи важен потому, что сама по себе задача пользователя не имеет ценности. Задача приобретает ценность, когда мы ее выполняем для достижения прогресса в определенной ситуации.
Для получения перечня задач пользователей следует задавать направляющие вопросы.
Интервью может быть организовано кем угодно в команде (менеджером продукта, разработчиком, QA-инженером). Обратная связь пользователя, приводящая к изменениям в продукте, должна валидироваться на данных для того, чтобы понимать масштабность проблемы.
Ваша первоочередная задача — понять, чего хочет достичь пользователь своими действиями. Вы должны задать вопрос почему столько раз, сколько это требуется для того, чтобы понять первопричину проблемы (см. технику «Пять почему»).
Вы должны проанализировать рабочий процесс, в каком контексте выполняется операция, масштаб проблемы. Если вы хотите сделать «ремонт» в отдельном бизнес-процессе, вы должны понимать, это косметический ремонт или перестройка всего процесса. Для разного масштаба действий требуются разные подходы, инструменты и средства. Вы можете избавить команду инженеров от работы с низкоценными процессами с помощью организационного изменения процесса или подхода.
Этот вопрос побуждает пользователя дать вам некоторые идеи о том, какие области нуждаются в наибольшей помощи.
Этот вопрос также может помочь вам получить информацию вас о прототипе, который вы можете создать, чтобы проверить, можете ли вы решить проблему.
Вы не должны создавать именно то, что говорят пользователи. Протестируйте прототипы, чтобы увидеть, в конечном итоге ваши проекты решают их проблему. Не просто делать то, что люди хотят.
От понимания проблемы и задач пользователя, проектирование продукта ведет вас к формулированию сущностей предметной области и их поведению.
Основа создания продукта лежит в моделировании сущностей реального мира. Поэтому понимание предметной области — ключевой навык менеджера продукта.
Описание сущностей - объектов реального мира — требует, чтобы эти объекты содержали всю бизнес логику в себе и строились исходя из того какую ответственность объекты имеют и как они взаимодействуют с другими объектами.
Модель — это информационный аналог объекта. Создавая модель, вы описываете сущности, их атрибутный состав и поведение. Описание всегда идёт от крупного плана к мелкому. Описывая сущности, вы постоянно смещаете фокус от общего плана до конкретных атрибутов и деталей поведения.
см. профильный раздел «Предметно-ориентированное программирование»
При описании сущности прежде всего нужно обозначить ее — дать ей имя. Далее мы должны описать характеристики и возможности сущности.
В описании сущности следует приводить не все ее свойства, а только существенные в данной ситуации. Описывая состав сущности, мы мысленно «разбираем» ее на части. При этом, как правило, используется такой приём: сначала называется небольшое число крупных частей, затем каждая из них «разбирается» на части поменьше и так далее.
Под состоянием сущности мы подразумеваем определённое сочетание всех или некоторых характеристик этой сущности. Среди всех возможных состояний сущности обычно выделяется такие, при достижении которых ее свойства меняются особенно существенно, так, что либо вообще становятся недоступны некоторые из его действий, либо они выполняются другим способом. Например, колесо может быть в состоянии «Накачано», «Лопнуло», корзина продуктов может быть в состоянии «Создана», «Рассчитана», «Продана».
Имена действий означают процессы, которые могут происходить с сущностью, и отвечают на вопросы «что она может делать?» или «что с ней можно делать?». Например, автомобиль можно завести или остановить. Корзину продуктов можно создать, распечатать заявку на кредит, выдать кредит.
Кроме свойств конкретной сущности, следует описать и отношения между сущностями.
Существует два основных вида отношений:
генерализация (наследование), когда мы говорим, что одна сущность является надможеством другой сущности: «Евразия — это материк», или «Магазин — это Точка продаж».
соотношение множеств, когда мы говорим «колёса входят в состав автомобиля» или «Оферта входит в состав Корзины». В таких отношениях мы должны указать вид связи: 1:1, 1:M или M:1.
Лучше всего материал данной главы усваивается в виде игры «Сущности и поведение». Суть игры заключается в следующем:
Ведущий называет каждому участнику по очереди сущность.
Участник называет несколько поведений данной сущности, например «Светофор»: может переключаться сам по программе, можно включить кнопкой зеленый свет вручную
Участник называет приемочный критерий для одного из видов поведений. Например, по шаблону «предусловие», «действия», «результат»: горит красные сигнал пешеходного светофора, пользователь нажимает кнопку на столбе, через 20 секунд зажигается зеленый сигнал светофора для пешеходов.
Для изучения отношений сущностей можно полезно задания участникам из одной общей сущности, например первый участник называет поведение сущности «автомобиль», остальные участники называют поведение вложенных сущностей «дверь», «колесо», «двигатель» и т. д.
Для понимания отношения «генерализация» следует обыграть пример, когда у нескольких сущностей появляется одно и то же поведение. Наличие общего поведения может быть причиной выделения общей, генеральной сущности. Например, в ходе игры с предметами окружающего мира, участники выяснили, что «завести» можно грузовой, легковой автомобиль или автобус. В зависимости от целей и условий моделирования, данный факт может послужить причиной выделения базовой сущности «Транспортное средство», обладающей поведением «Завести»
Моделирование - это:
построение моделей реально существующих объектов (предметов, явлений, процессов)
замена реального объекта его подходящей копией, исследование объектов познания на их моделях
Методики моделирования
Мысленный эксперимент - «разыгрывание» ситуации в воображении, основываясь на реальных сценариях поведения пользователя или клиента.
Системное мышление - возможность обобщать и распространять свой опыт, полученный в одной области, на окружающий мир.
Сценарный анализ — способность рассматривать альтернативные варианты развития событий, сравнивая их результаты.
Анализ чувствительности - оценке влияния изменения исходных параметров проекта на его конечные характеристики, в качестве которых, обычно, используется внутренняя норма прибыли или NPV
Симуляция - имитация процесса, например на ретро-данных поведения, характеристик клиентов, данных ранее заключенных сделок и т. д.
Количественный анализ необходим как для принятия решения, так и для построения математических моделей.
SQL. Самый простой доступный способ, позволяющий получить ответы на многие вопросы: сколько сделок совершается с дифференцированным графиком платежей? Какое среднее значение или медиана годовой ставки в разрезе X, Y, Z?
Линейная регрессия. Позволяет не только построить модель результирующей переменной, но и оценить степень влияния переменных по коэффициентам. Для построения простой линейной регрессии можно использовать web-интерфейс H2O.
Данные виды анализа позволяют провести раннюю диагностику проблемы, без обращения к профильным специалистам — аналитикам данных. Они являются аналогом стетоскопа в больнице. Не всегда требуется МРТ и дорогостоящие виды анализа. Анализ всегда начинается с самых простых и доступных средств.
Для управления продуктом на основе данных мы должны сформулировать метрики, которые имеют значение для бизнеса. Сначала определяем корневые метрики, интересующий бизнес, далее декомпозируем их на то, что на них влияет.
Как правило, бизнес интересует внутренняя норма прибыли. Следовательно, мы должны взять данную метрику как корневую и проанализировать, что и в какой мере влияет на данную метрику: из чего формируются прибыли и убытки денежного потока.
Так же бизнес может задать целью определенные объемы продаж для того, чтобы максимально полно использовать имеющиеся ресурсы, например капитал.
Объемы продаж складываются из первичной лидогенерации — потери на каждом этапе воронки продаж. Следовательно, увеличение продаж возможно как за счет дополнительной лидогенерации (SEO, платные лиды), так и за счет устранения потерь конверсии.
Для устранения потерь конверсии мы должны проанализировать воронку продаж и соотношение количества фактов на различных этапах воронки. Значительное падение фактов на любом этапе воронки продаж является сигналом к анализу причин данного «выпадения».
Соответствует ли метрика основным бизнес-целям? Если вы измените значение, это приведет к положительным изменениям?
Является ли значение метрик объективным? Вы можете определить формулу расчета метрики? Можно ли технически получить данные для расчета метрики?
Можете ли вы сделать что-то положительное и действенное с данными? Рассчитать мотивацию?
Метрика технически устойчива? Будет ли она актуальной через год? Поможет ли она отслеживать прогресс с течением времени?
Может ли значение метрики быть неправильно понято? Требуется ли много контекста для понимания метрики? Есть ли «отставание» метрики, затрудняющее оценку?
Единицей продаж в нашем продукте является корзина. Мы можем отметить ключевые события, в которых происходит интересующее бизнес изменение статуса корзины.
Перспективные возможности. Воронка продаж начинается с того, что посетитель на сайте изучает описание продукта или иной материал связанный с продуктом, где мы можем предположить интерес клиента.
Лиды. Момент, когда клиент проявляет ярко выраженный интерес к сделке, идентифицирует себя (регистрируется на сайте), вводит данные или заполняет корзину является следующим существенным изменением состояния. Получив статистику, мы увидим соотношение общего количество сгенерированных лидов к перспективным возможностям.
Лид может перерасти в заявку. Событием перехода в заявку мы считаем момент когда клиент наполнил корзину и оформил заявку.
Заявка может перерасти в сделку. Сделка - это бизнес-цель всего процесса.
Каждое решение, которое принимает менеджер продукта, сопряжено с определенным риском. В случае сомнений всегда полезно задавать правильные вопросы, вовлекать соответствующие заинтересованные стороны и использовать данные и идеи, когда они у вас есть, чтобы принять осознанное решение, и при этом иметь возможность вернуться к чему-то, если вам это абсолютно необходимо.
Рассмотрим некоторые вопросы и стратегии, которые можно использовать для выявления, оценки и потенциального снижения рисков, чтобы в конечном итоге обеспечить запуск успешного продукта.
Вы правильно расставили приоритеты?
Задача приоритизации дорожной карты может быть особенно сложной и сопряженной с риском, потому что вы часто учитываете несколько факторов, пытаясь собрать достаточно подтверждающих доказательств для поддержки своих решений. Важно убедиться, что вы расставляете приоритеты на основе показателей, которые лучше всего соответствуют целям продукта, ожиданиям бизнеса и руководства, а также тому, что клиенту нужно больше всего прямо сейчас.
Насколько отличается этот продукт для вашей организации от других продуктов или выпусков?
В зависимости от того, запускаете ли вы новую версию существующего продукта или совершенно новый продукт, ваши риски могут значительно различаться. Например, если вы запускаете новую функцию в стабильном, зрелом продукте, у вас, вероятно, уже есть определенные базовые данные о ваших пользователях, техническом стеке, предыдущей производительности продукта и т.д. Это все обширные данные, которые вы можете использовать для принимать взвешенные решения о том, подойдет ли новая функция вашей аудитории и насколько реалистичны целевые ключевые показатели эффективности. Однако, если вы запускаете совершенно новый продукт или говорите о новой интеграции или расширении продукта, риск определенно выше, поскольку существующие данные могут не служить хорошим показателем. Если вы попали в этот сценарий, подумайте об инвестировании в дополнительные исследования пользователей и рынка, изучение вторичных источников данных, анализировать конкуренцию и в конечном итоге полагаться на свою интуицию и опыт. Это может особенно пригодиться, если вам нужно убедить своих руководителей в том, что этот новый продукт / не является жизнеспособной идеей и почему его следует / не следует реализовывать.
Насколько вы уверены в дизайне продукта?
Нетрудно понять, почему менеджеры по маркетингу и дизайнеры должны работать рука об руку при разработке новых функций или улучшений. Это необходимо для того, чтобы команда разрабатывала правильный пользовательский интерфейс, который реально отвечает целям продукта / функции при минимизации рисков проектирования. Например, работает ли выбор традиционной обработки дизайна против вашего продукта, потому что контекст кардинально отличается? Всегда безопаснее проводить адекватные исследования и тестирование пользователей, когда в дизайне есть области, которые вызывают неопределенность с точки зрения удобства использования или способности достигать целей. Как менеджер проекта, вы хотите убедиться, что вы вселяете в свой дизайн столько же уверенности, прежде чем инженеры разработают и протестируют функцию, чтобы снизить вероятность внесения изменений в функцию после ее полной разработки (или, что еще хуже, после ее выпуска. )
Вы достаточно протестировали?
Конечно, обеспечение качества - это ключевая часть процесса разработки продукта, но какие еще тесты, по вашему мнению, будут пропущены или дополнительно необходимы для обеспечения успешной доставки? Учитывайте ошибки, которые могут быть пропущены или упущены из виду вашими тестовыми командами из-за того, что не было проведено достаточных полевых испытаний или испытаний на долговечность. Некоторые ошибки могут появиться только после непрерывного использования продукта. Некоторые способы борьбы с этим в качестве менеджера - это встроить адекватное альфа- и бета-тестирование в вашу временную шкалу до запуска. Это поможет вам представить ваш продукт «реальным» пользователям и в среде, очень близкой к той, в которой будут находиться ваши конечные пользователи. Внутренние тесты с участием сотрудников в вашей команде или организации - отличный способ выполнить раннее тестирование, потому что любые потенциальные проблемы остаются внутри вашей организации (и не раскрываются заказчику), и эти тесты относительно рентабельны для запуска и управления. Это также может быть отличным способом выявить любые существенные проблемы в дизайне на основе отзывов пользователей, полученных свежим взглядом. Недостатком внутреннего тестирования является то, что вы можете подвергнуться предвзятости, а ваши тестовые пользователи могут не очень хорошо представлять ваших конечных пользователей. Вот тут-то и появляется бета-тестирование, которое можно проводить либо через A / B-тестирование, либо через ограниченное развертывание. Менеджерам редко следует предпочесть полноценный запуск Это также может быть отличным способом выявить любые существенные проблемы в дизайне на основе отзывов пользователей, полученных свежим взглядом.
Я отслеживаю правильные показатели?
Важно определить и согласовать правильные показатели, которые нужно отслеживать и отслеживать на ранних этапах цикла. Хотя в некоторых случаях эти метрики могут быть очевидными на основе целей, поставленных бизнесом, чаще всего менеджеры по менеджменту должны владеть метриками и отслеживать их, чтобы наилучшим образом определять рентабельность инвестиций при выпуске, и проверять их у ключевых заинтересованных сторон, чтобы прояснить опасения. С технической стороны, чтобы иметь данные, которым вы можете доверять, вам необходимо провести время со своей аналитической командой, чтобы понять, откуда берутся данные, как они агрегируются и в каких отчетах. Могут быть различия в интерпретации данных, и важно согласовать команды в отношении того, что отслеживается и сообщается задолго до выпуска. Более того, если новая функция приносит с собой новые показатели,
Я создаю пути отступления?
При любом выборе продукта всегда лучше создавать план «отступления». Если вы выпускаете новую версию продукта, есть ли у вас план отката на случай непредвиденных обстоятельств? Есть ли какие-либо соображения по поводу обратной совместимости и проверяли ли вы их? Если исправление программного обеспечения - единственный путь вперед, насколько сложно и прерывисто его администрировать? Даже если вы очень уверены в своем продукте / функциях, всегда полезно создать пути отката, чтобы в случае возникновения проблемы у вас был относительно безболезненный выход.