CustDev Laboratory

237. Христофор Колумб тоже был стартапером

12 октября 1492 года матрос Родриго де Триана закричал: «Земля! Земля!» — и заработал 10 тыс. мараведи (местная валюта) — примерно столько он зарабатывал за год. Однако денег он в итоге не получил: потому что, глава экспедиции — Христофор Колумб — за 22 часа до этого видел землю, но никому об этом не сказал, но сделал запись в бортовом журнале.

Родриго был членом команды стартапа, который не получил ни доли, ни бонуса. Христофор Колумб был стартапером.

1. Придумал идею стартапа. Точнее, подсмотрел ее у других.
2. Долго и упорно искал инвестиции, ходил в разные инвест-фонды. Чаще всего ему отказывали под предлогом: идея слишком рискованная, ничего не получится.
3. В итоге он нашел инвестиции, но еще вложил свои деньги, которые тоже занял.
4. Сделал MVP: купил один корабль, другие взял в аренду (но меньше, чем нужно было на самом деле).

Он настолько сильно верил в идею, что реально поставил все на карту. (Кстати, потом его даже посадят в тюрьму)…

Как итог: первая экспедиция признана убыточной (-800 тыс), и это не считая стоимости судна, которое пришлось разобрать для строительства здания по месту прибытия. Да и открыл он вовсе не то, что обещал — острова Карибского бассейна, а не Индию (и не Америку).

Прошло 520 лет. Суть стартапа не поменялась — идти куда-то, куда никто не ходил, делать что-то, что никто не делал до тебя, стараться стратить меньше, но не получается.

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

В сухом остатке: стартапы зародились очень давно; суть стартапа не меняется — работа в условиях неопределенности и изменений; тестирование гипотез через MVP.

#интересное@custdevlab

236. AJTBD-сценарии и верхнеуровневая работа. Кейс Стажер.online

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

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

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

На практике, во многих кейс-чемпионатах и других активностях с кейсами обратная связь участникам дается или поверхностно, или не дается вовсе. Для организатора ответить развернуто, скажем, на 50 различных решений — задача крайне сложная и трудоемкая. А решений может быть и 150.

Как найти то, за что целевой сегмент будет готов платить?
Вариантов много, но главное на данном этапе не тратить время на то, что результат не принесет, т.е. «отсечь гипотезы, заведомо провальные для главной метрики продукта» (для роста дохода).

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

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

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

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

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

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

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

В сухом остатке: AJTBD-фреймворк позволяет определять работы более высокого уровня; для Стажер.online один из подобных продуктов для верхнеуровневой работы — создать набор кейсов для понимания что нравится/не нравится в процессии.

#кейс@custdevlab #стажерonline@custdevlab #ajtbd@custdevlab #jtbd@custdevlab

235. Важная роль основателя или если команда тормозит развитие продукта

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

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

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

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

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

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

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

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

В сухом остатке: цель и стратегия достижения цели, разработанные на основе custdev-процедур, должны быть приоритетом в развитии продукта; роль продакта (или основателя) в этом процессе неоспарима.

#интересное@custdevlab #профессияпродакт@custdevlab

234. Стоимость привлечения пользователя (CPUser)

CPUser = стоимость привлечения одного пользователя. Формул для расчета много, но самый правильный — сложить все стоимости платного привлечения для каждого пользователя (сложить CPC, cost per click).

Первые тесты каналов продвижения, особенно исчерпаемые (канал в ТГ, блогер и пр.) обычно приносят пользователей не по самой высокой стоимости.

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

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

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

В сухом остатке: стоимость привлечения пользователя (CPUser) это метрика, которая в долгосрочной перспективе всегда будет расти в цене.

#метрики@custdevlab #cpuser@custdevlab

233. Unit в unit-экономике: смещаем фокус для роста. Кейс Стажер.online

Unit-экономика — база для роста стартапа и понимания его бизнеса. Именно этот подход позволяет понять перспективы стартапа.

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

Unit в unit-экономике — это единица, которая приносит нам деньги. Например, пользователь, который пользуется нашим продуктом и приносит нам деньги. Для ныне несуществующего QIWI юнитом являлись QIWI-терминалы: чем больше терминалов, тем больше будет поток денег. Для отелей unit — это номер (и ночь). Чем больше номеров, тем больше будет поток денег.

Unit — это, что мы хотим масштабировать. Это источник нашего дохода.

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

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

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

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

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

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

Как будет выглядеть новая модель unit-экономики
Мотивируем компании бесплатно размещать задания на платформе, помогаем с заданиями (внедряем AI, например), помогаем с размещением (максимально смещаем акцент на то, чтобы задание было размещено, а все барьеры появились позже -- например, разместил, а регистрация уже в самом конце).

