🗯63. Разбор типичных ошибок на этапе формирования MVP


💯 Хочу поделиться моим самым "наблюдаемым" паттерном поведения стартапов. Очень много работаю с различными акселераторами и постоянно слышу от них слова, что "вот-вот допиливают МВПшечку, еще 2-3 недели и пойдут на рынок проверять, продавать и т.д. Как вы догадываетесь, проходит 2-3 недели и они говорят, что их ИТшники подвели и им еще нужно еще 1-2 недели что бы допилить MVP ... В общем, акселератор заканчивается, а они как "пилили", так и "пилят" ...

Для меня это самый распространенный паттерн который я постоянно встречаю. Получается, что вместо действий и встречи с реальным рынком, коллеги "пилят" MVP, ради того, что бы "пилить" MVP 😢. Как минимум тут две ошибки: первая - не нужно ждать MVP что бы проверять ценность, вторая - сроки в большинстве случаях проваливаются, нужно находить другие способы как проверять гипотезы быстро и дешево (не дожидаясь когда сделают MVP) - fake it till you make it.

Собранный ТОП ошибок, касающихся MVP:
🟠Долгое "пиление" идеального продукта, вообще "пиление" MVP вместо быстрых и дешевых проверок;

🟠Работа на многих направлениях вместо четкого, узкого сегмента на старте. Cherry picking, низковисящие яблоки - пусть узкий сегмент, но мы можем быстро и просто их "сорвать". Предпочтение на старте отдается тем сегментам, откуда проще получить ответ;

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

🟠Страх выходить на реальный рынок. Вы все равно с ним столкнетесь, через месяц, через два - но начнете искать клиентов. Был отличные шансы начать продавать продукт: один месяц назад, второй - сегодня. Начинайте продавать сегодня! Да - страшно, да - сложно, но кому сейчас легко ...

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

🟠Технодрочево. Работа над MVP ради MVP, без вывода на рынок.

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

❓Какие вы знаете еще паттерны? Что встречали у себя или у коллег? Пишите в окмментриях.

#ПаттерныОшибок #MVP

🗯64. Кейс из жизни


Пусть и шуточный, но почти реальный кейс (взято с bash.org - если кто помнит что это).
💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩
Вася и Петя одновременно начали писать один и тот же продукт.

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

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

Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение, отвечающее желаниям клиентов. У Пети было вылизанное, никому не известное приложение, минус на банковском счёте и ни одного клиента.

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


👉 Какие выводы для себя сделаете вы?

#ПаттерныОшибок #MVP

🗯65. Инструменты проверки первичных гипотез


Давайте разберем результаты опроса и уточним для чего нужен MVP (по крайней мере как я обоснованно считаю).

1️⃣❌ Нам не нужен MVP что бы показать, что продукт работает. Распространенный паттерн - стартапы пытаются доказать, что продукт работает. Верим! Не нужно доказывать, что беспилотные такси ездят - в это верю, покажите как из них таксопарк построить и сколько инвестор на нем заработает (насколько больше чем с обычными такси).
Объективная потребность доказать, что продукт работает есть только у 10%-15% стартапов. Например: что ваш технологический процесс выдает нужный химический элемент с заданными свойствами; что в биореакторе действительно получился антибиотик, убивающий специфические бактерии. Только в подобных случаях стоит доказывать гипотезу, что продукт реализуем. В остальных случаях, это не вопрос первого порядка и есть более важные вопросы.

2️⃣❌ Нам не нужен MVP, что бы проверять гипотезы. Кроме MVP есть PoC (Proof of Concept), есть прототип - инструменты, которые более просто, более быстро и гораздо дешевле можно получить, т.е. не стоит микроскопом гвозди забивать, есть же молоток. То есть:
🟠PoC (концепт), одностраничник, продающая презентация - сделайте ее за 2-3 дня и идите проверять гипотезы про проблемы. Проведете JTBD интервью, еще и будущий продукт попробуете с их помощью продать. В чем сложности?
🟠Прототип - я много работаю на хакатонах, я вижу что можно сделать за 48 часов, это даже прототипом не назовешь (почти готовый продукт, даже не MVP). Например: переводчик исходного видео на 10 языков с синхронизацией губ; система распознавания лесных пожаров с видеопотока; система контроля отвлечения водителей от дороги во время движения (повороты головы, телефон, предметы, еда); система аналитики результативности игроков в футбол по видеопотоку и т.д.

Имея прототип, который показывает результат, можно проверить гипотезы, что прототип решает проблему клиента, что результат, генерируемый будущим продуктом, имеет для клиента ценность и т.д. По времени - максимум 1-2 недели на создание прототипа.
Считаю, что раньше, лет 10-15 назад, действительно чаще нужен был MVP (не было удобных инструментов прототипирования). Сейчас с учетом нейронок, работающий прототип продукта собирается за пару дней - и результат-то прототипом не назовешь 😂.

3️⃣✅ MVP нужен для сбора реальных метрик продукта, что бы получить оплату за продукт (которую можно будет сразу "инвестировать" в разработку). Пример: делаем новый легкий двигатель 200 л.с. Если его поставить на среднестатистическое шасси - получим скорость 200 км/ч.
Могу продать через презентацию? Могу! Могу договориться о пилотировании - могу! Нужно с собой двигатель таскать? Не обязательно, чего на него смотреть, "сало, як сало". Нужны реальные метрики двигателя - выдаст 200 л.с. или нет. Сделаем 200 км/час или нет. И далее по реальным метрикам (предположим 180 л.с.) уже или скорректируем презентацию (заменим 200 км/ч на 180 км/ч) или пойдем дорабатывать двигатель, что бы получить заявленные 200 л.с.
По оплате - реально получить деньги, если MVP используют для конкретных целей? Реально! Есть и отличная альтернатива - получить не деньгами, а вовлеченностью и обратной связью от испытателей - какой крутящий момент, в каком диапазоне мощный подхват, где провал, сколько "жрет" бенизина, масла, как греется, что ломалось и т.д. Поверьте, такая обратная связь гораздо ценней тех денег, за которые вы продаете будущий продукт.

