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

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

• «акцент на важном. «я с тебя не слезу»
• «акцент на важном, что быстрее всего приводит к цели»

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

Когда. На встрече сначала долго обсуждают понятное и приятное (разработку, статусы), а трудное и лимитирующее остаётся на последние пять минут.

• «Важные темы — в начало ТМ. Важное — то что нас лимитирует, то в чем мы испытываем затруднения.»
• «давай-ка начнём с конкурентного анализа, а разработку на конец оставим»

В начале встречи трекер сам объявляет, сколько времени уходит на отчёт о сделанном и когда начинается разговор о выводах. Отчёт получает жёсткую рамку, а разбор — основное время.

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

• «Слушай, а давай я тебе предложу тайминг — сейчас за 5-7 минут расскажешь, что сделано, что не сделано, а потом про выводы поговорим.»
• «Эффективное использование времени на встречах помогает сосредоточиться на ключевых моментах»

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

Когда. Задачи на спринт набраны без иерархии, всё выглядит одинаково срочным.

• «а что сейчас самое важное»
• «Что сейчас самое важное?» приоритезация задач на спринт»

Короткая директивная реплика, которой трекер останавливает расползание обсуждения и возвращает разговор к выбранной линии.

Когда. Разговор уходит в стороны, команда перескакивает между темами, в голове менеджера проекта хаос.

• «Давай сфокусируемся»
• «В голове МП хаос — как не стать жертвой хаоса»

Трекер выясняет цель до того, как начнётся разговор о задачах и действиях — на диагностике, в начале трека, в начале спринта. Цель проговаривается вперёд, а не выводится задним числом из сделанного.

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

• «заранее спрашивать про цель»
• «Важно заранее определить и уточнить цель, чтобы все участники процесса имели ясное представление о конечном результате.»

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

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

• «чтобы что?»
• «Постоянно задавайте вопрос «чтобы что?», чтобы уточнить цели и задачи, и избежать выполнения ненужных действий.»

Трекер проверяет исследовательское намерение: прежде чем команда пойдёт что-то узнавать, она должна назвать решение, которое примет по результату.

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

• «а зечем тебе это нужно? что ты будешь делать с ответом.»
• «А зачем нам это узнавать? — цель»

Трекер демонстративно обесценивает отчёт о деятельности и требует отчёт о полученном знании. Мера прогресса — не объём работ, а прирост знания.

Когда. Команда отчитывается активностью: провели столько-то интервью, сделали столько-то задач — а выводов нет.

• «мне все равно что вы делали, что вы узнали?»
• «не надо рассказывать, что ты будешь делать, какой результат ты получишь?»

Трекер не даёт остановиться на факте: за каждым добытым фактом требует сформулированный вывод и следующий шаг.

Когда. Фактура накоплена (интервью, дашборд, исследование), но команда не превращает её в решения.

• «мы это узнали, какой вывод можем сделать?»
• «Ок, и какие выводы?»

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

Когда. Исследование длинное, команда ждёт его завершения и в это время ничего не двигает.

• «Перевела промежуточные выводы из исследования в задачу»
• «Превращаем фактуру из исследования в задачи»

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

Когда. Долгое обсуждение, участники разошлись в понимании; есть риск, что вывод трекера воспримут как навязанное мнение.

• «обобщение выводов чтобы свериться»
• «это будет не моя позиция, это обобщения ваших слов»

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

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

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

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

Когда. Менеджер соглашается кивком, а на следующей встрече выясняется, что понял иначе или не считает это своим.

• «в конце ТМа возвращает МП, чтобы тот сам проговорил договоренности, которые достигли на ТМ»

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

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

• «Прошелся по задачам и тому, успели ли их закрыть за спринт. (не дал слезть с договоренностей) — У меня есть, написано, что мы хотели за следующий спринт.»
• «давай вспомним, о чем говорили\договаривались в прошлый раз?»

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

Когда. Спринт провален, есть соблазн ограничиться извинениями и переносом задач.

• «Узнал, с какими ограничениями с———нулись и как их можно было расшить, почему это не сделали в моменте. — учил МП быть МП. (Почему не сделали? Частично или целиком, во что упёрлись? А почему так?) Решение — поделить задачи, которые не блокированы и расставить систему флажков.»

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

Когда. Команда работает, но не продвигается; работ много, результата нет.

• «Во что упирается команда?»
• «что не дает нам двигаться дальше?»

