Продуктовая стратегия и роадмап

В статье про приоритизацию мы научились сравнивать задачи между собой: RICE, ICE, WSJF. Но у любой формулы приоритизации есть слепое пятно: она ранжирует только то, что уже попало в список. Если в бэклоге лежат сорок способов улучшить онбординг, RICE честно выберет лучший из сорока — и не скажет, что настоящее узкое место находится в удержании на третьем месяце, а онбординг трогать вообще не стоило.

Стратегия — это механизм, отвечающий на вопрос «из какого множества мы вообще выбираем». Роадмап — то, как выбранное коммуницируется наружу без вранья о сроках. Обе вещи в индустрии массово выродились в ритуал: «стратегия» стала слайдом с амбициями, роадмап — диаграммой Ганта с датами, в которые никто не верит. Разберём, как выглядят рабочие версии.

1. Что такое стратегия на самом деле

1.1. Определение через отрицание

Ричард Румельт в «Good Strategy / Bad Strategy» (2011) даёт самый строгий из существующих критериев. Плохая стратегия узнаётся по четырём признакам (разбор автора в McKinsey Quarterly):

1. Пух (fluff) — абстракции, которые звучат умно и ничего не запрещают: «стать клиентоцентричной платформой мирового класса».
2. Неспособность назвать проблему. Если в документе нет предложения «наша главная трудность в том, что…», стратегии нет — есть настроение.
3. Цели вместо стратегии. «Вырасти в 3 раза за год» — желание. Стратегия — это как именно и за счёт чего при ограниченных ресурсах.
4. Плохие стратегические цели — не связанные друг с другом, не приоритизированные, невыполнимые одновременно.

Отсюда рабочий тест: возьмите вашу стратегию и спросите — что она запрещает? Если из неё нельзя вывести «поэтому мы НЕ будем делать X, хотя X полезен» — это не стратегия. Стратегия всегда болезненна, потому что отсекает хорошие варианты ради лучших.

1.2. Ядро стратегии: три обязательных части

Румельт формулирует «kernel» — минимальную структуру, без которой документ не работает:

Ключевое слово в третьей строке — связные (coherent): действия должны усиливать друг друга, а не просто существовать. Если убрать любую инициативу и остальные не пострадают — у вас не стратегия, а портфель случайностей.

Пример полного ядра для B2B-SaaS:

Диагноз. Мы теряем 60% команд между регистрацией и первым отчётом, потому что настройка требует аналитика, а у нашего целевого сегмента (продуктовые команды 10–50 человек) аналитика нет. Конкуренты решают это платными внедренцами — нам это недоступно по экономике.

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

Связные действия. (а) Авто-инструментирование SDK без разметки событий; (б) 12 готовых шаблонов дашбордов под типовые продуктовые вопросы; (в) отказ от кастомного SQL-конструктора на год; (г) переориентация маркетинга на self-serve; (д) метрика команды — TTFV (time to first value), а не MAU.

Обратите внимание: пункт (в) — это явный отказ. Он и делает набор стратегией.

1.3. Иерархия: от видения до задачи в спринте

Две вещи чаще всего ломают эту схему на практике:

• Пропуск среднего слоя. Из видения сразу прыгают в бэклог. Тогда любая задача обосновывается через «ну это же приближает нас к видению» — а приближает всё.
• Отсутствие обратной стрелки. Стратегия, которую нельзя опровергнуть данными, — догма. Раз в квартал нужно честно спрашивать: «что мы узнали такого, что делает наш диагноз неверным?»

2. Диагноз: как его получить, а не выдумать

Диагноз — самая техническая часть стратегии, и именно её чаще всего пропускают, потому что она требует работы. Три источника, которые нужно сводить вместе:

1. Количественный — где в воронке и в удержании теряются деньги (см. продуктовые метрики).
2. Качественный — почему теряются: интервью, JTBD, разбор оттока (см. discovery).
3. Конкурентно-рыночный — что структурно меняется вокруг: регуляции, платформы, стоимость технологий.

2.1. Количественная часть: искать не среднее, а расслоение

Средние значения прячут стратегию. Полезный приём — сравнить кривые удержания по сегментам: если у одного сегмента retention выходит на плато, а у остальных падает в ноль, вы нашли и целевой сегмент, и продуктовую задачу одновременно.