‼️ Выводы:
1. Нам не нужен MVP для проверок гипотез - есть другие более эффективные инструменты (концепт или прототип).
2. В большинстве случаев нам не нужен MVP, что бы показать, что продукт работает или дает результат. Поверьте, вам просто поверят 😂, если грамотно покажите пруфы (сам результат).
3. Гипотезы про ценность так же оптимальнее доказывать не при помощи MVP.
4. MVP нужно для получения реальных метрик или живых денег (или их более ценного эквивалента).

👉 Как вы считаете, нужен MVP или нет? Давайте обсудим - пишите в комментарии ваше мнение.

#MVP

🗯66. Проверка гипотез через инструменты


Давайте подробнее обсудим как проверять различные гипотезы (про проблемы, решение, ценности) через инструменты, относящихся к ранним стадиям продукта. Мы говорили о том, что у нас есть три инструмента: Proof of Concept (Концепт)→ Прототип → MVP. Обсуждали, что стоимость создания каждого инструмента кратно возрастает, что четко ограничивает сферу и целесообразность его применения (может быть более дешевый способ проверки, че именно этим конкретным инструментом).

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

➡️ Proof of Concept/Концепт продукта:
⚫️Основная задача: подтвердить наличие проблемы у клиента; вторично - подтвердить, что результат решает проблему клиента;
⚫️Итог встречи: подтверждение, что проблема клиента существует; зафиксированные договоренности о дальнейших действиях по использованию продукта;
⚫️Что представляет: (1) onepager, пресс-релиз; (2) презентация про продукт (5-7 слайдов) с описанием что на входе, какой выдается результат и каким образом он получается.


➡️ Prototype/Прототип:
⚫️Основная задача: подтвердить, что результат, формируемый продуктом, решает проблему клиента; вторичная задача - подтвердить ценность результата для клиента (через оплату, договоренности);
⚫️Итог встречи: аванс, договор, пилот;
⚫️Что представляет: (3) демо - как создается результат (например, видеоролик); (4) прототип, куда пользователь может загрузить входящую информацию и получить результат. Тут есть развилка - или мы фокусируемся только на демонстрации результата (условно, показываем один тип отчета, который минимально меняется в зависимости от входных параметров) или мы сами "руками" создаем этот результат (пусть не с такой скоростью);
🟠Пример: Продукт проверяет домашние задания через нейросеть. Результат - проверенное домашнее задание. Реализация - наймите студентов для проверки, важно проверить, что такая проверка закрывает проблему или нет, готов клиент или нет платить за такую проверку;
🟠Пример: Продукт делает персонализированный комикс через нейросеть. Результат - комикс с героем похожим на клиента. Реализация - наймите художников для отрисовки первых 20-30 комиксов, важно проверить, такой комикс это то, что появилось в голове у клиента, готов клиент или нет платить за такую проверку.


➡️ MVP:
⚫️Основная задача: получить изменения в клиентских метриках (было → стало); через оцифровку метрик получить оплату (продукт создает столько-то ценности, что подтверждено такими-то метриками во время пилотирования);
⚫️Итог встречи: пилотирование MVP; зафиксированное изменение в клиентских метриках (было → стало); получение оплаты пропорционально отгружаемой ценности (или по факту заявляемой ценности для клиента или по факту полученной клиентом ценности);
⚫️Что представляет: (5) первая версия продукта; (6) часть продукта, реализующая наиболее ценный для клиента блок. Cледует отметить, что результат здесь (в отличие от прототипа) получается автоматизированным способом, а не "руками";
🟠Пример: При MVP интеграция может выполняться через коннекторы (есть автоматизация, но "на коленке", это не 100% надежный способ как API). В прототипе будет приемлемо, если интеграция выполняется "руками". В продукте предполагаем, что вся интеграция идет через API.


➡️ Пример: Продукт делает персонализированный комикс через нейросеть. Результат - комикс с героем похожим на клиента.
⚫️Прототип: художник для отрисовки первых 20-30 комиксов;
⚫️MVP: нейронка, вставляющая лицо клиента в комикс, нарисованный художником (единый шаблон, 1-2 комикса);
⚫️Продукт: нейронка, генерирующая комикс самостоятельно с лицом клиента;

#MVP

🗯67. Ключевые гипотезы на старте для проверки


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

0️⃣ Продуктовый блок канваса. Мы заполняем продуктовый блок канваса, что бы систематизировать наше видение продукта и что бы было с чем идти в проверку гипотез.

Ключевые гипотезы которые мы проверяем (пока мы их все не проверим мы не двигаемся дальше):
1️⃣ Гипотезы про проблемы. Подтверждаем задачи и проблемы клиента (по-хорошему, для каждого сегмента). Подтверждаем, что у клиента стоит такая-то задача или есть такая-то проблема в процессе выполнения этой задачи. Понимаем как часто возникает это задача (проблема) и сколько стоит "проблема" (не решение вовремя задачи).
⚫️Как это делаем? Проблемные, JTBD интервью - идем общаться и задаем вопросы.