Постоянный фоновый вопрос наблюдателя за командой — рамка, в которой трекер смотрит на любую встречу. Не «что они делают», а «что держит их темп».

Когда. Всегда — при наблюдении за работой команды и при разборе чужого трекшн-митинга.

• «Почему они бегут с той скоростью, с которой бегут, а не быстрее?»

Обнаружив узкое звено, трекер не решает за команду, а даёт метод или инструмент, которым команда сама его снимет — «немного Голдратта».

Когда. Ограничение найдено и признано, но у команды нет способа с ним работать.

• «расшивает ограничение»
• «*Дал инструмент команде для снятия ограничения (немного Голдрата).»

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

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

• «Цель (чего мы хотим добиться) Метрика цели (как поймем что мы этого добьемся) Этап (какие КР и в каком порядке нам нужны / какие барьеры стоят между нами и целью) Цель этапа: (Сейчас мы здесь, цель этапа такая / какой барьер сейчас снимаем) Лимитирующий фактор = узкое звено (Вот какой фактор приводит к тому, что цель еще не достигнута) Причина, по которой он существует (Техническая причина) Управляющее воздействие (Прием который применить) — Куда перейдет УЗ, когда мы снимем ЛФ?»
• «Инструмент: декомпозиция цели»

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

Когда. Всегда — как норма собственной работы трекера, проверяемая перед каждой встречей и после неё.

• «Мета прием: Трекер в любой момент знает где команда относительно цели и что ее лимитирует (чтобы снять лимитирующий фактор и ускорить). Для этого надо знать: Цель, Метрику, Этап, Лимитирующий фактор»
• «Мы должны сделать все чтобы мы могли принять решение, минимизировав стоимость и риски и максимизировав профит»

Трекер придумывает реальность, в которой заявленная метрика достигнута, а заказчик всё равно не доволен. Если такая реальность существует — метрика выбрана неверно.

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

• «попытка ФАЛЬСИФИКАЦИИ»
• «пытаемся придумать реальность где мы нашли эту цифру, а заказчика не устраивает»

Общеметодический принцип: прежде чем улучшать, надо построить наблюдение — дашборд, замер, график. Без наблюдения нельзя ни определить, что улучшать, ни увидеть эффект.

Когда. Команда собирается улучшать метрику, которую не измеряет; нет визуализации, нет ретро-данных.

• «нельзя улучшать, то что не наблюдаешь.»
• «Наблюдение является ключевым элементом в процессе улучшения. Без наблюдения невозможно определить, что именно требует улучшения и как это сделать наиболее эффективно.»

Трекер разбирает данные вместе с командой прямо на графике: смотрит форму кривой, когорты, воронку — вместо обсуждения на словах.

Когда. Обсуждение метрик идёт в общих словах («выросло», «просело»), без картинки.

• «работа с графиком»
• «можно всю воронку посмотреть?»

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

Когда. Команда приносит аналитику и уже готовые выводы, происхождение цифр не проверено.

• «*Понять, есть ли искажение в данных. Почему для аналитики сервисы используют? (какую базу использовали?) Искажение есть? — тогда не валидный опыт»
• «уточняет про формат данных, в котором смотрим ту инфу, которую принёс МП на ТМ»

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

Когда. Команда сделала несколько интервью и уже готова считать проблему подтверждённой.

• «а есть количественное подтверждение исследования?»
• «Спросить: «А есть количественное подтверждение исследования?»

Прежде чем браться за улучшение показателя, оценить, насколько сильно он вообще способен сдвинуть целевую цифру.

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

• «считайте плечо метрики»
• «как нам понять какой из факторов сильнее влияет на выживаемость когорты»

Трекер заставляет проверить, не приписывает ли команда себе изменения, которые произошли бы и без неё.

Когда. Метрика выросла после запуска, и команда автоматически считает это своим эффектом.

• «надо отделять результат своих действий от независимого поведения рынка»

Гипотеза не считается сформулированной, пока не назван способ её проверки и критерий подтверждения или опровержения.

Когда. Бэклог гипотез растёт, но проверять их нечем; команда обсуждает гипотезы бесконечно.

• «при формулировании гипотезы сразу планировать, как проверим»
• «При разработке гипотезы важно сразу определить методы её проверки, чтобы обеспечить её реалистичность и достижимость.»

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

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

• «Мне хочется увидеть постановку на эксперимент. В смысле, постановка на эксперимент означает, что у нас есть гипотеза формата — мы верим, что если мы сделаем вот такое, то получится вот такое и вот такое.»
• «что хотим узнать / критерий»

