224. Этапы jtbd-методологии: итог
Собрали в один пост все этапы jtbd-методологии:
1. Первая мысль о продукте (First thought)
2. Пассивный поиск (Passive looking)
3. Активный поиск (Active looking)
4. Принятие решения о покупке (Deciding)
5. Онбординг (Onboarding)
6. Использования в процессе (Ongoing Use)
7. Офбординг (Offboarding)
Между этими процессами происходят события перехода. Что-то стимулирует осознанный или неосознанный переход от одного этапа на другой. Задачей custdev-процедур является выявление этого события для более эффективного использования в стратегии продвижения.
В сухом остатке: этапы jtbd и переход между ними помогают понять процесс мышления пользователя.
#jtbd@custdevlab #этапыjtbd@custdevlab
Собрали в один пост все этапы jtbd-методологии:
1. Первая мысль о продукте (First thought)
2. Пассивный поиск (Passive looking)
3. Активный поиск (Active looking)
4. Принятие решения о покупке (Deciding)
5. Онбординг (Onboarding)
6. Использования в процессе (Ongoing Use)
7. Офбординг (Offboarding)
Между этими процессами происходят события перехода. Что-то стимулирует осознанный или неосознанный переход от одного этапа на другой. Задачей custdev-процедур является выявление этого события для более эффективного использования в стратегии продвижения.
В сухом остатке: этапы jtbd и переход между ними помогают понять процесс мышления пользователя.
#jtbd@custdevlab #этапыjtbd@custdevlab
24👍9🔥7🌭2🤔1🤩1👾1
225. MVP не всегда проще самого продукта
MVP — это версия продукта, обладающая минимально ощутимой ценностью для потребителя. Создание MVP является целью этапа Customer Discovery и перехода на этап Customer Validation.
Крайне важно создать MVP таким, чтобы можно было протестировать гипотезу, которая чаще всего является сложносоставной. Для этого мы создали CDDC-канвас.
Считается, что MVP должен быть дешевым, простым и не всегда удобным. На самом деле существует еще одно очень важное требование к MVP: он должен давать возможность собирать метрики, необходимые как для HADI-циклов, так и для CDDC.
Но главное — возможность проверять гипотезы!
Предположим, нам нужно MVP для тестирвоания такрифной сетки. По сути, мы можем сделать лендтинг с описанием тарифов. Но стоит понимать, что сами по себе тарифы — это проверка гипотезы о том, за члю пользователи готовы платить, а за что не готовы.
Нужно ли делать бесплатный период? Или сразу платный, но дешевый?
Сколько дней/недель/месяцев этот период должен быть?
Нужно ли делать часть функций бесплатной, а другую — платной?
Какую часть сделать бесплатной?
Это все гипотезы. И для их тестирования (проверки) нужно... MVP.
Поэтому, по сути, для тестирования этих гипотез можно делать много разных MVP, по сути один или даже несколько. Но можно проверять это через конструктор MVP — тарифы должны быть гибкими, чтобы быстро изменять тарифную сетку, перенастриавать условия и получать метрики для принятия решений.
Получается, что MVP может быть сложнее обычного продукта. Особенно, если главная цель проверки гипотез — скорость, а не стоимость.
В сухом остатке: MVP может быть сложнее самого продукта; главное — скорость, данные и гибкость.
#mvp@custdevlab #гипотезы@custdevlab
P.S. Если есть прототип продукта, но он не позволяет собирать нужные для дальнейшего развития данные, то это не MVP.
MVP — это версия продукта, обладающая минимально ощутимой ценностью для потребителя. Создание MVP является целью этапа Customer Discovery и перехода на этап Customer Validation.
Крайне важно создать MVP таким, чтобы можно было протестировать гипотезу, которая чаще всего является сложносоставной. Для этого мы создали CDDC-канвас.
Считается, что MVP должен быть дешевым, простым и не всегда удобным. На самом деле существует еще одно очень важное требование к MVP: он должен давать возможность собирать метрики, необходимые как для HADI-циклов, так и для CDDC.
Но главное — возможность проверять гипотезы!
Предположим, нам нужно MVP для тестирвоания такрифной сетки. По сути, мы можем сделать лендтинг с описанием тарифов. Но стоит понимать, что сами по себе тарифы — это проверка гипотезы о том, за члю пользователи готовы платить, а за что не готовы.
Нужно ли делать бесплатный период? Или сразу платный, но дешевый?
Сколько дней/недель/месяцев этот период должен быть?
Нужно ли делать часть функций бесплатной, а другую — платной?
Какую часть сделать бесплатной?
Это все гипотезы. И для их тестирования (проверки) нужно... MVP.
Поэтому, по сути, для тестирования этих гипотез можно делать много разных MVP, по сути один или даже несколько. Но можно проверять это через конструктор MVP — тарифы должны быть гибкими, чтобы быстро изменять тарифную сетку, перенастриавать условия и получать метрики для принятия решений.
Получается, что MVP может быть сложнее обычного продукта. Особенно, если главная цель проверки гипотез — скорость, а не стоимость.
В сухом остатке: MVP может быть сложнее самого продукта; главное — скорость, данные и гибкость.
#mvp@custdevlab #гипотезы@custdevlab
12✍3👍3🤔2
226. Управление ожиданием: правило последнего впечатления (peak-end rule)
Правило последнего впечатления было изучено Даниелем Канеманом и коллегами в 1990-ых. Проведя несколько экспериментов исследователи сформулировали ряд правил, назвав их "peak-end rule". На основе этих правил может быть построено управление ожиданиями для продукта.
Суть эксперимента пересказывать не будем, но вывод следующий: среди вереницы последовательных событий, которые включает определенный опыт пользователя, запоминается не усредненное значение пережитых эмоций, а пиковое и последнее.
Например, опыт использования продукта. Он состоит из множества «работ» и может быть визуализирован в CJM или LXM. В обеих моделях принято спрашивать про эмоции, потому что пользователь будет судить обо всем опыте использования продукта по пиковому значению опыта (как положительному, так и отрицательному), и по итоговому опыту на этом пути.
Это еще раз подтверждает важность офбординга, так как скорее всего он запомнится в качестве итогового опыта взаимодействия с продуктом.
Как это можно использовать в продуктовом управлении. Если мы по результатам анализа понимаем, что у нас есть пиковый негативный опыт, следует добавить что-то в продукт, чтобы после пикового негативного опыта был опыт с бОльшим позитивным эффектом, пусть и не таким сильным. Подобный подход «сгладит» общее впечатление о продукте. А, возможно, и позволит избежать сильно негативного отзыва.
Правило универсальное. Работает в кино, медицине, отношениях: если последнее событие было очень сильным и негативным, оно исказит общие воспоминания о всем процессе.
В сухом остатке: правило "peak-end rule" нужно использовать для управления ожиданиями и управления пользовательским опытом.
#управлениеожиданиями@custdevlab
Правило последнего впечатления было изучено Даниелем Канеманом и коллегами в 1990-ых. Проведя несколько экспериментов исследователи сформулировали ряд правил, назвав их "peak-end rule". На основе этих правил может быть построено управление ожиданиями для продукта.
Суть эксперимента пересказывать не будем, но вывод следующий: среди вереницы последовательных событий, которые включает определенный опыт пользователя, запоминается не усредненное значение пережитых эмоций, а пиковое и последнее.
Например, опыт использования продукта. Он состоит из множества «работ» и может быть визуализирован в CJM или LXM. В обеих моделях принято спрашивать про эмоции, потому что пользователь будет судить обо всем опыте использования продукта по пиковому значению опыта (как положительному, так и отрицательному), и по итоговому опыту на этом пути.
Это еще раз подтверждает важность офбординга, так как скорее всего он запомнится в качестве итогового опыта взаимодействия с продуктом.
Как это можно использовать в продуктовом управлении. Если мы по результатам анализа понимаем, что у нас есть пиковый негативный опыт, следует добавить что-то в продукт, чтобы после пикового негативного опыта был опыт с бОльшим позитивным эффектом, пусть и не таким сильным. Подобный подход «сгладит» общее впечатление о продукте. А, возможно, и позволит избежать сильно негативного отзыва.
Правило универсальное. Работает в кино, медицине, отношениях: если последнее событие было очень сильным и негативным, оно исказит общие воспоминания о всем процессе.
В сухом остатке: правило "peak-end rule" нужно использовать для управления ожиданиями и управления пользовательским опытом.
#управлениеожиданиями@custdevlab
11👍5🔥3🌭2✍1🤔1
227. Информирование не равно обучению
Функция обучения для продукта очень важна. Если пользователь не умеет его использовать, то продукт вряд ли будет успешным.
Роль онбординга в этом процессе возрастает многократно. Второй попытки произвести первое впечатление может и не случиться.
Но просто рассказать о функциях продукта — это еще не научить. Нельзя заменять обучение информированием.
Также важно понимать, что научить пользователя невозможно. Он может только научиться сам. Важно создать для него условия для этого обучения/научения.
Допустим, в продукте есть кнопка, которая позволяет отфильтровать товары в каталоге. Просто рассказать об этом, означает просто проинформировать. Дать человеку возможность нажать на эту кнопку и увидеть результат уже лучше, но еще не обучение.
Дать задание отфильтровать товары определенным образом, дать возможность пользователю это задание выполнить, проверить его и вознаградить за правильно выполненное задание — это уже ближе к обучению.
Ошибки это тоже неотъемлемая часть обучения. Если пользователь что-то сделал неправильно, нужно ему об этом рассказать, объяснить и показать правильный путь решения.
Зачем так сложно? Иногда это действительно слишком. Но, как говорил Суворов: «Тяжело в учении, легко в бою!»
К тому же, приведенный пример фильтрации товаров в каталоге, скорее всего, будет похож на какие-то аналоги, то есть модель поведения достаточно осознаваемая. Например, на фильтрацию на маркетплейсах. То есть так «заморачиваться» с обучением не нужно, если процесс в целом пользователю знаком.
Подобный подход скорее нужен для продуктов, функции которых меняют привычное поведение. Как Фудфокс на рынке доставки еды или Мовиста на рынке мультимодальных перевозок.
В сухом остатке: обучение не равно информирование; мало просто рассказать, нужно сформировать петлю научения, иначе результата не будет
#обучение@custdevlab
Функция обучения для продукта очень важна. Если пользователь не умеет его использовать, то продукт вряд ли будет успешным.
Роль онбординга в этом процессе возрастает многократно. Второй попытки произвести первое впечатление может и не случиться.
Но просто рассказать о функциях продукта — это еще не научить. Нельзя заменять обучение информированием.
Также важно понимать, что научить пользователя невозможно. Он может только научиться сам. Важно создать для него условия для этого обучения/научения.
Допустим, в продукте есть кнопка, которая позволяет отфильтровать товары в каталоге. Просто рассказать об этом, означает просто проинформировать. Дать человеку возможность нажать на эту кнопку и увидеть результат уже лучше, но еще не обучение.
Дать задание отфильтровать товары определенным образом, дать возможность пользователю это задание выполнить, проверить его и вознаградить за правильно выполненное задание — это уже ближе к обучению.
Ошибки это тоже неотъемлемая часть обучения. Если пользователь что-то сделал неправильно, нужно ему об этом рассказать, объяснить и показать правильный путь решения.
Зачем так сложно? Иногда это действительно слишком. Но, как говорил Суворов: «Тяжело в учении, легко в бою!»
К тому же, приведенный пример фильтрации товаров в каталоге, скорее всего, будет похож на какие-то аналоги, то есть модель поведения достаточно осознаваемая. Например, на фильтрацию на маркетплейсах. То есть так «заморачиваться» с обучением не нужно, если процесс в целом пользователю знаком.
Подобный подход скорее нужен для продуктов, функции которых меняют привычное поведение. Как Фудфокс на рынке доставки еды или Мовиста на рынке мультимодальных перевозок.
В сухом остатке: обучение не равно информирование; мало просто рассказать, нужно сформировать петлю научения, иначе результата не будет
#обучение@custdevlab
13✍3👍3🌭2👾2
228. Синдром «создателя чат-бота» (chat-bot creation syndrome)
Синдром создателя чат-ботов это псевдо-навык, дающий ощущение тестирования продукта через создание чат-бота.
Надо протестировать потребительскую гипотезу? Делаем чат-бот.
По сравнению с мобильным приложением, например, это гораздо быстрее, дешевле и проще. С учетом современного развития ИИ, даже не особо понимая программирование можно сделать чат-бот (да-да, можно, проверено).
Но вот в чем проблема, продукт, сделанный через чат-бот, тестирует гипотезу поведения потребителя в чат-боте в том мессенджере, где он располагается. То есть он не проверяет гипотезу в целом, он именно проверяет возможность решения ее через чат-бот. Ни больше, ни меньше.
В CDDC чат-боты позволяют тестировать ранние (левые) части гипотезы. Но не гипотезу в целом.
Пилить чат-боты еще не значит стать серийным предпринимателем. Пилить чат-боты это значит пилить чат-боты. А синдром создателя чат-ботов для предпринимателя скорее минус, чем плюс.
В сухом остатке: создавать чат-боты это не полноценный custdev; это часто вовсе не Custdev.
#интересное@custdevlab
Синдром создателя чат-ботов это псевдо-навык, дающий ощущение тестирования продукта через создание чат-бота.
Надо протестировать потребительскую гипотезу? Делаем чат-бот.
По сравнению с мобильным приложением, например, это гораздо быстрее, дешевле и проще. С учетом современного развития ИИ, даже не особо понимая программирование можно сделать чат-бот (да-да, можно, проверено).
Но вот в чем проблема, продукт, сделанный через чат-бот, тестирует гипотезу поведения потребителя в чат-боте в том мессенджере, где он располагается. То есть он не проверяет гипотезу в целом, он именно проверяет возможность решения ее через чат-бот. Ни больше, ни меньше.
В CDDC чат-боты позволяют тестировать ранние (левые) части гипотезы. Но не гипотезу в целом.
Пилить чат-боты еще не значит стать серийным предпринимателем. Пилить чат-боты это значит пилить чат-боты. А синдром создателя чат-ботов для предпринимателя скорее минус, чем плюс.
В сухом остатке: создавать чат-боты это не полноценный custdev; это часто вовсе не Custdev.
#интересное@custdevlab
11👍7✍2🌭1👾1
229. Custdev это не про методику, это про mindset
Custdev по своей сути это не столько набор методов и методик, сколько способ мыслить, т.е. подход к решению задачи.
Можно изучить customer interview досканально, но без сформированного образа мышления сам по себе инструмент мало эффективен. Можно понимать другие custdev-процедуры, но если нет понимания о целях применения, пользы для продукта будет мало.
То же самое можно сказать про JTBD и AJTBD. Это больше про мышление, чем про инструменты.
В сухом остатке: важнее сформировать mindset (образ мышления), чем научиться применять инструменты.
#полезное@custdevlab
Custdev по своей сути это не столько набор методов и методик, сколько способ мыслить, т.е. подход к решению задачи.
Можно изучить customer interview досканально, но без сформированного образа мышления сам по себе инструмент мало эффективен. Можно понимать другие custdev-процедуры, но если нет понимания о целях применения, пользы для продукта будет мало.
То же самое можно сказать про JTBD и AJTBD. Это больше про мышление, чем про инструменты.
В сухом остатке: важнее сформировать mindset (образ мышления), чем научиться применять инструменты.
#полезное@custdevlab
10✍2👍2🌭2👾1
LXM-based.pdf
43.6 KB
230. LXM-based customer interview
Этапы принятия решения о покупке в соотстветствии с JTBD-подходом мы недавно описывали. Если узнать у потребителя про каждый этап подробно, получится отличная база для построения LXM.
Остается только составить список вопросов для каждого этапа. А также понимать, что между этапами происходит триггерное событие, о котором также нужно узнать во время интервью.
Поэтому мы подготовили еще один канвас, который позволяет максимально подробно построить LXM. В модели указаны основные вопросы, а также уточняющите. Присутствуют теги, опираясь на которые можно понять, раскрыт этап полностью, или что-то еще нужно уточнить. Даны примеры уточняющих вопросов.
Правда, про правило «Пяти почему» забывать не стоит.
В сухом остатке: интервью, основанное на модели LXM позволит максимально подробно описать процесс принятия решения о покупке в товарной категории.
#lxm@custdevlab #customerinterview@custdevlab
Этапы принятия решения о покупке в соотстветствии с JTBD-подходом мы недавно описывали. Если узнать у потребителя про каждый этап подробно, получится отличная база для построения LXM.
Остается только составить список вопросов для каждого этапа. А также понимать, что между этапами происходит триггерное событие, о котором также нужно узнать во время интервью.
Поэтому мы подготовили еще один канвас, который позволяет максимально подробно построить LXM. В модели указаны основные вопросы, а также уточняющите. Присутствуют теги, опираясь на которые можно понять, раскрыт этап полностью, или что-то еще нужно уточнить. Даны примеры уточняющих вопросов.
Правда, про правило «Пяти почему» забывать не стоит.
В сухом остатке: интервью, основанное на модели LXM позволит максимально подробно описать процесс принятия решения о покупке в товарной категории.
#lxm@custdevlab #customerinterview@custdevlab
10👍4✍2🌭2🔥1👾1
Напоминаем, что мы уже давно задумали и сделали новый канал
👨🏼💻 Паспортичка
Там размещаем реальные стенограммы реальных интервью. Тематики самые разные.
Можно просто читать вместо новостей, а можно использовать как интересный источник знаний о поведении потребителей. Ведь никто не расскажет о своем поведении лучше, чем сам потребитель.
Приятного чтения!
👨🏼💻 Паспортичка
Там размещаем реальные стенограммы реальных интервью. Тематики самые разные.
Можно просто читать вместо новостей, а можно использовать как интересный источник знаний о поведении потребителей. Ведь никто не расскажет о своем поведении лучше, чем сам потребитель.
Приятного чтения!
Telegram
Паспортичка
Интервью №15
Про подбор участников в команду для решения заданий во время обучения в вузе
https://telegra.ph/Intervyu-15-09-06
#образование@pasportichka #команднаяработа@pasportichka #межгрупповоевзаимодействие@pasportichka
Про подбор участников в команду для решения заданий во время обучения в вузе
https://telegra.ph/Intervyu-15-09-06
#образование@pasportichka #команднаяработа@pasportichka #межгрупповоевзаимодействие@pasportichka
11👍6✍3🌭2
231. Почему на рынке выигрывают продукты, которые выполняют больше работ
В конкурентной борьбе на рынке чаще выигрывают продукты, которые могут выполнять больше работ, чем их конкуренты. Говоря иначе, продукты, которые являются более универсальными решениями, по сравнению с узко специализированными.
Например, в нулевые были популярны навигаторы — целая товарная категория, которая в итоге была вытеснена смартфонами. Навигатор — это специальное устройство со своими характеристиками (размер экрана, способ загрузки карт, способ крепления и пр.), которая была наряду с видеорегистратором желанным девайсом любого водителя. Мобильный интернет тогда был редкостью, а пробки не учитывались вовсе, или учитывались, но не в режиме реального времени, а как динамическая модель, основанная на статистических данных.
Шли годы, смартфоны стали доступнее и функциональнее. И навигаторы превратились из отдельного устройства в приложение на смартфоне.
Смартфон «убил» товарную категорию «навигаторов». То же самое смартфон сделал и с MP3-плеерами. И фотоаппаратами. И много с чем еще. Потому что смартфон может выполнять много разных работ: от позвонить, записать заметку, сделать фотографию до послушать музыку, посмотреть кино и так далее.
ChatGPT является более универсальным продуктом, чем поисковик (правда, пока это скорее вопрос времени). Но, например, работу репетиторов по иностранным языкам он, скорее всего, тоже убъет. Как уже убивает работу Фотошопа и других фото- и видео-редакторов.
Суть в том, что чем больше работ можно выполнить одним продуктом, тем он более конкурентоспособен.
В дополнение вопрос обучения, т.е. если нужно переучиваться или изучать новый продукт для решения отдельной работы, текущий продукт + имеющиеся о нем знания дадут сильное конкурентное преимущество.
В сухом остатке: на рынке выживает продукт, который решает больше работ, чем его конкуренты; еще лучше, если переобучение продукту не требуется.
#jtbd@custdevlab #конкуренция@custdevlab
В конкурентной борьбе на рынке чаще выигрывают продукты, которые могут выполнять больше работ, чем их конкуренты. Говоря иначе, продукты, которые являются более универсальными решениями, по сравнению с узко специализированными.
Например, в нулевые были популярны навигаторы — целая товарная категория, которая в итоге была вытеснена смартфонами. Навигатор — это специальное устройство со своими характеристиками (размер экрана, способ загрузки карт, способ крепления и пр.), которая была наряду с видеорегистратором желанным девайсом любого водителя. Мобильный интернет тогда был редкостью, а пробки не учитывались вовсе, или учитывались, но не в режиме реального времени, а как динамическая модель, основанная на статистических данных.
Шли годы, смартфоны стали доступнее и функциональнее. И навигаторы превратились из отдельного устройства в приложение на смартфоне.
Смартфон «убил» товарную категорию «навигаторов». То же самое смартфон сделал и с MP3-плеерами. И фотоаппаратами. И много с чем еще. Потому что смартфон может выполнять много разных работ: от позвонить, записать заметку, сделать фотографию до послушать музыку, посмотреть кино и так далее.
ChatGPT является более универсальным продуктом, чем поисковик (правда, пока это скорее вопрос времени). Но, например, работу репетиторов по иностранным языкам он, скорее всего, тоже убъет. Как уже убивает работу Фотошопа и других фото- и видео-редакторов.
Суть в том, что чем больше работ можно выполнить одним продуктом, тем он более конкурентоспособен.
В дополнение вопрос обучения, т.е. если нужно переучиваться или изучать новый продукт для решения отдельной работы, текущий продукт + имеющиеся о нем знания дадут сильное конкурентное преимущество.
В сухом остатке: на рынке выживает продукт, который решает больше работ, чем его конкуренты; еще лучше, если переобучение продукту не требуется.
#jtbd@custdevlab #конкуренция@custdevlab
13👍4🤔4🌭2✍1🔥1🤩1👾1
232. Опыт исполнителя и новый подход к определению ценности опыта
Считается, что опыт измеряется временем. Обычно в резюме или при рассказе о себе человек говорит: опыт работы 10 лет. Этот подход устарел и не отвечает современным требованиям.
Не так важен срок (время) опыта. Как важен прогресс, который был получен человеком за этот период.
Можно 10 лет работать над продуктом, выполнять совершенно обычные функции, которые не приводят к прогрессу (росту) личностного и профессионального роста.
Можно за год сделать что-то с продуктом, что позволит человеку трансформировать собственный mindset на совершенно другой уровень, недоступный человеку с опытом в 10 лет.
Поэтому оценивать опыт нужно не временем, и даже не количеством проведенных работ, а прогрессом, который получил человек за период этого опыта.
Например, вы ищите агентство для проведения custdev-процедур для вашего продукта. Один претендент рассказывает, что проводит исследования более 15 лет. Второй, что провел уже более 2000 глубинных интервью. А третий говорит, что проводит исследования полгода, но за это время смог переупаковать 5 продуктов и помочь им выйти на новый уровень продаж за счет изменения методики проведения интервью.
В сухом остатке: опыт должен измеряться не временем, а прогрессом профессионального и личностного роста.
#интересное@custdevlab
Считается, что опыт измеряется временем. Обычно в резюме или при рассказе о себе человек говорит: опыт работы 10 лет. Этот подход устарел и не отвечает современным требованиям.
Не так важен срок (время) опыта. Как важен прогресс, который был получен человеком за этот период.
Можно 10 лет работать над продуктом, выполнять совершенно обычные функции, которые не приводят к прогрессу (росту) личностного и профессионального роста.
Можно за год сделать что-то с продуктом, что позволит человеку трансформировать собственный mindset на совершенно другой уровень, недоступный человеку с опытом в 10 лет.
Поэтому оценивать опыт нужно не временем, и даже не количеством проведенных работ, а прогрессом, который получил человек за период этого опыта.
Например, вы ищите агентство для проведения custdev-процедур для вашего продукта. Один претендент рассказывает, что проводит исследования более 15 лет. Второй, что провел уже более 2000 глубинных интервью. А третий говорит, что проводит исследования полгода, но за это время смог переупаковать 5 продуктов и помочь им выйти на новый уровень продаж за счет изменения методики проведения интервью.
В сухом остатке: опыт должен измеряться не временем, а прогрессом профессионального и личностного роста.
#интересное@custdevlab
7👍5✍4🌭3🔥1🤩1👾1
233. Unit в unit-экономике: смещаем фокус для роста. Кейс Стажер.online
Unit-экономика — база для роста стартапа и понимания его бизнеса. Именно этот подход позволяет понять перспективы стартапа.
Если на начальном этапе развити стартапа важно проводить custdev-процедуры для создания полезного MVP (т.е. MVP который позволит получить нужные данные о продукте и пользователях в том числе, для расчета unit-экономики). То после запуска MVP, его корректировок и сбора достаточной информации именно анализ unit-экономики — ключ к взрывному (или хотя бы какому-нибудь) росту продукта.
Unit в unit-экономике — это единица, которая приносит нам деньги. Например, пользователь, который пользуется нашим продуктом и приносит нам деньги. Для ныне несуществующего QIWI юнитом являлись QIWI-терминалы: чем больше терминалов, тем больше будет поток денег. Для отелей unit — это номер (и ночь). Чем больше номеров, тем больше будет поток денег.
Unit — это, что мы хотим масштабировать. Это источник нашего дохода.
Проект Стажер.online — это платформа по размещению кейсовых заданий от работодателей для решения студентами в целях поиска талантливых стажеров. Проект межвузовский, что является преимуществом для работодателя — не нужно общаться с каждым отдельным вузом, чтобы сообщить о стажировках.
Получается аналог традиционной модели отбора стажеров, где: много студентов изъявляют желание пройти стажировку, HR в компании проводит предварительный отбор на основе резюме, проводится большая работа по последующему отбору через решение задания и в итоге стажер получает место в компании.
Стажер.online меняет привычное поведение компаний — на платформе размещается задание, заинтересованные студенты его решают, далее HR (или представитель компании) производит отбор из меньшего числа студентов, решивших кейс. В теории — экономия времени, а главное, ресурсов HR в дополнение к более подробной оценке реальных навыков студентов, ведь мы не оцениваем их по резюме, которое скорее всего пустое, а оцениваем сразу по результатам выполненного задания.
Платформа получает доход от размещения заданий. Тарифы разные, но основным юнитом является компания (ее представитель), который приносит деньги за каждое размещение. Первое изучение ситуации сразу подсказывает — компаний меньше, чем студентов, да и привлекать на платформу студентов гораздо дешевле. Что, если попробовать юнитом сделать студентов?
Что нужно сделать для этого?
Нужно перенести фокус внимания с компании на студента, а именно подробно изучить ценность от решения подобных заданий для него и постараться «докрутить» ценность продукта до уровня, за который студент готов платить. Вот тут как раз нужен custdev. Также важно понять, что привычное поведение студентов меняется в меньшей степени — они умеют решать кейсы и для них это привычно.
Прекращаем работать с компаниями?
Нет. Именно компании являются источником заданий, но размещают их неохотно, так как существует множество барьеров — начиная от банального отсутствия времени на разработку задания, заканчивая тем, что размещенное публично задание может стать достоянием конкурентов. И конечно, просто отсутствием компетенций для этого (не умею и даже не знаю, как это сделать).
Как будет выглядеть новая модель unit-экономики
Мотивируем компании бесплатно размещать задания на платформе, помогаем с заданиями (внедряем AI, например), помогаем с размещением (максимально смещаем акцент на то, чтобы задание было размещено, а все барьеры появились позже -- например, разместил, а регистрация уже в самом конце).
Тут нам поможет CJM или LXM, что ближе. А для студентов ценность еще предстоит сформировать через custdev-процедуры, чтобы узнать за что они действительно готовы платить после решения.
Но главное — если сложно и дорого привлекать компании, нужно сместить фокус на студентов и начать масштабировать продукт за счет них.
В сухом остатке: unit-экономика это подход для понимания источника масштабирвоания продукта; если один unit нам не приносит дохода, ищем другой unit и тестируем гипотезы получения дохода от него.
#кейс@custdevlab #стажеронлайн@custdevlab
Unit-экономика — база для роста стартапа и понимания его бизнеса. Именно этот подход позволяет понять перспективы стартапа.
Если на начальном этапе развити стартапа важно проводить custdev-процедуры для создания полезного MVP (т.е. MVP который позволит получить нужные данные о продукте и пользователях в том числе, для расчета unit-экономики). То после запуска MVP, его корректировок и сбора достаточной информации именно анализ unit-экономики — ключ к взрывному (или хотя бы какому-нибудь) росту продукта.
Unit в unit-экономике — это единица, которая приносит нам деньги. Например, пользователь, который пользуется нашим продуктом и приносит нам деньги. Для ныне несуществующего QIWI юнитом являлись QIWI-терминалы: чем больше терминалов, тем больше будет поток денег. Для отелей unit — это номер (и ночь). Чем больше номеров, тем больше будет поток денег.
Unit — это, что мы хотим масштабировать. Это источник нашего дохода.
Проект Стажер.online — это платформа по размещению кейсовых заданий от работодателей для решения студентами в целях поиска талантливых стажеров. Проект межвузовский, что является преимуществом для работодателя — не нужно общаться с каждым отдельным вузом, чтобы сообщить о стажировках.
Получается аналог традиционной модели отбора стажеров, где: много студентов изъявляют желание пройти стажировку, HR в компании проводит предварительный отбор на основе резюме, проводится большая работа по последующему отбору через решение задания и в итоге стажер получает место в компании.
Стажер.online меняет привычное поведение компаний — на платформе размещается задание, заинтересованные студенты его решают, далее HR (или представитель компании) производит отбор из меньшего числа студентов, решивших кейс. В теории — экономия времени, а главное, ресурсов HR в дополнение к более подробной оценке реальных навыков студентов, ведь мы не оцениваем их по резюме, которое скорее всего пустое, а оцениваем сразу по результатам выполненного задания.
Платформа получает доход от размещения заданий. Тарифы разные, но основным юнитом является компания (ее представитель), который приносит деньги за каждое размещение. Первое изучение ситуации сразу подсказывает — компаний меньше, чем студентов, да и привлекать на платформу студентов гораздо дешевле. Что, если попробовать юнитом сделать студентов?
Что нужно сделать для этого?
Нужно перенести фокус внимания с компании на студента, а именно подробно изучить ценность от решения подобных заданий для него и постараться «докрутить» ценность продукта до уровня, за который студент готов платить. Вот тут как раз нужен custdev. Также важно понять, что привычное поведение студентов меняется в меньшей степени — они умеют решать кейсы и для них это привычно.
Прекращаем работать с компаниями?
Нет. Именно компании являются источником заданий, но размещают их неохотно, так как существует множество барьеров — начиная от банального отсутствия времени на разработку задания, заканчивая тем, что размещенное публично задание может стать достоянием конкурентов. И конечно, просто отсутствием компетенций для этого (не умею и даже не знаю, как это сделать).
Как будет выглядеть новая модель unit-экономики
Мотивируем компании бесплатно размещать задания на платформе, помогаем с заданиями (внедряем AI, например), помогаем с размещением (максимально смещаем акцент на то, чтобы задание было размещено, а все барьеры появились позже -- например, разместил, а регистрация уже в самом конце).
Тут нам поможет CJM или LXM, что ближе. А для студентов ценность еще предстоит сформировать через custdev-процедуры, чтобы узнать за что они действительно готовы платить после решения.
Но главное — если сложно и дорого привлекать компании, нужно сместить фокус на студентов и начать масштабировать продукт за счет них.
В сухом остатке: unit-экономика это подход для понимания источника масштабирвоания продукта; если один unit нам не приносит дохода, ищем другой unit и тестируем гипотезы получения дохода от него.
#кейс@custdevlab #стажеронлайн@custdevlab
11👍5🔥2🌭2🤩1👾1
234. Стоимость привлечения пользователя (CPUser)
CPUser = стоимость привлечения одного пользователя. Формул для расчета много, но самый правильный — сложить все стоимости платного привлечения для каждого пользователя (сложить CPC, cost per click).
Первые тесты каналов продвижения, особенно исчерпаемые (канал в ТГ, блогер и пр.) обычно приносят пользователей не по самой высокой стоимости.
Попытки закрепить успех приводят к росту этой метрики. Далее стартап пробует другие каналы привлечения пользователей, оставляя те, которые обходятся дешевле.
Многие каналы привлечения пользователей, особенно в digital, аукционные. Это значит, что стоимость размещения рекламы не фиксированная, а зависит от конкретных условий конкретного аукциона. Можно выбирать разные стратегии участия в аукционе, но по сути мы выбираем между балансом от «каждый пользователь дороже, больше пользователей» и «каждый пользователь дешевле, меньше пользователей».
Получается, что сначала пользователи обходятся нам недорого, потом дорожают. И будут дорожать каждый день, потому что при росте масштабов мы вынуждены подключать все более дорогие каналы привлечения пользователей, а более дешевые редко получается масштабировать.
В сухом остатке: стоимость привлечения пользователя (CPUser) это метрика, которая в долгосрочной перспективе всегда будет расти в цене.
#метрики@custdevlab #cpuser@custdevlab
CPUser = стоимость привлечения одного пользователя. Формул для расчета много, но самый правильный — сложить все стоимости платного привлечения для каждого пользователя (сложить CPC, cost per click).
Первые тесты каналов продвижения, особенно исчерпаемые (канал в ТГ, блогер и пр.) обычно приносят пользователей не по самой высокой стоимости.
Попытки закрепить успех приводят к росту этой метрики. Далее стартап пробует другие каналы привлечения пользователей, оставляя те, которые обходятся дешевле.
Многие каналы привлечения пользователей, особенно в digital, аукционные. Это значит, что стоимость размещения рекламы не фиксированная, а зависит от конкретных условий конкретного аукциона. Можно выбирать разные стратегии участия в аукционе, но по сути мы выбираем между балансом от «каждый пользователь дороже, больше пользователей» и «каждый пользователь дешевле, меньше пользователей».
Получается, что сначала пользователи обходятся нам недорого, потом дорожают. И будут дорожать каждый день, потому что при росте масштабов мы вынуждены подключать все более дорогие каналы привлечения пользователей, а более дешевые редко получается масштабировать.
В сухом остатке: стоимость привлечения пользователя (CPUser) это метрика, которая в долгосрочной перспективе всегда будет расти в цене.
#метрики@custdevlab #cpuser@custdevlab
15👍3✍2🌭2👾1
235. Важная роль основателя или если команда тормозит развитие продукта
Роль основателя в продукте — тема очень дискуссионная. Основатели успешных стартапов по-разному видят свою роль. Кто-то считает, что задача основателя — нанимать и увольнять людей в команду. Кто-то, что основатель это главный по упаковке продукта под PMF, да и под SPF тоже. Другие скажут, что PMF без маркетолога не получится. Но есть и те, кто считает роль маркетинга исключительно в привлечении трафика (с конверсией в лиды).
Тем не менее, основатель в продукте, без сомнения, самый важный человек. Иногда его заменяет продакт (product manager), но суть и функции не изменятся от этого. От него зависит общий успех продукта, а именно — доход.
Он должен видеть и задавать направление развития стартапа, формулировать цель и формировать стратегию по ее достижению. Каждый день продукт будут проверять на прочность и на устойчивость — новые предложения о сотрудничестве, новые предложения по фичам в продукт, новые идеи по монетизации и так далее.
Стратегия позволит принимать правильные решения, потому что стратегия это больше не про то, что мы делаем, а про то, что мы НЕ делаем.
Представьте ситуацию, что продуктовая команда, особенно команда разработки, на инициативы основателя (или продакта) говорит, что что-то лучше не делать или сделать, но не так. И продакт соглашается с предложением команды. Получается, что команда делает не то, что нужно по мнению продакта, а то, что она может/хочет или считает правильным делать. Она, а не продакт.
Так быть не должно. Продакт в этом случае определяет недостающие ресурсы, которые мешают команде реализовать его инициативы, ведь они не с потолка взяты, а определены на основе касаний рынка или целевой аудитории. Такие касания всегда стоят денег.
В результате, функция продукта, которая должна выглядеть, скажем, как финансовое вознаграждение участника кейс-чемпионата, превращается в функцию вознаграждений (но не финансовых). Функция формирования команды из незнакомых между собой людей превращается в функцию «заведения команды из знакомых» (такой сценарий проще реализовать). Так проще, так быстрее, так оптимально по соотношению ресурсов... Причин может быть бесконечно много.
Но это все не про тот продукт, который нужен рынку! В итоге, продукт вроде бы и есть, но функции в нем совсем не те, что были сформулированы после custdev-процедур. А значит ценности в этом продукте для пользователей, особенно платящих, может вовсе не быть. И как следствие — нет дохода.
В сухом остатке: цель и стратегия достижения цели, разработанные на основе custdev-процедур, должны быть приоритетом в развитии продукта; роль продакта (или основателя) в этом процессе неоспарима.
#интересное@custdevlab #профессияпродакт@custdevlab
Роль основателя в продукте — тема очень дискуссионная. Основатели успешных стартапов по-разному видят свою роль. Кто-то считает, что задача основателя — нанимать и увольнять людей в команду. Кто-то, что основатель это главный по упаковке продукта под PMF, да и под SPF тоже. Другие скажут, что PMF без маркетолога не получится. Но есть и те, кто считает роль маркетинга исключительно в привлечении трафика (с конверсией в лиды).
Тем не менее, основатель в продукте, без сомнения, самый важный человек. Иногда его заменяет продакт (product manager), но суть и функции не изменятся от этого. От него зависит общий успех продукта, а именно — доход.
Он должен видеть и задавать направление развития стартапа, формулировать цель и формировать стратегию по ее достижению. Каждый день продукт будут проверять на прочность и на устойчивость — новые предложения о сотрудничестве, новые предложения по фичам в продукт, новые идеи по монетизации и так далее.
Стратегия позволит принимать правильные решения, потому что стратегия это больше не про то, что мы делаем, а про то, что мы НЕ делаем.
Представьте ситуацию, что продуктовая команда, особенно команда разработки, на инициативы основателя (или продакта) говорит, что что-то лучше не делать или сделать, но не так. И продакт соглашается с предложением команды. Получается, что команда делает не то, что нужно по мнению продакта, а то, что она может/хочет или считает правильным делать. Она, а не продакт.
Так быть не должно. Продакт в этом случае определяет недостающие ресурсы, которые мешают команде реализовать его инициативы, ведь они не с потолка взяты, а определены на основе касаний рынка или целевой аудитории. Такие касания всегда стоят денег.
В результате, функция продукта, которая должна выглядеть, скажем, как финансовое вознаграждение участника кейс-чемпионата, превращается в функцию вознаграждений (но не финансовых). Функция формирования команды из незнакомых между собой людей превращается в функцию «заведения команды из знакомых» (такой сценарий проще реализовать). Так проще, так быстрее, так оптимально по соотношению ресурсов... Причин может быть бесконечно много.
Но это все не про тот продукт, который нужен рынку! В итоге, продукт вроде бы и есть, но функции в нем совсем не те, что были сформулированы после custdev-процедур. А значит ценности в этом продукте для пользователей, особенно платящих, может вовсе не быть. И как следствие — нет дохода.
В сухом остатке: цель и стратегия достижения цели, разработанные на основе custdev-процедур, должны быть приоритетом в развитии продукта; роль продакта (или основателя) в этом процессе неоспарима.
#интересное@custdevlab #профессияпродакт@custdevlab
3👍3✍2💩2🌭2
236. AJTBD-сценарии и верхнеуровневая работа. Кейс Стажер.online
Мы уже писали про проект Стажер.online, который позволяет размещать задачи от компаний, чтобы их решали студенты. В рамках прошлого поста мы пытались найти точки роста, желательно — кратного. Для этого, как гипотеза, предлагалось сместить фокус с одного юнита (компаний, размещающих кейсы на платформе), на другой (студента, эти кейсы решающего).
Логично, что студенты платить за обратную связь по решенному заданию не хотят и не будут. Докручивать ценность — это пилить фичи, которые к результату все равно не приведут. У студентов сформировано стойкое мнение, что обратная связь — само собой разумеющаяся часть продукта.
Например, как безопасность во время полетов на самолете. Нет ни одной авиакомпании в мире, которая бы позиционировала себя как «безопасная компания», потому что безопасность в этой товарной категории — база.
На практике, во многих кейс-чемпионатах и других активностях с кейсами обратная связь участникам дается или поверхностно, или не дается вовсе. Для организатора ответить развернуто, скажем, на 50 различных решений — задача крайне сложная и трудоемкая. А решений может быть и 150.
Как найти то, за что целевой сегмент будет готов платить?
Вариантов много, но главное на данном этапе не тратить время на то, что результат не принесет, т.е. «отсечь гипотезы, заведомо провальные для главной метрики продукта» (для роста дохода).
Проводим исследование для построения графа работ студента по AJTBD-фреймворку (не путайте с простым JTBD). Сам граф большой и описать его в одном посте не получится, но главный вывод в том, что само по себе решение задач от компаний для студента является работой нижнего уровня по отношению к чему-то более важному, и, по сути, является одной из работ в целой веренице других последовательных работ.
Граф работ — это модель, согласно которой работы одного уровня могут и включают в себя работы разных уровней: работы выше уровнем, ниже уровнем, работы, которые человек делал в прошлом, которые делал после выполнения конкретной работы.
По итогу мы увидели, что «решить кейс» само по себе не является целью студента, это шаг для достижения другой цели в контексте определенной ситуации. И цели у студентов, конечно, разные.
Приоретизация целей (верхнеуровневых работ в данном примере) — задача сложная и еще до конца не решенная. Но уже сейчас видна важная и значимая работа с высокой значимость и важность — попробовать разные направления в одной предметной области.
Например, студент учится на маркетинг, в котором много направления: исследование рынка, разработка стратегии продвижения, бренд-менеджмент, работа на стороне агентства/клиента и так далее. В процессе обучения немногие студенты понимают, что им нравится больше, даже если есть практический опыт в одной сфере и все нравится, может оказаться, что в других сферах понравится еще больше.
Теперь попробуем выйти на работу более высокого уровня с кейс-задачами. Если собрать подборку кейс-заданий одной тематической области и дать возможность за ограниченный срок решить несколько заданий из одного направления, скажем, по маркетингу, студент в итоге сможет сопоставить свои трудозатраты и результат (не обязательно развернутый). Получается, мы предложим ему комплексную стажировку сразу по разным направлениям внутри одной специальности, чтобы было легче определиться с тем, какое направление подходит ему лучше.
Конечно, это нужно упаковать, добавить ценности. Но просто сравните: «реши кейс от компании» или «попробуй себя в разных направлениях своей специальности».
В сухом остатке: AJTBD-фреймворк позволяет определять работы более высокого уровня; для Стажер.online один из подобных продуктов для верхнеуровневой работы — создать набор кейсов для понимания что нравится/не нравится в процессии.
#кейс@custdevlab #стажерonline@custdevlab #ajtbd@custdevlab #jtbd@custdevlab
Мы уже писали про проект Стажер.online, который позволяет размещать задачи от компаний, чтобы их решали студенты. В рамках прошлого поста мы пытались найти точки роста, желательно — кратного. Для этого, как гипотеза, предлагалось сместить фокус с одного юнита (компаний, размещающих кейсы на платформе), на другой (студента, эти кейсы решающего).
Логично, что студенты платить за обратную связь по решенному заданию не хотят и не будут. Докручивать ценность — это пилить фичи, которые к результату все равно не приведут. У студентов сформировано стойкое мнение, что обратная связь — само собой разумеющаяся часть продукта.
Например, как безопасность во время полетов на самолете. Нет ни одной авиакомпании в мире, которая бы позиционировала себя как «безопасная компания», потому что безопасность в этой товарной категории — база.
На практике, во многих кейс-чемпионатах и других активностях с кейсами обратная связь участникам дается или поверхностно, или не дается вовсе. Для организатора ответить развернуто, скажем, на 50 различных решений — задача крайне сложная и трудоемкая. А решений может быть и 150.
Как найти то, за что целевой сегмент будет готов платить?
Вариантов много, но главное на данном этапе не тратить время на то, что результат не принесет, т.е. «отсечь гипотезы, заведомо провальные для главной метрики продукта» (для роста дохода).
Проводим исследование для построения графа работ студента по AJTBD-фреймворку (не путайте с простым JTBD). Сам граф большой и описать его в одном посте не получится, но главный вывод в том, что само по себе решение задач от компаний для студента является работой нижнего уровня по отношению к чему-то более важному, и, по сути, является одной из работ в целой веренице других последовательных работ.
Граф работ — это модель, согласно которой работы одного уровня могут и включают в себя работы разных уровней: работы выше уровнем, ниже уровнем, работы, которые человек делал в прошлом, которые делал после выполнения конкретной работы.
По итогу мы увидели, что «решить кейс» само по себе не является целью студента, это шаг для достижения другой цели в контексте определенной ситуации. И цели у студентов, конечно, разные.
Приоретизация целей (верхнеуровневых работ в данном примере) — задача сложная и еще до конца не решенная. Но уже сейчас видна важная и значимая работа с высокой значимость и важность — попробовать разные направления в одной предметной области.
Например, студент учится на маркетинг, в котором много направления: исследование рынка, разработка стратегии продвижения, бренд-менеджмент, работа на стороне агентства/клиента и так далее. В процессе обучения немногие студенты понимают, что им нравится больше, даже если есть практический опыт в одной сфере и все нравится, может оказаться, что в других сферах понравится еще больше.
Теперь попробуем выйти на работу более высокого уровня с кейс-задачами. Если собрать подборку кейс-заданий одной тематической области и дать возможность за ограниченный срок решить несколько заданий из одного направления, скажем, по маркетингу, студент в итоге сможет сопоставить свои трудозатраты и результат (не обязательно развернутый). Получается, мы предложим ему комплексную стажировку сразу по разным направлениям внутри одной специальности, чтобы было легче определиться с тем, какое направление подходит ему лучше.
Конечно, это нужно упаковать, добавить ценности. Но просто сравните: «реши кейс от компании» или «попробуй себя в разных направлениях своей специальности».
В сухом остатке: AJTBD-фреймворк позволяет определять работы более высокого уровня; для Стажер.online один из подобных продуктов для верхнеуровневой работы — создать набор кейсов для понимания что нравится/не нравится в процессии.
#кейс@custdevlab #стажерonline@custdevlab #ajtbd@custdevlab #jtbd@custdevlab
3👍4🌭2✍1👎1🔥1🤣1👾1
237. Христофор Колумб тоже был стартапером
12 октября 1492 года матрос Родриго де Триана закричал: «Земля! Земля!» — и заработал 10 тыс. мараведи (местная валюта) — примерно столько он зарабатывал за год. Однако денег он в итоге не получил: потому что, глава экспедиции — Христофор Колумб — за 22 часа до этого видел землю, но никому об этом не сказал, но сделал запись в бортовом журнале.
Родриго был членом команды стартапа, который не получил ни доли, ни бонуса. Христофор Колумб был стартапером.
1. Придумал идею стартапа. Точнее, подсмотрел ее у других.
2. Долго и упорно искал инвестиции, ходил в разные инвест-фонды. Чаще всего ему отказывали под предлогом: идея слишком рискованная, ничего не получится.
3. В итоге он нашел инвестиции, но еще вложил свои деньги, которые тоже занял.
4. Сделал MVP: купил один корабль, другие взял в аренду (но меньше, чем нужно было на самом деле).
Он настолько сильно верил в идею, что реально поставил все на карту. (Кстати, потом его даже посадят в тюрьму)…
Как итог: первая экспедиция признана убыточной (-800 тыс), и это не считая стоимости судна, которое пришлось разобрать для строительства здания по месту прибытия. Да и открыл он вовсе не то, что обещал — острова Карибского бассейна, а не Индию (и не Америку).
Прошло 520 лет. Суть стартапа не поменялась — идти куда-то, куда никто не ходил, делать что-то, что никто не делал до тебя, стараться стратить меньше, но не получается.
Идеи и технологии менялись. Но главное, поменялись подходы к тестированию продуктов и идей. Сегодня есть передовые методы, которые ускоряют работу над продуктом стартапа в разы, повышают эффективность экспоненциально и направлены на то, чтобы стартап начал приносить доход (или даже прибыль).
В сухом остатке: стартапы зародились очень давно; суть стартапа не меняется — работа в условиях неопределенности и изменений; тестирование гипотез через MVP.
#интересное@custdevlab
12 октября 1492 года матрос Родриго де Триана закричал: «Земля! Земля!» — и заработал 10 тыс. мараведи (местная валюта) — примерно столько он зарабатывал за год. Однако денег он в итоге не получил: потому что, глава экспедиции — Христофор Колумб — за 22 часа до этого видел землю, но никому об этом не сказал, но сделал запись в бортовом журнале.
Родриго был членом команды стартапа, который не получил ни доли, ни бонуса. Христофор Колумб был стартапером.
1. Придумал идею стартапа. Точнее, подсмотрел ее у других.
2. Долго и упорно искал инвестиции, ходил в разные инвест-фонды. Чаще всего ему отказывали под предлогом: идея слишком рискованная, ничего не получится.
3. В итоге он нашел инвестиции, но еще вложил свои деньги, которые тоже занял.
4. Сделал MVP: купил один корабль, другие взял в аренду (но меньше, чем нужно было на самом деле).
Он настолько сильно верил в идею, что реально поставил все на карту. (Кстати, потом его даже посадят в тюрьму)…
Как итог: первая экспедиция признана убыточной (-800 тыс), и это не считая стоимости судна, которое пришлось разобрать для строительства здания по месту прибытия. Да и открыл он вовсе не то, что обещал — острова Карибского бассейна, а не Индию (и не Америку).
Прошло 520 лет. Суть стартапа не поменялась — идти куда-то, куда никто не ходил, делать что-то, что никто не делал до тебя, стараться стратить меньше, но не получается.
Идеи и технологии менялись. Но главное, поменялись подходы к тестированию продуктов и идей. Сегодня есть передовые методы, которые ускоряют работу над продуктом стартапа в разы, повышают эффективность экспоненциально и направлены на то, чтобы стартап начал приносить доход (или даже прибыль).
В сухом остатке: стартапы зародились очень давно; суть стартапа не меняется — работа в условиях неопределенности и изменений; тестирование гипотез через MVP.
#интересное@custdevlab
5👍4🌭4✍2🔥2👾2
238. Сегментация Шона Эллиса для определния PMF
В custdev-гайдах иногда рекомендуют задавать вопрос «Что вы будете делать, если наш/мой продукт с рынка уйдет?» Отношение собственников к этому вопросу неоднозначное. Обычно говорят, что вопрос плохой, потому что человек, услышав его, будет думать, что у меня все плохо и я скоро закроюсь...
На самом деле нет.
Во-первых, мы можем получить «Вариант №2» в голове нашего пользователя. Это всегда важно и интересно.
Во-вторых, существует сегментация клиентов Шона Эллиса. Для существующего продукта по ответам на вопрос: «Насколько сильно вы будете разочарованы, если мой продукт перестанет существовать?»
Считается, что если более 40% текущих клиентов будут сильно разочарованы, в случае, если продукт перестанет существовать, то у этого продукта есть PMF [Product Market Fit].
В сухом остатке: как определить PMF для существующего продукта — спросить «насколько вильно Вы будете разочарованы, если продукт перестанет существовать?»
#вопросы@custdevlab
В custdev-гайдах иногда рекомендуют задавать вопрос «Что вы будете делать, если наш/мой продукт с рынка уйдет?» Отношение собственников к этому вопросу неоднозначное. Обычно говорят, что вопрос плохой, потому что человек, услышав его, будет думать, что у меня все плохо и я скоро закроюсь...
На самом деле нет.
Во-первых, мы можем получить «Вариант №2» в голове нашего пользователя. Это всегда важно и интересно.
Во-вторых, существует сегментация клиентов Шона Эллиса. Для существующего продукта по ответам на вопрос: «Насколько сильно вы будете разочарованы, если мой продукт перестанет существовать?»
Считается, что если более 40% текущих клиентов будут сильно разочарованы, в случае, если продукт перестанет существовать, то у этого продукта есть PMF [Product Market Fit].
В сухом остатке: как определить PMF для существующего продукта — спросить «насколько вильно Вы будете разочарованы, если продукт перестанет существовать?»
#вопросы@custdevlab
7👍3✍2🔥2🌭2🤩1👾1
239. Технология изготовления влияет на то, как продукт выглядит
То, как продукт сделан, определяет его форму. Например, почти вся посуда круглая, потому что ее изготавливали на гончарном круге. Круг крутится, посуда получается круглой.
У книг есть поля, чтобы черви и другие паразиты во время длительного хранения книг в библиотеках не успели съесть ценное содержимое, а обгрызание страницы без текста не так страшно для основной (ключевой) функции — передача информации.
На часах цифры показывают часы, потому что изначально была только часовая стрелка, без минутной. Так было технически проще сделать. Секундные стрелки тогда даже обсуждались. А солнечные часы вообще не умели показывать каждый час одинаковым, ведь длина светового дня каждый день разная.
В компьютерных играх есть механика протискивания, когда герой медленно проходит через ящики или в еле открываемую дверь. Нужно это для того, чтобы старые компьютеры успевали прогрузить мир вокруг, а сам геймплей от этого сильно лучше не становится.
Фонтаны на улицах больших городов нужны были не столько для красоты, сколько для водопоя лошадей. Поэтому раньше их было много, сейчас, так как фонтаны выполняют другую работу, требования к ним изменились.
То, как сделан custdev влияет на его результат. Некоторые механики проведения были такими в связи с развитием технологий на момент их изобретения. Не обязательно применять их именно в том же виде сегодня, когда у нас есть новые технологии и возможности.
В сухом остатке: методика custdev не всегда оптимальна для текущих условий; следует помнить об ограничениях, которые были на момент изобретения методики.
#методика@custdevlab #интересное@custdevlab
То, как продукт сделан, определяет его форму. Например, почти вся посуда круглая, потому что ее изготавливали на гончарном круге. Круг крутится, посуда получается круглой.
У книг есть поля, чтобы черви и другие паразиты во время длительного хранения книг в библиотеках не успели съесть ценное содержимое, а обгрызание страницы без текста не так страшно для основной (ключевой) функции — передача информации.
На часах цифры показывают часы, потому что изначально была только часовая стрелка, без минутной. Так было технически проще сделать. Секундные стрелки тогда даже обсуждались. А солнечные часы вообще не умели показывать каждый час одинаковым, ведь длина светового дня каждый день разная.
В компьютерных играх есть механика протискивания, когда герой медленно проходит через ящики или в еле открываемую дверь. Нужно это для того, чтобы старые компьютеры успевали прогрузить мир вокруг, а сам геймплей от этого сильно лучше не становится.
Фонтаны на улицах больших городов нужны были не столько для красоты, сколько для водопоя лошадей. Поэтому раньше их было много, сейчас, так как фонтаны выполняют другую работу, требования к ним изменились.
То, как сделан custdev влияет на его результат. Некоторые механики проведения были такими в связи с развитием технологий на момент их изобретения. Не обязательно применять их именно в том же виде сегодня, когда у нас есть новые технологии и возможности.
В сухом остатке: методика custdev не всегда оптимальна для текущих условий; следует помнить об ограничениях, которые были на момент изобретения методики.
#методика@custdevlab #интересное@custdevlab
10👍5🔥3🌭3✍2🤩1👾1
240. Custdev нужен не чтобы делать, а чтобы не делать
Custdev и результаты этих процедур нужны, чтобы понять, что не нужно делать.
Мы стараемся отсечь то, что не даст результата, то есть то, что не будет решать проблему потребителя.
В сухом остатке: главное, понять, что мы не делаем, а потом — что делаем.
#интересное@custdevlab
Custdev и результаты этих процедур нужны, чтобы понять, что не нужно делать.
Мы стараемся отсечь то, что не даст результата, то есть то, что не будет решать проблему потребителя.
В сухом остатке: главное, понять, что мы не делаем, а потом — что делаем.
#интересное@custdevlab
8👍13🥰5🌭3👾2✍1🔥1😁1😱1🤩1
241. CJM и LXM: в чем отличие
CJM это карта сокровищ. Понятный путь куда идти, где свернуть, где копать. Ничего лишнего, только цель и необходимое количество подробностей. Итог (клад) — покупка и использование вашего продукта.
LXM это карта местности. Подробное описание ландшафта и объяснение принципов, по которым можно определить, где зарыты сокровища (много кладов).
LXM может не содержать конкретное место, где зарыт конкретный клад, но зато даст понять, где в принципе клады могут быть зарыты. Много кладов.
В сухом остатке: LXM более подробная карта местности (поведения потребителя), чем CJM.
#cjm@custdevlab #lxm@custdevlab
CJM это карта сокровищ. Понятный путь куда идти, где свернуть, где копать. Ничего лишнего, только цель и необходимое количество подробностей. Итог (клад) — покупка и использование вашего продукта.
LXM это карта местности. Подробное описание ландшафта и объяснение принципов, по которым можно определить, где зарыты сокровища (много кладов).
LXM может не содержать конкретное место, где зарыт конкретный клад, но зато даст понять, где в принципе клады могут быть зарыты. Много кладов.
В сухом остатке: LXM более подробная карта местности (поведения потребителя), чем CJM.
#cjm@custdevlab #lxm@custdevlab
16👍8✍3🌭3🔥1🤩1👾1