2️⃣ Гипотезы про решение. Нам нужно подтвердить что "результат", который формирует наш продукт, решает проблему клиента. Помним, что покупают не процесс решения проблемы (задачи), а результат (условно, "волшебную" таблетку).
⚫️Как это делаем? Решенческие интервью - идем общаться и задаем вопросы, показываем "результат", спрашиваем решает ли "результат" озвученную ранее проблему: в чём решает, как именно решает, что он исправляет и т.д.

3️⃣ Гипотезы про реализуемость. Нужно для себя понять, что наш продукт сможет сгенерировать "результат", который решает озвученную проблему.
⚫️Как это делаем? В большинстве случаев это технические гипотезы - тестируем вопросы реализации. Можем/не можем. Если можем, то сколько?

4️⃣ Гипотезы про ценность. Подтверждаем оцифровку "результата" и что "результат" имеет ценность для клиента.
⚫️Как это делаем? Идем общаться и задаем вопросы - вытаскиваем метрики и цифры из головы клиента. Нам нужно "увидеть" цифры и "услышать" ценность.

5️⃣ Гипотезы про оплату. Нам нужно получить "оплату" за то решение, которое генерирует наш продукт. Проверяем готовность оплаты результата клиентом (не продукта, прошу заметить, а результата, который принес оцифрованную выгоду или устранил заявленные проблемы/предотвратил потери).
⚫️Как это делаем? Фиксируем договоренности о дальнейших шагах, проверяем заинтересованность клиента. Идеально, если сможем получить оплату или "вовлеченность" клиента в формирование результата (как вариант оплаты).

✅ Почему об этом говорю?
Потому, что пока не проверим гипотезы - не идем "делать MVP". Потому как системно не определили какую задачу решает MVP. А если понятно, то, кажется, что эту задачу можно решить проще и быстрее.

‼️Пара интересных примеров и замечаний:
1. Нам не всегда нужно проверять все 5 пунктов. Некоторые гипотезу более очевидны и требует меньше фокуса.
2. Проблема может быть достаточно очевидной. Например, плохая успеваемость учеников/детей. Не нужно задавать вопросы видят ли они в этом проблему. Фокус на том, что ваша "волшебная пилюля" для учеников или их родителей решает проблему успеваемости или нет? Спросите именно это.
3. Проблема может быть очевидной, решение и ценность - понятны. Вопрос, сможем ли реализовать? Например, трансурановые элементы с метеоритов. Проблема, ценность - понятные. Решение - понятно (ракета). Вопрос в реализуемости - сможем ли сделать такую ракету.
4. Ценность на словах может быть понятна, она даже есть. Просто забесплатно клиент готов пользоваться, он видит ценность, а платить за результат - не готов. Результата - "мало" для оплаты.

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

#MVP

🗯69. Ключевая фокусировка в инструментах


⚠️ Давайте посмотрим другие срезы - на чем еще можно фокусироваться и под каким углом на это смотреть.

➡️ Деньги:
⚫️Прототип: проверяем готовность оплаты за предоставляемый результат. Предположим, делаем легкий компакный двигатель 200 л.с. Проверяем принципиальную готовность заключить договор на определенную сумму;
⚫️MVP: проверяем чувствительность к цене продукта. 200 л.с. - Х заплатят? В конкретном сегменте - Y заплатят? А если будет 180 л.с. - Z заплатят? В случае с ИТ продуктами предполагаем что ценность не бинарна (есть ценность/нет, есть двигатель/нет), а имеет диапазон. И мы как раз и пытаемся "нащупать" этот диапазон - продаем MVP, условно, за 5к, потом, за 7.5к, потом за 10к, потом возвращаемся на 7.5к (понимаем чувствительность к цене).
Полученные суммы реинвестируются в разработку - снижаем стоимость создания продукта и гарантируем его создание;
⚫️Продукт: важно обеспечить стабильные поступления. Стабильный денежный поток обеспечивает бесперебойное функционирование операционной деятельности (как разработки, так и продаж, поддержки, роста и т.д.).


➡️ Фокус внимания:
⚫️Прототип: на выстраивание процесса проверки гипотез (про проблемы, про ценность); на выстраивание ручного процесса продаж через фаундера проекта. Важно научиться "руками" продавать продукт, что бы понять проблематику клиентов и ценность продукта для клиентов и, потом, делегировать процесс продаж;
⚫️MVP: на получении клиентских метрик и метрик продукт от первых пользователей; мы должны подтвердить на практике (метриками), что продукт дает заявленную ценность (условно, что двигаетль действительно выдает 200 л.с. и разгоняет автомобиль до 200 км/ч как заявлено в презентации (концепте или прототипе);
⚫️Продукт: переключаем свое внимание на рост продукта через постоянный процесс улучшения качества и метрик продукта (growth hacking), через бизнес процессы привлечения новых клиентов и бизнес процессы удержания старых клиентов.


➡️ Реализация, функционал "под капотом":
⚫️Прототип: на старте внутренний функционал отсутствует (просто демо); может быть реализована руками - важно проверить продажи, а не пилить технический функционал, который никому будет не нужен; функционал может быть передан на аутсорс - важно обеспечить поток клиентов, фиксировать их у себя в CRM, а обслуживание на старте можно передать на "аутсорс". В будущем, реализуем внутренний функционал, но самое главное - список клиентов, который остался у нас в проекте и мы переключим этих клиентов обратно на себя;
⚫️MVP: Функционал сделан "на коленке", есть какая-то автоматизация, но это все собрано на "живую нитку" и неспособно перенести высокие нагрузки. Разумный вариант для первичного масштабирования;
⚫️Продукт: реализован полный функционал и выполнена полная автоматизация получения результата - на сколько это технически возможно).