-- Ищем не средний retention, а сегмент, чья кривая удержания выходит на плато.
WITH cohorts AS (
    SELECT u.user_id, u.segment,                      -- segment: размер компании или сценарий
           DATE_DIFF('week', u.signed_up_at, a.event_at) AS week_no
    FROM users u JOIN activity a ON a.user_id = u.user_id
    WHERE u.signed_up_at >= CURRENT_DATE - INTERVAL '180' DAY
),
retained AS (
    SELECT segment, week_no, COUNT(DISTINCT user_id) AS active
    FROM cohorts WHERE week_no BETWEEN 0 AND 12
    GROUP BY segment, week_no
)
SELECT segment, week_no, active,
       -- доля от нулевой недели: это и есть точка кривой удержания
       ROUND(active * 1.0 / MAX(active) OVER (PARTITION BY segment), 3) AS retention
FROM retained
ORDER BY segment, week_no;

Читать результат так: сегмент, у которого retention на 8–12 неделе перестаёт падать, — это ваш product/market fit в миниатюре. Стратегия часто сводится к «сделать так, чтобы этот сегмент стал больше», а не «починить всё для всех».

2.2. Качественная часть: силы, действующие на переключение

Из JTBD-традиции берётся модель четырёх сил (толчок от текущего решения, притяжение нового, привычка и тревога). Для стратегии важно, что два фактора из четырёх работают против вас, и их систематически недооценивают: стоимость переключения и страх ошибиться. Если диагноз их игнорирует, стратегия будет строиться на «сделаем функцию лучше», хотя реальная преграда — миграция данных и страх админа потерять историю.

3. Направляющая политика: где вы выигрываете и почему это надолго

3.1. DHM: три вопроса Гибсона Биддла

Гибсон Биддл, бывший VP Product в Netflix, свёл продуктовую стратегию к формуле DHM: Delight customers, in Hard-to-copy, Margin-enhancing ways (gibsonbiddle.com). Проверка любой ставки:

• D — радует ли клиента настолько, что он заметит? Не «улучшает», а именно заметно радует.
• H — сложно ли это скопировать? Если конкурент повторит за квартал, это не стратегия, а фича.
• M — улучшает ли это маржинальность? Если рост требует линейного роста затрат, вы построили агентство.

Буква H — самая недооценённая. Источники «сложности копирования» ограничены и хорошо каталогизированы:

Если ответа на вопрос «за счёт чего именно нас будет тяжело догнать» нет, стратегия сводится к «бежать быстрее» — а это работает ровно до появления конкурента с большим бюджетом.

3.2. Стратегическая канва: где кривые расходятся

Инструмент из «Blue Ocean Strategy» (Ким и Моборн). Вы выписываете факторы конкуренции в отрасли и рисуете по ним уровень предложения — свой и типичный. Стратегия видна там, где кривые расходятся; если ваша кривая просто чуть выше отраслевой везде, вы играете в чужую игру и проиграете тому, у кого больше ресурсов.

Дальше применяется схема ERRC — четыре вопроса, каждый требует явного ответа: Eliminate (что из «обязательного по отрасли» убрать полностью?), Reduce (что дать заметно ниже стандарта?), Raise (что заметно выше?), Create (чего в отрасли нет вообще?). Первые два — источник маржи и фокуса, вторые два — источник дифференциации. Стратегии, где заполнены только Raise и Create, нереализуемы: на них не хватит людей.

3.3. Позиционирование в одном предложении

Шаблон Джеффри Мура (из «Crossing the Chasm») до сих пор лучший тест на связность:

Для {сегмент}, который {потребность}, наш {продукт} — это {категория}, который {ключевая выгода}. В отличие от {альтернатива}, мы {ключевое отличие}.

Если в поле «альтернатива» вы пишете конкурента, а не «Excel и ручной процесс», — проверьте диагноз: в большинстве B2B-рынков главный конкурент это статус-кво.

4. От стратегии к ставкам: портфель, а не список

4.1. Три горизонта и правило 70/20/10

Ресурс команды конечен, а стратегия требует одновременно платить по счетам сегодня и строить завтра. Стандартное разделение (McKinsey Three Horizons, у Google популяризовано как 70/20/10): H1 (~70%) — улучшение работающего ядра, предсказуемая отдача; H2 (~20%) — расширение в новый сегмент или сценарий, отдача через 2–4 квартала; H3 (~10%) — рискованные ставки с большим потенциалом, большинство умрёт.