До начала проверки формулируется, при каком результате гипотеза считается подтверждённой, а при каком — убитой, в цифрах и долях.

Когда. Проверка уже идёт, а команда не может сказать, какой исход её удовлетворит; спор о том, достаточно ли доказательств.

• «Цель этапа (критерий подтверждения/опровержения)»
• «Доказать, что 40% представителей сегмента есть проблематика.»

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

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

• «Почему RAT — хороший способ приоритезации — потому что это самый короткий путь к опровержению. Нам надо как можно быстрее понять стоит ли инвестировать в бизнес»
• «сначала проверять те риски, которые если не будут сняты с гарантией убивают бизнес либо их влияние выходит за границы инвестиций; среди них надо сначала проверять те, которые можно проверить быстрее»

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

Когда. Команда выбирает гипотезы «какие понятнее»; экономика при этом не сходится.

• «приоритезация гипотез по юнит-экономике»
• «Оценивайте и приоритизируйте гипотезы на основе их влияния на юнит-экономику, чтобы обеспечить устойчивый рост.»

Трекер держит в руках несколько методов приоритизации и выбирает подходящий под ситуацию: RAT — когда решает риск, TOC — когда есть узкое звено, RICE — когда сравниваем однородные работы.

Когда. Команда не может выбрать, что делать раньше — например, касдев или юнит-экономику; спор о приоритете идёт на вкусе.

• «метод приоретизации: RAT / TOC / RICE»
• «Как помочь менеджеру проекта быстро решить — что ему делать, касдев или юнит экономику.»

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

Когда. У команды есть одна самоочевидная стратегия, в которую все верят, и никто её не проверял.

• «У нас, вот, короче, очевидная 1 из стратегий, что мы находим точку входа из неё, обселимся. Вот, у нас есть очевидная точка входа, да? Как опровергнуть эту стратегию? Обнаружили, что из-под Диадока нихера не продается.»
• «откуда мы знаем, что этой проблемы нет?»

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

Когда. Обсуждение стратегии идёт в одном сценарии, альтернатива не рассматривается; команда не отличает стратегию от плана работ.

• «Сейчас 2 альтернативные реальности сформулирую... Ты что, что думаешь?.. это стратегия, а как понять?»
• «Визуализировать для команды стратегию добегания до цели в виде дерева вариантов»

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

Когда. Решение выглядит единственно возможным; команда застряла в одной логике.

• «А что если сделать наоборот»
• «а как ещё можно сделать\понять?»

Трекер вбрасывает заведомо нестандартный вариант, обозначая его как безумный, чтобы снять с команды страх обсуждать неочевидное.

Когда. Команда генерит только осторожные идеи; поле решений сузилось.

• «есть безумная идея»
• «Фасилитировать мозговой штурм»

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

Когда. Команда планирует дорогую и долгую проверку там, где годится дешёвая.

• «как сделать (целевое действие) дешевым»
• «а можно сделать/получить быстрее?»

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

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

• «А можем, вот прямо сейчас с тобой этот путь клиента пройти? Вот, зайти сейчас на маркетплейс, найти место, откуда они посылают в Диадок, и посмотреть, куда именно приходит.»

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

Когда. Непонятно, реальны ли знания команды или это ощущение осведомлённости; нужно быстро проверить достаточность фактуры.

• «Попросить заполнить часть нового фрейма прямо сейчас: а можем эти 2 строчки заполнить, хватает ли у нас данных?»
• «Достаточно ли данных для того, чтобы найти точки входа?»

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

Когда. Команда планирует работы, а не знания; спринт кончается объёмом сделанного без движения к решению.

• «Целевое незнание (над получением какого знания работает команда? почему именно над ним?)»
• «Какое целевое для команды незнание нашли?»

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

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

• «Что нам известно? — незнание»
• «А что мы не знаем? — незнание»

Трекер требует показать основание вывода — откуда взялось утверждение, на каких данных оно стоит.

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

• «Как ты это понял? — анализ»
• «откуда мы знаем, что этой проблемы нет?»

Трекер разворачивает разговор к текущему поведению клиента и к деньгам, которые уже тратятся на альтернативные решения.

Когда. Команда обсуждает будущий продукт, не изучив, чем клиент решает задачу сегодня.

