CustDev Laboratory

207. «Стартап» не равно стратегия вывода на рынок. Почему бесплатные продукты становятся платными Яндекс.Еда (ex. Фудфокс) изначально обещал бесплатную доставку еды из ресторанов. Потребитель оплачивал только стоимость еды, а доход сервиса основывался на комиссии от заведения. Telegram изначально обещал бесплатное использование навсегда, и полное отсутствие рекламы. Прошло время и продукты сильно изменились. Яндекс.Еда за доставку берет деньги с потребителя. Комиссия заведений не отменилась. Telegram ввел рекламные блоки, включая пталформу Telegram Ads, и платные аккаунты для пользователей. Такой путь проходит большинство стартапов, которые выживают на рынке. Важно понимать, что на начальном этапе команда через продукт проверяет гипотезу о потребителях и конкурентно борется за внимание пользователей. Последующий отказ от изначального обещания связан с рыночным влиянием и ростом количества активных и лояльных пользователей. Чем больше пользователей переключилось с других продуктов на новый, тем более вероятно успешно изменить изначальное обещание. Не стоит путать стратегию выхода продукта на рынок и стартап. Это не одно и то же. Ввод новых платных услуг — это тоже гипотезы, которые необходимо тестировать, в том числе, на основе custdev-процедур. В сухом остатке: продукт на этапе стартапа может тестировать гипотезы бесплатного использования продукта; с ростом рыночного влияния компании переходят к тестированию новых гипотез, улучшая показатели unit-экономики. #выходнарынок@custdevlab #бесплатное@custdevlab

206. «Узловые тесты» и custdev Если собирать автомобиль на конвейере, то есть приносить по одной детали и прикручивать друг к другу, вероятность получить продукт без брака равна нулю. Если в автомобиле 2 млн деталей, что-то обязательно сломается. Поэтому автомобили тестируют узлами. Сначала собираем узел, проверяем его работоспособность. Если узел хорошо работает, используем дальше в готовом автомобиле. Все узлы будут протестированы по отдельности и в случае поломки найти ее будет значительно проще и быстрее. Выпускать продукт на рынок без custdev-процедур, то же самое, что и собирать автомобиль без узловых тестов. Конечно можно, но «автомобиль» обязательно сломается. И в чем причина, будет установить очень сложно. В этом основная идея канваса CDDC — мы последовательно разделяем тестирование гипотезы по продукту на «узлы» и тестируем каждый из них определенным образом. В сухом остатке: тестировать одну большую гипотезу очень сложно и ненадежно; скорее всего она не будет подтверждена, и не получится понять, где «узкое место» нашего продукта. #cddc@custdevlab #декомпозиция@custdevlab

205. Почему custdev подходит не всем Не все проекты получают действительно большую ценность от custdev. Чаще всего custdev проводят просто, чтобы его провести. Исследователи разных уровней безусловно имеют разный навык проведения custdev, но в среднем 8 из 10 результатов не дают ничего ценного. Причин, как и всегда, несколько: 1. Мышление. Custdev скорее обременительная функция, чем инструмент знания. Custdev это не фундамент, а отвлечение ресурсов. 2. Видение продукта. У предпринимателя или продакта есть свое видение продукта, если custdev его подтверждает, значит он хороший, если нет — он плохой (причину придумаем/найдем). 3. Негативный опыт. Слишком много custdev-процедур проводится «для галочки» или после долгих уговор. Проводится с ошибками в методологии и неточностями в интерпретации. Отсюда негативный опыт, влияющий на текущие действия. «Что полезного даст этот custdev…» Пишите ваши идеи и другие причины в комментариях, дополним список. В сухом остатке: custdev не работает тогда, когда мы не ждём, что он сработает; лучше не делать «плохой» custdev, чем делать его «для галочки». #ошибки@custdevlab P.S. Про типичные ошибки мы уже много писали и даже сделали подборку постов об этом. Но пока консультации подтверждают грустную тенденцию: неправильное применение инструмента кидает тень на сам инструмент.