Тут нам поможет CJM или LXM, что ближе. А для студентов ценность еще предстоит сформировать через custdev-процедуры, чтобы узнать за что они действительно готовы платить после решения.

Но главное — если сложно и дорого привлекать компании, нужно сместить фокус на студентов и начать масштабировать продукт за счет них.

В сухом остатке: unit-экономика это подход для понимания источника масштабирвоания продукта; если один unit нам не приносит дохода, ищем другой unit и тестируем гипотезы получения дохода от него.

#кейс@custdevlab #стажеронлайн@custdevlab

232. Опыт исполнителя и новый подход к определению ценности опыта

Считается, что опыт измеряется временем. Обычно в резюме или при рассказе о себе человек говорит: опыт работы 10 лет. Этот подход устарел и не отвечает современным требованиям.

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

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

Можно за год сделать что-то с продуктом, что позволит человеку трансформировать собственный mindset на совершенно другой уровень, недоступный человеку с опытом в 10 лет.

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

Например, вы ищите агентство для проведения custdev-процедур для вашего продукта. Один претендент рассказывает, что проводит исследования более 15 лет. Второй, что провел уже более 2000 глубинных интервью. А третий говорит, что проводит исследования полгода, но за это время смог переупаковать 5 продуктов и помочь им выйти на новый уровень продаж за счет изменения методики проведения интервью.

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

#интересное@custdevlab

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

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

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

Шли годы, смартфоны стали доступнее и функциональнее. И навигаторы превратились из отдельного устройства в приложение на смартфоне.

Смартфон «убил» товарную категорию «навигаторов». То же самое смартфон сделал и с MP3-плеерами. И фотоаппаратами. И много с чем еще. Потому что смартфон может выполнять много разных работ: от позвонить, записать заметку, сделать фотографию до послушать музыку, посмотреть кино и так далее.

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

Суть в том, что чем больше работ можно выполнить одним продуктом, тем он более конкурентоспособен.

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

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

#jtbd@custdevlab #конкуренция@custdevlab

Напоминаем, что мы уже давно задумали и сделали новый канал

👨🏼‍💻 Паспортичка

Там размещаем реальные стенограммы реальных интервью. Тематики самые разные.

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

Приятного чтения!

230. LXM-based customer interview

Этапы принятия решения о покупке в соотстветствии с JTBD-подходом мы недавно описывали. Если узнать у потребителя про каждый этап подробно, получится отличная база для построения LXM.

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

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

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

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

#lxm@custdevlab #customerinterview@custdevlab

229. Custdev это не про методику, это про mindset

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

Можно изучить customer interview досканально, но без сформированного образа мышления сам по себе инструмент мало эффективен. Можно понимать другие custdev-процедуры, но если нет понимания о целях применения, пользы для продукта будет мало.

То же самое можно сказать про JTBD и AJTBD. Это больше про мышление, чем про инструменты.

В сухом остатке: важнее сформировать mindset (образ мышления), чем научиться применять инструменты.

#полезное@custdevlab

228. Синдром «создателя чат-бота» (chat-bot creation syndrome)

Синдром создателя чат-ботов это псевдо-навык, дающий ощущение тестирования продукта через создание чат-бота.

Надо протестировать потребительскую гипотезу? Делаем чат-бот.

По сравнению с мобильным приложением, например, это гораздо быстрее, дешевле и проще. С учетом современного развития ИИ, даже не особо понимая программирование можно сделать чат-бот (да-да, можно, проверено).

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

В CDDC чат-боты позволяют тестировать ранние (левые) части гипотезы. Но не гипотезу в целом.

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

В сухом остатке: создавать чат-боты это не полноценный custdev; это часто вовсе не Custdev.

#интересное@custdevlab

227. Информирование не равно обучению

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

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

Но просто рассказать о функциях продукта — это еще не научить. Нельзя заменять обучение информированием.

Также важно понимать, что научить пользователя невозможно. Он может только научиться сам. Важно создать для него условия для этого обучения/научения.

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

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

Ошибки это тоже неотъемлемая часть обучения. Если пользователь что-то сделал неправильно, нужно ему об этом рассказать, объяснить и показать правильный путь решения.

Зачем так сложно? Иногда это действительно слишком. Но, как говорил Суворов: «Тяжело в учении, легко в бою!»

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

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

В сухом остатке: обучение не равно информирование; мало просто рассказать, нужно сформировать петлю научения, иначе результата не будет

#обучение@custdevlab

226. Управление ожиданием: правило последнего впечатления (peak-end rule)

Правило последнего впечатления было изучено Даниелем Канеманом и коллегами в 1990-ых. Проведя несколько экспериментов исследователи сформулировали ряд правил, назвав их "peak-end rule". На основе этих правил может быть построено управление ожиданиями для продукта.

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

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

Это еще раз подтверждает важность офбординга, так как скорее всего он запомнится в качестве итогового опыта взаимодействия с продуктом.