• «А как сейчас они это делают? — анализ»
• «Кто сейчас тратит деньги на альтернативные решения? — анализ»

Трекер ведёт команду к поиску конкретного места в процессе клиента, где есть измеримые потери, и к точке входа — тому, за что клиент готов платить.

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

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

Трекер разворачивает команду от списка работ клиента к списку его проблем — потому что покупают решение проблемы, а не выполнение работы.

Когда. Команда закопалась в JTBD-раскладку и потеряла связь с реальной болью и деньгами.

• «в чем проблемы? а не джобы»
• «надо решать проблему клиента, а не напоминать ему о том, что ему надо поработать еще»

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

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

• «раскладывает продукт наш и конкурентов на джобы»
• «выявление джоб»

Трекер ищет различающий признак: чем те, у кого получилось, отличаются от тех, у кого нет — и превращает признак в критерий сегмента.

Когда. Сегмент описан размыто; часть клиентов видит эффект, часть нет, и непонятно почему.

• «а чем отличается (этот клиент) от всех остальных»
• «чем отличаются клиенты, которые видят эффект на бизнес, от клиентов, которые не видят эффекта на бизнес?»

Трекер добивается формулировки требований к клиенту в двух списках: по каким признакам мы поймём, что продадим, и по каким — что не продадим.

Когда. Команда ищет сегмент наощупь, тратит время на клиентов, которым не продаст.

• «найти квалифицирующие / отсекающие признаки сегмента»
• «вот как мы понимаем что мы продадим / вот какие признаки у тех кому не продадим»

Трекер переводит разговор с фич на условия: какие требования обязаны выполняться, чтобы продажа состоялась, чтобы клиент продлился, чтобы сошёлся юнит.

Когда. Команда обсуждает функциональность в отрыве от условий сделки и экономики.

• «требования к продукту (не фичи, а какие нужно соблюсти условия)»
• «скорость подбора данных для предприятия не может быть дольше чем n дней от запроса; если это требование мы не можем продемонстрировать при продаже, не будет продажи»

Трекер просит разложить функциональность на то, что улучшает опыт уже пришедшего пользователя, и то, что приводит новых.

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

• «разделение фич по влиянию на пользователя внутри продукта и на привлечение пользователей»
• «Не понимают, как группировать фичи.»

Трекер размещает сегменты на шкале осведомлённости — DA (готов покупать), ID (осознал проблему, но рынок формируется), AI (спроса ещё нет) — и связывает каждую стадию со своей стратегией входа и своим типом продаж.

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

• «DA. Сегмент на связке самый горячий, и он будет прямо сразу покупать. Критерием для такого сегмента будут непосредственно продажи... (для стратегии «Сразу в кэшфлоу»)»
• «ID — сегмент в стадии формирования... Продажи будут медленней. В онбординг надо включать обучение. Вообще работает продажа через обучение. (для стратегии «впрыгиваем в разгоняющийся поезд»)»

Трекер заставляет назвать, по каким параметрам сравниваются бизнес-модели — стоимость запуска, потенциал в деньгах, доля рынка — и что считается «лучшей» моделью в терминах выбранной стратегии.

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

• «Цель — определиться с бизнес-моделью. Метрика — по каким параметрам будем сравнивать? — стоимость запуска — потенциал в деньгах — доля рынка»
• «лучшей будет та бизнесмодель которая быстрее окупится и выйдет на большую прибыль за 3 года»

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

Когда. Команда либо не строит модель вообще, либо считает экспертную прикидку рабочей моделью.

• «1. целевая модель — мы понимаем только структуру деятельности, все переменные пока экспертные (экстраполяция с подобной деятельности)»
• «2. грубая экспериментальная модель — мы проверили экспериментально самые важные верхнеуровневые драйверы»

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

Когда. Всё выглядит гладко, но результата нет; или данные и рассказ расходятся.

• «На что стоит обращать внимание — есть ли какие-то флажки? (например, выбивающиеся метрики, несоответствия)»
• «расставить систему флажков»

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

Когда. Команда объясняет успех или провал словами «качество», «удобство», «выгода», за которыми нет ни метрики, ни поведения.

• «стоп слова: качество, удобство, целевые метрики, выгода, важность»

Трекер сознательно отказывается принимать решения за команду и явно проговаривает разграничение ролей: решения принимает CEO, трекер даёт методику.

Когда. Менеджер ждёт готовых ответов и подсказок; команда начинает принимать задачи, а не формировать их.

