Technical Product Manager: задачи и собеседование

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

От пользовательской проблемы к технической гипотезе

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

Рабочая формулировка связывает три слоя. Продуктовый слой описывает потерянное действие или доверие пользователя. Системный слой называет компонент, контракт и режим отказа. Измеримый слой задаёт baseline и признак улучшения. Вместо «ускорить API» получится: «снизить p95 времени подтверждения с 2,4 до 0,8 секунды без роста повторных заказов и ошибок оплаты». Такая цель оставляет инженерам пространство для вариантов и не подменяет проблему заранее выбранной реализацией.

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

Контракт API, данные и границы совместимости

API-контракт — это обещание о поведении, а не перечень endpoint и полей. Для команды-потребителя важны семантика ошибок, таймаут, лимит запросов, повторяемость операции, порядок событий и срок поддержки версии. Если команда добавила поле, но изменила смысл существующего статуса, формально совместимый JSON может сломать продукт. TPM добивается примеров для happy path и отказов, а также фиксирует, кто принимает решение о несовместимом изменении.

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

Изменение данных требует продуктового контроля даже при безошибочном SQL. Нужно определить, что увидит пользователь во время перехода, сохранятся ли история и права, как будут сосуществовать старая и новая версии приложения. Для рискованного переноса полезны dry run, сверка инвариантов, выборочная ручная проверка и план остановки. Rollback кода не возвращает автоматически преобразованные или удалённые значения, поэтому обратимость данных проектируют отдельно.

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

Discovery и thin slice без технических сюрпризов

Техническую осуществимость нельзя откладывать до конца пользовательских интервью, но и начинать discovery с многонедельного прототипа опасно. Ответ на вопрос «нужно ли проверять feasibility сейчас?» обычно звучит «да, параллельно и в объёме, достаточном для решения». Продуктовая команда проверяет desirability: существует ли проблема и меняет ли предложенный сценарий поведение. Инженеры проверяют критические ограничения: доступность данных, latency, безопасность, стоимость и интеграции. Результаты встречаются в одной точке выбора, а не в двух последовательных проектах.

Thin slice должен пройти через систему и дать обратную связь о ценности. Если большая функция включает интерфейс, новый сервис и аналитическое хранилище, реализация только сервиса не отвечает на продуктовый вопрос. Первый срез может обслуживать один частый сценарий, один сегмент и ограниченный объём данных, но он должен завершаться реальным пользовательским результатом. Ограничения среза записывают заранее, чтобы временное решение не превратилось в незаявленный стандарт платформы.

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

Технический долг попадает в roadmap не потому, что его неприятно видеть в коде. Нужна связь с последствием: увеличение lead time, частота инцидентов, стоимость инфраструктуры или невозможность запустить важный сценарий. Затем долг сравнивается с продуктовой работой по ожидаемому эффекту и срочности. Иногда правильным решением будет локальная защита и наблюдение, а не немедленный рефакторинг всей подсистемы.

SLO, наблюдаемость и безопасный rollout

SLO начинается с пользовательского индикатора. Для API оплаты доля успешных ответов сервера может быть недостаточной: операция может завершиться технически успешно, но позже потеряться у провайдера. Команда определяет SLI, окно измерения, целевой уровень и error budget. Например: 99,9% подтверждений оплаты завершаются не дольше пяти секунд за 28 дней. Такой контракт позволяет обсуждать, когда ускорять поставку, а когда останавливать релизы и инвестировать в надёжность.

Для нового endpoint недостаточно общего uptime. Операционные сигналы включают latency по операциям и перцентилям, error rate с классификацией причин, saturation ограничивающего ресурса и трассировку критического пути. Бизнес-метрика нужна для оценки эффекта функции, но не заменяет диагностику системы. На дашборде заранее отмечают нормальный диапазон, порог остановки и владельца реакции; иначе команда увидит графики, но не примет своевременное решение.

Критический workflow выпускают ступенчато. Сначала внутренняя когорта или небольшой процент трафика, затем расширение при стабильных guardrail-метриках. Feature flag помогает отключить новый путь, однако не откатывает необратимое изменение данных и не гарантирует совместимость старой версии. До старта команда проверяет kill switch, способ возврата, длительность наблюдения и ответственного за решение продолжить или остановиться.

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

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

Как собирать кейс для интервью

Сильный кейс удобно строить вокруг решения, которое могло пойти иначе. Сначала дайте контекст: пользовательский сценарий, масштаб и ограничение. Затем назовите альтернативы и критерии выбора. После этого отделите личный вклад от работы команды и покажите, какой факт изменил первоначальный план. Завершайте двумя группами результатов: целевое поведение пользователя и технические guardrails. Релиз в срок — это характеристика поставки, а не доказательство пользы.

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

Перед интервью сравните реальные требования в вакансиях для Technical Product Manager и зарплатные ориентиры роли. В других материалах блога можно подобрать соседние примеры по аналитике и управлению продуктом. Подготовьте два контрастных рассказа: безопасный запуск нового сценария и отказ от технически привлекательного решения. Для каждого назовите baseline, альтернативу, компромисс, свою зону ответственности и метрику после релиза. Это позволяет интервьюеру увидеть не словарь терминов, а способ принимать решения в сложной системе.