Соотношение не догма (у ранней стадии стартапа оно может быть 30/40/30), но явное распределение обязано быть. Без него H3 всегда съедается срочными задачами H1 — это самый частый механизм, которым компания теряет будущее, не приняв ни одного плохого решения.

4.2. Карта ставок

Практическое правило чтения карты: элементы из квадранта «большие ставки» нельзя ставить в роадмап как поставку — их ставят как исследование с гейтом принятия решения. Подробнее о таких гейтах — в статье про MVP и эксперименты.

4.3. Выбор набора ставок под ограниченную ёмкость

Задача «выбрать подмножество инициатив с максимальной ожидаемой ценностью при бюджете команды» — это задача о рюкзаке 0/1. Псевдокод:

ЗНАЧЕНИЕ(инициатива) = вероятность_успеха * ценность_при_успехе * стратегическое_соответствие
ВЕС(инициатива)      = оценка в человеко-неделях

dp[0..C] = 0                                  # C — ёмкость команды в человеко-неделях
для каждой инициативы i:
    для c от C вниз до ВЕС(i):                # обратный проход => каждый предмет берётся ≤ 1 раза
        dp[c] = max(dp[c], dp[c - ВЕС(i)] + ЗНАЧЕНИЕ(i))
вернуть dp[C] и восстановленный набор

Реализация с восстановлением набора:

from dataclasses import dataclass


@dataclass(frozen=True)
class Bet:
    name: str
    weeks: int            # оценка в человеко-неделях (медиана)
    value: float          # ценность при успехе, в деньгах или условных баллах
    p_success: float      # честная вероятность успеха, 0..1
    strategic_fit: float  # 0..1 — насколько работает на направляющую политику

    @property
    def expected_value(self) -> float:
        # Ставка вне стратегии обесценивается, даже если сама по себе выгодна:
        # именно это отличает портфель от жадного набора "всего хорошего".
        return self.value * self.p_success * self.strategic_fit


def select_portfolio(bets: list[Bet], capacity_weeks: int) -> tuple[float, list[Bet]]:
    """0/1-рюкзак: максимизируем ожидаемую ценность при ограничении по ёмкости.

    Время: O(n * C), память: O(n * C) из-за таблицы для восстановления набора.
    Для n ~ 30 и C ~ 200 это тысячи операций — считается мгновенно.
    """
    n = len(bets)
    dp = [[0.0] * (capacity_weeks + 1) for _ in range(n + 1)]

    for i in range(1, n + 1):
        bet = bets[i - 1]
        for c in range(capacity_weeks + 1):
            dp[i][c] = dp[i - 1][c]                       # не берём
            if bet.weeks <= c:                            # берём, если влезает
                cand = dp[i - 1][c - bet.weeks] + bet.expected_value
                if cand > dp[i][c]:
                    dp[i][c] = cand

    chosen, c = [], capacity_weeks                        # обратное восстановление набора
    for i in range(n, 0, -1):
        if dp[i][c] != dp[i - 1][c]:
            chosen.append(bets[i - 1])
            c -= bets[i - 1].weeks

    return dp[n][capacity_weeks], list(reversed(chosen))


quarter = [
    Bet("Авто-инструментирование SDK", weeks=14, value=900, p_success=0.7, strategic_fit=1.0),
    Bet("12 шаблонов дашбордов",       weeks=6,  value=400, p_success=0.85, strategic_fit=0.9),
    Bet("SQL-конструктор",             weeks=20, value=800, p_success=0.6, strategic_fit=0.2),
    Bet("SSO и SCIM",                  weeks=8,  value=500, p_success=0.9, strategic_fit=0.4),
    Bet("AI-ассистент по данным",      weeks=16, value=1200, p_success=0.25, strategic_fit=0.6),
]

total, picked = select_portfolio(quarter, capacity_weeks=26)
print(round(total, 1), [b.name for b in picked])
# 936.0 ['Авто-инструментирование SDK', '12 шаблонов дашбордов']

Разбор результата поучителен сам по себе. «SQL-конструктор» выброшен, хотя value у него высокий: strategic_fit = 0.2 обнуляет вклад — ровно тот отказ, который мы записали в направляющую политику. «AI-ассистент» с максимальной ценностью тоже выброшен: p_success = 0.25 делает его дорогой лотереей, его место в discovery, а не в поставке. И обратите внимание, что 6 из 26 недель остались свободны: рюкзак не обязан заполняться полностью, а резерв под инциденты и техдолг — не баг, а норма.