➡️ Продажи:
⚫️Прототип: Ручные продажи фаундера; Подтверждение PSF (Problem-Solution-Fit), личные встречи с потенциальными клиентами для понимания задач и проблематики клиентов. Данный этап не делегируется - очень большая ошибка на старте передавать общение с клиентами и продажи,
⚫️MVP: Первые продажи и общение с клиентами приводят к понимаю процесса. На этапе MVP можно пробовать формировать отдел продаж и выстраивать системный процесс продаж. На данном этапе фокус именно на построении процесса, не масштабировании. Поиск системных инструментов продаж, основная работа строится в 1-2 базовых каналах;
⚫️Продукт: Системный продажи. Масштабирование процесса продаж. Найден или будет найден PMF (Product-Market-Fit), ведется поиск PCF (Product-Channel-Fit).

#MVP

🗯70. Ценовая политика продажи продукта на разных стадиях


Разберем сегодня тактические приемы продаж будущего продукта на разных стадиях (от прототипа до MVP и готового продукта).
Первое, что хочется напомнить - что наша целевая аудитория (с точки зрения готовности покупки новых продуктов) - инноваторы и ранние последователи. Подробно разобрали этот вопрос в посте 61. На ком проверять продуктовые гипотезы.

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


Предлагаемые стратегии продаж:

➡️ Инноваторы:
1. Единовременная оплата за прототип. Показываем прототип, если попали в проблему просим авансировать разработку. Предлагаем, что за сумму аванса клиент получает готовый продукт (возможно потом небольшая доплата), но в целом сумма за продукт будет существенно меньше рыночной - в примере 15%. Пример, депозит за новую модель. Указанная сумма идет на разработку MVP и продукта.

2. Единовременная оплата за MVP. Показываем прототип, подписываем договор на поставку, но поставляем MVP ранней версии. В примере оплата составляет 20% от рыночной стоимости продукта и не меняется при выпуске полной версии продукта. Заплатил один раз и получаешь продукт по цене существенно ниже рыночной, ничего не теряешь, пользуйся сейчас, а потом проапгрейдим до полной версии.

3. Пропорциональная оплата за MVP и продукт. Демонстрируем MVP, подписываем договор на поставку, поставляем MVP. В примере оплата за MVP составляет 20% от рыночной стоимости продукта, при выпуске полной версии продукта - увеличивается (берется доплата за полную версию продукта). Заплатил один раз и получаешь продукт по цене существенно ниже рыночной. При выпуске полной версии будет небольшая доплата за полный функционал.


➡️ Ранние последователи (Early adopters):
4. Пропорционально отгружаемой ценности. Ценный клиент. Полный продукт дает ценность 100%, но мы продаем его за 80% от рыночный цены. На этапе MVP продаем пропорционально ценности: MVP создает ценности на 25% - продаем чуть дешевле за 20%. Продукт создает ценности на 50% - продаем за 40%. Премия за первые покупки, за вход в сегмент. Больше ценности - немного выше оплата, но все честно. Больше зарабатываешь - больше платишь.

5. Пропорционально отгружаемой ценности. Обычный клиент. Продаем без скидок. Полный продукт дает ценность 100%, продаем его за 1000% от рыночный цены. На этапе MVP продаем пропорционально ценности: MVP создает ценности на 25% - продаем за 25% от рыночной цены конечного продукта. Продукт создает ценности на 50% - продаем за 50% от рыночной цены. Адекватная ценность - адекватная цена.

6. Продажи MVP. Продаем MVP продукта, например, за 50% от рыночной стоимости. Полный продукт продаем за 80% от рыночной цены - премия за вход в сегмент. В целом есть возможность купить продукт по цене ниже рыночной.

7. Продажи продукта. MVP продукта не продаем. Сразу начинаем продавать полный продукт, продаем за полную стоимость, 100% рыночная цена и рыночная ситуация.

‼️ В этом месте считаем, что ранний рынок закончился - выбрали всех потенциальных клиентов из раннего рынка. Наступает "пропасть", которую нужно преодолеть. В этом месте компании могут застревать на длительное время без роста новых клиентов. Проблема в том, что компании из следующего сегмента (раннее большинство) будут покупать только тогда, когда продукт есть у их "соседей". А сам сегмент относительно консервативен и покупает только зрелые продукты.


➡️ Преодоление "пропасти" у раннего большинства (early majority):
8. Скидка за вход в сегмент. Продаем продукт первым клиентам в сегменте с существенным дисконтом к рынку, например, 75% от рыночной цены. Задача - войти в сегмент, закрепиться в нем.

➡️ Ранние последователи (early majority):
9. Рыночные продажи в сегменте. Продаем зрелый продукт по рыночной цене.

➡️ Поздние последователи (late majority):
10. Зрелый рынок. Продаем продукт версии 2.0.

#Продажи

🗯71. Универсальный шаблон взаимодействия в B2B


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


➡️ На встрече с потенциальным клиентом мы выясняем его заинтересованность в продукте. В случае заинтересованности просим клиента подписать договор, со следующими ключевыми положениями:

1️⃣ Прописан срок, когда мы предоставляем клиенту продукт или MVP для пилотирования. Например, встреча проходит в марте, 1 июня фиксируем дату передачи продукта или MVP - то есть у нас есть время для создания продукта.