• «возвращение ответственности за принятие решений в МП»
• «*Разграничил зоны ответственности. Давай расскажу про наше планирование. ты — главный, я тебе не начальник, решения принимаешь ты»

Трекер возвращает ответственность и одновременно обозначает, что результат будет проверен — но не постоянным контролем, а по предъявлению.

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

• «Вернул ответственность + показал, что чекнешь, как сео настроил работу. Я не буду это каждый раз проверять, но в следующий раз покажите, что вы это сделали.»

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

Когда. Менеджер относится к проекту как к поручению; решения принимаются с оглядкой на отчётность, а не на результат.

• «давай представим, что это наш бизнес с тобой, а не гипотеза в ———е»

Трекер разворачивает задачу продвижения от проталкивания к вытягиванию: искать, за счёт чего пользователи сами станут запрашивать и распространять продукт.

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

• «как сделать так, чтобы они сами просили?»
• «как сделать так чтобы бота распространяли за счет того, что он приносит пользу людям»

Увидев риск, трекер не проговаривает его, а серией вопросов проверяет, видит ли его команда, и подводит к тому, чтобы риск назвали сами.

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

• «если видит риск, то начинает через вопросы узнать, видит ли его команда, а не проговаривает его»
• «вижу риск»

Когда трекер видит проблему, а CEO нет, задача трекера — организовать запрос: сделать так, чтобы CEO самостоятельно обнаружил узкое звено, осознал и выбрал проблему и сфокусировался на ней. Трекер даёт методику, а не решение.

Когда. Расхождение картин мира: трекер уверен в проблеме, CEO её не признаёт, наводящие вопросы не срабатывают.

• «Что делать если я вижу проблему, а CEO не видит. — Нужно организовать запрос»
• «Задача трекера сделать так, чтобы CEO самостоятельно обнаружил узкое звено, осознал (и выбрал) проблему, и сфокусировался на ней»

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

Когда. Менеджер загнан, ушёл в оправдания, боится признать невыполненное; давление перестало работать.

• «Сняла напряжение с МП»
• «насколько трекер должен хвалить.»

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

Когда. Команда устала, ушла в текучку, задача воспринимается как рутина.

• «Жесткая геймификация любой продуктовой задачки с минимальной наградой работает невероятно эффективно. Прямо выше ожиданий.»
• «Как мотивировать команду, когда они устали или ушли в текучку?»

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

Когда. Цикл обратной связи длинный, ошибки обнаруживаются через две недели.

• «у меня есть такое предложение: и дальше сокращение сроков между итерациями\встречами»
• «Уменьшение интервалов между итерациями или встречами способствует более быстрому реагированию на изменения»

Регулярная сверка: одинаково ли команда, CEO и заказчик понимают цель и ожидаемый результат, и не разошлись ли они с прошлого раза.

Когда. У CEO и у команды разные взгляды на цели; бизнес-заказчик меняет вводные по ходу.

• «синхрон целей»
• «синхрон ожиданий»

Трекер сверяет всю деятельность менеджера с целью трека и ищет конкурирующие цели — от заказчика, от руководителя, от параллельных проектов.

Когда. Менеджер занят, но не движется; часть его работы идёт вне трека и никем не учитывается.

• «подчинены ли все действия МП цели?»
• «есть ли цель более высокого уровня которой руководствуется МП?»

Трекер вскрывает ситуацию, когда у менеджера есть гипотезы внутри трека и гипотезы вне трека, и они не ускоряют друг друга: фактура фрагментируется, качество результата падает.

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

• «есть гипотезы вне акселя / есть гипотезы внутри акселя / в итоге у нас две очереди приоритетов»
• «происходит расфокусировка»

Мало выстроить приоритизированный список гипотез — надо добиться, чтобы CEO реально им пользовался при выборе работ, и показать заказчику выигрыш от работы внутри трека.

Когда. Приоритеты расставлены на бумаге, но решения принимаются мимо них.

• «нужен ряд нормально приоритезированных гипотез / приоритезировать / сделать так чтобы СЕО пользовался приоритетом»
• «показать ей и заказчику что если она будет работать в акселе мы будем проверять сегменты быстрее и массовей»

Трекер не считает цель неприкосновенной: если формулировка цели порождает расфокус, он предлагает переформулировать её в более узкую и достижимую.

Когда. Цель заставляет проверять 20 сегментов, а команда способна на 4; цель сформулирована так, что подчинить ей работу невозможно.