204. «Знание-рыба» и «знание-удочка» Есть известная притча: дай человеку рыбу и он будет сыт один день, дай ему удочку — он будет сыт всю жизнь. «Знание-рыба» это конкретное знание, которое позволяет здесь и сейчас решить какую-то проблему. Например, какая средняя конверсия из посетителя онлайн-магазина в покупателя. Или какой TAM-SAM-SOM конкретного рынка в конкретный год. «Знание-удочка» научит получать «знание-рыбу». Это, как правило, знания о том, как решать задачи, а не конкретное решение. Например, методика определять среднюю конверсию по нужно йотрасли или методика расчета TAM-SAM-SOM. Custdev можно заказать на стороне. Агентств много, цены очень разные. А можно научиться делать его самостоятельно, чтобы в нужный момент получать нужные знания о потребителях и особенностях их поведения. В сухом остатке: custdev-процедуры, как их проводить и что это дает — «знание-удочка»; это позволит «быть сытым» каждый день. #полезное@custdevlab P.S. В стартап-термиологии есть еще аналогия: экспертная сессия — это «рыба»; полноценный трекшн — «удочка».

203. Проактивная и реактивная разработка продукта Реактивная разработка продукта означает, что мы реагируем на входяющую информацию от клиентов. Т.е. клиент пожаловался — мы реагируем. Если жалоб нет, считаем, что продукт прекрасен, доработки не нужны. Скорость реакции и процент жалоб, решенных быстро, — показатели эффективности работы компании с клиентским опытом (считайте, равно какой хороший мы продукт). Проактивный подход означает, что мы не ждем жалоб, или ждем и отрабатываем, но обязательно делаем шаг вперед — сам инициируем процесс работы с клиентом. Некоторые запросы клиента это не негативный опыт, т.е. нет желания и намерения написать в службу поддержки, а просто есть соображения о том, что могло бы быть лучше/удобнее/проще в продукте. На самом деле про улучшения в продукте рядовой клиент не задумывается. Он задумывается о том, что ему неудобно делать. Задача владельца продукта перевести знания о том, что клиенту неудобно делать в требования к характеристикам и функциональности продукта. Custdev-процедуры призываны сделать этот процесс максимально эффективным. Классические методики custdev это проактивный подход по своей сути. Реактивный подход не позволяет делать продукты на опережение рынка; мы всегда будем предлагать что-то, что другие уже предложили, потому что так работает клиентский опыт и сравнение этого опыта. Проактивный подход позволяет создавать продукты с прорывным функционалом. В сухом остатке: проактивный подход позволит шагнуть за пределы текущего уровня продукта, тогда как реактивный подход упирается в потолок эмпирического потребления. #методика@custdevlab #полезное@custdevlab

202. Неправильный custdev как фундаментальная причина провала продукта Регулярная ситуация на экспертных и трекшн-сессиях: 1. Основатель рассказывает про продукт. 2. На вопрос о custdev-процедурах и их результатах говорит, что все сделал, потребность в продукте оцевидна. 3. Проходит время. Продукт не двигается с места, набраны пользователи (обычно бесплатные) и метрики продукта удручают. 4. Спрашвиаем основателя, в чем он видит причину провала. Ответ обычно такой: ниша перегрета/занята... Custdev и нужен, чтобы понять, насколько ниша перегрета, занята, свободна, емкая по деньгам. Если произошла такая ситуация, 99,99% причина кроется в неправильных custdev-процедурах. При корректном custdev-подходе не должна произойти ситуация, что продукт окажется невостребованным по причинам отсутствия problem/solution fit или product/market fit. К сожалению, 95% всех custdev-процедур, с которыми приходится сталкиваться, обладают чем-то из перечисленного ниже: 1. Неправильный метод 2. Неправильная выборка 3. Неправильная интерпретация результатов Есть и другие ошибки, но фундаментально все связано с методикой. В сухом остатке: custdev-процедуры — это фундамент для построения продукта и компании вокруг него; нельзя делать его формально или «для галочки», так как это фундаметнально убивает продукт. #ошибки@custdevlab

160. Как определить ситуацию? Цель действия Тип продукта Время...

200. Customer Development Design Canvas Представляем оригинальный артефакт для custdev-процедур продукта -- CDDC. Customer Development -- это концепция разработки продукта и компании вокруг потребностей потребителей.

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