2️⃣ Прописан срок для бесплатного пилотирования продукта. Напомню, что наша задача за время пилотирования зафиксировать изменения в клиентских и продуктовых метриках: что изменилось в его бизнесе и как клиент в реальности использует продукт.
👉 Важно уметь измерять и снимать клиентские и продуктовые метрики. В договоре прописываем требование к клиенту по информированию и сбору клиентских метрик - нам это действительно важно.
👉 Важно обеспечить качественный онбординг в продукт. Вероятность пилотирования продукта (использования продукта) без качественного онбординга - достаточно невелика, требуется "за уши" тянуть клиента по его клиентскому пути в продукте. Тут будет обоюдная польза - вы получаете клиентские метрики, а клиент получает качественное понимание какую ценность дает ему продукт (повышаем конверсию в покупку продукта). В договоре прописываем процедуру онбординга.


3️⃣ Прописан срок и процедура подведения итогов пилота. Как минимум протокол с фиксацией динамики изменения клиенских метрик (точка А и точка Б).


4️⃣ Прописана дата, когда клиент может или бесплатно вернуть продукт (отказаться от его дальнейшего использования) или, если возврата не происходит, оплатить стоимость продукта - прописан срок оплаты и стоимость продукта.
👉 То есть даже на старте клиент понимает стоимость продукта, понимает сколько он должен заплатить за результат, который генерирует продукт. Но до указанной даты клиент не несет никаких обязательств по оплате - он может вернуть продукт без каких-либо оплат. То есть на старте договор для него, по сути, бесплатный, но клиент понимает все финансовые обязательства.


5️⃣ После даты оплаты мы можем прописать срок доработки продукта. То есть клиент уверен, что все его замечания будут учтены и он ничем не рискует.


➡️ Резюме:
🟠В подобном договоре учтены все ключевые положения: время на создание MVP или продукта, срок пилотирования, процедура получения клиентских метрик, срок для возврата продукта, срок для доработки продукта.
🟠Совет - не нужно делать этот договор большим, важно зафиксировать суть договоренностей. Так как мы обязательно указываем цену за продукт, что бы клиент понимал сколько он должен будет заплатить, то юридическая форма документа именно договор.

#Продажи #MVP

🗯72. Примеры реализации прототипов и MVP продуктов


➡ Пример 1️⃣
Продукт делает персонализированный комикс через нейросеть. Результат - комикс с героем похожим на клиента.
⚫Проверка гипотез: Нанимаем художника для отрисовки первых 20-30 комиксов. Находим клиентов из сегмента (мамочки, делающие комикс для ребенка), берем у них фотографию ребенка в директе и с помощью художника руками делаем комикс. Возвращаемся и пытаемся получить оплату. "Вот комикс, вы подтверждали заинтересованность в комиксе, прошу оплатить результат".
⚫Результат проверки: продав комикс 10-20 раз мы получаем подтверждение тому, что это покупают. То есть сможем продать еще 100-1000-10000 раз. Только после первых продаж уже делаем MVP (нейронка 1.0, вставляющая лицо в готовый комикс от художника) и полноценный продукт - нейронка 2.0, которая уже сама генерирует законченный комикс.
🟠Важно: стоимость работы художника гораздо ниже, чем стоимость разработки нейросети с нуля. Мы не рискуем деньгами не доказав востребованность продукта.


➡ Пример 2️⃣
Робот уборщик паркингов в ТСЖ.
⚫Проверка гипотез: Делаем презентацию продукта, снимаем видео как робот убирает, делаем расчет (затраты на уборку сейчас, затраты на уборку роботом, окупаемость, ценность). Идем по ТСЖ, показываем расчеты, объясняем экономию и выгоду для ТСЖ (более выгодно убирать роботами, чем нанимать зимой исполнителей).
⚫Результат проверки: Заключив предварительные договора (с четкой суммой оплат в месяц), понимая окупаемость робота → идем к инвестору и просим денег на создание робота. Вот договора, вот стоимость, вот расчет окупаемости и прибыли → дайте денег Х что бы заработать Y.


➡ Пример 3️⃣
CRM для частных пивоварен. Сокращает потери на 10%.
⚫Проверка гипотез: Делаем презентацию продукта, делаем расчет - вот среднестатистические потери в отрасли, мы сокращаем потери на 10% через контроль этой стадии производства, этой и этой. 10% потерь при ваших объемах производства это - такая сумма. Находим клиентов, презентуем им решение, из 20 клиентов примерно 5 готовы купить это решение по подписке "авансом", то есть на стадии MVP (реализована только одна функция контроля из 4-х).
⚫Результат проверки: Заключив договора с четкой суммой оплат в месяц (но ниже рыночной, так как продукт функционирует не в полном объеме), используем данные оплаты для реализации нашего продукта (функции 2). Продолжаем ходить по рынку, презентуем наше решение новым клиентам. Берем оплату уже больше чем в первом случае (так как реализована уже функция 1 и функция 2, ценности даем больше → оплата больше). Старым клиентам бесплатно апдейтим продукт, они пользуются новой версией продукта с большим функционалом, но по старой цене.
В целом, продолжаем дорабатывать продукт. Повышаем ценность продукта, увеличиваем цену продукта для новых клиентов и бесплатно проводя апгрейд старым клиентам.


