Менял ли дорожную карту

Как я менял дорожную карту: примеры, уроки, процесс

Главный принцип

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

Цитирую Jeff Bezos: "День, когда вы меняете план, — день, когда вы учитесь."

Реальный пример: стартап EdTech

Исходная дорожная карта (Q1-Q2)

План был:

1. Q1: Запустить основной продукт (LMS для школ)
2. Q2: Интегрировать с Google Classroom
3. Q3: Расширить на 10 школ
4. Q4: Привлечь Series A

Почему я это планировал:

• Интервью с 5 директорами школ показали спрос
• Tech stack был готов
• Был фокус: "education is broken, let's fix it"

Реальность (3 месяца спустя)

Q1 был сложнее, чем я думал:

• Вместо 1 месяца на запуск ушло 2 месяца (сложнее, чем казалось)
• Запустили только для 2 школ вместо запланированных 5
• Google интеграция показалась ненужной (школы используют свои системы)

Что я узнал (новые данные):

• Директоры говорили, что хотят LMS, но реально хотели "упростить общение с родителями"
• Главная боль была не в обучении, а в администрировании
• Конкуренция была больше, чем я думал (Google Classroom был популярен)
• Цена за аккуас была выше ($5k за школу вместо планируемых $2k)

Решение: я переписал дорожную карту

Новый план (новая Q2-Q4):

1. Q2: Вместо Google интеграции — fokus на фичи для parent communication (остановили Q2 инициативу)
2. Q2-Q3: Запустить в 5 школах (сохранить план по кол-ву, но переместить по времени)
3. Q3: На основе feedback — вырезать 30% фич LMS, добавить функцию родительского портала
4. Q4: Расширить на 20 школ (более амбициозный growth target)

Вот что я изменил:

• Убрал фичу (Google интеграция)
• Добавил фичу (parent portal)
• Переместил сроки
• Переоценил рыночный спрос

Результат

Новая дорожная карта была правильнее:

• Запустили в 5 школах (вместо плана 2) через 6 месяцев
• Parent communication features дали более высокую retention (90% вместо 60%)
• CAC снизилась на 30% (потому что parent portal создавал word-of-mouth)

Пример 2: B2B SaaS платформа

Исходный план

Фокус на enterprise клиентов:

• Q1: Выбрали 3 enterprise clients (телеком, финансы, логистика)
• Изучали их требования
• Стали расширять продукт под их niche needs

Проблема

• Разработка для каждого enterprise заняла месяцы
• Обещали запустить фичу для Enterprise A в Q1 → запустили в Q2
• Enterprise B ушёл из-за задержек
• Затраты на R&D выросли в 3 раза

Перелом

Мой CEO провел встречу. Вопрос был жесткий: "Мы хотим быть лучше для всех или хорошо для немногих?"

Я переписал план:

Новая стратегия (pivot to SMB):

• Вместо enterprise → fokus на SMB (100-500 employees)
• Вместо custom features → выстроить product-led growth
• Запустили freemium версию
• Добавили self-serve onboarding

Результат

• SMB клиенты были легче привлекать (не нужна sales team)
• Churn был ниже (потому что они не требовали custom features)
• Growth был faster (вирусный эффект от freemium)
• За 6 месяцев мы выросли с 50 SMB клиентов до 500

Как я формально меняю дорожную карту

Процесс

Step 1: Data collection (когда я понимаю, что что-то не правильно)

Краски флагов:

• Планировал запустить фичу в Q2 → запускаю в Q3
• Целевая аудитория не конвертится как ожидалось
• Конкурент запустил что-то, что меняет рынок
• Feedback от клиентов drastically другой, чем ожидал
• Retention не растёт, несмотря на планы

Step 2: Анализ причин (root cause analysis)

Я копаю глубже:

• Это проблема с выполнением (мы медленнее, чем ожидали)?
• Или это проблема с гипотезой (рынок не тот, что мы думали)?

Это критично, потому что решения разные:

• Если проблема в выполнении → нужна лучшая мотивация, ресурсы, или более простые фичи
• Если проблема в гипотезе → нужно менять стратегию

Step 3: Options and recommendations

Я выношу 2-3 варианта перед team и CEO:

Вариант A: Продолжить текущий план (но с коррекциями сроков)

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

Вариант B: Pivot (полная смена стратегии)

• Плюсы: align с реальным спросом, faster growth
• Минусы: разбиваем текущие планы, могут быть sunk costs

Вариант C: Modular approach (делаем оба)

