🗯74. Логика проверки ключевых гипотез Продолжаем обсуждение очень важной темы - что и какие гипотезы мы проверяем на старте (в продолжении поста 67 про ключевые гипотезы на старте). Почему это важно: мы должны отрефлексировать текущий статус нашей идеи (будущего продукта) и определиться с фокусом нашего внимания - сформировать локальный бэклог гипотез для проверки ключевых предположений о продукте. ➡️ Логика проверки: 0️⃣ До общения с клиентами у нас должны быть зафиксированы наши предположения по клиентским задачам и проблемам. Фактически должен быть или заполнен продуктовый канвас или прописано ценностное предложение. 1️⃣ На этом шаге мы должны "услышать" от клиента "словами через рот" какие задачи решает клиент и какие есть проблемы в процессе выполнения данных задач. Подтверждаем наличие задач и проблем. 2️⃣ Мы должны подтвердить, что задачи, решаемые клиентом, являются высокочастотными, то есть часто выполняются в ходе какого-либо процесса. Например, ежедневно или еженедельно. Очень большая ошибка сфокусироваться на решении низкочастотных задач. 👉 Здесь же мы должны оцифровать проблематику клиента - понимать потери клиента при условии невыполнения задач. Нет потерь - нет проблемы, нет ценности, нет смысла покупать решение для отсутствующей проблемы. ⚫️Так же напомню здесь про лестницу Ханта - уровень осознания проблемы клиентом. Нет проблемы - клиент не осознает проблему, готов с ней мириться или вообще не знает о ее существовании (для нес - нецелевой клиент). 3️⃣ Понимая проблематику (задачи и проблемы) - мы можем сформировать способ их решения. Тут способ решения проблемы может появиться как после общения с клиентами, так и присуствовать как вариант решения изначально. Напомню, что продукт формирует некий результат работы продукта (артефакт) и именно этот артефакт интересен клиенту. ⚫️Продукт всего-лишь способ автоматизированного получения результата. Клиенты покупают не процесс создания результата, а именно сам результат (артефакт). 👉 Наша задача здесь получить явное подтверждение от клиента, что результат работы продукта (артефакт) решает его задачи или устраняет проблемы на пути решения задач. Фактически, мы показываем артефакт и получаем ответ: "Да, этот артефакт решает мою задачу". 4️⃣ Технический блок - мы для себя должны ответить на вопрос, что мы вообще сможем получить требуемый результат (артефакт). Сможем получить вообще, в рамках бюджета, в рамках сроков и т.д. Это блок технических гипотез про реализуемость продукта. 5️⃣ Мы должны получить четкий ответ, что результат (артефакт) имеет ценность для клиента. Это сильно коррелирует с блоком 2 - есть оцифровка проблем, есть потери - значит, можем вообще говорить о ценности результата для клиента. 👉 Логично, что нет потерь - нет ценности. Обратите внимание, что может ценность и есть, но для другого сегмента клиентов. 6️⃣ Последнее что проверяем, что ценности продукта достаточно для оплаты полученного клиентом результата работы продукта (артефакта). ➡️ Интересно, что не всегда все 6 пунктов сразу требует проверки. Очень часто какие-то из этих пунктов так или иначе уже определены и очевидны, например, наличие общеизвестных проблем. То есть, в каждом продукте (в каждом кейсе) ключевой фокус лежит только в некоторых областях их перечисленных. Как ни странно, чаще всего предопределено наличие проблемы и общая ценность от решения. Часто, суть решения так же очевидна, хотя это не значит, что не может быть альтернативных вариантов решения проблемы. 💯 Ключевые (рискованные) гипотезы, требующие обязательной проверки (неочевидные факты): 🟠Мы обязательно должны убедиться, что задачи клиента - высокочастотные и в том, что клиент может оцифровать потери. 🟠Мы обязательно должны проверить, что результат работы продукта (артефакт) решает проблему клиента. 🟠Мы обязательно должны получением оплаты подтвердить ценность результата (артефакта) для клиента. ➡️ Мы движемся последовательно и, не подтвердив старые гипотезы, не идем вперед. Очень часто отсутствие подтвер