➡ Пример 4️⃣
Нейросеть для проверки домашних заданий.
⚫Проверка гипотез: Нанимаем студента на проверку домашних заданий. Находим учителей, презентуем им продукт, предлагаем тестировать продукт. Учителя скидывают домашнее задание в чат, студент его проверяет. Мы смотрим как часто учителя используют проверку и сколько готовы платить, тестируем разные когорты с разными условиями использования и разной ценой.
⚫Результат проверки: Продав решение 20-30 раз, понимаем частоту использования продукта и можем сформировать оптимальный тариф для оплаты. Дорабатываем наш продукт, шаг за шагом делаем нейронку, которую подключаем к проверкам. Постепенно снижаем нагрузку со студента, перекидываем ее на нейросеть, отдаем ей все больше и больше функций.
🟠Важно: стоимость работы студента гораздо ниже, чем стоимость разработки нейросети с нуля. Мы не рискуем деньгами не доказав востребованность продукта.

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

#Продажи #MVP

🗯73. Факты, подтверждающие ценность продукта для клиента


Общий алгоритм подтверждения ценности:
1. Общаемся с клиентом.
2. Получаем подтверждение проблемы, оцифровку проблемы. Нет оцифровки - нет проблемы (нет потерь, не за что платить).
3. Четко рассказываем продуктовую часть в формате ценностного предложения: проблема → решение → оцифрованная выгода.
4. Резюмируем: есть проблема, теряете - столько. Решение - такое, позволяет убрать проблему и дать такую ценность, в цифрах - столько.
5. Предлагаем клиенту купить продукт которые решает его проблему - оплатить деньгами или через smart money.


➡️ Как понять, что клиент заинтересован в продукте?
🟠По результатам встречи зафиксировали четкие конструктивные договоренности о дальнейших шагах. Договоренности есть, они продвигают в сторону цели, переводят сделку на следующий этап воронки продаж. Противоположность этому - "увиливание" от договоренностей, договоренности ни о чем (созвониться на следующей неделе).


⁉️Что может еще приниматься в качестве "оплаты"?
🟠Время. Готовность еще раз встречаться, инвестировать время в тестирование продукта. Собеседник вовлечен, активно задает вопросы.
🟠Репутация. Готовность рекомендовать вас, собеседник делится у кого есть еще такая же проблема, готов организовать встречу с вами.
🟠Ресурсы. Готовность выделить какие-либо ресурсы для продукта.
🟠Деньги. Готовность к оплате, подписанию договора (смотри тут), протокола о намерениях.
🟠Информация. Готовность к раскрытию информации (b2b) - как происходит процесс принятия решения в компании, суммы на решения и т.д.
🟠Бюджет. Готовность к резервированию суммы в бюджете (b2b) - резерв на этот или следующий год.


➡️ Что делать если ответ нет?
🟠Задаем вопрос чего не хватило?
🟠Уточняем причины, работаем с возражениями, узнаем во что не верит клиент: не верит что мы сделаем продукт, не верит что продукт решает проблему, не видит ценности и т.д.
🟠Как ни странно, ответ нет - более ценный с продуктовой точки зрения, так как дает нам информацию о продукте ("голос рынка").
💯 Ответ дорого - значит клиент не понимает ценность продукта.

👉 Напишите в чат как вы убеждались в заинтересованности клиента в вашем продукте?

#Продажи #MVP

🗯74. Логика проверки ключевых гипотез


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

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


➡️ Логика проверки:

0️⃣ До общения с клиентами у нас должны быть зафиксированы наши предположения по клиентским задачам и проблемам. Фактически должен быть или заполнен продуктовый канвас или прописано ценностное предложение.

1️⃣ На этом шаге мы должны "услышать" от клиента "словами через рот" какие задачи решает клиент и какие есть проблемы в процессе выполнения данных задач. Подтверждаем наличие задач и проблем.

2️⃣ Мы должны подтвердить, что задачи, решаемые клиентом, являются высокочастотными, то есть часто выполняются в ходе какого-либо процесса. Например, ежедневно или еженедельно. Очень большая ошибка сфокусироваться на решении низкочастотных задач.
👉 Здесь же мы должны оцифровать проблематику клиента - понимать потери клиента при условии невыполнения задач. Нет потерь - нет проблемы, нет ценности, нет смысла покупать решение для отсутствующей проблемы.
⚫️Так же напомню здесь про лестницу Ханта - уровень осознания проблемы клиентом. Нет проблемы - клиент не осознает проблему, готов с ней мириться или вообще не знает о ее существовании (для нес - нецелевой клиент).

3️⃣ Понимая проблематику (задачи и проблемы) - мы можем сформировать способ их решения. Тут способ решения проблемы может появиться как после общения с клиентами, так и присуствовать как вариант решения изначально. Напомню, что продукт формирует некий результат работы продукта (артефакт) и именно этот артефакт интересен клиенту.
⚫️Продукт всего-лишь способ автоматизированного получения результата. Клиенты покупают не процесс создания результата, а именно сам результат (артефакт).
👉 Наша задача здесь получить явное подтверждение от клиента, что результат работы продукта (артефакт) решает его задачи или устраняет проблемы на пути решения задач. Фактически, мы показываем артефакт и получаем ответ: "Да, этот артефакт решает мою задачу".

4️⃣ Технический блок - мы для себя должны ответить на вопрос, что мы вообще сможем получить требуемый результат (артефакт). Сможем получить вообще, в рамках бюджета, в рамках сроков и т.д. Это блок технических гипотез про реализуемость продукта.

5️⃣ Мы должны получить четкий ответ, что результат (артефакт) имеет ценность для клиента. Это сильно коррелирует с блоком 2 - есть оцифровка проблем, есть потери - значит, можем вообще говорить о ценности результата для клиента.
👉 Логично, что нет потерь - нет ценности. Обратите внимание, что может ценность и есть, но для другого сегмента клиентов.

