Случилось так, что братья по разуму из словенской D-Labs отчаянно разрекламировали мне книгу под названием Running Lean автора Ash Maurya. Книга действительно системно прочищает мозги и помогает задуматься о правильном распределении ресурсов независимо от того, запускаете ли вы стартап или двигаете бизнес с какой-то ненулевой точки. Если владеете хотя бы базовым английским, смело беритесь — книга написана очень просто. Для остальных решил смастерить перевод. Начну с первой части, если будет интерес, продолжу. Enjoy! Уважаемые читатели, у меня есть к вам вопрос. За то время, на которое я выпал из процесса, у гуру Lean г-на Ash Maurya вышла новая книжка на ту же тему: Scaling Lean: Mastering the Key Metrics for Startup Growth. Как нетрудно догадаться, она представляет собой логическое продолжение Running Lean и посвящена тому, как действовать после того, как создан и протестирован MVP, когда пришла пора понять — а может ли ваша идея стать жизнеспособным бизнесом. Как написано в предисловии:

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

Ну и, собственно, вопрос: оно ~~вам~~ нам надо? Осилить сейчас такой объем работы в режиме хобби, к сожалению, не смогу себе позволить. Поэтому, если на приведенный выше вопрос получу явный положительный ответ, надо будет думать, как заморочиться с краудфандингом. Кстати, советы на эту тему также приветствуются. Надеюсь, текст понравился вам так же, (или почти так же) как мне понравился английский оригинал. На протяжении того времени, которое занял у меня перевод, я успел опробовать 2 практических приема, приведенных в книге, на том бизнесе, в котором занят постоянно. В обоих случаях это помогло мне рационально распределить свои ресурсы и быстрее, и с меньшими затратами получить ответ о целесообразности запуска нового направления (в одном случае ответ получился отрицательным; тем выше значение того, что я не бросил на новую задачу все силы и средства). За рамками перевода остался раздел Приложение, в котором Ash Maurya рассказывает о том,

Как построить низкозатратный стартап
Почему преждевременное привлечение инвестиций — это нерациональное распределение ресурсов
Как выбрать правильную цену для продукта SaaS (Software as a Service)
Как создать работающую посадочную страницу

И о многих других практически применимых, интересных и вкусных вещах.

Running Lean или Рационализация Стартапа — Часть 4 (заключение)

Раздел 13: Не выдумывайте ненужных характеристик

На хорошем рынке, рынке, изобилующем реальными потенциальными клиентами, сам рынок вытягивает продукт из стартапа. – Марк Андреэсен (Marc Andreesen, “The Pmarca Guide to Startups”)

Характеристики продукта должны быть затребованы рынком, а не навязаны ему

Ранее я высказывался в поддержку системы Непрерывного Внедрения. В целом эта система помогает значительно ускорить процесс разработки продукта, но это не должно провоцировать вас на ускоренное добавление к продукту новых характеристик. Когда вы запускаете свой продукт, проблемы могут и будут возникать. Весьма вероятно, что запросы на добавление новых характеристик начнут поступать сразу после старта. Общая тенденция заключается в том, чтобы расширять продукт, но это редко решает проблему. Вот почему: Новые характеристики размывают ваше УТП Вы приложили массу усилий к тому, чтобы ваш минимальный актуальный продукт был идеально сфокусированным и включал в себя только то, что действительно необходимо. Не размывайте ваше УТП ненужными отвлекающими факторами. Простой продукт легче понять Создать хорошее приложение трудно. Кроме того, кропотливые исследования позволили вам глубоко понять важность Проблемы, но о Решении вы имеете пока лишь примерное представление. Дайте вашему МАП шанс – сначала устраните проблемы с уже реализованными характеристиками и лишь потом принимайтесь за добавление новых.

Отложите в сторону компилятор, пока не поймете, почему ваш продукт не покупается. – Джейсон Коэн, A Smart Bear blog

Новые характеристики всегда чего-то вам стоят Новые характеристики означают новые тесты, новые скриншоты, новые видео, новые сложности и новые отвлекающие факторы.

Начните с ответа «Нет». – 37signals, Getting Real

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

Изобретение новых «примочек» может стать дурной привычкой. – Бен Йосковиц (Ben Yoskovitz, Instigator blog)

Используйте правило 80/20

Для этого случая отлично подходит эмпирическое правило 80/20 (см. рисунок 13-1).

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

Контролируйте поток внедрения новых элементов

Удобный метод для того, чтобы не выпускать из-под контроля поток внедрения новых элементов заключается в ограничении числа одновременно обрабатываемых элементов и переходе к новым только после того, как уже внедренные элементы протестированы, и вы получили от них положительный или отрицательный результат (т.е. получили знания). Для этого отлично подойдет такой инструмент, как доска Канбан[1] (Kanban), называемая также визуальной доской. Доска Канбан помогает вам отслеживать внедряемые характеристики и элементы так же, как Панель Управления Конверсии позволяет вам отслеживать метрики. Оба этих инструмента помогают вам сфокусировать внимание на макро-показателях. На рисунке 13-2 изображена простейшая доска Канбан с разбивкой на три группы.