• «скорректировать цель — нам надо как можно быстрее найти сегмент(ов)»
• «добиться улучшения продлений, а для этого надо найти 1 сегмент где мы будем хорошо продляться и приносить наши бабки»

Трекер сам накидывает команде варианты ценностных предложений и вариантов анализа — как материал для выбора, а не как решение.

Когда. Команда не генерит гипотезы из выводов исследования и из наблюдения за конкурентами; поле вариантов пустое.

• «накидывает команде гипотезы ценностных предложений для клиента»
• «Предложить несколько вариантов анализа для приоритезации в продукте»

Базовая пара действий на встрече: трекер выясняет, что именно команда собирается делать, и одновременно проверяет её картину рынка.

Когда. Начало работы с командой или новый этап; трекер ещё не знает, на какой картине мира команда строит план.

• «узнает план действий»
• «уточняет понимание рынка»

Трекер прямо приглашает менеджера назвать то, что тревожит, но пока не оформлено в проблему.

Когда. Формально всё в порядке, но у менеджера есть неоформленное беспокойство, которое он не выносит на встречу.

• «есть что-то, что тебя смущает и ты не знаешь, что с этим делать?»
• «Ответить нужно, но не получается самостоятельно»

Трекер прогоняет прошедший цикл по схеме гипотеза-действие-данные-выводы и ищет, где цепочка рвётся: не сформулирована гипотеза, не сделано действие, не собраны данные или не сделан вывод.

Когда. Команда что-то делала, но результат цикла не читается; выводы не сделаны или не связаны с действиями.

• «HADI цикл — найди разрывы»
• «Не знает как работать по HADI»

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

Когда. Менеджер верит или не верит в гипотезу без явных оснований; спор идёт на убеждениях.

• «Какой телс тебе с рынка должен прийти, чтобы ты сказал, что я хочу эту гипотезу?»
• «Если МП верит/не верит в гипотезу, как повлиять на его мнение?»

Трекер просит заранее проговорить, что команда сделает при том или ином исходе: если 25 из 30 ответили так — какой вывод, какие следующие шаги.

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

• «Это подтверждает гипотезу? Ну, давай представим себе, что мы такие провели там 30 интервью. Из 30 интервью 25 человек сказали... Что это для нас значит?»
• «Если мы это узнаем, то что для нас будет значить?»

Трекер переносит между командами найденные удачные ходы, соединяя опыт разных проектов в один инструмент.

Когда. Одна команда уже решила задачу, с которой сейчас бьётся другая.

• «объединение лучших практик»
• «какие знания получили из опыта?»

Трекер берёт на себя роль ведущего обсуждения: держит рамку, не даёт уйти в стороны, помогает команде выработать формулировку самой.

Когда. Команда накидывает сырых идей без структуры; обсуждение расползается.

• «Фасилитирует обсуждение гипотезы»
• «Фасилитировать мозговой штурм»

Трекер оценивает фаундера по жёстким критериям: тратит ли он больше половины времени на проект до нахождения соответствия продукта рынку и есть ли у него предпринимательская компетенция — ему больше всех надо, он находит выходы из тупиков, его воля ———ает всех. Без CEO нет проекта и продукта.

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

• «можем ли мы на ЭТОМ этапе использовать этого эксперта как CEO или нет? — Нет CEO — нет проекта / продукта.»
• «требования к CEO — больше 50% времени тратит на проект до того как будет найден PMF»

Трекер обучает CEO постановке задач по полному ———у: цель → задача → пересказ своими словами → ресурсы и полномочия → точки и способ контроля → условия разрыва контракта → подтверждение принятия ответственности. Качество постановки измеряется уровнем самостоятельности подчинённых — насколько редко надо контролировать, чтобы получить предсказуемый результат.

Когда. CEO не умеет ставить и контролировать задачу; команда работает предсказуемо плохо; надо понять, растёт ли управляемость.

• «Неотчуждаемые компетенции — постановка цели (понять чего мы хотим, и какого результата собираемся добиться) — декомпозировать до задач — уметь ставить задачи»
• «цель (зачем мы это делаем) — задача (какой результат надо получить сейчас) — перескажи своими словами (контроль понимания связи цели и задачи) — ресурсы (договориться о средствах и полномочиях) — вот в каких точках и каким способом я тебя буду контролировать (границы ответственности и способ контроля) — я разорву контракт если / ты можешь расторгнуть контракт если — скажи что ты взял это в ответственность»