6️⃣ Последнее что проверяем, что ценности продукта достаточно для оплаты полученного клиентом результата работы продукта (артефакта).


➡️ Интересно, что не всегда все 6 пунктов сразу требует проверки. Очень часто какие-то из этих пунктов так или иначе уже определены и очевидны, например, наличие общеизвестных проблем. То есть, в каждом продукте (в каждом кейсе) ключевой фокус лежит только в некоторых областях их перечисленных. Как ни странно, чаще всего предопределено наличие проблемы и общая ценность от решения. Часто, суть решения так же очевидна, хотя это не значит, что не может быть альтернативных вариантов решения проблемы.

💯 Ключевые (рискованные) гипотезы, требующие обязательной проверки (неочевидные факты):
🟠Мы обязательно должны убедиться, что задачи клиента - высокочастотные и в том, что клиент может оцифровать потери.
🟠Мы обязательно должны проверить, что результат работы продукта (артефакт) решает проблему клиента.
🟠Мы обязательно должны получением оплаты подтвердить ценность результата (артефакта) для клиента.

➡️ Мы движемся последовательно и, не подтвердив старые гипотезы, не идем вперед. Очень часто отсутствие подтверждения гипотез может потребовать pivot в видении продукта.

#ПроверкаГипотез #MVP

🗯74. Логика проверки ключевых гипотез


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


➡️ Рассмотрим левую часть рисунка. В множестве слева мы опросили 10К людей и выяснили их предпочтения. Предположим, что проблему или заинтересованность в продукте подтвердили 2К, то есть пропорция составила 20%. В ходе общения с этими 2К потенциальных клиентов мы можем оценить их потери от наличия проблемы, что дает нам возможность предположить сколько они потенциально готовы заплатить за решение проблемы (обычно люди готовы платить 30%-40% от стоимости потерь).

➡️ Теперь понимая, что весь доступный рынок составляет 10М, мы можем предположить, что эта же проблема (или заинтересованность в продукте) присутствует у 2М человек - сохраняется пропорция 20%.

➡️ Понимая, что заинтересованность выразило 2М человек, стоит реалистично посмотреть на конверсию - пусть это будет 10%. Тогда наш достижимый рынок будет 200К клиентов (10% от 2M).

➡️ Понимая потери клиентов по результатам опроса, мы можем предположить, что у 200К такие же потери как было выяснено ранее и отсюда можем предположить сколько клиенты готовы заплатить за устранение проблем. Здесь потери определяют стоимость продукта - сумму, которую готов заплатить клиент.


👉 Данный пример показывает как на малой выборке (узком сегменте) можно подтвердить ценность продукта и экстраполировать результаты тестов на большой сегмент. Это относится ко всему: опросам, к подтверждению гипотез, к проверке ценности по прототипу продукта или MVP.

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

💯 Самое главное, что проверить гипотезы проще, быстрее и дешевле именно на узком сегменте (малой выборке) - нужно меньше усилий, ресурсов и затрат.

#ПроверкаГипотез #Продажи

🗯76. Кейс. Приложение для анализа затрат


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


➡️ Продукт: Приложение, собирающее ваши траты и показывающее сколько денег вы потратили за период и в каких категориях товаров.

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

Повышение ценности: С точки зрения JTBD какую задачу решают люди? Часть клиентов, хотят структурировать свои траты, что бы понять где сэкономить в будущем. Качественный мотив понятен, но давайте попробуем его оцифровать и показать ценность продукта.


➡️ Решение: к каждой категории добавим сумму потенциального кешбэка по карточным предложениям популярных банков. Теперь видна не только сумма трат по категориям, но и понятно сколько можно получить кэшбека за данную категорию. Можно добавить совет, максимизирующий полученный кэшбэк: что эту и эту категорию товаров лучше оплачивать с карты этого банка, а эти категории товаров - с карты этого банка. Есть советы по сокращению трат в рамках категорий, понятен график поступления средств и график переводов на эти карты.

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


👉 Как проверить ценность продукта? Нужно ли делать приложение для этого?
Ответ - нет. Предлагаем в качестве прототипа использовать отчет, который абстрактно покажет распределение трат по категориям и сумма кэшбека. Показать, что по данному отчету "заработали" и сэкономили столько денег.
Все, для продажи продукта кроме этого отчета больше ничего не нужно. Выходим на клиентов через ценностное предложение (с оцифровкой ценности), показываем отчет и предлагаем скачать приожение, что бы управлять и получить кэшбек. То есть протитип продукта - отчет, то есть результат, который генерирует продукт. Для проверки ценности этого достаточно, красивый отчет можно сделать за 2-3 дня, приложение делать не нужно.


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


#ПроверкаГипотез #MVP

🗯77. Кейс. Приложение для бронирования столиков в ресторане


➡ Продукт: Приложение, позволяющее забронировать столик в ресторане.
Стандартный вопрос - как наиболее быстро и дешево проверить ценность продукта для клиента. Что может быть прототипом продукта или MVP продукта?

➡ Общий совет: сегментируйтесь, тем более на этапе проверки гипотез. Выбирайте значимый, но максимально узкий сегмент. Под словами "узкий" может много чего иметься ввиду, в частности, GEO - район города, улица, определенный тип клиентов, определенный тип сервиса и т.д.
Касательно GEO при проверке гипотез - не замахивайтесь на весь город сразу, практика показывает, что не хватит сил и ресурсов закрыть весь город сразу - идите шаг за шагом.