Trade-offs, которые обязательно проговорить, прежде чем показывать это руководству:

• Модель предполагает аддитивность и независимость ставок, а в реальности есть синергия (шаблоны работают только поверх авто-инструментирования) и конфликт за одних людей. Синергию грубо учитывают, склеивая связанные ставки в один «предмет».
• p_success и value — смещённые оценки. Если команда систематически оптимистична, оптимизатор выберет самые красиво оценённые ставки, а не самые ценные. Лечится калибровкой: раз в квартал сравнивайте прогноз с фактом.
• Оптимум рюкзака хрупок: сдвиг ёмкости на 2 недели может полностью поменять набор. Поэтому это вход в разговор, а не способ снять с себя ответственность за выбор.
• Ёмкость — не единственное ограничение: как только важны зависимости и порядок, задача превращается в планирование с предшествованием, а это уже NP-трудно.

5. Роадмап: как коммуницировать план, не соврав

5.1. Почему «роадмап-Гант» ломается

Классическая форма выглядит так и почти всегда лжёт:

Что здесь неверно:

1. Одинаковая точность на разных горизонтах. Полоса в мае нарисована так же уверенно, как январская, хотя неопределённость на пятом месяце в разы выше.
2. Фиксация решений, а не проблем. «AI-ассистент» — это решение. Через полгода данные могут показать, что проблема решается иначе, но обещание уже дано.
3. Отсутствие результата. Ни в одной полосе не написано, какое изменение метрики ожидается. Значит, успех = «поставили в срок», и вы снова в фабрике фич.
4. Механизм эскалации сроков. Даты воспринимаются как обязательства, поэтому команда защищает их качеством, а не переговорами.

Гант остаётся уместным там, где неопределённость действительно низка: интеграция с известным API, миграция, комплаенс-дедлайн, аппаратный релиз. Именно поэтому в проектном управлении он жив — там объём фиксирован по контракту, а в продукте объём и есть переменная.

5.2. Now / Next / Later

Формат, предложенный Джанной Бастоу (ProdPad) и ставший де-факто стандартом (prodpad.com): горизонт задаётся не датами, а степенью определённости.

Важное следствие: элемент не «переезжает» из Later в Now целиком — он там переписывается. В Later была тема «выйти в enterprise», в Next появилась проблема «крупные клиенты не проходят security review без SSO», в Now — задача «SAML SSO для трёх провайдеров». Это не одна сущность на разных стадиях, а последовательное сужение.

5.3. Роадмап, основанный на результатах

Мелисса Перри в «Escaping the Build Trap» предлагает следующий шаг: строки роадмапа — не фичи, а результаты (outcomes) с текущей гипотезой решения (O’Reilly). Разница на одном примере:

Второй вариант делает три вещи сразу: даёт критерий успеха, оставляет команде свободу поменять решение и превращает разговор со стейкхолдерами из «когда будет визард» в «нужен ли нам этот результат».

5.4. Жизненный цикл элемента роадмапа

Состояние Отклонена должно быть таким же уважаемым исходом, как Масштабирование. Здоровая метрика процесса — доля инициатив, убитых на этапе Discovery: если она близка к нулю, discovery это театр (см. discovery и исследования).

6. Сроки: как отвечать «когда», не обманывая

Отказ от дат невозможен: бизнесу нужно планировать найм, маркетинг и продажи. Правильный ответ — не «даты не бывают», а «даты бывают вероятностными».

6.1. Прогноз по историческому throughput методом Монте-Карло

Вместо суммирования оценок в неделях используется фактическая пропускная способность команды за прошлые недели (число завершённых элементов). Это устраняет главную ошибку оценок — систематический оптимизм, — потому что история уже включает все прерывания, баги и отпуска. Подход разобран у Дэниела Ваканти в «Actionable Agile Metrics for Predictability» и в материалах FocusedObjective.

import random
import statistics