Хороший CEO вместе с командой осваивает именно тот навык, который снимает текущее ограничение: если не понимаем, какую боль закрывать — CEO сам ходит на интервью и делает выводы из частотника. Без присвоения результата он будет хуже использовать прогресс команды и принимать решения худшего качества.

Когда. CEO делегирует именно ту работу, которая сейчас является узким звеном, и потому не присваивает результат.

• «У команды в каждый момент времени есть узкое звено и ЗБР — хороший CEO вместе с командой овладевает навыком который помогает снять текущее ограничение»
• «например если текущее ограничение в том что мы не понимаем какую боль клиента надо закрывать — CEO должен вместе с командой ходить на интервью и делать выводы из частотника. Потому что CEO должен присвоить результат.»

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

Когда. CEO соглашается на внешние задачи и отдаёт ресурс команды, из-за чего проект не движется.

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

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

Когда. Наблюдение за чужой сессией, обучение трекеров, разбор записи трекшн-митинга.

• «Когда мы наблюдаем работу трекера, мы ведем конспект в котором выделяем: Хорошие вопросы (то на что вам нужно получить ответ, но не получается); Какие есть барьеры (то что мешает команде бежать); Целевое незнание (над получением какого знания работает команда? почему именно над ним?); Какие приемы использует трекер и для чего?»

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

Когда. Трек ушёл в текущую тему и потерял часть исходной рамки; или ситуация изменилась настолько, что нужна новая диагностика.

• «возвращается к гипотезам с ДС, чтобы не упустить вторую цель трекшена»
• «как проводить диагностику перед стартом проекта? как понять что пришло время провести повторную ДСку?»

Трекер требует назвать ставку — то немногое, на чём держится путь к цели, и то, в каких областях у нас пробел в знаниях, который эту ставку подрывает.

Когда. План выглядит как набор работ; неясно, какое допущение несёт основной вес.

• «на что мы делаем ставку (чтобы придти к нашей цели)»
• «Мы определяем ключевые области, в которых у нас есть пробелы в знаниях, и разрабатываем стратегию для их устранения»

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

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

• «20 млн в месяц от продаж медуслуг — мы привлекаем (50) новых клиентов в месяц — менеджеры способны обслужить (70 клиентов) в месяц — средний чек у нас 300+ — 50 клиентов из накопленной базы каждый месяц заказывают еще»
• «у нас больше чем 150 входящих в месяц (к концу года) / у нас конверсия в продажу > 33%»

Трекер строит карту сегментов не по формальным признакам, а вокруг вопроса «что является драйвером перехода» — и предлагает смотреть на рынок там, где он соприкасается с драйвером, искать тех, кто уже сменил поведение, и говорить с ними.

Когда. Сегменты нарезаны по размеру и географии, но непонятно, почему кто-то из них начнёт покупать.

• «что является драйвером перехода в белую?»
• «давайте посмотрим на рынок, там где он соприкасается с драйвером»

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

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

• «Провели интервью с топ3 сегментами — проблема не подтвердилась. Не знаем, достаточно ли доказательств того, что гипотеза опровергнута»
• «Убедиться, что проверили все сегменты, сотрудники которых потенциально могут составлять 5% работающего населения»

Трекер не даёт остановиться на первом успехе в середине трека, даже если менеджер считает дальнейшее копание «не задачей трека».

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

• «МП получил результат на середине трека в сложных условиях. Обрадовался и хочет на этом остановиться. Копать глубже не хочет, потому что это «не задача трека»
• «Получилось, но что, если бы не получилось?»

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

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

• «Берёмся за область, которую не знаем и не понимаем -> прокрастинируем и откладываем задачи на потом, делаем более знакомые»
• «Скорость старта проверки гипотез, очень много рефлексии до целевых действий по проверке.»

Трекер требует не абсолютных цифр, а разницы: что даёт клиент с продуктом и без него, в каких сегментах дельта по выручке больше.

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

• «Дельта по выручке в разных сегментах клиентов Эльбы без РКО и с РКО»
• «как смэтчить юэ Эльбы с нашей, чтобы показать им выгоду в цифрах»

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

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

• «если нам хватает рынка, мы имеем доказательства спроса, у нас сходится модель юнит-экономики, мы понимаем требования к продукту — можно идти на инвест»
• «проверить сходимость юнита»

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

Когда. Команда делает продукт и не может продавать «воздух»; или тестирует спрос без внятного оффера.