👉 В этом случае предлагаю рассмотреть следующие варианты сегментации для проверки гипотез:
1️⃣ Ресторанный кластер. В каждом городе есть центральная улочка, где сконцентрированы рестораны. В приложении (на сайте) выкладываем данные по ресторанам, расположенным только на этой улице. Для проверки гипотез ценности можно или спарсить всю информацию о ресторанах (из открытых источников) или сразу договориться с ними о проведении пилота. Таким образом, у вас будут все рестораны на этой улочке, можно распространять информацию об этом сервисе или в этих ресторанах или на этой улочке (раздавать посетителям флаеры, визитки для бронирования). Кажется, что 2-3-х недель будет достаточно для изучения метрик спроса (раздали всего визиток vs получили переходы) и метрик удержания (когорты первой, второй, третей недели и т.д.).

2️⃣ Деловой кластер. Несколько бизнес центров и несколько кафе, где обедают те, кто работают в этих бизнес-центрах. Проверяем гипотезу, будут ли бронировать время для бизнес-ланчей. В бизнес центрах легко повесить рекламу приложения (сайта), отследить переходы.

3️⃣ Ресторанный фудкорт. В современных форматах на фудкорте присутствует 15-25 корнеров и поток посетителей. Можно так же очень концентрированно проверить гипотезу о востребованности продукта. Безусловно, нужно продумать что будем проверять, так как формат будет немного другой.


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


➡ Прототип, MVP: В качестве прототипа продукта может выступать сайт (посадочная страница) для бронирования. Там просто размещена информация о ресторанах и кнопка бронирования. Мы проверяем нажатия кнопки бронирования, при нажатии кнопки информация с сайта передается менеджеру, который уже "руками" закрывает все вопросы.

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


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

#ПроверкаГипотез #MVP

🗯79. Особенности проверки гипотез для маркетплейсов


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

1️⃣ Двухсторонние продукты
Самые распространенный вид продуктов. Сразу напомню, что есть утилитарные и функциональные двусторонние продукты, но это разделение мы сейчас не будем использовать.
🟠Роли: для наших целей важно, что есть собственнник продукта (владелец) и клиенты продукта. И взаимоотношения выстраиваются линейно, собственник vs клиенты.
🟠Проверка гипотез: для проверки мы должны найти клиентов, привлечь их и т.д. Собрав пул клиентов мы транслируем определенный месседж и по реакции клиентов на него интерпретируем их восприятие продукта. на самом деле мы добиваемся исполнения клиентами ключевого действия относительно продукта, которое заложено в нашу стратегию продаж.
🟠Ресурсы: у нас должны быть ресурсы для проверки гипотез - в общем случае время и средства на привлечение клиентов.

2️⃣ Трехсторонние продукты
Здесь уже все существенно сложнее. Большее количество ролей, требуется в 2-3 раза больше ресурсов для проверки гипотез.
🟠Роли: есть исходная роль собственника продукта (владельца) и есть роли клиентов и исполнителей (поставщиков).
🟠Проверка гипотез: осуществляется гораздо сложнее. Мы должны проверить гипотезы между клиентом и решением (1), между исполнителем и решением (2) и взаимодействие между клиентами и исполнителями (3).
Проблема осложняется тем, что если (1) и (2) мы еще можем проверить независимо друг от друга, то (3) мы сможем проверить только вместе: когда у нас уже на платформе есть пул или клиентов или исполнителей (поставщиков). То есть для этой проверки до привлечения другой стороны (условно, клиентов) мы должны уже обеспечить присутствие первой стороны (условно, поставщиков) в продукте.
⚫️Собираем клиентов, потом привлекаем поставщиков. Или собираем поставщиков, потом привлекаем клиентов.
🟠Ресурсы: трата ресурсов существенно возрастает. Нужно заложить двойной бюджет на проверку гипотез и бюджет на первоначальный сбор какой-либо из сторон. Есть возможности сделать это относительно небольшим бюджетом, но не нужно рассчитывать, что это осуществляется вообще без ресурсов. То есть бюджет (и действия) на сбор одной стороны и бюджет на привлечение второй стороны.

💯 Если рассматривать варианты проверки (1) или (2), то с точки зрения трудозатрат они чаще всего не эквиваленты. Скорее всего проблема одной стороны плюс-минус очевидна (прозрачна) и не требует серьезных проверок (не нужно подтверждать саму проблему только отдельные детали ее существования), а вот проблематика второй стороны не так уж очевидна и требует проверки по полной программе.

‼️ Более сложный случай - ключевая проверка (3). Как уже упоминалось, нам нужно сначала "физически" собрать одну сторону в продукте и, только потом, через затраты на рекламу привлечь в продукт вторую сторону для проверки их взаимодействия друг с другом через продукт. Трехсторонние продукты - парный танец, мы можем привлечь деньгами кого-то (одну сторону) на платформу, но без присутствия второй стороны в продукте, первая сторона - уйдет с нее. Обратите внимание, что времени на такой сбор - крайне мало, никто не будет ждать по пол-года в ожидании каких-либо действий в продукте.

⚠️ Пример: мы можем привлечь клиентов в маркеплейс через рекламу, но если там не будет поставщиков, которые закрывают запросы по поставкам, то клиенты оттуда уйдут и больше не вернутся - они получили негативный опыты (UX). Очень важно держать в голове опыт клиента в продукте, зачем возвращаться туда, где ничего не было?

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

‼️Вывод: в трехсторонних продуктах не возможно реализовать или проверить ценность без вовлечения двух сторон одновременно. Резерв ресурсов на первоначальный сбор участников продукта - обязателен.


#Маркетплейсы #Платформы