Как это можно использовать в продуктовом управлении. Если мы по результатам анализа понимаем, что у нас есть пиковый негативный опыт, следует добавить что-то в продукт, чтобы после пикового негативного опыта был опыт с бОльшим позитивным эффектом, пусть и не таким сильным. Подобный подход «сгладит» общее впечатление о продукте. А, возможно, и позволит избежать сильно негативного отзыва.

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

В сухом остатке: правило "peak-end rule" нужно использовать для управления ожиданиями и управления пользовательским опытом.

#управлениеожиданиями@custdevlab

225. MVP не всегда проще самого продукта

MVP — это версия продукта, обладающая минимально ощутимой ценностью для потребителя. Создание MVP является целью этапа Customer Discovery и перехода на этап Customer Validation.

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

Считается, что MVP должен быть дешевым, простым и не всегда удобным. На самом деле существует еще одно очень важное требование к MVP: он должен давать возможность собирать метрики, необходимые как для HADI-циклов, так и для CDDC.

Но главное — возможность проверять гипотезы!

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

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

Это все гипотезы. И для их тестирования (проверки) нужно... MVP.

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

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

В сухом остатке: MVP может быть сложнее самого продукта; главное — скорость, данные и гибкость.

#mvp@custdevlab #гипотезы@custdevlab

P.S. Если есть прототип продукта, но он не позволяет собирать нужные для дальнейшего развития данные, то это не MVP.

#юмор@custdevlab

224. Этапы jtbd-методологии: итог

Собрали в один пост все этапы jtbd-методологии:
1. Первая мысль о продукте (First thought)
2. Пассивный поиск (Passive looking)
3. Активный поиск (Active looking)
4. Принятие решения о покупке (Deciding)
5. Онбординг (Onboarding)
6. Использования в процессе (Ongoing Use)
7. Офбординг (Offboarding)

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

В сухом остатке: этапы jtbd и переход между ними помогают понять процесс мышления пользователя.

#jtbd@custdevlab #этапыjtbd@custdevlab

223. Процесс использования продукта (между онбордингом и оффбордингом)

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

Работа, для которой продукт был куплен, должна выполняться на постоянной основе, и желаемый прогресс (путь от точки «А» к точке «Б») должен достигаться.

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

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

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

В сухом остатке: ingoing use этап, ради которого продукт создается.

#jtbd@custdevlab #этапыjtbd@custdevlab

222. Последняя часть процесса использования продукта: офбординг

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

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

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

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

Зачем:
1. Сохранение положительного пользавательского опыта. Хорошие окончания отношений не стимулируют написать гневный отзыв, которые другие пользователи прочитаю во время этапа активного поиска информации
2. Репутация бренда. Особенно для экосистемных продуктов
3. Будущие положительные решения в пользу этого же продукта или других продуктов этой компании. Положительный опыт останется в памяти и в следующий раз будет играть в плюс при сравнении вариантов.

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

#jtbd@custdevlab #этапыjtbd@custdevlab

221. Life experience map

LXM (life experience map) — карта жизненного пути потенциальных клиентов. Она помогает понять, как живёт целевая аудитория продукта, чем увлекаются эти люди, какие у них проблемы и потребности. Это нужно, чтобы улучшить продукт и каждый этап взаимодействия с ним для тех, кто ещё о нём не знает.

По сравнению с CJM подход LXM помогает изучить именно поведение потребителя вне зависимости от использования конкретного продукта.

Так CJM строится с позиции того, что клиент уже выбрал определенный продукт. А LXM учитывает возможность вариативного выбора.

Например, самокат (средство индивидуальной мобильности). У компаний разные приложения, а значит и задачи (работы) с помощью них могут быть решены разные. Но если строить CJM для Яндекса, то она не учитывает как именно клиент делал выбор между разными продуктами. LXM учитывает.

Единого подхода к построению LXM не существует. Процесс ее построения похож на процесс построения CJM: множество исследований по сбору первичных, вторичных данных, а также данных zero-side.

В сухом остатке: LXM нужен для понимания того, как пользователь взаимодействует с разными продуктами, а не с одним (как в CJM).

#lxm@custdevlab #cjm@custdevlab

220. Первая часть процесса использования: онбординг (Боб Моэста)

После покупки начинается процесс использования продукта. Он состоит из минимум трех этапов: онбординг (on-boarding), непосредственное использование (ongoing use) и оффбординг (off-boarding).

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

Если первый опыт оказался неудачным, пользователь скорее всего попробует вернуть продукт или просто откажется от него: в таком случае, с высокой вероятностью, он уже больше не вернется к этому продукту. Существует даже специальная метрика на этот случай: TTV (Time-To-Value).

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

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

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

#онбординг@custdevlab #jtbd@custdevlab #jtbdэтапы@custdevlab