def forecast_weeks(historical_throughput: list[int], items_remaining: int,
                   trials: int = 20_000, seed: int = 42) -> dict[str, float]:
    """Сколько недель займёт доставка items_remaining элементов.

    Идея: в каждую симулированную неделю мы «вытягиваем» случайную неделю из истории
    (bootstrap с возвращением) и вычитаем её throughput из остатка.

    Время: O(trials * ожидаемое_число_недель) — доли секунды. Память: O(trials).
    """
    rng = random.Random(seed)
    results: list[int] = []

    for _ in range(trials):
        remaining, weeks = items_remaining, 0
        while remaining > 0:
            remaining -= rng.choice(historical_throughput)
            weeks += 1
            if weeks > 500:            # защита от вырожденной истории из одних нулей
                break
        results.append(weeks)

    results.sort()
    pc = lambda p: results[min(int(p * len(results)), len(results) - 1)]
    return {"median_p50": pc(0.50),    # внутреннее планирование
            "p85": pc(0.85),           # внешние обещания
            "p95": pc(0.95),           # контрактные дедлайны
            "mean": round(statistics.fmean(results), 2)}


# Фактические завершения по неделям за последние 14 недель:
history = [4, 6, 2, 5, 7, 3, 5, 4, 0, 6, 5, 3, 8, 4]
print(forecast_weeks(history, items_remaining=40))
# {'median_p50': 9, 'p85': 11, 'p95': 12, 'mean': 9.51}

Как этим пользоваться в разговоре: «Медиана — 9 недель. С вероятностью 85% уложимся в 11, с вероятностью 95% — в 12. Какой уровень риска берём для анонса?» Это переносит разговор из плоскости «обещай / не обещай» в плоскость управления риском, что для стейкхолдеров понятнее и честнее. Оговорки:

• метод требует стабильного потока и сопоставимой нарезки элементов; если элементы различаются на порядок, сначала нарежьте их мельче;
• история должна отражать ту же команду и тот же контекст: после реорганизации данные обнуляются;
• прогноз не учитывает неизвестный объём, поэтому items_remaining тоже стоит брать диапазоном (например, 40–60) и прогонять симуляцию для обеих границ.

6.2. Конус неопределённости

Барри Бём эмпирически показал ещё в 1981 году, что на старте проекта оценка объёма ошибается в 4 раза в обе стороны и сходится к факту только к концу (обзор понятия). Отсюда практическое правило коммуникации: точность обещания обязана соответствовать позиции в конусе. Называть точную дату для того, что стоит в Later, — не оптимизм, а методическая ошибка.

7. Связка с OKR: чтобы стратегия дожила до квартала

OKR — механизм перевода направляющей политики в измеримый результат квартала. Хорошо: O: команды получают ценность в первый день. KR1: TTFV p50 с 6 дней → 1 день. KR2: доля команд с первым отчётом за 24 ч 38% → 60%. KR3: доля тикетов «не могу настроить» 22% → 8%. Типичные поломки:

• Key Results — это задачи. «Выпустить визард» — не результат, а действие. Проверка: KR описывает состояние мира, а не факт поставки. Если формулировка начинается с «сделать/запустить» — переписывайте.
• Сэндбэггинг. Цели ставят так, чтобы гарантированно выполнить, особенно если OKR привязаны к премии. Привязка к компенсации надёжно убивает их смысл — это отмечал ещё Энди Гроув, автор подхода, в «High Output Management».
• Слишком много целей. Более 3 O и 3–4 KR на команду означает отсутствие фокуса, то есть отсутствие стратегии.
• Разрыв со стратегией. Каждый O должен быть выводим из направляющей политики. Не выводится — либо цель лишняя, либо стратегия неполна.

Подробнее про выбор метрик и защиту от гейминга — в статьях про продуктовые метрики и аналитику и принятие решений.

8. Как это выглядит в проде

Amazon — Working Backwards / PR-FAQ. Прежде чем что-либо строить, команда пишет пресс-релиз будущего продукта (одна страница, языком клиента) и FAQ на 5–6 страниц с неудобными вопросами; документ читается молча в начале встречи. Смысл механики: сформулировать ценность до того, как вложены инженерные месяцы, и сделать слабую идею очевидно слабой на бумаге (Bryar & Carr).

Netflix — DHM и «стратегия как гипотезы». Биддл описывает стратегию как набор проверяемых утверждений с явными метриками успеха, пересматриваемых ежеквартально. Знаменитый пример — ставка на персонализацию как на трудно копируемый актив: она работала именно потому, что данные о просмотрах накапливались и усиливали сами себя.