• Плюсы: миним. risk, тестируем обе гипотезы
• Минусы: разобщённость, slow progress

Step 4: Decision and communication

Мы выбираем вариант. Важно:

• Объяснить ПОЧЕМУ (какие данные з showed это нужно)
• Что это значит для каждого человека (меняются ли их задачи?)
• Когда будет следующий пересмотр (дорожная карта меняется каждый квартал)

Step 5: Execution and monitoring

Новая дорожная карта переводится в спринты. Я отслеживаю метрики, которые подтверждают/опровергают новую гипотезу.

Если за 2 недели я вижу, что новый план тоже не работает → я снова пересматриваю.

Метрики, которые триггерят пересмотр дорожной карты

Я каждый понедельник смотрю на эти метрики:

Product метрики:

• Velocity (скорость разработки) — если упала на 20%+, пересматриваю
• Feature adoption — если новая фича использует < 5% пользователей, переосмысляю её ценность
• Retention/Churn — если выросла на 2-3 процентных пункта, что-то не так

Market метрики:

• CAC по каналам — если выросла, может быть, рынок перенасыщен
• Competitive activity — если конкурент запустил что-то похожее, нужно pivot
• Press/социальные медиа mentions — тренд направления

Business метрики:

• MRR growth rate — если упала ниже плана, нужна перестройка
• Headcount vs. spend — если растут расходы, но не растёт выручка

Процент изменения, который триггерит review:

• 15%+ дельта → обсуждаем, может ли это ждать до квартального review
• 25%+ дельта → немедленный pivot
• 50%+ дельта → emergency meeting, переписываем план

Типичные ошибки (чему я научился на своих ошибках)

Ошибка 1: Слишком долго придерживаюсь неработающего плана

Было: Я планировал запустить фичу X. Три месяца спустя вижу, что спроса на неё нет. Но я думаю: "Может, людям просто нужно больше времени привыкнуть, дайте ещё месяц." Проходит ещё месяц. Ничего не меняется.

Сейчас: Я даю плану максимум 2 недели на валидацию. Если за 2 недели нет признаков того, что это работает, я меняю.

Правило: "Fail fast, learn faster."

Ошибка 2: Не слушаю gut feeling

Было: Я запланировал, что целевая аудитория — enterprise. Но когда я встречался с founders, мой gut говорил, что они испугались complexity. Но я игнорировал и продолжал в enterprise.

Сейчас: Я слушаю gut, но требую данные. "Gut говорит, что не так, давайте прямо сейчас возьмём интервью у 5 клиентов и узнаем." Это быстрое валидирование.

Ошибка 3: Менять План слишком часто (flip-flopping)

Было: Каждый неделю я менял приоритеты на основе последнего feedback. Команда была запутана: в понедельник делаем X, в среду Y, в пятницу Z.

Сейчас: Дорожная карта меняется ежемесячно (не ежеминутно). Я собираю всё feedback за месяц, затем один раз переписываю в конце месяца. Это дёшево предсказуемость.

Шаблон: как я документирую изменение дорожной кары

Дата изменения: [date]
Разумные причины:
- Что случилось
- Какие данные это показали

Что меняется:
- Была: Фича X в Q2
- Стала: Фича X отложена на Q4, добавлена Фича Y в Q2

Почему:
- X имеет спрос ниже, чем ожидалась
- Y имеет спрос выше (интервью с 10 клиентами показали)

Риск:
- Клиент, который ждал X, может быть разочарован
- План на Q4 может стать перегруженным

Митигирование:
- Позвоним клиентам, рассказать про Y
- Пересмотрим Q4 в конце Q3

Метрики для валидирования нового плана:
- Feature Y должна привести к 10% увеличению retention
- Клиент satisfaction должна остаться > 8/10

Выводы

Дорожная карта меняется потому, что:

1. Рынок меняется
2. Я учу больше о клиентах
3. Конкуренты реагируют
4. Мои гипотезы оказываются неправильными

Это нормально и даже ожидаемо. Лучший PM — это не тот, кто идеально план, а тот, кто быстро адаптируется.

Мой процесс:

• Собрать данные о том, что не работает
• Провести root cause analysis
• Выдвинуть 2-3 варианта
• Решить с CEO и team
• Коммуницировать ясно
• Отслеживать метрики новых планов
• Repeat каждый месяц

И самое главное: я документирую ПОЧЕМУ мы меняем план, а не просто меняю. Это помогает команде понять reasoning и доверять процессу.