199. Если потребитель использует бесплатно, не обязательно он будет платить Если вы протестировали гипотезу о поведении потребителя про бесплатное пользование продуктом, нет гарантии, что гипотеза о платном пользовании тоже будет успешно подтверждена. Человек может пользоваться продуктом и быть этому рад, но как речь заходит о использовании продуктом за деньги, он может отказаться. Самый главным критерием успешного тестирования гипотезы о поведении — плата за продукт. Бесплатное использование продукта может быть частью иерархии тестирования гипотезы. Но не дает окончательное представление о конверсиях, стоимости привлечения клиента и других важных параметров бизнес-моделирования и управления продуктом. Бесплатное и платное использование продукта — это два разных состояния пользователя. Дело в управлении ценностью. Но это снова тестирование новых гипотез. В сухом остатке: если клиент использует продукт бесплатно, не обязательно он начнет платить за его использование; бесплатный и платный продукты — это два разных продукта. #тестированиегипотез@custdevlab

#юмор @custdevlab

198. Когда продукт очень похож, то помогает сервис Некоторые продукты и услуги друг от друга сильно не отличаются. Например, услуга поверки счетчиков. Нужна всем, потому что по закону обязательно нужно проводить поверку счетчика раз в несколько лет. Конкуренция на этом рынке высокая, а услуга похожая: мастер приходит, делает манипуляции, заносит данные в базу, уходит. Казало бы, чем отличаться от конкурентов? Нанять более квалифицированного мастера за более высокую цену? Тогда услуга станет дороже, а цена примерно одинаковая. Решение кроется не в самой услуге, а в том, как организован сервис вокруг нее. Если построить CJM, станет понятно, что для клиента важно как он собирает информацию, как она записывается и как он ожидает мастера. Если узнать важность каждого этапа и сложности, с которыми сталкивается человек, то станет очевидно, что самый значимый и эмоционально раздражающий этап — согласование времени прихода мастера и его ожидание. Выделиться на фоне конкурентов просто: сделать согласование времени и ожидание мастера маскимально удобным для клиента. То есть вместо «мастер приедет в течение дня» предлагать приезд мастера к конкретному времени. И если человек попросил приехать к 16:30, то мастер приезжает к 16:30. Не в 16:00 или в 17:00. Даже не в 16:40, а именно в 16:30. Клиент готов и рад платить больше, потому что мы даем ему больше ценности! Получается, что мы получаем конкурентное преимущество, начинаем зарабатывать больше денег и получаем более высокий уровень удовлетворения клиентов. И все это потому, что мы решаем значимую проблему. В сухом остатке: если продукты на рынке очень похожи, нужно изучить процессы ДО и ПОСЛЕ непосредственного потребления продукта; именно улучшение сервиса позволит повысить ценность продукта. #сервисдизайн@custdevlab #конкуренция@custdevlab

197. CustDev и продажа: можно или нельзя Лучший критерий проверки гипотезы продукта — деньги за продукт от целевой аудитории. Именно деньги, которые потребитель платит за продукт для решения собственной проблемы показывают настоящую ценность продукта. По сути, продажа продукта это финальная часть проверки гипотезы продукта перед масштабированием. Но не стоит путать тестирование продукта через продажу и попытку продать решение через тестирование продукта. ✅Тестировать через пробную продажу — продавать «идею», сырое решение. Мы не пытаемся под видом исследования найти более доступный способ привлечения клиентов. Мы проводим исследование в первую очередь, а уже в рамках него стараемся получить деньги за решение. ❌Продать продукт означает продать готовое решение, прикрываясь исследованием (custdev-процедурой). Продукт вряд ли будет изменяться по результати исследования, ценность уже сформирована, а исследование — это прикрытие. У этих двух подходов разные цели. У одного — исследовательская, у второго — коммерческая. Между ними пропасть. В сухом остатке: продавать товар под видом custdev — плохо; проводить custdev через продажу — хорошо. #правильныйcustdev@custdevlab #быстрыйcustdev@custdevlab

