Большинство начинающих разработчиков имеют роадмеп, полный фич, которые они хотят создать. Это кажется продуктивным: вы выпскаете, вы продвигаетесь вперед.
И хотя я предпочитаю быструю поставку совершенству, когда эта скорость сосредоточена исключительно на функциях, это может быть опасно — особенно когда вы начинаете планировать на несколько месяцев вперед. Вы предполагаете, что знаете, что нужно пользователям, прежде чем это проверить, и вы также берете на себя обязательства по функциям и улучшениям в сфере, которая все еще очень нестабильна.
Тогда план превращается в список дел, составленный на основе предположений; результаты, а не итоги. Вы выпускаете функции с большим энтузиазмом, но не обязательно узнаете, действительно ли они важны. Или, по крайней мере, обучение происходит гораздо медленнее, чем должно.
Я видела, как новые приложения с подпиской тратили месяцы на создание функций, которыми никто на самом деле не пользуется, потому что они никогда не останавливались, чтобы спросить себя: чему нам нужно научиться прямо сейчас?
Для начинающих приложений планы не должны быть сосредоточены на том, что нужно создавать, поскольку вы все равно не можете надежно прогнозировать более чем на квартал вперед.
Вместо этого, они должны быть о том, чему нужно учиться.
Именно на этом мы и сосредоточимся: на построении дорожной карты обучения.
Дорожная карта обучения — это структурированный план, построенный вокруг вопросов и гипотез, а не функций, — предназначенный для проверки предположений перед принятием решения о разработке.
Сосредоточьтесь на проверке, а не на выпуске функций
Существует разница между подходом, ориентированным на выпуск функций, и подходом, ориентированным на проверку.
- Подход, ориентированный на выпуск функций: Какие функции мы можем выпустить в этом квартале?
- Подход, ориентированный на проверку: На какой самый важный вопрос нам нужно ответить прямо сейчас?
На этапе до достижения соответствия продукта рынку (Product-Market Fit) вы не пытаетесь создать полноценное приложение, которое делает всё. Вместо этого вы пытаетесь понять, создаёте ли вы правильный продукт.
Цель состоит в том, чтобы узнать, что действительно важно для ваших первых пользователей и что побуждает их платить.
Прелесть перехода к подходу, ориентированному на проверку, заключается в том, что для получения информации часто не требуется создание полноценной фичи. Вы сосредотачиваетесь на самом маленьком возможном тесте, который позволяет вам понять.
Как Robinhood проводил проверку перед запуском.
Перед созданием своего торгового приложения Robinhood запустил целевую страницу со списком ожидания. Предложение было простым: «Торговля без комиссий». Главная цель заключалась в простой регистрации с электронной почтой, а также в создании реферальной программы, которая побуждала людей продвигаться вверх по списку, делясь информацией.
В результате, еще до появления приложения, было зарегистрировано более 1 миллиона пользователей.
Но регистрация сама по себе не была тем показателем, на котором они сосредоточились. Они отслеживали несколько поведенческих аспектов, чтобы понять качество этой ранней аудитории:
- Реферальное поведение: делились ли люди сами, без напоминаний? (Да, вирусный коэффициент был высоким)
- Вовлечённость в email-рассылку: открывали ли пользователи из списка ожидания обновления и спрашивали ли о сроках запуска?
- Готовность действовать: когда ранний доступ предлагали лучшим реферерам, предпринимали ли люди реальные усилия, чтобы его получить?
Когда вы в конечном итоге создаете функцию, это обычно должно происходить потому, что что-то было проверено, и даже тогда вы создаете это, чтобы ответить на вопрос, а не просто добавить еще один элемент к продукту.
Как выглядит дорожная карта обучения?
Дорожная карта обучения строится вокруг вопросов, а не функций.
Для каждого вопроса вы должны четко понимать, каким, по вашему мнению, может быть ответ, как вы будете его тестировать и что покажет, правы вы или нет.
Структура выглядит следующим образом:
Стратегическая цель → Вопрос → Гипотеза → Проверка → Критерии успеха → Следующий шаг.
Важно, чтобы каждый вопрос, на который вы пытаетесь ответить, был напрямую связан с более широкой стратегической целью.
Это заставляет вас конкретизировать то, что вы пытаетесь узнать, вместо того, чтобы просто поставлять фичи и надеяться на лучшее.
Например, представьте, что вы не уверены, понимают ли пользователи ценность приложения до того, как столкнутся с пейволом.
- Стратегическая цель: улучшить коэффициент конверсии download-to-trial-started.
- Вопрос: понимают ли пользователи ценность приложения до того, как столкнутся с платным доступом?
- Гипотеза: пользователи лучше поймут ценность приложения, если мы покажем больше визуализаций того, как выглядит приложение, напрямую связанных с измеряемыми преимуществами.
- Тест: добавьте скриншот приложения в раздел преимуществ вместо иллюстраций.
- Критерии успеха: значительное увеличение коэффициента конверсии на первом пейволе.
- Следующий шаг: если подтвердится, изучите другие способы более убедительно донести ценность. Если опровергнется, протестируйте альтернативы; например, добавьте короткое видео перед началом использования, демонстрирующее результаты, которых могут достичь пользователи.
Каждый вопрос, на который вы пытаетесь ответить, по сути, является возможностью создать ценность для ваших пользователей.
Ключевой вывод, почерпнутый из работы Терезы Торрес о непрерывном исследовании, заключается в том, чтобы рассматривать возможности так, как их описали бы ваши клиенты, а не на языке внутренних продуктов.
Например, вы можете переформулировать вопрос с точки зрения пользователя: «Я не понимаю, что делает это приложение, прежде чем мне нужно будет заплатить».
Подобная клиентоориентированная формулировка помогает вам рассмотреть несколько возможных решений, и поэтому важно не спешить с первой же идеи для тестирования.
Если тест, например, «добавление скриншота вместо иллюстраций», не проходит, это не обязательно означает, что на основной вопрос дан ответ. Возможно, вам потребуется изучить несколько разных способов проверки одной и той же гипотезы, прежде чем прийти к ясности.
Мой подход заключается в том, чтобы сначала отметить несколько моментов:
- Например, количественные данные, лежащие в основе вопроса или гипотезы, показывают очень низкий процент начала триала, в то время как процент завершения онбординга уже высок.
- Качественные данные, которые помогают нам лучше понять поведение пользователей, например, в ходе пользовательского тестирования мы заметили, что люди, которые ушли с пейвола, все еще пытались понять, что на самом деле делает приложение.
- Согласно SOSA 2026, 55% всех отмен 3-дневных пробных периодов происходит в нулевой день — поэтому вопрос о том, понимают ли пользователи ценность вашего приложения до появления пейвола, является одним из наиболее важных предположений, которые необходимо проверить на раннем этапе.
Исходя из этого я разрабатываю несколько возможных вариантов тестирования. В исходном примере вы также можете попробовать:
- Добавить короткое видео в онбординг, демонстрирующее работу приложения;
- Протестировать карусель функций в начале;
- Показать упрощенный обзор «что вы можете делать в приложении» во время онбординга.
Затем вы можете вернуться к исходному вопросу и оценить, какой подход с наибольшей вероятностью поможет вам прояснить ситуацию, учитывая собранные данные.
Три направления: Сейчас, Далее, Позже
Если вы задаетесь вопросом, что вам следует создавать через 2-3 месяца, не волнуйтесь, вам это знать не нужно.
Я всегда говорила, что квартал в стартапе может ощущаться как год в корпорации. Честно говоря, месяц в стартапе на ранней стадии может ощущаться как квартал в стартапе на более поздней стадии. Все происходит быстро, и слава богу, есть дорогая косметика и светлые волосы, которые помогают скрыть седые волосы, в появлении которых, я уверена, виноваты стартапы.
Хотя ваше видение и стратегия должны быть долгосрочными, ваша дорожная карта может оставаться краткосрочной. Попытки планировать что-то на более длительный срок обычно приводят к бесконечным переделкам.
Мне нравится структурировать дорожную карту обучения по трем временным горизонтам: Сейчас, Далее и Позже; эта концепция, популяризированная Джанной Бастоу, позволяет вам не делать все сразу.
Ваши временные рамки могут выглядеть так:
- Сейчас (1–2 недели): Самый важный вопрос, на который вам нужно ответить прямо сейчас. Всего один вопрос. Максимальная концентрация.
- Далее (2–4 недели): Вопросы, которые, вероятно, возникнут в будущем, в зависимости от того, что вы узнаете из текущих тестов. Это предварительные, а не окончательно решенные вопросы — например: «Если это произойдет, то мы сделаем X», основываясь на сигналах, которые вы видите.
- Позже (бэклог): Идеи и вопросы, которые вы хотите изучить в будущем, но пока не планируете. Они могут и будут меняться по мере того, как вы будете узнавать новое.
Такой подход позволяет вам оставаться сосредоточенным, при этом сохраняя идеи, не отвлекаясь.
Если вы похожи на меня, вы, вероятно, генерируете миллион идей на ранней стадии. Хотя долгосрочное планирование сложно, генерация идей обычно не представляет сложности, поэтому наличие бэклога помогает вам отложить идеи и вернуться к ним позже.
Честно говоря, многие идеи не переживут этот процесс (у меня столько стикеров с идеями для статей, что спустя несколько дней я начинаю сомневаться, о чём я вообще думала). Поэтому возьмите за правило регулярно наводить порядок в накопившихся идеях.
Как расставить приоритеты в изучении
Вы не можете протестировать всё сразу, все идеи и вопросы, которые вы хотите исследовать, необходимо безжалостно расставить по приоритетам.
Здесь вступают в игру предположения. Начните с проверки предположений, которые подорвут вашу стратегию, если окажутся неверными.
Обычно я думаю о трёх типах предположений:
- Предположения о проблеме. Действительно ли у пользователей есть эта проблема, и достаточно ли им это важно, чтобы изменить своё поведение?
- Предположения о ценности. Действительно ли наше решение помогает так, как это понимают пользователи?
- Предположения о готовности платить. Заплатит ли достаточное количество пользователей достаточно высокую цену, чтобы продукт был устойчивым?
Это очень упрощённо, но, будучи новым приложением по подписке, вы, по сути, пытаетесь ответить на эти вопросы до достижения соответствия продукта рынку:
- Достаточно ли сильна у пользователей эта проблема, чтобы они изменили своё поведение?
- Понимают ли они ценность до того, как столкнутся с пейволом?
- Готовы ли они платить эту цену?
- Что заставляет их возвращаться после первого дня?
- Какое ключевое действие предсказывает удержание пользователей?
Я предлагаю проводить тестирование именно в таком порядке. Если проблема не реальна, нет смысла тестировать предположения о ценности. Если решение не работает, нет смысла тестировать ценообразование.
Затем сгруппируйте связанные вопросы; вы часто обнаружите, что многие из них взаимосвязаны. Например, возвращаясь к сценарию с пейволом, вопрос «понимание ценности до введения платного доступа» может быть разбит на подвопросы, такие как:
- Видят ли они, как выглядит приложение?
- Понимают ли они результаты, которых могут достичь?
- Знают ли они, сколько времени потребуется, чтобы увидеть результаты?
Такая группировка вопросов помогает определить основной вопрос, которому следует отдать приоритет, а также показывает, на какие подвопросы, вероятно, будут даны ответы вместе.
Например, если вы разрабатываете приложение для сна и не уверены, испытывает ли ваша аудитория больше трудности с засыпанием или с поддержанием сна, это предположение можно проверить с помощью исследования пользователей.
Меньшие тесты, более быстрое обучение
Надеюсь, теперь вы убедились, что для обучения не обязательно создавать полноценную функцию — и что, как следствие, традиционная дорожная карта функций несколько ограничена. Цель состоит в том, чтобы проверять предположения с наименьшими усилиями.
Вы уже видели, как подход с использованием списка ожидания сработал для Robinhood, но есть и много других вариантов:
- Прототипы. Создавать прототипы с помощью ИИ-инструментов , таких как Lovable, стало проще, чем когда-либо.
- Тесты «нарисованной двери» (painted door tests). По сути, вы «притворяетесь, пока не сделаете» — в буквальном смысле. Можно, например, показать кнопку функции, которая на самом деле ещё не работает.
- Ручные версии функций. Если вы в конечном итоге хотите автоматизировать что-то, начните с тестирования человеческой версии. Например, вы можете захотеть создать автоматизированный анализ кожи и рекомендации, но сначала протестировать возможность ручного предоставления советов.
- Начните только с первой части. Например, если вы создаете систему обратной связи с сообществом, вы можете начать с проверки использования простого действия «лайк», даже если последующая функциональность еще не разработана. В одном случае действие «лайк» даже не вызвало никакой видимой реакции вначале, но это помогло подтвердить, что пользователи готовы взаимодействовать с таким поведением.
Если вы хотите еще более упростить задачу, вы можете начать с исследования, например, просмотра форумов для проверки проблемной области или проведения пользовательских интервью, прежде чем создавать какие-либо макеты. Для стартапов на ранней стадии пользовательские исследования почти всегда являются хорошей инвестицией времени.
Что происходит, когда вы учитесь
Каждый тест приведет к одному из трех результатов:
- Уверенность повышается
- Уверенность снижается
- Результат неубедителен
Честно говоря, последний вариант не очень хорош, но я думаю, что он все равно может чему-то вас научить. Это даст вам ясность относительно дальнейших действий:
- Если уверенность повышается, решите, нужна ли вам дополнительная проверка, есть ли еще что-то, что нужно узнать, или можно перейти к следующему вопросу.
- Если уверенность падает, решите, нужна ли вам дополнительная проверка, есть ли еще что-то, что нужно узнать, или можно перейти к следующему вопросу.
- Если результат неубедителен, это может означать несколько вещей: возможно, изменение не оказало ожидаемого эффекта, не хватило данных, или сам тест не был правильным способом ответить на вопрос. Затем вы можете определить наилучший следующий шаг, исходя из причины.
Цель не в том, чтобы быть правым. На ранних этапах работы вы будете довольно часто ошибаться, и это совершенно нормально.
Настоящая цель — учиться достаточно быстро, чтобы ошибки не стали дорогостоящими.
Как понять, что вы продвигаетесь вперед
Дорожная карта обучения иногда может казаться медленнее, потому что вы не выпускаете видимые функции. Именно здесь доверие может начать колебаться, как у основателей, так и у команд.
Прогресс просто выглядит по-другому, и частью принятия позитивного мышления является переосмысление того, что означает прогресс.
Прогресс можно увидеть несколькими способами:
- Вы можете сформулировать то, что теперь знаете, чего не знали раньше;
- Вы исключили неработающие решения (отрицательные результаты — это прогресс);
- Ваши вопросы становятся более конкретными и сфокусированными;
- Вы сходитесь к меньшему набору перспективных возможностей;
- Ваши критерии успеха становятся более измеримыми с течением времени;
Регулярное обсуждение на спринтовых совещаниях того, что вы узнали и поняли, а также небольших побед, помогает лучше видеть прогресс, который может еще не отражаться на ваших дашбордах.
Распространенные ловушки при планировании дорожной карты
В стартапах, с которыми я работала, одни и те же ошибки при планировании дорожной карты повторяются. Они редко связаны с усилиями или намерениями — они связаны с тем, как принимаются решения.
1. Разработка до проверки
Это часто проявляется в завуалированной форме.
Иногда команды говорят, что не следуют роадмепу, но конкретная функция или обновление внезапно начинают казаться неизбежными. Все убеждаются в их важности. Когда вы спрашиваете, на чем основана эта вера, ответ обычно звучит примерно так: «мы просто знаем» или «мы должны это сделать».
Это все еще разработка до проверки.
Уверенность — это не то же самое, что доказательства. Даже сильная интуиция должна быть подкреплена исследованиями, данными или реальными пользовательскими сигналами. Чем больше вас вдохновляет идея, тем дисциплинированнее вам нужно ее проверять.
2. Слишком много приоритетов
Если все является приоритетом, то ничто не является приоритетом.
Стратегия — это не десять параллельных проектов; это четкое обязательство сосредоточиться на одной или двух важных вещах прямо сейчас. Ваша дорожная карта должна отражать эту направленность.
Будьте безжалостны в отношении своего «сейчас». Если вы пытаетесь ответить на несколько важных вопросов одновременно, вы, скорее всего, добьетесь поверхностного прогресса по всем из них и ни по одному значимому.
3. Расплывчатые критерии успеха
«Посмотрим, понравится ли это пользователям» — это не критерий успеха.
«Немного лучше» — тоже не критерий.
На ранних этапах статистическая значимость не всегда возможна, и это нормально. Важно четко определить, что означает успех, прежде чем начать.
Спросите себя:
- Какой сигнал придаст вам уверенности, чтобы продолжить?
- Какой результат четко подскажет вам остановиться?
Также заранее продумайте второстепенные показатели. Например:
- Если основной показатель не улучшится, но улучшится другой, что вы будете делать?
- Если основной показатель улучшится, но что-то другое ухудшится, приемлемо ли это?
Планирование этих сценариев на ранних этапах предотвращает множество оправданий задним числом.
4. Игнорирование отрицательных результатов
Заманчиво объяснять данные, которые не подтверждают ваши убеждения. Как однажды сказал один спикер: «Если достаточно долго мучить данные, они всегда признаются». Эта мысль запала мне в душу, потому что она болезненно правдива.
Почти всегда найдется способ представить результаты как «не такие уж плохие» или выборочно использовать подтверждающие данные. Четкие критерии успеха помогают защититься от этого, но важен и образ мышления.
Отрицательные результаты — это не повод для стыда. Большинство вещей не сработают; это совершенно нормально. Воспринимайте неудачные эксперименты как обучение, а не как повод для оправданий. Именно это и двигает команды вперед.
5. Никогда не двигаться дальше
Последняя ловушка — это застревание в режиме тестирования.
Тестирование может казаться безопасным, потому что всегда есть еще один вариант, который можно попробовать, или еще одна неделя сбора данных. Но в какой-то момент вам нужен достаточный сигнал, чтобы принять решение и двигаться дальше.
Дорожные карты — это не бесконечная проверка, а укрепление уверенности и последующее принятие решения.
Будьте честны с собой: изменит ли дальнейшее тестирование ваше решение, или это просто способ избежать его принятия?
Признаки того, что вы готовы двигаться дальше:
- Вы протестировали в 2–3 группах, и закономерность сохраняется
- Сигнал достаточно сильный, чтобы оправдать выделение ресурсов (а не просто «слегка положительный»)
- Дальнейшее тестирование вряд ли изменит ваше решение
- Вы откладываете принятие решения, вместо того чтобы действительно учиться
Используйте этот список распространенных ошибок, чтобы контролировать себя; вы даже можете использовать его в рамках ретроспективы спринта. Проанализируйте следующие вопросы всей командой:
- Были ли случаи, когда мы разрабатывали продукт до проверки?
- Каковы наши главные приоритеты? Нужно ли их сузить?
- Достаточно ли ясны критерии успеха всех экспериментов?
- Какие «негативные» результаты были получены в этом спринте? Чему мы из них научились?
- Не пора ли переходить к другим приоритетным направлениям?
Продолжать в том же духе, совершенствовать или менять курс?
В концепции «бережливого стартапа» Эрика Риса рекомендуется проводить регулярные (часто ежемесячные) встречи, чтобы решить, менять ли курс или продолжать двигаться вперед, по сути, менять направление или оставаться на прежнем курсе.
Я согласна с методологией, но бинарная формулировка может показаться слишком черно-белой. Решение обычно не так просто, как либо отказаться от идеи, либо продолжать без изменений. Иногда что-то работает частично, и давление выбора между изменением курса и продолжением может подтолкнуть команды к продолжению, потому что изменение курса кажется более пугающим. Именно здесь начинает проявляться ошибка невозвратных затрат; вы вложили так много, что трудно отступить.
Вместо этого я предпочитаю рассматривать это в трех вариантах:
- Продолжать в том же духе (продолжать). Когда основная гипотеза подтверждается, сосредоточьтесь на выполнении и итерациях.
- Совершенствовать. Направление в целом правильное, но некоторые детали неверны. Речь идет не о мелкой оптимизации; Речь идёт о внесении значимых корректировок, таких как изменение целевой аудитории, уточнение позиционирования или изменение функций.
- Пивот (или закрытие). Основная гипотеза опровергнута, а это значит, что вам нужно коренным образом переосмыслить проблему, пользователя или решение.
Большинству запусков не нужен пивот — им нужна доработка. Настоящий пивот имеет смысл только тогда, когда факты прямо противоречат вашему базовому предположению о проблеме или пользователе — например, когда целевая аудитория не видит ценности или отсутствуют значимые сигналы монетизации.
Известный пример крупного пивота — это Instagram*. Первоначально запущенный как Burbn, продукт начинался как приложение для отметок местоположения со множеством функций.
После запуска данные показали, что:
- Большинство функций игнорировались
- Обмен фотографиями показал необычайно высокую вовлеченность
Основатели убрали всё, кроме фотографий, потому что поняли, что их основная гипотеза была неверной: пользователи искали не столько приложение для отметок местоположения, сколько более широкий набор функций. Вместо этого они сосредоточились на сигнале с самым сильным вовлечением пользователей и повернулись вокруг него.
Когда можно отказаться от дорожной карты обучения?
Дорожная карта обучения не предназначена для того, чтобы существовать вечно.
В какой-то момент она может начать терять свою полезность. Вместо того чтобы обеспечивать ясность и направление, она может начать восприниматься как длинный список нерешенных вопросов. По мере роста команд и количества инициатив чистая дорожная карта обучения иногда может создавать больше шума, чем фокуса.
Обычно это признак того, что вы приближаетесь к соответствию продукта рынку.
По мере роста уверенности баланс естественным образом смещается. После достижения соответствия продукта рынку у вас, как правило, появляется более четкое понимание того, кто ваши пользователи, чего они хотят и какие проблемы действительно важны. На этом этапе более традиционная, ориентированная на функции дорожная карта (хотя и по-прежнему сфокусированная на результатах) часто становится более практичной.
Это не означает, что обучение прекращается.
Рынки развиваются. Поведение пользователей меняется. Конкуренты улучшаются. Разница в том, что акцент смещается с преимущественно обучения с элементами построения на преимущественно построение с элементами обучения.
Вы больше не подвергаете сомнению всё подряд, но при этом оставляете место для проверки ключевых предположений и, при необходимости, для оспаривания стратегического направления.
В этом смысле дорожная карта обучения помогает вам достичь точки, где дорожная карта функций действительно начинает работать.
Построение дорожных карт на основе вопросов, а не результатов
Поэтому помните, что на ранних этапах развития приложений с подпиской сильные дорожные карты строятся на основе вопросов, а не функций, не точек постепенного улучшения и уж точно не роста ради роста.
Хорошо работает простая структура:
- Что мы делаем сейчас?
- Что мы будем делать дальше?
- Что будет позже?
Ваш бэклог должен быть отнесен к категории «позже».
Настоящая работа заключается в безжалостном выявлении предположений, которые могут подорвать вашу идею, если окажутся неверными, и в определении приоритетов именно для них.
Начните с небольшого тестирования и двигайтесь быстро. Только после этого следует расширять и строить с большей уверенностью.
Такой подход иногда может казаться медленнее, потому что вы выпускаете меньше продуктов. На практике же он обычно быстрее. Команды, которые по умолчанию занимаются постоянной разработкой, часто тратят месяцы на внедрение функций, которые на самом деле никому не нужны. Начало работы с обучения помогает избежать пустой траты времени на разработку чего-либо просто ради разработки.