Общая идея заключается в следующем6 новый элемент/характеристика появляется в левой части доски и проходит через все стадии разработки продукта и клиента, пока не переходит в состояние «Закончено». [1] Система планирования Канбан (Kanban) была разработана Таичи Оно (Taiichi Ohno), отцом производственной системы Toyota. Система Канбан говорит вам что необходимо производить, когда это производить, и в каком количестве. (Английский текст цитируется по http://en.wikipedia.org/wiki/Kanban). Кратко рассмотрим три основных этапа процесса, изображенного на рисунке 13-2.

Очередь

Все потенциальные кандидаты на внедрение начинают свой путь в группе Очередь. Туда они попадают одним из следующих способов:

Улучшение существующих элементов (например, адаптация процесса подписки)
Запросы пользователей
Ваши пожелания (например, из отложенных ранее «желательных» характеристик)

Прежде чем двигаться дальше, необходимо пояснить разницу между минимальным значимым элементом, МЗЭ (minimal marketable feature, MMF) и небольшой правкой/исправлением ошибок. Термин МЗЭ впервые был введен в книге Software by Numbers, написанной Марком Денном и Джейн Клиланд-Хуан (Marc Denne, Jane Cleland-Huang, Prentice Hall) и определялся как наименьшая работа, дающая ощутимое преимущество для пользователя (таким образом, речь идет о любых характеристиках, значимых с точки зрения маркетинга). Говоря о «характеристиках» или «элементах», я всегда имею в виду МЗЭ. В качестве теста на то, является ли новый элемент МЗЭ, спросите себя – будете ли вы анонсировать его появление у себя в блоге или журнале? Если он слишком мелок для упоминания, это – не МЗЭ. МЗЭ обычно состоит из более мелких задач, которые, если вы практикуете систему Непрерывного Внедрения, составляют ваши минимальные порции для внедрения. Небольшие правки и исправления ошибок обычно входят в состав таких мелких задач. Я использую доску Канбан только для отслеживания МЗЭ, а для задач более мелкого масштаба – облегченный инструмент мониторинга (типа Pivotal Tracker).

В работе

Перечень задач, ожидающих внедрения в группе «Очередь», обычно отсортирован по приоритетности с учетом текущих целей вашего проекта. Поэтому для перемещения задачи на следующий этап вы просто берете ту, которая находится на вершине списка. Этап «В работе», в свою очередь, состоит из нескольких под-шагов, таких как создание макетов, программирование, внедрение и т.д. Подробнее мы поговорим об этом в следующем разделе. Ключевой принцип Канбан, позволяющий контролировать процесс внедрения, состоит в том, что вы ограничиваете максимальное число элементов, одновременно находящихся в процессе внедрения. Это позволяет вам максимизировать полезный выход и минимизировать нерациональную трату ресурсов. Тех, кому интересна технология этого процесса в деталях, я отошлю к книге Дональда Рейнертсена (Donald Reinertsen) The Principles of Product Development Flow (Celeritas Publishing), где всё это очень понятно и глубоко изучено. Я рекомендую вам начать с максимального числа одновременно внедряемых элементов, равного числу основателей/членов команды и регулировать это число в дальнейшем по необходимости. Так, если в вашей команде всего три основателя, ограничьте себя тремя одновременно внедряемыми элементами/характеристиками.

Закончено

Когда внедрение нового элемента завершено, он перемещается в группу «Закончено». Статус «Закончено» не совсем однозначен и разные группы разработчиков могут вкладывать в это совсем разное – от «кодирование завершено», до «протестировано» или «внедрено». В терминах Рационального Стартапа, однако, статус «Закончено» присваивается только тому элементу, по которому вы получили ясную обратную связь от потребителя.

Рисунок 13‑3. Получение обратной связи по внедренным характеристикам

По этой причине Эрик Рийс предлагает либо внести получение обратной связи в определение фазы «Закончено», либо добавить для этого отдельную, четвертую группу обработки. Как мы увидим дальше, я пользуюсь промежуточным решением и провожу двухступенчатую проверку внедренного элемента: сначала качественную, потом – количественную. Такое определение статуса «Закончено» вносит дополнительную степень контроля в ваш процесс внедрения и не дает перейти к работе по новому элементу до тех пор, пока вы не получили ясную обратную связь по уже внедренные характеристикам.

Обработка запросов на добавление характеристик

В этом пункте я приведу алгоритм обработки запросов на добавление к продукту новых характеристик, с которыми вам так или иначе придется столкнуться (см. рисунок 13-4).

Рисунок 13‑4. Алгоритм внедрения новых элементов

Первый выбор заключается в следующем: принимая во внимание срочные потребности и приоритеты вашего проекта, необходимо решить – насколько своевременным будет решение данной задачи в текущий момент времени. Например, если у вас есть серьезные проблемы с процессом подписки, всем остальным запросам придется подождать. Затем вам следует определить – является ли внедряемый элемент небольшим дополнением (исправлением ошибок) или представляет собой крупную, значимую с маркетинговой точки зрения характеристику. Если речь идет о небольшой, но срочной задаче, выполните её сразу (например, запрограммируйте-протестируйте-внедрите с помощью процесса Непрерывного Внедрения). В противном случае (если сроки терпят), внесите её в очередь своей доски управления задачами. Я также рекомендую выставлять приоритет для всех задач из этой группы. При таком подходе любой из вашей команды, у кого появилась свободная минута, сможет без труда выбрать и решить наиболее важную задачу. Если же вы имеете дело с МЗЭ (минимальный значимый элемент), поместите его в очередь на доску Канбан. Далее я покажу как расставлять приоритеты и обрабатывать задачи такого рода.

Жизненный цикл элемента

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

Как отслеживать внедрение элемента с помощью доски Канбан

Прежде чем углубиться в конкретный процесс, давайте остановимся на некоторых общих аспектах доски Канбан.

Рисунок 13‑5. Жизненный цикл внедряемых элементов

Цели Полезно разместить ваши ближайшие цели и приоритеты непосредственно над вашей доской Канбан. Это помогает всем участникам процесса оставаться «на одной волне» при выставлении приоритетов по задачам. Ограничения по одновременной обработке Ограничение по количеству задач, находящихся в работе одновременно, указано в строке заголовка. Для больших команд целесообразно устанавливать дополнительные ограничения для каждого под-этапа (макет, демо, кодирование и т.д.), но на данной стадии это будет излишним, так как большинство стартапов по умолчанию малочисленны. Буферные строки Каждый этап разбит на две строки. Верхняя строка содержит задачи, находящиеся в процессе обработки, а нижняя – задачи, для которых данный этап закончен и ожидается перевод на следующий этап. Элементы, которые могут быть ликвидированы на любой стадии Жизненный цикл элемента содержит в себе несколько стадий проверки на пользователях. Если какой-либо элемент не проходит тестирование, его можно либо переместить на предыдущую стадию для переработки, либо ликвидировать совсем. Такие «сомнительные» элементы помечены красным. Непрерывное внедрение Подразумевая, что вы используете процесс Непрерывного Внедрения, под заголовком «Кодирование» я объединяю весь цикл Программирование-Тестирование-Внедрение-Наблюдение.

ПРИМЕЧАНИЕ Хотя я и рассматриваю разработку ПО в качестве примера, термин «Кодирование» может быть легко заменен на соответствующую фазу создания вашего продукта.

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

Процесс в подробностях

Теперь пройдем последовательно по всем этапам жизненного цикла. Разберитесь в проблеме:

Очередь

Мы закончили Раздел 12 простым алгоритмом, позволяющим быстро отбирать элементы, достойные попадания в очередь на внедрение. Теперь эти элементы размещаются в верхней части столбца «Очередь», поскольку за их обработку еще не принялись. С учетом лимитов на количество обрабатываемых одновременно задач, вам стоит основательно задуматься над расставлением приоритетов в очереди, так чтобы они отражали первостепенные цели вашего проекта. Как только вы идентифицировали новый элемент, вам необходимо ответить на вопрос – «Является ли эта проблема достойной решения?» Если вы не можете найти достойное оправдание внедрению нового элемента, ликвидируйте его из очереди немедленно.

Пользовательские запросы

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

Внутренние запросы

Если запрос на добавление элемента появился внутри команды, рассмотрите все те же критерии, что и для пользовательских запросов и ответьте на вопрос – «Достойна ли эта проблема решения?» Определите решение:

Макет

Как только вы выделили для себя элемент, достойный внедрения, займитесь созданием макета решения, руководствуясь подходом, описанным ранее в Разделе 8. Начните с бумажных набросков, но как можно быстрее переходите к HTML/CSS макетам, подключаемым к вашему основному приложению.

Демонстрация

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

Программирование

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

Частичное внедрение

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

Качественная проверка

Проведите тестирование удобства использования с помощью шаблона интервью по МВП. При необходимости внесите требуемые изменения для устранения недостатков. Подтвердите количественно:

Полное внедрение

Вы готовы к полному запуску. Как только новый элемент запущен в «боевом» режиме, он переходит в следующий столбец на доске Канбан, освобождая, таким образом, место для обработки следующего элемента из очереди.

Количественное подтверждение

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

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

Раздел 14: Определите соответствие Продукт/Рынок

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

Что такое соответствие Продукт/Рынок?

Хотя Марк Андреэссен (Marc Andreessen) и не является автором термина «соответствие продукт/рынок»[1], публикация в его блоге остается наиболее популярным объяснением того, что это такое.

Соответствие Продукт/Рынок означает, что вы вышли на хороший рынок с продуктом, который может удовлетворить запросы этого рынка. Вы легко можете почувствовать отсутствие такого соответствия. Клиенты не вполне осознают значимость продукта, «сарафанное радио» не рекламирует ваш продукт, прирост клиентов не так велик, как ожидалось, обзоры в прессе бесцветны и бессодержательны, цикл продаж слишком длинен и множество сделок так никогда и не совершаются. Вы также легко можете почувствовать наличие такого соответствия. Клиенты покупают продукт с той скоростью, с которой вы успеваете его производить – или приток новых клиентов ограничивается только вводом новых серверов. Поступления от клиентов копятся на счетах компании. Вы нанимаете новых продавцов и специалистов по технической поддержке с максимально возможной скоростью. Репортеры звонят вам и хотят обсудить те удивительные новости, которые они слышали о вашем продукте. – Марк Андреэссен, «The Pmarca Guide to Startups»

К сожалению, Марк завершил эту публикацию, предложив больше вопросов, чем ответов, и не предоставил никакого руководства к тому, как достичь этого соответствия. Шон Эллис (Sean Ellis) сделал концепцию менее абстрактной, предложив метрику для определения раннего привлечения клиентов, что является необходимым условием для достижения соответствия продукт/рынок. Я рассмотрю её в следующей главе. [1] Авторство термина «соответствие продукт/рынок» (product/market fit) принадлежит Энди Рэклиффу (Andy Rachleff), сооснователю венчурной компании Benchmark Capital.

Тест Шона Эллиса

Шон Эллис руководит консалтинговой компанией 12in6, которая специализируется на помощи стартапам, находящимся в стадии переходного роста. В качестве проверочного условия для начала сотрудничества со стартапом он использовал опрос клиентов компании, ставивший целью определить наличие раннего привлечения, которое, в свою очередь, является хорошим показателем того, что стартап находится на верном пути. В ходе опроса клиентам предлагалось ответить на несколько вопросов: Как бы вы чувствовали себя, если бы не смогли больше пользоваться продуктом этой компании?

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

Если более 40% ваших клиентов говорят, что они будут «очень расстроены» отсутствием вашего продукта, то у вас есть большой шанс построить устойчивый и масштабируемый бизнес на этом безусловно нужном продукте. Показатель 40% был выведен эмпирически по результатам анализа деятельности сотен стартапов. Те из них, которые преодолевали показатель 40%, обычно могли устойчиво расширять свой бизнес; те, кому не удалось достичь потолка 40%, обычно еле сводили концы с концами[1]. У меня есть ощущение, что конкретная формулировка вопроса может быть немного адаптирована для каждого рынка. Например, в контексте B2B предпринимательства предположение об исчезновении вашего продукта с рынка вряд ли будет адекватно воспринято ранними последователями, которые инвестируют своё время в ваш продукт. За исключением этого, основной посыл теста не подвергается никакому сомнению – он измеряет то, насколько ваш продукт внутренне близок вашим клиентам. Однако, более важная проблема с тестом Шона заключается в другом. Как я уже ранее высказывался по поводу опросов пользователей, опросы эффективны для проверки имеющихся знаний, а не для приобретения новых. В данном случае, хотя тест Шона безусловно поможет вам определить наличие или отсутствие раннего привлечения клиентов, он никак не поможет вам достичь его. Кроме того, для получения статистически значимого результата вам необходимо привлечь достаточно большую выборку пользователей, учесть их сегментацию и мотивацию. По этой причине тест Шона лучше всего применять когда вы уже близки к достижению соответствия продукт/рынок (что рекомендует и сам Шон). Но что вам делать до этого? Как повести свой продукт в сторону соответствия продукт/рынок? Ответ вы найдете на вашей панели управления конверсиями. В следующей главе я опишу другой подход для определения раннего привлечения пользователей, использующий два ключевых показателя из жизненного цикла потребителя – активацию и удержание, которые вместе составляют основную метрику. [1] http://startup-marketing.com/using-survey-io/

Фокусируйтесь на правильных макро-показателях

Создавайте что-то, что нужно людям. – Пол Грэм (Paul Graham)

Достижение соответствия продукт/рынок или вовлечения пользователей можно вкратце свести к созданию чего-то, что нужно людям, или, иными словами, воплощению вашего УТП. Некоторые продукты разрабатываются для того, чтобы удовлетворить одноразовую потребность – например, свадебные фотоуслуги, услуги адвокатов по разводу, книги, DVD и т.д. Другие, напротив, призваны предоставлять услуги, повторяющиеся многократно – например, продукты Software as a Service, сервисы в социальных сетях, рестораны, журналы и т.д. Первый тип в основном движим впечатлением, которое пользователь получает от сервиса, что можно эффективно измерить с помощью метрики активации. Второй тип также сильно зависит от первого впечатления (следовательно, активация также важна), но более важный фактор успеха – повторное использование, что делает удержание более значимым показателем того, насколько людям нужен ваш продукт (см. рисунок 14-1).

Рисунок 14‑1. Фокусируйтесь на правильном макро-показателе

Можно предположить возражение такого рода, что постоянное использование продукта на протяжении достаточно долгого времени должно хорошо коррелировать с показателем «очень расстроен» по шкале Шона. С учетом этого можно применять тот же показатель 40% для определения раннего вовлечения[1]. Вы имеете достаточное раннее вовлечение, если месяц за месяцем вы удерживаете не менее 4%; активированных пользователей.

Что насчет доходов?

Я убежден в том, что цена является неотъемлемой частью продукта, и поддерживаю взимание платы с самого первого дня. Однако, доходы сами по себе представляют только одну из форм проверки и, будучи использованы в отрыве от всего остального, могут стать ложным подтверждением соответствия продукт/рынок. Я сам сталкивался с рядом случаев, когда клиенты продолжали платить за мои продукты, давно не пользуясь ими (хотя бы даже нерегулярно). Иногда это объяснялось тем, что платил кто-то другой (например, их компания), иногда – тем, что они просто забывали отменить подписку. С другой стороны, я встречал стартапы, потерявшие себя в погоне за неправильным типом доходов, например, за заключением одноразовых сделок по лицензированию/разработке на заказ. Доходы являются первой формой проверки вашего продукта, но более важной формой является удержание клиентов. Более того, если вы предлагаете одноразовый продукт, взимаете сообразную плату и имеете нормальный уровень активации, доходы сами о себе позаботятся. Аналогично, если вы предлагаете сервис по подписке, взимаете плату с первого дня и имеете хороший уровень удержания клиентов, доходы также позаботятся о себе сами. [1] Я консультировался по этому поводу с Шоном Эллисом, и он согласился.

Создали ли вы что-то, нужное людям?

В этой главе я резюмирую процесс приближения к раннему вовлечению и показатели того, что оно вами достигнуто.

Еженедельно анализируйте показатели вашей панели управления конверсии.

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

Расставьте приоритеты среди своих целей и в очереди на внедрение новых элементов.

Анализируйте свой список новых элементов и выделяйте те из них, которые следует внедрять раньше остальных.

Формулируйте гипотезы макро-уровня.

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

Добавляйте и удаляйте новые элементы.

Анализируйте новые элементы по мере их внедрения и смело удаляйте их, если они не дают положительного эффекта.

Наблюдайте за ключевыми метриками.

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

Пройдите тест Шона Эллиса.

После того, как ваш показатель удержания достиг 40%, подвергните ваш продукт тесту Шона Эллиса.

Каковы критерии достижения раннего вовлечения?

Вы закончили с этим этапом, если:

Вы удерживаете 40% и более привлеченных пользователей
Успешно прошли тест Шона Эллиса

Что насчет Рынка в соответствии Продукт/Рынок?

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

Начните с идентификации ключевого фактора роста

Фактор роста – это механизм, посредством которого стартапы достигают устойчивого роста. – Эрик Рийс (The Lean Startup, Crown Business) В своей книге Эрик Рийс описывает три следующих фактора роста: Прилипчивый: высокое удержание Продукт, который использует прилипчивый фактор роста, строится на высоком уровне удержания клиентов (или низком уровне оттока). Примеры: провайдеры телефонных/кабельных сервисов, продукты типа Software-as-a-Service (ПО как сервис). Уровень оттока – доля клиентов, отказавшихся от продукта или оставшихся невовлеченными в продукт в течение данного периода времени. Рост в данном случае обеспечивается тем, что Уровень Привлечения Клиентов выше Уровня Оттока Клиентов. Вирусный: высокое распространение Продукт, использующий вирусный фактор роста, строится на высоком уровне распространения от клиента к клиенту (или высоком коэффициенте виральности), который часто является встроенным побочным эффектом использования продуктов. Примеры: он-лайн социальные сети типа Facebook или Twitter. Коэффициент виральности измеряется как количество сконвертированных рекомендаций на одного клиента. В данном случае рост обеспечивается при Коэффициенте Виральности > 1 (т.е. когда каждый клиент приводит с собой по крайней мере еще одного клиента). Платный: высокая прибыльность Продукт, использующий платный фактор роста, строится на том, что часть доходов, получаемых от клиентов (стоимость жизненного цикла клиента, lifetime value или LTV), реинвестируется на привлечение новых клиентов посредством рекламы или найма продавцов. В данном случае рост обеспечивается при условии LTV > COCA (cost of customer acquisition, стоимость привлечения клиента). Хорошее эмпирическое правило, выведенное Дэвидом Скоком (David Skok, Matrix Partners), гласит, что следует иметь LTV > 3 * COCA. Итак, какой выбираете вы? Даже в том случае, если вашему продукту соответствует несколько (или даже все) из описанных факторов, следует для начала сконцентрироваться на том одном, который имеет наибольший потенциал с учетом вашего конкретного канала связи с потребителем.

Что не дает вашему бизнесу вырасти в 10 раз? – Дэвид Скок

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

Начните с анализа ваших основных метрик.

Каждый продукт должен начинаться с демонстрации и предоставления клиенту некоей базовой ценности.

Разберитесь в том, как клиенты взаимодействуют с вашим продуктом.

Исследуйте жизненный цикл вашего типичного пользователя и выделите характерные шаблоны использования:

Если ваш продукт имеет встроенный вирусный механизм распространения — т.е. клиенты регулярно приводят к вам новых клиентов как следствие нормального использования вашего сервиса (например, Facebook или Twitter) – вам следует задуматься об инвестициях в вирусный фактор роста. В этом же направлении часто работают шаги, направленные на снижение входного порога, например, бесплатная подписка на сервис для максимизации потока пользователей.
Если ваш продукт предусматривает повторное использование (например, продукт типа SaaS), стоит задуматься о том, чтобы приложить усилия к увеличению стоимости жизненного цикла клиентов путем снижения уровня их оттока. В какой-то момент вы упретесь в потолок снижающихся доходов, что будет сигналом для переключения на другой механизм роста, например, платный. В продуктах такого типа вы можете получить распространение по рекомендации, но они редко будут выходить дальше второй степени, т.е. коэффициент виральности будет меньше 1.
Если вы предлагаете продукт одноразового пользования, который не имеет свойства вирусности, как, например, услуги свадебного фотографа или юриста по разводам, ваша единственная ставка – на платный фактор роста. Опять таки, ваш продукт может распространяться по устным рекомендациям и некоторые из ваших клиентов могут даже обратиться к вам повторно, но это никак не может рассматриваться в качестве механизма устойчивого роста.

Выберите механизм для настройки.

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

Кейс CloudFire: смена направления, упорное продолжение или перезапуск Предыдущий этап мы закончили тем, что подписали на наш сервис несколько мам, которые помогли нам доработать наш минимальный актуальный продукт (МАП). Существенный их процент успешно дошел до конца жизненного цикла потребителя , что выразилось в платной подписке и положительных отзывах. Однако, после того как продукт был запущен на широкую аудиторию, мы столкнулись с трудностями при расширении бизнеса на большее число пользователей. В то время как мы создавали продукт для занятых мам с первым ребенком, сам факт того, что они так заняты (событием, которое значительно изменило их жизнь), мешал нам добиться необходимого уровня внимания (проблема механизма роста). Ряд предупреждающих признаков этого (как отмена встречи в последнюю минуту с несколькими последующими переносами) мы вовремя не приняли во внимание. Параллельно с этим, мы тестировали CloudFire на рынке фотографов (используя отдельно брендированный pro-сайт), выбрав в качестве ранних последователей сегмент свадебных фотографов. В отличие от мам, их интерес заключался в распространении и продаже этого контента. Как результат, их мотивация использовать CloudFire была выше, и они были готовы платить за него больше. Однако, между этими двумя сегментами потребителей обнаружилось еще одно неожиданное совпадение. Свадебные фотографы оказались в идеальном положении для того, чтобы продавать CloudFire новобрачным, которые со временем смогли бы использовать сервис для других значительных событий в жизни, например, рождения ребенка – таким образом повышая стоимость жизненного цикла клиента. Свадебные фотографы были мотивированы действовать как партнерские каналы продаж, поскольку CloudFire позволял им дифференцироваться от конкурентов и потенциально извлечь выгоду из брендирования и мероприятий по SEO, которые мы проводили для нашего продукта. Хотя всё это звучало многообещающе, была одна проблема. Я создал эту компанию на техническом основании и для потенциального клиента, который был больше похож на меня, чем на молодую маму или свадебного фотографа. Мне было очень интересно заниматься техническим осуществлением решения, но я обнаружил, что мне гораздо меньше интересны клиенты и их проблемы. Быть заинтересованным только в решении недостаточно. Оглядываясь назад, я могу объяснить, как это случилось. Мой путь как предпринимателя до этого момента можно разделить на три стадии: 1. Соблазн процесса созидания: Предприниматели – суть Художники.

Мы создали это и никогда не думали о том, что это может стать компанией. Мы занимались этим только потому, что считали, что это круто. – Марк Цукерберг (Marc Zuckerberg)

–См. продолжение –

Кейс (продолжение) Как многие предприниматели, я был движим неизъяснимой жаждой «создавать» — строить что-то уникальное, что потенциально изменит мир. Я основал свою компанию в 2002, запустив приложение частной социальной сети под названием 6Degrees. Я совершенно не подозревал о том, что несколько месяцев спустя запустится Friendster, а за ним – еще десяток похожих сайтов социального взаимодействия. Это не остановило нас, поскольку мы использовали другой подход (основанный на приватности и децентрализации). Конкуренция воспринималась нами как форма проверки и давала нам стимул «создавать» дальше. Социальные сети и приватность в 2002 году были далеки друг от друга. Урок 1: Отличаться от конкурентов хорошо только тогда, когда ваше отличие важно для потребителей. 2. Стартап как средство выживания: Художникам тоже нужно есть. Вам необходимо заранее продумать – как обеспечить себе такую «взлетную полосу», которая позволит вам пережить период первоначальных инвестиций. Я не сразу пришел к бутстрэппингу. Я только что покинул стартап, измерявшийся числом с девятью нулями (которым в основном владели сами основатели), поэтому я устроил встречу с основателями. К моему удивлению, хотя концепция им понравилась, финансировать её разработку они не пожелали. Это было моим первым уроком в понимании рисков стартапа и истинной работы предпринимателя. В то время я не полностью усвоил его. С финансированием в этом году было туго (особенно в Техасе), но я был настроен двигаться вперед. В конце концов, удача посетила меня в виде обращения предпринимателя из Норвегии, который нашел меня через блог в интернете и согласился профинансировать разработку моей платформы в обмен на скидку на лицензию.

Количество счастливых совпадений, которые случатся в вашей жизни, ваша Площадь Поверхности Удачи (Luck Surface Area), прямо пропорционально степени вашей увлеченности собственным делом, помноженному на количество людей, которым вы об этом эффективно сообщили. – Джейсон Робертс (Jason Roberts, “How to Increase Your Luck Surface Area”)

Уже тогда я высоко ценил свое время. Я заключил с женой соглашение о том, что буду использовать деньги как барометр успеха – накопление достаточного стартового капитала для удовлетворения моих творческих потуг было призом в этой игре. Как ни странно, в течение семи последующих лет я не испытывал проблем с оплатой счетов и выживал весьма успешно. Постепенно я стал меньше интересоваться созданием сложных продуктов и больше – созданием продуктов успешных. До сего дня я позанимался созданием продукта в «режиме невидимки», пытался построить платформу, поковырялся с открытым кодом, практиковал методику «выпускай быстрее, выпускай чаще», освоил подход «меньше значит больше» и даже попробовал «больше значит больше». К этому моменту я также познакомился с концепцией Работы с Потребителем (Customer Development), и отсюда тропа привела меня к Рациональному Стартапу (Lean Startup), который совершенно изменил мой подход к исследованию и созданию продуктов. –См. продолжение –

Кейс (продолжение) С проектом CloudFire мне удалось найти значимую проблему потребителя и даже зайти достаточно далеко в проверке бизнес-модели (с положительным кэш-флоу), но мне недоставало кое-чего очень важного – ощущения близости к клиентам и их проблемам. В процессе разработки я неосознанно сместил свой акцент от фокуса на проблеме: «соединить всех на планете», к фокусу на решении: «сеть peer-to-web, которая стирает границу между персональным компьютером и сетью». Я стал компанией, которая «искала проблему для своего решения» и рынки и потребители, на которых я вышел, оказались для меня совершенно неожиданными. Урок 2:Прибыль – это первая форма проверки, но этого может быть недостаточно. 3. Призраки прошлого: Художникам необходимо постоянно переосмысливать себя. Люди создают стартап по нескольким причинам, многие из которых выливаются в создание успешного бизнеса (или его успешную продажу). Однако, я пришёл к состоянию, когда мне недоставало чего-то более важного: цели. Я был вынужден осознать образовавшийся разрыв между моим интересом разработчика и найденной проблемой и в результате я понял, что имею два выхода. Я могу нанять недостающие связующие элементы, которые закроют этот разрыв, либо я могу продать компанию. Прошлое может быть полезным опытом либо сдерживающим препятствием, и это не было для меня легким решением. За два прошедших года я столкнулся с новыми проблемами, которые вошли в множественный резонанс с моим «я». Я завел собственный блог как средство повысить свою публичную оценку и параллельно я погрузился в мир Рациональных Стартапов и вступил в активное обсуждение этой концепции. Я был приятно удивлен реакцией и одобрением, которое я получил в ответ. С большой неохотой я принялся за написание этой книги и с еще большим внутренним сопротивлением – за проведение семинаров. Когда я почувствовал, что паззл складывается, я решил нажать кнопку перезагрузки. Я связался со своим первым клиентом из Норвегии (Sverre Fjeldheim) и в течение двух недель мы заключили сделку по продаже. После короткого периода передачи компании я начал закладывать фундамент для новой компании: Spark59. Урок 3:Стартап может занять несколько лет вашей жизни, поэтому выбирайте проблему, которая достойна решения. Хороший способ найти проблему, достойную решения (сформулированный с помощью Патрика Смита (Patrick Smith)), заключается в следующем: погрузитесь полностью в вертикаль (любую вертикаль), которая интересна лично вам и окружите себя другими интересующимися людьми. У людей неизбежно возникают проблемы, и вы, как предприниматель, призваны находить им решения.

Заключение

На рисунке 14-2 представлена схема того, как развивался процесс, описанный в этой книге.

Рисунок 14‑2. Методология Рационализации Стартапа

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

Шаблон разработки для продуктов с сетевым эффектом

Продукт с сетевым эффектом – это продукт, ценность которого зависит от количества человек, которые его используют. Классический пример – телефонный сервис, и многие сетевые сервисы, такие как Twitter и Facebook, также используют эту модель. Рассмотренный нами мета-шаблон может использоваться и для таких продуктов с некоторыми дополнительными оговорками: Внимание – это конвертируемый актив Поскольку ценность продукта растет с количеством пользователей, в разделе «Доходы» вашего Рационального Шаблона вместо «реальной выручки» будет стоять некая формула, конвертирующая количество пользователей в актив. Эту формулу трудно определить точно, но начать можно с рассмотрения стоимости рекламных услуг и оценки проектов, построенных на аналогичной модели. Главный вызов для продуктов такого типа заключается в том, что им необходимо пройти некий переломный момент для того, чтобы получить реальную ценность. До достижения этого момента стартапу приходится выживать в весьма неопределенных условиях.

Twitter начинался как развлекательный побочный проект в то время как Эван Уильямс (Evan Williams) работал на основном месте в компании Odeo, которая незадолго до этого привлекла миллионы долларов инвестиционных средств. – Источник: New York Times

Когда Цукерберг на втором курсе обучения переехал в Силиконовую долину, он думал, что, возможно, однажды он и его команда разработают стартап, но он не думал, что этим стартапом является Facebook. – Источник: TechCrunch

Удержание всё-таки первично Первый значительный этап всё-таки напрямую связан с построением чего-то, что нужно людям. Подтверждением этого будет повторное использование или вовлечение (метрика ценности). Подробнее об этом см. во врезке «Подтвердите ценность прежде, чем расти: Facebook». Используемый фактор роста – вирусный После того, как метрика ценности получила подтверждение на микро-уровне, вам нужно стремиться к переломному моменту роста, используя вирусный механизм роста. Достигнув этого момента, вы можете задуматься о конвертации внимания пользователей в реальный актив с помощью таких средств, как реклама (как в случае Facebook), премиум-аккаунты (как в случае LinkedIn) или что-то подобное.

ПРИМЕЧАНИЕ Хотя мне могут возразить, что продукт с сетевым эффектом, использующий рекламу, является ничем иным, как многосторонним продуктом (площадкой), я предпочитаю зарезервировать последнее название для сервисов, в которых обе стороны активно действуют вместе, развивая бизнес. Этот тип продуктов мы рассмотрим в следующей главе.

Подтвердите ценность прежде, чем расти: FacebookFacebook не был первой социальной сетью, но ему удалось стать крупнейшим. Его создатели применили один уникальный прием: они внедрили свой продукт в уже существующее офф-лайн сообщество – кампус Гарвардского Университета. Прежде, чем распространять продукт на широкую аудиторию, они методично проверили свои предположения о значимых ценностях. Двигаясь от одного кампуса к другому, им удалось выстроить продукт, который был одновременно и ценным для потребителей, и масштабным по охвату.

Шаблон разработки для многосторонних продуктов (площадок)

Многосторонним продуктом я называю сервис, который соединяет покупателей и продавцов, и ценность которого заключается в снижении затрат (в широком смысле слова) на установление взаимного контакта. Классическими примерами таких продуктов являются eBay, Expedia и Priceline. По разным причинам, я вижу, что многие предприниматели выбирают именно эту модель. Вероятно, потому, что эта модель кажется наиболее легко монетизируемой. В конце концов, цель любой площадки – осуществлять бизнес. Но, в то же время, такие площадки довольно трудно организовать по причине, являющейся одним из случаев хорошо известной «проблемы курицы и яйца»: Вы не интересны покупателям потому, что у вас мало продавцов, и наоборот. Вот несколько соображений по развитию таких моделей: Создайте Рациональный Шаблон для каждой участвующей стороны По сути, вы создаете две бизнес-модели в одном. Вам необходимо понять – кто ваши покупатели, как вы установите с ними контакт, и какую уникальную ценность вы им предложите. Затем сделайте то же самое для продавцов. Создание отдельного Рационального Шаблона для каждой из участвующих сторон – отличный способ зафиксировать свои предположения. Проверьте ценность своего продукта среди ранних последователей на небольшой площадке-прототипе Как и в случае продуктов с сетевым эффектом, вам сперва нужно продемонстрировать свои ценности в микро-масштабе. Вместо того, чтобы создавать новую или большую площадку, попытайтесь найти существующую площадку-прототип с потенциальными ранними последователями , на которой и мотивация, и затраты на контакт в настоящее время чрезмерно высоки. Например, если вы задумали площадку, соединяющую операторов экстремальных туров с провайдерами соответствующих сервисов, начните с конкретного вида активного отдыха (например, скалолазания) в вашей местности, в случае которого вы имеете прямой доступ к обеим сторонам процесса. Аналогично, если вы планируете заниматься улучшением процесса продаж множества категорий/товаров, начните с одной узкой ниши. Проведите раздельные интервью по Проблеме и Решению, чтобы проверить свои предположения касательно уровня дискомфорта и мотивации как продавцов, так и покупателей. Получите подтверждение, создайте МАП и начните соединять продавцов и покупателей. Пример этого см. во врезке «Начните решать проблемы площадки с микро-масштаба: Airbnb». Не автоматизируйте процесс подбора Найти соответствие покупателя и продавца – трудная задача. Подумайте о том, чтобы создать Консьерж МАП (как пример см. описание проекта Food on The Table в Разделе 5) – это поможет вам сохранить высокий уровень качества пока вы будете учиться тому, как можно автоматизировать этот процесс. Другой пример этого вы найдете во врезке «Сначала научитесь делать руками, потом автоматизируйте: AngelList». Определите подходящий фактор роста для каждой стороны Вам, вероятно, удастся использовать рекомендации, полученные на ранней стадии, для того, чтобы войти на смежные площадки. Однако, избегайте ситуации, в которой вам придется параллельно настраивать два различных механизма роста для каждой из сторон площадки.

Начните решать проблемы площадки с микро-масштаба: AirbnbAirbnb – это сервис, соединяющий людей, ищущих апартаменты на отпуск или на другой краткосрочный период, и людей, у которых есть соответствующие объекты в аренду. На момент написания этих строк у Airbnb имеются предложения из 16000 городов 186 стран мира. Но этот сервис не ушел бы так далеко без долгого периода кропотливого обучения. В ходе первого эксперимента, с которого и начался продукт, основатели предлагали комнаты в аренду во время проведения известной дизайнерской конференции с ажиотажным посетительским спросом. После этого они провели еще два дополнительных эксперимента: один – во время фестиваля SXSW в Остине, Техас, и второй – во время Национальной Демократической Конвенции в Денвере, всё это время консультируясь «на стороне». Вскоре после этого они присоединились к программе Y Combinator, где сконцентрировались на продукте полностью и стали систематично разворачивать его на всё новые и новые города.

Сначала научитесь делать руками, потом автоматизируйте: AngelListКогда проект AngelList только запустился, его основатели – Ниви и Наваль – потратили массу личного времени на то, чтобы исследовать и обучить компании с высокими перспективами привлечения инвестиций, которые они затем сводили с первоклассными инвесторами посредством представления по электронной почте. Такая организация процесса позволила добиться высокого процента заключенных сделок, подкрепленных благоприятными отзывами как инвесторов, так и предпринимателей, что помогло бизнесу вырасти. Это также помогло им выявить те части ручного процесса, которые было наиболее целесообразно автоматизировать, что они позднее с успехом реализовали в своем онлайн-сервисе.

Раздел 15: Заключение

Что дальше?

Я уверен, что жизнь любого стартапа можно разделить на два этапа: до достижения соответствия Продукт/Рынок и после достижения этого соответствия. – Марк Андреэссен, «The Pmarca Guide to Startups»

Жизнь после достижения соответствия Продукт/Рынок

Достижение соответствия Продукт/Рынок – это первая важная веха в жизни любого стартапа. Начиная с этой стадии, определенная доля успеха вам уже гарантирована и вы можете сместить фокус своего внимания с обучения на масштабирование (см. Рисунок 15-1).

Рисунок 15‑1. После достижения соответствия Продукт/Рынок

Помимо очевидного вызова, связанного с необходимостью настройки механизма роста по мере привлечения новых пользователей и перехода от ранних последователей к массовому клиенту[1], вы столкнетесь и с другими проблемами роста. Всё идет хорошо до тех пор, пока вы не добавляете новых людей. Ключ в том, чтобы создать культуру постоянного обучения, в которой эксперимент превалирует над специалистом, и в которой каждый сотрудник занят тем, что создает и реализует ценности клиента.

Стиль Toyota не в том, чтобы создавать результат путем упорного труда. Это – система, которая утверждает, что креативности людей нет предела. Люди приходят в компанию Toyota не «трудиться», они приходят туда «мыслить». – Таичи Оно

[1] Джеффри Мур (Geoffrey Moore) описывает процесс этого перехода в своей книге Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers (Harper Business)

Сдержал ли я своё обещание?

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

Остаемся на связи

Книга, как большой программный продукт, никогда не бывает закончена. Можно говорить только о выпуске очередной версии. Эта книга – только начало. Я продолжаю делиться своими результатами в блоге по адресу http://ashmaurya.com и периодически провожу семинары. Больше практических советов по теме вы найдете в моем журнале Мастерство Рационализации Стартапов (Running Lean Mastery): http://blog.runningleanhq.com/mastery/. Вы можете в любой момент написать мне на ash@spark59.com. Twitter: @ashmaurya Skype: ashmaurya Спасибо, что прочитали эту книгу, и теперь – вперед, к вашему успеху!

Running Lean или Рационализация Стартапа — Часть 4 (продолжение)

Раздел 8: Интервью по Решению

Проведите тестирование на демо-версии прежде, чем создавать полноценный продукт.

Что необходимо узнать?

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

Тестирование вашего решения

Основная цель этого этапа – помочь клиентам визуализировать ваше Решение и проверить – насколько оно решает их проблемы. Большинство клиентов способно объяснить свою проблему, но мало кто способен представить решение. Термин демо-версия я использую для того, чтобы описать всё, что может подменить собой реальный продукт. Предположение, из которого я исхожу – создание «реального продукта» отнимает много времени и может стать нерациональным расходованием ресурсов, если вы создадите неправильный продукт или займетесь добавлением невостребованных характеристик. Вам нужно построить ровно столько из своего продукта (например, скриншоты или прототипы), сколько вам необходимо показать своему клиенту для измерения его реакции и дальнейшего определения набора свойств Минимально Актуального Продукта (МАП). В случае программного продукта макеты и видео прекрасно справляются с демонстрацией идеи вашего Решения. Для физических продуктов в этом качестве могут выступить наброски, CAD-макеты или даже прототипы, наскоро изготовленные из модельной глины или напечатанные на 3D-принтере. Вне зависимости от того, какой материал вы выбираете для своей демо-версии, держите в голове следующие соображения: Демо-версия должна быть воплощаема в жизнь У меня есть друзья в дизайн-студиях, у которых целые команды занимаются тем, что разрабатывают демо для ранних демонстраций. Эти демо являются важной частью процесса продаж и на них делается большой акцент, однако зачастую они создаются с использованием технологий (например, Flash), которые не будут использоваться в реальном продукте. Будучи очень эффективны для продаж, эти элементы сильно осложняют работу команды внедрения, поскольку многие из них бывает затруднительно или просто невозможно реализовать на основе других технологий. Это ведет к негативному разрыву между тем, что было обещано (и продано) клиенту, и тем, что было реализовано на самом деле. Демо-версия должна выглядеть реалистичной Я также не рекомендую впадать в другую крайность и работать с грубыми «скелетными» макетами и набросками. Хотя они и экономят время разработчика, их применение требует от клиента большей веры в конечный продукт, чего я стараюсь избегать. Чем более реалистичным выглядит ваше демо, тем более точными будут результаты ваших тестов. Демо-версия должна быть легко корректируемой В ходе интервью вы, вероятно, получите ценные рекомендации по изменениям, которые будет необходимо протестировать в дальнейшем. Именно поэтому я настоятельно не рекомендую отдавать разработку демо-версии на аутсорсинг. Зависимость от чужого расписания может действительно навредить вашему проекту на этой ранней стадии. Разработка демо-версии также должна быть рациональной Создание демо с использованием какой-либо технологии, которая не будет реализована в конечном продукте, является нерациональным расходованием ресурсов. Для своих макетов я обычно начинаю с набросков, которые затем довожу до ума в Photoshop и Illustrator, и, наконец, конвертирую в HTML/CSS, что, в конечном итоге, дает мне экономию сил и средств. Демо-версия должна использовать реалистичные данные Вместо данных-«заполнителей» (типа текста lorem ipsum) старайтесь использовать реалистичные данные. Это не только поможет вам более качественно спроектировать дизайн, но и поддержит презентацию вашего решения с содержательной точки зрения.

Контент первичнее дизайна. Дизайн в отсутствие контента – не дизайн, а лишь декорация. – Джеффри Зелдман (Jeffrey Zeldman), A List Apart (Happy Cog Studios)

Кейс CloudFire В случае с CloudFire я смонтировал несколько изображений экрана в видео-ролик, демонстрирующее, как пользователь менее чем за две минуты выкладывает в обмен 500 фотографий из существующего альбома iPhoto и 10 видео из локальной папки на компьютере.

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

Кейс Тестирование Решения с помощью записи в блоге В августе 2009 я опубликовал в своем блоге запись под названием «Как я документирую свои гипотетические бизнес-модели». Ранее я придерживался подхода Стива Бланка и использовал для этого электронные таблицы, как это описано в его книге, но каждый раз мне приходилось прикладывать усилия к тому, чтобы поддерживать их в обновленном состоянии. Из разговоров с другими поклонниками концепции Customer Development (Работа с потребителем) я знал, что их это тоже мучает. Незадолго до этого я наткнулся на работу Алекса Остервальдера по Шаблону Бизнес-Модели (Business Model Canvas), но поначалу отверг идею шаблона как чрезмерно упрощенную. Однако, глядя на то, как другой предприниматель – Роб Фитцпатрик (Rob Fitzpatrick) – создает вариацию, комбинирующую таблицы Стива Бланка с шаблоном Алекса Остервальдера, я решил и сам поэкспериментировать на этом поле. Результатом стал Рациональный Шаблон, который я и описал в своем блоге. Пост с этой записью быстро стал самым популярным среди всех моих постов. Я расценил это как сильный положительный сигнал в пользу моей идеи и использовал этот импульс для проведения нескольких формализованных интервью с пользователями, которые подтвердили достоинства моего решения. В итоге это привело к созданию команды (также через мой блог), которая занялась созданием он-лайн версии Рационального Шаблона.

Тестирование ценообразования

Я обнаружил, что люди часто неверно трактуют метафору «обучение, а не продажа» для случая интервью с потребителями. Действительно, ваша цель при проведении таких интервью – приобретение знаний, а не продажа, но факт заключается в том, что вы не можете обучаться эффективно если вы формулируете слишком туманные или открытые вопросы. На интервью вам следует выносить четкие, опровержимые гипотезы, которые могут быть очевидным образом разрушены. Это – правильный подход. Цена, которую вы собираетесь брать за свой продукт – это еще одна из таких гипотез, но метод её проверки несколько отличается. В отличие от гипотезы о «критической» проблеме, где вы пытаетесь «прозондировать» пользователя и выявить истинные причины его поведения, цена продукта представляет собой более «серую» зону и с ней нужно работать более непосредственно.

Не спрашивайте клиентов, сколько они готовы заплатить. Говорите им это

Можете ли вы представить себе Стива Джобса, спрашивающего вас перед запуском на рынок iPad о том, сколько вы готовы заплатить за него? Звучит смехотворно, не так ли? Кроме того, вероятно в какой-то момент вы уже спрашивали потребителей о «примерной цене». В целом, это только осложнит вашу работу. Задумайтесь – у потребителя нет ни одной разумной экономической причины не назвать вам заниженную цифру. Ваш клиент совершенно искренне не знает, сколько он готов был бы заплатить, и ваш вопрос только ставит его в неудобное положение. Вы не можете (и не должны) убеждать клиента в том, что у него есть важная проблема, но вы часто можете (и должны к этому стремиться) убедить клиента заплатить «справедливую» цену за ваш продукт, которая обычно выше, чем предполагаете и вы, и ваш клиент. Настрой, с которым большинство из нас выходит на интервью по Решению, можно назвать «снижение входного барьера». Мы хотим, чтобы клиенту было максимально просто сказать «да» и согласиться попробовать наш продукт, питаясь надеждами на то, что в неопределенном будущем польза нашего решения позволит собрать дивиденды с его бизнеса. Такой подход не только вреден для объективной оценки, поскольку сказать «да» в таких условиях слишком просто. Кроме этого, недостаточная вовлеченность клиента может пагубно сказаться на результатах вашего исследования. Ваша работа заключается в том, чтобы найти ранних последователей, которые так же озабочены рассматриваемой проблемой, как и вы, и которые готовы платить ту справедливую цену, которую вы просите. Как мы рассматривали раньше, цена не просто является частью продукта, она еще и определяет сегмент потребителей, к которому вы обращаетесь.

Не снижайте входной барьер, повышайте его

Я знаю, что это может противоречить вашей интуиции. Так было и со мной. Вот небольшой социальный эксперимент, который я провел в ходе одного интервью с клиентом (и затем повторил еще несколько раз), и который изменил мой взгляд на вещи. Я только что закончил демонстрацию решения и убедился, что мы имеем на руках важную для потребителя проблему и её решение. Я: Теперь поговорим о цене… Клиент: Стоит ли торговаться о цене прямо сейчас? Я: Это не совсем торговля. Дело в том, что хотя мы и используем этот продукт для себя, нам надо убедиться, что производство его для внешних клиентов экономически оправдано. Клиент: Ага, ясно. Я: Итак, сколько бы вы заплатили за этот продукт? Клиент: Я не знаю, вероятно, что-нибудь от 15 до 20 долларов в месяц. Я: Ммм… Это не совсем та цена, которую мы держали в голове. Мы планировали начать со 100$ в месяц. Я понимаю, почему вы не хотите платить много (потому что ваша компания только развивается) и, возможно, в будущем мы разработаем специальный план с ограниченным набором бесплатных услуг. Сейчас мы специально отбираем 10 [назовите ранних последователей], которые явно испытывают потребность в решении [назовите значимую проблему]. Мы будем плотно совместно работать с этими 10 компаниями и либо мы подтвердим [назовите ваше УТП] в течение 30-60 дней, либо вернем назад полученные деньги. Вы упомянули, что уже тратили несколько часов работы инженера в месяц на построение аналогичной системы и всё-таки остались недовольны результатом. Эта версия продукта – наша третья попытка; 100$ в месяц – меньше, чем 2 часа работы инженера. Клиент: Да, звучит очень разумно. Мы бы хотели войти в этот список. Мы можем потратить на это 1200$ в год. Это существенно меньше, чем мы платим своим инженерам. Как нам попасть в этот список? Я: Мы всё еще в процессе финализации некоторых характеристик продукта и я сообщу вам когда мы приступим к его формированию. Клиент: Мы всерьёз намерены быть в числе ваших первых клиентов. Если хотите, я поднимусь наверх за чековой книжкой… Итак, что здесь произошло? Как клиент согласился заплатить впятеро от первоначальной цены? В игре были использованы несколько принципов, а именно: Призовая игра Орен Клафф (Oren Klaff) обсуждает эту методику в своей книге «Продай всё» (Pitch Anything, McGrow-Hill). Он находит, что в большинстве продающих презентаций ведущий действует чем-то сродни шуту при королевском дворе (потребителей). Чем пытаться впечатлить клиента, спозиционируйте себя как супер-приз. Ограниченность предложения Утверждение о «10 клиентах» не является полным блефом. Главная цель вашего МАП (минимального актуального продукта) – дать вам информацию, позволить научиться. Поэтому для меня гораздо предпочтительнее иметь всего 10 ранних последователей с высоким уровнем вовлеченности в проект, которым я смогу полностью уделить своё время, чем 100 клиентов-«наблюдателей» каждый день^[1]. Ценовой якорь Как мы обсуждали ранее, цена относительна. Однако, сравнение цены вашего продукта с существующими альтернативами может быть не так очевидно для ваших клиентов, как для вас. Даже Стив Джобс использовал этот принцип, когда презентовал цену на iPad в абсолютно новой товарной категории. Он грамотно спозиционировал цену на iPad относительно предсказаний «экспертов» (которые использовали нетбуки в качестве ценового якоря) и сделал так, что iPad стал восприниматься как подарок. Уверенность Многие предприниматели внутренне сопротивляются взиманию платы за свой МАП, поскольку считают его слишком «минимальным», и даже чувствуют в связи с этим неудобство. Я не поддерживаю такой образ мышления. Цель всей кропотливой работы по тестированию проблем и выбору самых важных из них заключается в том, чтобы создать «простейший» продукт, который решает реальную проблему потребителя.

Интервью по Решению с точки зрения AIDA

AIDA – это принятый в маркетинге акроним для последовательности, описывающей стадии взаимодействия с потребителем: Attention (Внимание), Interest (Интерес), Desire (Желание), Action (Действие). Эта универсальная схема также хороша и для построения структуры интервью по Решению. А именно: Внимание Ранее в ходе серии интервью по Проблеме вы обнаружили первостепенную для клиента проблему. Исходя из этого, составьте своё УТП – привлеките внимание клиента. Самый эффективный способ обратить на себя внимание – ухватить проблему клиента. Интерес Продемонстрируйте свой продукт (его демо-версию) и то, как он реализует ваше УТП – возбудите интерес клиента. Желание Теперь немного натяните леску. Когда вы снижаете порог входа, потребителю становится слишком просто сказать «да». При этом эффективность вашего исследования может страдать. Напротив, необходимо поддерживать высокую заинтересованность клиента, играя на его желании. Обсуждение цены уже на этой стадии с применением методов Призовая игра и Ограниченность предложения способно сгенерировать желание. Действие В зависимости от конкретного продукта получите устное, письменное или денежное подтверждение заинтересованности. [1] Правило 10Х при запуске продукта: http://www.ashmaurya.com/2011/10/the-10x-product-launch/

Чем это отличается от продажи?

Хотя внешне это может показаться похожим на продающую презентацию, тем не менее, всё интервью строится вокруг обучения. Продающая презентация, как правило, имеет характер предложения «всё или ничего». В нашем случае вы выходите на каждую новую стадию с четкой гипотезой и измеряете реакцию пользователя. Если вам не удается выявить ожидаемое поведение потребителя на какой-то стадии, ваше дело – сделать паузу и выяснить причины. Например, вы можете допустить ошибку с позиционированием или адресовать свое предложение неправильному сегменту потребителей. Модель AIDA отлично подходит также для разработки вашей будущей посадочной страницы и других сопутствующих инструментов продажи. Со временем вы сможете генерировать у потребителей желание с помощью других инструментов, таких как социальное признание и сила бренда, но никогда не стоит недооценивать возможности сильных эмоциональных механизмов.

Формулируйте опровержимые гипотезы

Как и ранее, вам необходимо сформулировать четкую опровержимую гипотезу, которую вы будете тестировать в ходе интервью.

Кейс CloudFire На рисунке 8-1 изображена предыдущая версия Шаблона и отмечены поля, которые необходимо протестировать. На рисунке 8-2 перечислены гипотезы, которые легли в основу моих экспериментов.

Рисунок 8-1. Интервью по Решению для проекта CloudFire

Рисунок 8-2. Эксперименты для проверки гипотез Интервью по Решению

Проведите интервью по Решению

Теперь вы готовы провести интервью по своему Решению. Используйте ранее найденных последователей. Ранее вы должны были получить разрешение на повторный контакт от тех людей, с которыми вы проводили интервью по Проблеме. Если эти клиенты демографически соответствуют вашим ранним последователям, договоритесь с ними о повторной встрече для обсуждения Решения. Добавьте несколько новых лиц Полезно добавлять к участию в опросах некоторое количество не опрошенных ранее людей на каждой новой стадии проведения интервью. Это поможет вам дополнительно проверять каждую гипотезу на свежих головах. Из предыдущих интервью у вас должны были остаться неиспользованные рекомендации, которые отлично подойдут для этой цели. Кроме того, сейчас настал подходящий момент для тестирования новых каналов, которые, возможно, определились на предыдущей стадии. Далее, рассмотрим сценарий интервью по Решению. Структура сценария показана на рисунке 8-3.

Рисунок 8-3. Сценарий интервью по Решению

Приветствие (краткое введение)

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

Демографические данные (тип сегмента потребителей)

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

Сколько у вас детей?
Сколько им лет?
Обмениваетесь ли вы фотографиями через интернет?
Обмениваетесь ли вы видео через интернет?
Как часто?
С кем?

Ваша история (определите контекст проблемы)

(2 минуты) Как и ранее, поясните основные проблемы на примере вашей истории: Отлично, спасибо. Теперь позвольте мне рассказать вам о проблеме, над которой мы работаем. После появления ребенка мы обнаружили, что стали снимать намного больше фото, а особенно – видео. Также мы стали получать регулярные (сейчас – еженедельные) запросы новых фото и видео от бабушек и дедушек, а также других членов семьи. Но мы обнаружили, что регулярно обмениваться свежим материалом весьма затруднительно, поскольку процесс занимает много времени, а иногда – и нервов. Приходилось сортировать файлы, менять разрешение, следить за процессом передачи. В случае с видео всё было еще хуже, поскольку приходилось конвертировать файлы в подходящий для воспроизведения в интернете формат. Как и большинству других родителей, нам и поспать особенно не удается, не говоря уже просто о свободном времени. С появлением ребенка мы стали совершенно по-новому ценить свободное время и тратить время на описанные выше упражнения с файлами кажется нам совершенно неразумным. Сталкивались ли вы с чем-либо подобным? Если в этот момент вы не чувствуете сильной заинтересованности пользователя, не продолжайте интервью по Решению, а лучше переключитесь на сценарий интервью по Проблеме и выясните – как ваш собеседник решает эти проблемы сейчас.

Демонстрация (тест Решения)

(15 минут) Этот пункт является основным во всем интервью. Рассматривайте проблему поочередно и показывайте, как ваш продукт их решает, с помощью вашего демо. <Для каждой проблемы> Покажите, как ваш продукт её решает, с помощью демо-версии. Сделайте паузу и спросите, не ли у собеседника вопросов. <Повторите для остальных проблем> Итак, вот как выглядит наше приложение прямо сейчас. Мы хотим расставить приоритеты и выяснить, какие функции запускать в первую очередь. Поэтому позвольте задать вам еще несколько вопросов:

Какая часть демо-продукта заинтересовала вас больше всего?
Без какой вы могли бы обойтись?
Есть ли что-то, что необходимо добавить?

Тест цены (доходная часть)

(3 минуты) Определение правильной цены – это больше искусство, чем наука. Обычно, правильная цена – это та цена, которую клиент принимает, но с небольшим сопротивлением. Проверьте восприятие цены, используя «стартовую цену», которую вы определили для этого сегмента потребителей ранее. Не спрашивайте клиента о его предположениях относительно цены. Наоборот, предложите ему свою цену (с якорями или без) и непосредственно замеряйте его реакцию. Если он соглашается с ценой, отметьте для себя – согласился ли он охотно или поколебался при этом. Теперь давайте поговорим о цене. Мы запускаем этот сервис на основе платной подписки. Готовы ли вы заплатить $49 в год за возможность неограниченного обмена фото и видео?

Завершение («Крючок» на будущее)

(2 минуты) Мы закончили со всеми гипотезами, но у вас осталось еще 2 вопроса, которые необходимо задать. Первый касается того, чтобы в будущем предложить этому клиенту протестировать сервис, когда тот будет готов. По возможности, постарайтесь получить что-то более весомое, чем просто устное согласие. Второй – про людей, с которыми вы сможете провести аналогичные интервью. Большое спасибо за ваше участие. Вы нам очень помогли. Как я упоминал в начале, продукт еще не готов, но мы готовимся вскоре запустить первую версию. Будет ли вам интересно протестировать наш продукт, когда что-то будет готово? Кроме того, нам было бы интересно поговорить с другими людьми, похожими на вас. Можете ли вы порекомендовать для этого других родителей с маленькими детьми?

Документирование результатов

(5 минут) Уделите 5 минут непосредственно после завершения интервью и задокументируйте результаты, пока они свежи в вашей голове. В этом вам поможет шаблон, подобный тому, который приведен ниже. Компактная форма позволяет быстро фиксировать реакцию собеседника на тестируемую гипотезу. Как и ранее, пусть каждый из вашей команды интервьюеров заполнит форму самостоятельно. Позже сравните ваши результаты и занесите финальный результат в общую систему учета, которой вы пользуетесь. ИНТЕРВЬЮ ПО РЕШЕНИЮ Дата:__________________ Контактные данные Имя:___________________________________________________________________________ Email:__________________________________________________________________________ Демографические данные Количество детей:_________________ Возраст:_________________________ Обменивается фото онлайн:__________ Обменивается видео онлайн:_________________ Как часто:____________________________ С кем:________________________________ Решение: Быстрый обмен контентом без «закачки» Приоритет:_____________ Уровень дискомфорта:_____________________ Дополнительные комментарии________________________________________________________ Решение: Интеграция с iPhoto/папками Приоритет:_____________ Уровень дискомфорта:_____________________ Дополнительные комментарии________________________________________________________ Решение: Автоматическое декодирование видео Приоритет:_____________ Уровень дискомфорта:_____________________ Дополнительные комментарии________________________________________________________ Цена Готов платить ($ в месяц)____________ Примечания:_____________________________________________________________ Рекомендации:____________________________________________________________

Заслуживает ли ваша Проблема Решения?

В этой главе я расскажу, как интерпретировать результаты ваших интервью, как адаптировать сценарий интервью и как определить правильный момент для завершения этого этапа. Анализируйте результаты еженедельно Как и ранее, дождитесь накопления порции недельных интервью, прежде чем менять сценарий. Добавляйте/удаляйте характеристики Если вы получили конкретное указание на некие необходимые улучшения или характеристики, обсудите с коллегами – так ли действительно они необходимы? Удаляйте невостребованные характеристики. Подтверждайте свои предшествующие гипотезы Если стадию интервью по Проблеме вы закончили с сильными сигналами позитивного восприятия, здесь не должно быть сюрпризов. В противном случае, вернитесь к своим гипотезам и уточняйте их до тех пор, пока не получите большей определенности. Уточняйте цену Если вы не чувствуете сопротивления клиентов текущей цене, попробуйте протестировать более высокое значение. Возьмите в расчет существующие альтернативы, использующиеся клиентами. Если существующая альтернатива распространяется бесплатно, как вы можете повысить ценность вашего предложения и оправдать взимание платы? Сможете ли вы построить жизнеспособный бизнес с этой ценой?

В какой момент можно заканчивать этап интервью по Решению?

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

Кейс CloudFire По результатам проведения еще 20 интервью мы узнали следующее: Потребительский риск: кто испытывает дискомфорт? (Ранние последователи) Гипотеза Интервью по Решению подтвердят, что родители с маленькими детьми являются ранними последователями. Результат Основываясь на ранее полученных результатах мы выяснили, что основную часть обмена контентом осуществляют мамы, и что мотивация к распространению контента выше в случае первого ребенка, причем это относилось ко всем членам семьи. Мы также обнаружили наступление некоторой усталости от процесса после достижения ребенком возраста трех лет. В последующих интервью мы смогли сузить целевой сегмент ранних последователей до «матерей с первым ребенком в возрасте до трех лет». Это очень помогло нам, так как существенно облегчило процесс идентификации и отбора ранних последователей. Продуктовый риск: Как вы решаете проблему? (Решение) Гипотеза Интервью по Решению подтвердят минимально необходимый набор характеристик Результат Показанное нами демо было встречено очень хорошо и вызвало у клиентов ощущение скорости и удобства обмена контентом. Тот факт, что данные в процессе обмена заодно и сохраняются в резервную копию, пришелся очень кстати. Хотя многие родители и высказывали необходимость интеграции с сторонними продуктами (iPhoto, Picasa и т.д.), все они соглашались начать с простой модели, работающей с папками. С нашей стороны, рациональное обоснование этому было простым: это решение требовало от нас меньше работы (по сравнению с интеграцией в сторонние приложения) и оно было более универсальным (каждый компьютер имеет файловую систему). Рыночный риск: какова будет цена? (Доходы) Гипотеза Интервью по Решению позволят получить устное подтверждение готовности платить $49 в год. Результаты Как и ожидалось, родители с «бесплатными альтернативами» немного сопротивлялись при обсуждении оплаты, но они видели ценность продукта в параллельном резервном копировании своих файлов в процессе обмена и соглашались на бесплатный тестовый период. Родители, использующие платные сервисы, не выказывали сомнений по поводу оплаты при условии, что мы облегчим для них процесс переноса существующего контента на CloudFire. – См. продолжение –

Кейс (продолжение) Обновленный Рациональный Шаблон Принимая во внимание уточненное определение сегмента ранних последователей, мы определили несколько новых потенциальных каналов, что показано на рисунке 8-4.

Рисунок 8‑4. Обновленный шаблон Родители

Что дальше? Воспользуйтесь этими знаниями для разработки и создания МАП.

Раздел 9: Приступаем к запуску Версии 1.0

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

Разработка продукта и последовательность обучения

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

Рисунок 9‑1. Традиционный цикл разработки продукта

Хотя первичное накопление знаний происходит и на этапе сбора требований, основное обучение происходит уже после запуска продукта. Парадоксально, но до запуска продукта, что является конечной целью стартапа, вы узнаете очень мало. То есть, конечно, вы узнаете о многих других вещах, но о своем клиенте вы не узнаете ничего нового ни в процессе разработки, ни в процессе тестирования. Очевидно, нельзя обойтись без разработки и контроля качества, но можно и нужно максимально укоротить время цикла от сбора требований до их внедрения, чтобы максимально быстро переходить к стадии получения знаний. Первый шаг заключается в том, чтобы сократить масштаб операций, выполняемых вашим минимальным актуальным продуктом (МАП), до самой необходимой сути.

Сокращайте свой МАП

Опасно увлекаться добавлением новых элементов на той стадии, когда ваш продукт существует только в макете – это может увести вас далеко от того, что действительно необходимо для минимального актуального продукта. Чтобы снизить нерациональное расходование ресурсов и добиться максимально эффективного обучения, режьте ваши макеты до тех пор, пока на них не останется самая суть вашего продукта: ваш МАП. Уменьшение масштаба операций вашего продукта не только сокращает время разработки, но и ликвидирует лишние отвлекающие факторы, которые могут размыть базовую идею и ценность вашего продукта. Ваш МАП должен быть как хорошо уваренный соус – концентрированный, насыщенный и ароматный. Вот как этого добиться:

Начните с чистого листа. Не считайте, что все когда-либо упомянутые характеристики должны быть обязательно реализованы в вашем продукте. Напротив, начните с пустого списка и хорошенько обдумывайте добавление каждой новой характеристики.
Начните со своей «Проблемы №1» Задача вашего УТП – сделать заманчивое предложение. Задача вашего МАП – выполнить сделанное обещание. Суть вашего МАП должна быть заключена в вашей «Проблеме №1». Начните с неё.
Откажитесь от «желательно» и «не нужно» Из ваших интервью по Проблеме вы должны были вынести понимание того, к какой категории относится каждая из придуманных вами характеристик вашего продукта: «обязательно», «желательно» или «не нужно». Не раздумывая откажитесь от категории «не нужно», и внесите категорию «желательно» в очередь на реализацию второго приоритета, за исключением тех случаев, когда эти функции неразрывно связаны с реализацией «обязательных» элементов продукта.
Повторите пункт 3 для «Проблемы №2» и «Проблемы №3».
Обдумайте запросы на добавление характеристик, поступившие от пользователей. Ваши клиенты могут называть характеристики, добавление которых необходимо для того, чтобы ваш продукт стал законченным или удобным в использовании, например, интеграцию с salesforce.com. Рассмотрите эти предложения и добавьте их в свой список или исключите из рассмотрения в зависимости от их реальной необходимости.
Выставляйте счета с первого дня, взимайте плату с 30го. Общепринято, что многие программные продукты в наше время предлагаются с неким тестовым периодом. Такой подход в целом позволяет снизить входной барьер и избежать потенциального риска возврата денег. Всё это также помогает вам уменьшить масштаб операций на начальном этапе. Вам не нужно беспокоиться о торговом счете, задумываться об организации сервиса подписки или разрабатывать несколько планов подписки уже на старте. У вас будет 30 дней после запуска для всего этого.
Сконцентрируйтесь на обучении, не на оптимизации. Вся ваша энергия должна быть направлена на максимально быстрое обучение. Скорость – ключ к успеху. Не тратьте ресурсы на то, чтобы оптимизировать серверы, код, базы данных и т.д. на будущее. Шансы того, что после запуска у вас не будет проблемы масштабирования, очень велики. В том редком случае, когда вы с ней столкнетесь (если ваш продукт решает действительно замечательно важную проблему), большинство проблем масштабирования решается поначалу простым наращиванием мощностей. Вы можете себе это позволить потому, что ваши клиенты платят вам – за ваше время, потраченное на более эффективное решение их проблемы.

Немедленно приступайте к внедрению

Еще одна полезная методика сокращения времени цикла разработки продукта – это процесс Непрерывного Внедрения (см. рисунок 9-2). Непрерывное Внедрение – это концепция непрерывного выпуска обновленных версий вашего продукта в течение короткого периода времени – за минуты, а не за дни, недели и месяцы.

Рисунок 9‑2. Процесс Непрерывного Внедрения

Непрерывное внедрение построено на идеологии непрерывных потоков, разработанной в компании Toyota. Было на практике доказано, что такой подход повышает эффективность производства путем реорганизации производственных процессов таким образом, что продукт создается от начала до конца по одному за раз, а не обрабатывается партиями, теряя время на ожидание, как было ранее. Цель – снизить нерациональное расходование ресурсов. Наиболее нерациональная трата ресурсов в производстве возникает при транспортировке продуктов из одного места в другое. Наиболее нерациональная трата ресурсов в создании программных продуктов возникает из-за ожидания, пока продукт пройдет все стадии запуска: ожидание кодирования, ожидание тестирования, ожидание запуска. Снижение продолжительности или полное исключение этих периодов позволяет быстрее внедрять обновления, что является ключом к успеху. Из всех методик Рационального Стартапа (Lean Startup) Непрерывное Внедрение представляет собой наиболее противоречивый пример. Среди опасений, которые сразу приходят на ум, основное касается возможной потери качества: Непрерывное Внедрение приравнивают к «программированию по-ковбойски». При правильном применении Непрерывное Внедрение никак не вредит качеству, а на деле даже требует применения более строгих стандартов тестирования и мониторинга. Непрерывное внедрение практикуется не только маленькими стартапами, эта методика применяется такими гигантами индустрии, как IMVU (один из пионеров внедрения), Flickr и Digg. Среди всех примеров наиболее выдающимся является, без сомнения, проект Wealthfront, который действует в критически сложной обстановке зарегулированной отрасли финансовых рынков и при этом выпускает более дюжины обновлений в день. Эти компании вместе обслуживают миллионы пользователей каждый день, и им удалось построить весьма сложные системы непрерывного внедрения, обеспечивающих высокие стандарты качества, что приводит нас ко второму опасению. Второе опасение обычно заключается в том, что построение системы непрерывного внедрения считают трудной и громоздкой задачей. Конечно, это так. Но приведенные в пример системы строились постепенно в течение многих лет. Как мы увидим в дальнейшем, процесс Непрерывного Внедрения сам по себе является ничем иным, как каналом обратной связи для сбора рыночной информации и улучшения продукта, что прекрасно реализуется уже на ранних стадиях развития компании. Поэтому я уделяю этому место в своей книге. Сейчас наступает самый подходящий момент для того, чтобы попрактиковаться в Непрерывном Внедрении – пока у вас нет клиентов, сложного кода и множества серверов, о которых надо постоянно заботиться. Хотя Непрерывное Внедрение и не поможет вам быстрее запустить ваш МАП, применение его базовых принципов не замедлит ваш запуск и при этом заложит фундамент для ускорения будущих обновлений. Также важно отметить, что хотя Непрерывное Внедрение и подразумевает внедрение нового кода малыми порциями, эти обновления не обязательно должны быть видны вашим пользователям. В этом отличие «программного запуска» от «маркетингового запуска». (См. «Как запустить систему Непрерывного Внедрения» в Приложении.)

Проработайте процесс активации

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

Анатомия процесса активации

Процесс активации можно представить в виде последовательности шагов, формирующих внутри воронки продаж свою суб-воронку (см. рисунок 9-3).

Хотя главная цель процесса активации заключается в том, чтобы как можно скорее довести вашего клиента до того, что было обещано вашим УТП, как ни странно, основные проблемы с вновь запущенным проектом случаются именно здесь. По этой причине критически необходимо сконструировать ваш процесс активации с приоритетом на обучение (получение информации о клиенте), а не на оптимизацию. Вот как это можно сделать: Снижайте входной барьер, но не ценой обучения В целом полезно делать форму подписки максимально короткой и запрашивать только те данные, которые вам действительно необходимы, однако ни в коем случае не стесняйтесь сразу же запрашивать важную контактную информацию (например, адрес электронной почты) (подробнее об этом см. во врезке «Создайте канал обратной связи с клиентами: CloudFire»).

Формы – это наименьшая из наших проблем. – Джошуа Портер (Joshua Porter, Bokardo.com)

Создайте канал обратной связи с клиентами: CloudFire CloudFire – это локальное приложение, требующее установки, и для упрощения процесса подписки мы разместили простую кнопку «Загрузить» на главной странице и отложили создание аккаунта (регистрацию) на стадию установки программы. Наша аналитика показала колоссальную разницу между количеством скачиваний и количеством регистраций. Мы знали, что мы теряем людей в процессе установки, но не знали почему. Поначалу мы пытались решить проблему методом догадок, уменьшая размер установочного файла, предоставляя возможность он-лайн установки и т.д., что отняло у нас несколько недель, но не принесло желаемого результата. Тогда мы вынесли экран регистрации в самое начало и стали собирать адреса email до скачивания. Хотя это само по себе не было решением проблемы активации, это позволило нам выявить пользователей, столкнувшихся с проблемой, и связаться с ними. Некоторые из них ответили нам, что помогло нам быстро выявить несколько критических проблем, не обнаруженных ранее, и существенно влиявших на уровень активации.

Уменьшайте количество шагов, но не ценой обучения Аналогичный принцип приоритета обучения над оптимизацией также применим и к количеству промежуточных шагов в процессе активации. Хотя в целом важно сократить количество шагов, гораздо важнее сохранить критические шаги отдельными, чтобы понимать – на каком этапе люди покидают процесс при негативном сценарии (подробнее см. во врезке «Избегайте преждевременной оптимизации: Posterous [Платформа для блогов]»).

Избегайте преждевременной оптимизации: Posterous [Платформа для блогов] Когда мы говорим о необходимости разделения критических шагов, на память сразу приходит яркий пример этого – главная страница сервиса блогов Posterous, когда он только запустился. Вместо того, чтобы попросить вас зарегистрироваться, они просили вас отправить свой первый пост по электронной почте (см. рисунок 9-4). Хотя это и было инновационной идеей, фактически, они просили пользователя покинуть свою страницу, чтобы отправить email, что с точки зрения аналитики приравнивало активированного пользователя к незаинтересованному. В итоге, когда возникли проблемы, этот оптимизированный процесс не дал необходимой информации для быстрого их решения.

Рисунок 9‑4. Скриншот первой версии сайта Posterous

Дайте клиентам обещанное Правильный процесс активации должен приводить клиента к тому, что вы ему обещали в вашем УТП. Составляя карту процесса, убедитесь в том, что он приводит к УТП, желательно, в один присест. У вас будет только один шанс создать хорошее впечатление. Будьте готовы к тому, что всё пойдет не так Предоставьте клиентам возможность оперативно решать их проблемы с продуктом посредством разных каналов связи: электронная почта, бесплатный номер 8-800 и т.д.

Создайте маркетинговый сайт

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

Анатомия маркетингового сайта

Привлечение также образует суб-воронку внутри воронки продаж (см. рисунок 9-5).

Следуя принципу приоритета обучения над оптимизацией, я рекомендую начать с отдельной страницы для каждого шага. Каждая страница должна содержать первичный призыв к действию и вторичный призыв к действию. Мой первичный призыв к действию направляет посетителей на страницу оплаты (суб-цель процесса привлечения), а вторичный – отправляет посетителя на страницу с более подробной информацией (тур по продукту). Посадочная страница вашего сайта, пожалуй, будет самой сложной в создании. Её работа – заинтересовать неангажированного посетителя в вашем продукте всего за восемь секунд. Мы коротко разберем основные элементы посадочной страницы, но сначала пройдемся по некоторым другим страницам, которые вам, вероятно, также необходимо будет создать. Страница «О компании» Если задача посадочной страницы – убедить купить ваш продукт, то работа информационной страницы – убедить купить его именно в вашей компании. На этой странице вы должны воспользоваться шансом придать своему продукту соответствующее лицо, рассказать свою историю, наладить контакт с вашими потребителями. Страница «Условия использования и политика конфиденциальности» Эта информация обязательно должна быть у любого сайта, предлагающего услуги через Интернет. Страницы эти довольно стандартны и вы без труда найдете в сети массу шаблонов для их создания. Однако, размещение неадекватной информации на этих страницах может создать вам юридические проблемы, поэтому уделите им должное внимание или спросите совета у профессионалов. Тур по продукту (видео, скрин-шоты) Я обычно откладываю эту страницу «на потом» и начинаю просто с посадочной. Но если вы знаете, что ваши посетители склонны к аналитике и исследованиям, возможно, вам стоит добавить страничку с техническими спецификациями и другой подобной информацией. Это зависит от фундаментального понимания ваших потребителей и их мотивации.

Посадочная страница в деталях

Хотя задача быстро установить позитивный контакт с посетителем и кажется пугающей, есть ряд базовых элементов, которые делают посадочную страницу успешной. Они перечислены ниже и показаны на рисунке 9-6. Уникальное торговое предложение (УТП) Обязательно поместите на самое видное место ваше УТП. Это – самый важный элемент страницы. Вспомогательный графический материал Для усиления вашего УТП добавьте на страницу картинку, которая поможет посетителю проассоциировать себя с потреблением вашего продукта. Это может быть статичная картинка, скрин-шот или видео в зависимости от особенностей продукта и целевой аудитории. Явный призыв к действию Каждая страница должна содержать явный призыв к действию. Он должен четко считываться и давать ясное понимание того, что произойдет дальше. Приглашение узнать больше Некоторым из посетителей может потребоваться больше информации для того, чтобы проникнуться вашим предложением. Оставьте ссылку на страницу с туром по продукту (если она у вас есть) или ваш бесплатный номер телефона.

Рисунок 9‑6. Элементы посадочной страницы

Посадочная страница на рисунке вверху лишена одного критически важного элемента : Общественное признание Элементы общественного признания помогают поднять доверие. Обычно в этой роли выступают позитивные отзывы пользователей или логотипы известных организаций, использующих ваш продукт. Причина, по которой они отсутствуют на рисунке 9-6, очевидна – вы пока не располагаете ничем подобным и добавите эти элементы позднее, с помощью ваших ранних последователей.

Раздел 10: Приготовьтесь измерять

Вам необходимо не только иметь возможность визуализировать цикл жизни своего потребителя, но и быть способным измерить его.

Потребность в информативной метрике

Хотя до проверки продукта на соответствие Продукт/Рынок вы окружены сплошным полем загадок, касающихся в основном качественной проверки информации, для визуализации и измерения жизненного цикла вашего потребителя вам необходима информативная метрика. Ваша цель до достижения соответствия Продукт/Рынок – не столько повысить конверсию, сколько суметь быстро идентифицировать и устранить сбои в жизненном цикле потребителя. До текущего момента вы принимали решения, основываясь на том, что говорят вам клиенты. Настало время посмотреть, что они делают.

Что такое информативная метрика?

Информативная метрика – это метрика, которая позволяет связать конкретное и повторяемое действие с наблюдаемым результатом. Противоположностью информативной метрике является показная метрика (например, количество кликов или скачиваний), которая служит только для того, чтобы зафиксировать текущее состояние продукта, не давая при этом информации ни о том, как вы в нем оказались, ни о том, что делать дальше. Первый тревожный сигнал того, что вы используете показную метрику – это неуклонный рост показателя в течение времени. Иными словами, клики и скачивания – это элементы суб-воронок, которые составляют действительно значимые макро-процессы, такие как привлечение и активация. Важно не только ЧТО вы меряете, но и КАК вы это делаете. Понимание разницы между показной и информативной метрикой – это первый шаг. Для того, чтобы ваша метрика стала информативной, вам нужно сделать её доступной (через простые отчеты) и проверяемой (через возможность найти объяснение тем или иным показателям). Я рассмотрю эти процедуры немного глубже в последующих главах, а затем я расскажу как построить панель управления конверсией.

Метрика – это в первую очередь люди

Эрик Рийс популяризировал мем «Метрики – тоже люди», имея в виду проверяемость численных показателей, но мне кажется, этого недостаточно. Я сам являюсь ярым сторонником культуры метрик, но мне очевидно, что для построения отличного продукта нужно нечто большее, чем цифры. Для начала, вам нужно уметь увидеть за цифрами реальных людей. Идеальная панель управления конверсией – это наполовину аналитика, наполовину – система управления отношениями с потребителями (customer relation management, CRM). Вот почему: Метрика не объясняет сама себя. Когда вы запускаете новый продукт или характеристику, множество проблем может случиться и случается. Метрика может показать вам – где возникла проблема, но она не может сказать – почему. За объяснением вам необходимо обращаться к людям. Не ждите, что пользователи сами обратятся к вам. Когда клиент использует ваш продукт впервые, он еще ничего не вложил в него. Обычно, они проявляют интерес вначале, но интерес быстро угасает по мере того, как возникают проблемы. Иными словами, не стоит ждать, что клиент, обнаружив проблему, отправит вам информацию об ошибке или кинется звонить вам. Может быть, кто-то так и поступит, но абсолютное большинство просто удалит ваш продукт и забудет о нем. Тяжкая доля быстрого выявления проблем и выяснения подробностей у столкнувшихся с ними пользователей целиком на ваших плечах. Не все метрики одинаково полезны. До сих пор вы очень тщательно подходили к отбору участников для своих интервью. После запуска вы не сможете так же скрупулезно контролировать тех, кто пользуется вашим продуктом. Помимо желанной целевой аудитории, к вам могут зайти поисковые боты, просто любопытные, и даже представители пока неизвестных вам целевых сегментов. Просто глядя на цифры, вы видите усредненный результат, который может сильно отклоняться от истины, если у вас недостаточно трафика (или трафик имеет недостаточно высокое качество). Вам необходимо уметь сегментировать метрику на группы.

Простого анализа воронки продаж недостаточно

Воронка продаж – мощный инструмент аналитики. Его просто воспринимать и он великолепно подходит в качестве визуального элемента панели управления конверсии. Однако, большинство готовых решений, предлагаемых третьими сторонами, лучше подходят для анализа воронок микроуровня (как конверсия посадочной страницы), чем для воронок макроуровня (как жизненный цикл потребителя). Воронки микроуровня обычно описывают события короткого масштаба времени, измеряемые минутами, в то время как воронки макроуровня относятся к событиям, занимающим дни или месяцы. Простые аналитические отчеты по воронкам работают так: вы указываете период анализа, в течение которого подсчитываются и визуализируются искомые события. Этот подход не работает, если интервалы между событиями превышают период анализа. Эту проблему легко проиллюстрировать на примере загружаемого продукта с 14-дневным тестовым периодом. На рисунке 10-1 показан пример того, как может выглядеть типичный простой отчет по воронке продаж.

На рисунке 10-1 события «привлечение» и «активация» относятся к короткому периоду времени, а событие «оплата» — к длинному. Это вызывает следующие нестыковки: Подсчет уровня конверсии Цифра, показывающая количество продаж, вероятнее всего, включает продажи посетителям, реально активированным в мае, и не включает продажи, сместившиеся на июль, что дает неверный уровень конверсии. Влияние флуктуаций трафика Смещение цифр еще больше усугубляется в случае флуктуаций трафика. Если в июле количество подписок падает, вы увидите это с задержкой. Измерение реакции Другая проблема отчетов такого рода связана с тем, что ваш продукт постоянно изменяется. Из-за смещения подсчета событий трудно, если не невозможно, сопоставить наблюдаемый эффект с внесенным в продукт изменением. Сегментирование воронок Со временем вам скорее всего будет необходимо провести раздельный анализ и выделить определенную группу пользователей на фоне остальных. Простые отчеты не позволят вам сделать это.

Познакомьтесь с когортным анализом

Итак, хотя воронки и являются замечательным инструментом, их одних явно недостаточно для качественного анализа. Ключ к успеху – совмещение воронок с когортным анализом. Когортный анализ очень распространен в медицине, где он применяется для анализа долгосрочных последствий применения лекарств и вакцин: Когорта – это группа людей, имеющих общий признак или подвергшихся одному и тому же событию в течение одного периода времени (например, родились или принимали одно и то же лекарство или вакцину). Таким образом, группа людей, родившихся в один день или год, например, 1948, формируют когорту по времени рождения. В качестве группы сравнения может использоваться вся популяция, из которой извлечена когорта, либо это может быть другая когорта, состоящая из людей, предположительно не подвергшихся воздействию исследуемого вещества, а в остальном похожая. В качестве альтернативы, между собой могут сравниваться разные подгруппы одной когорты.[1] Мы можем применить эту концепцию и выделить когорту или группу посетителей и отслеживать их жизненный цикл. Применительно к нашим целям, в качестве группирующего признака когорты может выступать любой атрибут пользователя. Наиболее распространенным является «дата присоединения», но, как мы убедимся в будущем, в этом качестве можно будет с таким же успехом использовать «тип плана подписки», «операционную систему», «пол» и т.д. [1] Английский текст цитируется по http://en.wikipedia.org/wiki/Cohort_study Давайте посмотрим, как применение когортного анализа (по дате присоединения), приведенное на рисунке 10-3, позволяет компенсировать недостатки простого анализа воронки, рассмотренного выше и приведенного еще раз для сравнения на рисунке 10-2.

Рисунок 10‑3. Недельные когорты (по дате присоединения)

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

Как построить панель управления конверсии

На рынке существует множество сторонних приложений, посвященных этому. Я приобретал свой опыт на изучении Google Analytics, KISSmetrics и Mixpanel. У каждого из них есть свои сильные и слабые стороны, но, к сожалению, я (пока) не нашел единого аналитического инструмента, который удовлетворял бы всем требованиям, описанным выше.[1] Чем погружаться в специфику каждого инструмента с риском утонуть, я лучше расскажу о том, как построил свою панель управления конверсии исходя из функциональной перспективы. Эту информацию вы найдете в Приложении.

Раздел 11: Интервью по МАП

Прежде, чем продавать свой минимальный актуальный продукт абсолютно новым людям через свой канал дистрибуции (например, маркетинговый сайт), попробуйте продать его один на один благожелательно настроенным ранним последователям. Получите от них необходимую информацию. Затем внесите необходимые изменения в дизайн, позиционирование и ценообразование и готовьтесь к полноценному запуску. [1] USERcycle – моя попытка решить эту проблему

Что вам необходимо узнать

Имея на руках готовый МАП, маркетинговый сайт и панель управления конверсии, вы готовы нанести вашим ранним последователям очередной визит. Ваша цель – подписать их на пользование вашим сервисом и, в процессе общения, протестировать вашу коммуникацию, цену на продукт и процесс активации. Если вам не удастся конвертировать подготовленного последователя в течение 20-минутного интервью, вас, скорее всего, ожидают проблемы с конвертированием незаинтересованного пользователя в течение 8 секунд, которые он проведет на посадочной странице вашего сайта. В процессе интервью по МАП вам необходимо найти ответы на следующие вопросы: Продуктовый риск: чем замечателен продукт? (УТП – уникальное торговое предложение) Привлекает ли внимание ваша посадочная страница? Проходит ли пользователь весь необходимый путь процесса активации? Есть ли проблемы с использованием сайта? Даёт ли ваш продукт то, что обещало УТП? Потребительский риск: достаточно ли у вас клиентов? (Каналы) Можете ли вы привлечь новых клиентов, используя существующие каналы? Рыночный риск: Правильна ли цена? (Доходы) Готовы ли клиенты платить за ваше решение?