305. Lead users: кто такие «лидирующие пользователи» по Эрику фон Хиппелю
Если искать инсайты только у «среднего» клиента, можно опоздать с продуктом на годы. Эрик фон Хиппель (Eric von Hippel), исследователь из MIT, описал другую точку опоры — lead users, лидирующих пользователей. Идея изложена в работах по user innovation и в книге Democratizing Innovation (2005).
Lead users — те, кто обладает двумя ключевыми характеристиками:
1. Они сталкиваются с потребностями, которые впоследствии станут общими на рынке, — но сталкиваются с ними за месяцы или годы до того, как большинство участников этого рынка их испытает.
2. Они получают значительную выгоду, находя решение для удовлетворения своих потребностей — часто сами, до появления готового продукта на рынке.
Обе характеристики важны сразу.
Первая — про опережение рынка: не «любит всё новое», а «живёт с проблемой, которая скоро станет массовой».
Вторая — про мотивацию: человеку реально больно/дорого/неудобно, поэтому он уже что-то придумал, доработал, склеил из костылей — и готов этим делиться, если видит смысл.
Чем lead users не являются
— Не просто early adopters по Роджерсу. Инноватор пробует новое ради новизны; lead user может вообще не пользоваться вашей категорией — он уже решил задачу иначе.
— Не «самый лояльный клиент». Фанат текущего продукта расскажет, как улучшить фичи. Lead user часто живёт за пределами вашего продукта — с самодельным workaround (собственным способом решить проблему).
— Не эксперт «вообще». Нужна связка «опережающая потребность + личная выгода от решения», а не должность в CV.
Ограничение
Lead users хороши для поиска нового, но плохи как единственный голос рынка: их потребности могут опережать массу слишком сильно. Поэтому после интервью с lead users проверяют, когда и для кого эта потребность станет общей — custdev, метрики, пилот.
В сухом остатке: lead users — пользователи с опережающей потребностью (раньше рынка) и с высокой личной выгодой от её решения; часто уже имеют самодельные обходные пути.
#custdev@custdevlab #методика@custdevlab #customerdiscovery@custdevlab #полезное@custdevlab
Если искать инсайты только у «среднего» клиента, можно опоздать с продуктом на годы. Эрик фон Хиппель (Eric von Hippel), исследователь из MIT, описал другую точку опоры — lead users, лидирующих пользователей. Идея изложена в работах по user innovation и в книге Democratizing Innovation (2005).
Lead users — те, кто обладает двумя ключевыми характеристиками:
1. Они сталкиваются с потребностями, которые впоследствии станут общими на рынке, — но сталкиваются с ними за месяцы или годы до того, как большинство участников этого рынка их испытает.
2. Они получают значительную выгоду, находя решение для удовлетворения своих потребностей — часто сами, до появления готового продукта на рынке.
Обе характеристики важны сразу.
Первая — про опережение рынка: не «любит всё новое», а «живёт с проблемой, которая скоро станет массовой».
Вторая — про мотивацию: человеку реально больно/дорого/неудобно, поэтому он уже что-то придумал, доработал, склеил из костылей — и готов этим делиться, если видит смысл.
Чем lead users не являются
— Не просто early adopters по Роджерсу. Инноватор пробует новое ради новизны; lead user может вообще не пользоваться вашей категорией — он уже решил задачу иначе.
— Не «самый лояльный клиент». Фанат текущего продукта расскажет, как улучшить фичи. Lead user часто живёт за пределами вашего продукта — с самодельным workaround (собственным способом решить проблему).
— Не эксперт «вообще». Нужна связка «опережающая потребность + личная выгода от решения», а не должность в CV.
Ограничение
Lead users хороши для поиска нового, но плохи как единственный голос рынка: их потребности могут опережать массу слишком сильно. Поэтому после интервью с lead users проверяют, когда и для кого эта потребность станет общей — custdev, метрики, пилот.
В сухом остатке: lead users — пользователи с опережающей потребностью (раньше рынка) и с высокой личной выгодой от её решения; часто уже имеют самодельные обходные пути.
#custdev@custdevlab #методика@custdevlab #customerdiscovery@custdevlab #полезное@custdevlab
3✍3🔥2🌭2👍1
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