Spotify — DIBB (Data → Insight → Belief → Bet). Формат заставляет явно показать цепочку от данных к ставке. Ключевая ценность — виден переход от инсайта к убеждению, то есть место, где стратегическая логика может сломаться и где её можно оспорить на ревью.

Intercom — «начинай с проблемы клиента». Любая инициатива описывается через проблему и «наихудший вариант решения, который мог бы сработать», — чтобы найти минимальный шаг, дающий сигнал (intercom.com).

Общее у всех четырёх: документ важнее слайдов, а гипотеза важнее плана.

9. Типичные ошибки

1. Стратегия = амбициозная цель. «Стать №1 на рынке» ничего не запрещает и не помогает выбирать.
2. Роадмап вместо стратегии. Если стратегический документ можно заменить роадмапом без потерь, стратегии не существует.
3. Отсутствие явных отказов. Если ни одна крупная возможность не отклонена письменно, вы ещё не выбирали.
4. Слишком много ставок. 8 приоритетов = 0 приоритетов. Ёмкость команды делится не только на разработку, но и на внимание.
5. Стратегия, которую нельзя опровергнуть. Нет ни одного факта, который заставил бы вас её изменить — значит, она не про реальность.
6. Даты в зоне Later. Выдуманная точность разрушает доверие быстрее, чем честное «не знаю».
7. Роадмап как контракт с продажами. Как только он становится обязательством, команда перестаёт учиться: новое знание превращается в угрозу плану, а не в его улучшение.
8. Стратегия в голове у одного человека. Тест: попросите трёх инженеров написать одной фразой, за счёт чего продукт выигрывает. Совпадение ответов и есть измерение качества стратегии.
9. Ежегодная стратегия без ревизии. Без квартального ревью документ превращается в артефакт.
10. Копирование конкурента как политика. Вы всегда отстаёте на цикл разработки и не знаете, работает ли скопированное у них самих.

10. Рабочий чеклист

Стратегия готова, если вы можете за две минуты ответить:

• Какая одна главная трудность стоит перед продуктом сейчас и чем она подтверждена (данные + интервью)?
• Какой подход мы выбрали и что из-за этого не делаем?
• За счёт чего нас будет сложно скопировать через два года?
• Какие 3–5 ставок из этого следуют и как они усиливают друг друга?
• Какой измеримый результат означает, что политика работает?
• Какой факт заставил бы нас признать стратегию ошибочной?
• Что стоит в Now/Next/Later и соответствует ли точность обещаний горизонту?
• Знает ли команда ответы на пункты 1–3 без подглядывания в документ?

11. Мини-итог

• Стратегия — это диагноз + направляющая политика + связные действия, а не цель и не слайд. Главный признак настоящей стратегии — явный список того, чего вы не делаете.
• Диагноз добывается из расслоения данных и интервью, а не из мозгового штурма.
• Направляющая политика обязана отвечать на вопрос о трудности копирования: без этого вы соревнуетесь в скорости, а не в позиции.
• Ставки живут в портфеле с распределением по горизонтам; выбор набора под ёмкость формализуется как рюкзак (O(n·C)), но результат — вход в разговор, а не приговор.
• Роадмап коммуницирует степень определённости: Now — даты, Next — намерения, Later — направление. Строки — результаты, а не фичи.
• Сроки называются вероятностно: Монте-Карло по историческому throughput даёт p50/p85/p95 и переводит разговор в управление риском.

Источники

• Richard Rumelt, «Good Strategy / Bad Strategy» (2011) — изложение ядра стратегии
• Melissa Perri, «Escaping the Build Trap» — O’Reilly
• Gibson Biddle, материалы про DHM и продуктовую стратегию — gibsonbiddle.com
• Marty Cagan, «INSPIRED» и статьи SVPG о продуктовой стратегии — svpg.com/articles
• Janna Bastow, Now/Next/Later — prodpad.com
• Daniel Vacanti, «Actionable Agile Metrics for Predictability» — прогнозирование по throughput
• Colin Bryar, Bill Carr, «Working Backwards» — workingbackwards.com
• W. Chan Kim, Renée Mauborgne, «Blue Ocean Strategy» — стратегическая канва и ERRC
• John Doerr, «Measure What Matters» — OKR: whatmatters.com

Что дальше

Стратегия называет ставку, роадмап называет порядок — но ни то, ни другое не доказывает, что ставка сыграет. Следующий шаг — научиться проверять её максимально дёшево: MVP, гипотезы и A/B-эксперименты.