196. Искажение PAM-TAM-SAM-SOM В большинстве презентаций на демо-днях размеры рынка показывают через PAM-TAM-SAM, а доля рынка конкретного продукта через SOM. В последние годы показывать PAM (потенциальный рынок) не принято. Причин несколько, но главная, в этом параметре нет большого смысла, так как потенциал может быть как глобальный, так и региональный. Какой считать — не очень понятно. TAM-SAM-SOM почти всегда показан через круги (см. изображение). И это плохо. 1. Непонятно, как были посчитаны эти параметры (нет прозрачности). 2. Не соблюдается масштаб, так как круги не пропорциональны расчетным параметрам. При оценке перспектив продукта важно понимать разницу между TAM и SAM, ведь это определяет и стоимость конкуренции, в том числе стоимость привлечения клиента, а также потенциал роста. Почему это происходит, объяснить просто. В Power Point есть стандартная Smart-фигура с подобными кругами. Создание слайда очень быстрое и простое. К тому же, «так делают все», то есть исторически сложилось представлять параметры рынка таким образом. Как исправить ситуацию: 1. Показывать круги пропорционально цифрам. Если TAM в 5 раз больше, чем SAM, значит нужно площадь (!), а не радиус, показывать в 5 раз больше. 2. Добавлять расчеты. Расчеты лучше показывать через таблицу, в основе которой лежат ключевые метрики стартапа. Если не помещается на слайде — добавляем QR и ссылку на нее на слайде. В сухом остатке: не надо делать что-то потому, что «все так делают»; если решили показывать TAM-SAM-SOM через «круги», учитывайте их пропорциональность. #рынок@custdevlab #метрики@custdevlab

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

195. Чем стартап отличается от «не стартапа» Не каждый бизнес является стартапом. Следовательно, не каждый бизнес должен развиваться по правилам развития стартап-проекта. Некоторым бизнесам это будет только вредить. Предположим, нужно приготовить яичницу. Можно взять уже готовый рецепт, которых в открытом доступе несколько десятков. Повторить несколько рецептов. Может получиться не сразу, но в итоге получится яичница. Яичницу готовили миллиарды раз, тонкостей ее приготовления, конечно, много, но в целом это известный процесс. В конечном итоге можно попросить знакомого повара научить готовить яичницу (поделиться опытом). А если нет знакомого повара — найти его. А вот если нужно приготовить новое блюдо, например, новый соус, на основе куриных яиц. Никто до вас этот новый соус не готовил. Вы не знаете, как его приготовить, потому что никто не знает. Также не знаете, понравится ли это вам или вашим клиентам. Спросить, как готовить этот соус, не у кого, ведь никто его не готовил. Вы, конечно, слышали, что кто-то где-то когда-то далеко такой соус сделал, но в целом, это для всех неизвестный процесс. И непонятный результат. Пример с рецептом яичницы — это не стартап. Процессы известны, бери и делай. Например, маркетинговое агентство, студия дизайна, HR-агентство, ларек с шаурмой — это примеры таких проектов. Действовать по принципу развития стартапа не нужно, достаточно посмотреть на успешные практики и повторить, адаптируя под себя и под целевую аудиторию. Пример с новым соусом — стартап. Новый сервис заказа одежды через AR-технологии, новый способ подбора персонала в компанию, автомат-робот, приготавливающий шаурму на заказ, но без повара — это примеры таких проектов. Тут сложно обойтись без custdev-процедур. В сухом остатке: не каждый бизнес — это стартап; применение методик развития стартапов для таких проектов может приносить больше вреда, чем пользы. #интересное@custdevlab #стартап@custdevlab

194. Реальные и фантомные «боли» клиентов Реальные боли — это то, с чем клиенты на самом деле сталкиваются при решени своих задач. Фантомные боли — это боли, которые кажутся клиентам существующими, но таковыми могут не являться. Например, при оплате через мобильное приложение банка на кассе у клиента на разных карточках может быть достаточная сумма, только в раздробленном виде. Нужно оплатить 500 рублей, но 200 на одной карте, а 300 на второй. Реальная боль — это необходимость сначала перевести деньги с одной карты на другую, а если карт больше трех, то можно еще и перепутать, что приведет к веренице переводов. От этого возрастает тревожность, особенно, если за спиной скопилась очередь: контекст задачи нельзя не принимать в рассчет. Решением могло бы стать просто снимать деньги сразу с двух карт, если клиент дал банку на это разрешение. Фантомная боль в данном случае, может быть связана с тем, что подобное решение клиентом не осознается. А следовательно, клиент в ходе интервью скажет, что именно процесс перевода денег с одной карты на другую является значимой проблемой, потому что он связывает тревожность с этими действиями. Решением с точки зрения клиента, могло бы стать, например, ранжирование карт и счетов в приложении сильно облегчило бы решение. Но это фантомная боль, которая не решает реальную проблему оплаты. В сухом остатке: исследователь должен научиться определять реальные и фантомные боли потребителей; преодоление фантомных болей не решает изначальную проблему клиента. #боли@custdevlab