• «выбрали гипотезу; сделали офер (который объясняет за счет чего связка problem solution эффективно работает) + сделали средство продажи (преза, лэндинг, демобот...); пошли тестировать спрос; собрать возражения; узнали главный лимитирующий фактор»
• «Делают продукт, не могут продавать «воздух»

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

Когда. Есть дашборды и гипотезы, но никто не видел, как человек проходит сценарий.

• «Нужно проводить юзабилити-тестирование»
• «сколько юзеров обломалось в сценарии?»

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

Когда. Наводящие вопросы не срабатывают, разговор буксует, есть соблазн просто сказать правильный ответ.

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

Трекер отдельно перечисляет, чего команда не умеет — оцифровывать проверку гипотез, работать по HADI, считать влияние фич на экономику, делать исследование рынка — и решает, что восполнять, а что обходить.

Когда. Старт работы с командой; менеджеру не хватает хард-скиллов, на восполнение которых нужно время.

• «Не знала, как оцифровывать проверку гипотез / Не знает как работать по HADI / Не знает, как повлияет разработка фич на экономику продукта / не умела делать исследование рынка»
• «Что делать, если у МП не хватает хард-скиллов, на восполнение которых нужно время?»

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

Когда. Спор о том, что проверять первым; риски разного масштаба смешаны в один список.

• «Влияние риска на цель / Вероятность риска / Итоговая стоимость»
• «бизнеса не будет = риск равен стоимости 1 цели (1x)»

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

Когда. Есть большая красивая гипотеза, но неясно, с какого края её проверять.

• «Стартовая гипотеза / Как выглядит гипотеза связки проблема / решение / Декомпозиция решения»
• «Не понятно как получить согласие организации на то, что третья сторона получит право распоряжаться данными»

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

Когда. Заказчик формулирует намерение словами; команда не понимает, что считать успехом этапа.

• «Цель бизнес-заказчика — какой эффект мы хотим получить от продукта / этапа»
• «метрика успеха (чем больше чего тем лучше)»

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

Когда. Задача сформулирована как деятельность («поработать над», «разобраться с»), а не как результат.

• «как мы поймем, что результат получен?»
• «как мы узнаем, что мы действительно помогли риэлтору»

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

Когда. Приоритет расставлен, но основание не проговорено; порядок держится на интуиции менеджера.

• «почему решил, что именно так нужно приоритезировать?»
• «Как выбрать над каким из вопросов работать?»

Трекер откатывает разговор на шаг назад, к основанию текущего рассуждения, когда чувствует, что вывод строится на непроверенной цифре или допущении.

Когда. Команда быстро проскочила основание и уже строит на нём следующий вывод.

• «А можно ещё на предыдущий шаг?»
• «А можно ещё на предыдущий шаг? Про рынок непотребления... т.е. наша цифра говорит нам сейчас, что рынка непотребления меньше, чем на самом деле.»

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

Когда. Проблемы перечислены, но не отранжированы и не связаны с решениями компании.

• «Топ проблем, которые ты нашла — А в чем сложность?»
• «*На какую из этих проблем тратится больше усилий? — Какой продукт у нас есть, который снимет проблему? — Как он эту проблему решает?»

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

Когда. Команда упёрлась и крутится в одной рамке; данные не дают нового.

• «Какие есть способы посмотреть на ситуацию под другим фокусом»
• «Как понять что ты бежишь в правильном направлении»

Трекер называет ограничением не рыночное незнание, а отсутствие роли: некому склеивать выводы из фактуры, принимать решения, ставить задачи и строить стратегию.

Когда. Фактура есть, работы идут, но никто не сводит их в решения; менеджер проекта фактически отсутствует.

• «Ограничение в команде: Отсутствие МП, как ответственного за склейку выводов на основании фактуры, принятие решений, постановку задач и работу над созданием стратегии.»
• «недостаток времени МП и команды на проверку гипотез»

Трекер рисует для команды дерево путей к цели, чтобы был виден выбор и его последствия, а не единственная линия.

Когда. Команда не видит альтернатив, стратегия существует только в голове фаундера.

• «Визуализировать для команды стратегию добегания до цели в виде дерева вариантов»

Трекер отдельно работает с составом и включённостью: собрать команду, включить её, продать ей идею, довести до общего понимания цели.

Когда. Проект есть, а команды нет; или люди формально назначены, но не включены.

• «собрать команду»
• «как включать команду»