306. Lead users: пример и custdev
Примеры из практики и литературы
— Горные велосипеды. В 1970-х энтузиасты сами модифицировали рамы и тормоза под спуск с гор — за годы до того, как индустрия оформила категорию MTB. Классический кейс фон Хиппеля: инновация шла от пользователей, не от R&D отдела.
— Медицина и 3M. В методике Lead User Method (развита совместно с 3M) команда намеренно ищет врачей и специалистов с «опережающими» проблемами — так, например, появлялись новые материалы и решения для хирургии, которых рынок ещё не формулировал.
— B2B и «свои костыли». Бухгалтер, который уже собрал макросы в Excel, логист, который ведёт учёт в Notion, инженер с самописным скриптом — часто lead users в зародыше: потребность уже есть, выгода от решения высокая, рынок догонит позже.
Зачем это custdev
Lead users — один из самых плотных источников прорывных, а не инкрементальных идей. В интервью с ними ищут не «понравится ли кнопка», а:
— какую работу человек уже пытается закрыть сам;
— какие обходные пути использует сегодня;
— что станет общей болью рынка через 6–18 месяцев;
— за что он уже платит временем, деньгами, репутацией — это маркер «значительной выгоды».
Их стоит искать там, где проблема острая и ещё слабо закрыта продуктами: профессиональные сообщества, узкие форумы, «хакеры» своей задачи, клиенты с нестандартным use case — см. также источники респондентов.
В сухом остатке: Это не early adopters и не фанаты продукта — скорее «завтрашний рынок сегодня». В custdev их ищут ради прорывных инсайтов, но проверяют, когда потребность станет массовой.
#custdev@custdevlab #методика@custdevlab #customerdiscovery@custdevlab #полезное@custdevlab
Примеры из практики и литературы
— Горные велосипеды. В 1970-х энтузиасты сами модифицировали рамы и тормоза под спуск с гор — за годы до того, как индустрия оформила категорию MTB. Классический кейс фон Хиппеля: инновация шла от пользователей, не от R&D отдела.
— Медицина и 3M. В методике Lead User Method (развита совместно с 3M) команда намеренно ищет врачей и специалистов с «опережающими» проблемами — так, например, появлялись новые материалы и решения для хирургии, которых рынок ещё не формулировал.
— B2B и «свои костыли». Бухгалтер, который уже собрал макросы в Excel, логист, который ведёт учёт в Notion, инженер с самописным скриптом — часто lead users в зародыше: потребность уже есть, выгода от решения высокая, рынок догонит позже.
Зачем это custdev
Lead users — один из самых плотных источников прорывных, а не инкрементальных идей. В интервью с ними ищут не «понравится ли кнопка», а:
— какую работу человек уже пытается закрыть сам;
— какие обходные пути использует сегодня;
— что станет общей болью рынка через 6–18 месяцев;
— за что он уже платит временем, деньгами, репутацией — это маркер «значительной выгоды».
Их стоит искать там, где проблема острая и ещё слабо закрыта продуктами: профессиональные сообщества, узкие форумы, «хакеры» своей задачи, клиенты с нестандартным use case — см. также источники респондентов.
В сухом остатке: Это не early adopters и не фанаты продукта — скорее «завтрашний рынок сегодня». В custdev их ищут ради прорывных инсайтов, но проверяют, когда потребность станет массовой.
#custdev@custdevlab #методика@custdevlab #customerdiscovery@custdevlab #полезное@custdevlab
9✍2🔥2🌭2👍1
307. Три уровня воркараундов (workaround)
Пользовательский (User Workaround)
Клиент сам находит способ решить свою задачу, потому что в продукте нет нужной кнопки.
Пример: В приложении для заметок нельзя форматировать текст жирным. Пользователь начинает писать слова КАПСЛОКОМ или выделять их звездочками *вот так*.
Это явный сигнал для продакта: функция востребована.
Операционный / Ручной (Operational Workaround)
Команда стартапа имитирует автоматическую работу продукта вручную («эффект Волшебника Изумрудного города»). Это классический подход в Customer Development и Lean Startup.
Пример: Стартап запустил сайт по подбору витаминов. Робот на сайте обещает «умный алгоритм анализа». На самом деле, когда пользователь отправляет анкету, данные приходят на почту основателю стартапа, и он вручную за 20 минут собирает PDF-отчет.
Технический (Technical Workaround / «Костыль»)
Разработчики пишут быстрый код, который временно решает критическую проблему (баг), чтобы приложение не падало, пока они ищут фундаментальное решение.
Пример: Упала интеграция с платежной системой. Вместо долгой починки кода разработчики за 5 минут выводят на экран плашку: «Извините, мы временно принимаем переводы по СБП на этот номер».
В сухом остатке: воркараунды бывают трех уровней: пользовательский, операционный и технический.
#полезное@custdevlab
Пользовательский (User Workaround)
Клиент сам находит способ решить свою задачу, потому что в продукте нет нужной кнопки.
Пример: В приложении для заметок нельзя форматировать текст жирным. Пользователь начинает писать слова КАПСЛОКОМ или выделять их звездочками *вот так*.
Это явный сигнал для продакта: функция востребована.
Операционный / Ручной (Operational Workaround)
Команда стартапа имитирует автоматическую работу продукта вручную («эффект Волшебника Изумрудного города»). Это классический подход в Customer Development и Lean Startup.
Пример: Стартап запустил сайт по подбору витаминов. Робот на сайте обещает «умный алгоритм анализа». На самом деле, когда пользователь отправляет анкету, данные приходят на почту основателю стартапа, и он вручную за 20 минут собирает PDF-отчет.
Технический (Technical Workaround / «Костыль»)
Разработчики пишут быстрый код, который временно решает критическую проблему (баг), чтобы приложение не падало, пока они ищут фундаментальное решение.
Пример: Упала интеграция с платежной системой. Вместо долгой починки кода разработчики за 5 минут выводят на экран плашку: «Извините, мы временно принимаем переводы по СБП на этот номер».
В сухом остатке: воркараунды бывают трех уровней: пользовательский, операционный и технический.
#полезное@custdevlab
10✍3👍2🌭2🔥1
308. Тестирование нескольких гипотез/прототипов за один спринт (подход GV)
Когда уместно проверять 2–3 варианта за спринт тестирования
HADI и CDDC обычно предполагают последовательную проверку гипотез. В GV/Design Sprint рекомендуют использовать иной подход: за спринт тестируют 2–3 разных value proposition (кружочек+квадратик) или прототипа одновременно.
Когда это уместно
— Если есть несколько равно правдоподобных гипотез о ценности или позиционировании
— Скорость получения результатов важнее
— Ресурсы discovery-этапа позволяют вести несколько веток исследования
Плюсы: быстрее получаете сравнение продуктовых гипотез между собой; меньше риска зациклиться на одном варианте; можно быстрее двигаться дальше, понимая перспективный прототип.
Минусы: выборка сильно дробится, поэтому сложнее будет изолировать причину получения результата исследования; выше нагрузка на discovery-команду.
Параллельное тестирование не заменяет последовательную проверку «узлами». Его используют, когда сравнивают варианты на одном уровне (например, три формулировки оффера), а не цепочку гипотез.
В сухом остатке: параллельное тестирование 2–3 вариантов за спринт — для сравнения офферов или формулировок; для цепочек гипотез лучше последовательная проверка.
#гипотезы@custdevlab #методика@custdevlab #hadi@custdevlab
Когда уместно проверять 2–3 варианта за спринт тестирования
HADI и CDDC обычно предполагают последовательную проверку гипотез. В GV/Design Sprint рекомендуют использовать иной подход: за спринт тестируют 2–3 разных value proposition (кружочек+квадратик) или прототипа одновременно.
Когда это уместно
— Если есть несколько равно правдоподобных гипотез о ценности или позиционировании
— Скорость получения результатов важнее
— Ресурсы discovery-этапа позволяют вести несколько веток исследования
Плюсы: быстрее получаете сравнение продуктовых гипотез между собой; меньше риска зациклиться на одном варианте; можно быстрее двигаться дальше, понимая перспективный прототип.
Минусы: выборка сильно дробится, поэтому сложнее будет изолировать причину получения результата исследования; выше нагрузка на discovery-команду.
Параллельное тестирование не заменяет последовательную проверку «узлами». Его используют, когда сравнивают варианты на одном уровне (например, три формулировки оффера), а не цепочку гипотез.
В сухом остатке: параллельное тестирование 2–3 вариантов за спринт — для сравнения офферов или формулировок; для цепочек гипотез лучше последовательная проверка.
#гипотезы@custdevlab #методика@custdevlab #hadi@custdevlab
8✍3👍2🌭2
Очередная пятничная #карусель@custdevlab про каналы поиска респодентов
4🔥4👍1