🧠 Навыки TPM: чему учиться и как прокачиваться
Если ты оказался в роли TPM — технического продуктового менеджера — или хочешь туда попасть, главный вопрос, который обычно возникает: а какие вообще навыки нужны?
Ответ, как это часто бывает: это зависит. От компании, индустрии, контекста, людей вокруг. Но если попытаться обобщить, то картина примерно такая.
Во-первых, TPM — это всегда человек на стыке. Он не обязательно пишет код, но должен понимать, как всё работает. Он не менеджер команды в классическом понимании, но всё равно организует совместную работу. Он не архитектор, но знает, какие технические решения возможны, а какие опасны.
Поэтому ключевые скиллы TPM — это:
Техническая эрудиция. Не обязательно глубокие знания по каждому направлению, но хорошее понимание базовых технологий, архитектурных подходов, API, CI/CD, безопасности и ограничений систем.
Продуктовое мышление. Умение сформулировать проблему, вычленить из хаоса реальные потребности, сформулировать гипотезу, найти метрику, по которой будем проверять, и обернуть всё это в фичу, которая решает нужную задачу.
Коммуникация и фасилитация. TPM часто становится переводчиком между бизнесом и инженерами, держит контекст и помогает договариваться, когда кажется, что договориться невозможно.
Системное мышление. Умение видеть не только фичу, но и весь поток изменений, влияние на другие компоненты, процессы доставки и эксплуатации, возможные деградации и сбои.
И самое главное — гибкость и здравый смысл. В реальности всегда будет неидеально: нет времени, нет ресурсов, нет документации. И в этой неопределённости TPM должен находить рабочий путь.
💡 И, пожалуй, тут важно сказать, почему я вообще начал так подробно копать в эту тему. Потому что со стороны системного анализа (а я сам прошёл этот путь) — роль TPM выглядит как очень органичное продолжение. Особенно если ты уже умеешь разбираться в архитектуре, разбираешь процессы, понимаешь, как работает команда — и хочешь не просто описывать, что должно быть сделано, а принимать участие в решении, почему и как это делать.
Дальше — больше. В следующем посте поговорим про типовые ошибки TPM на старте. Особенно если человек приходит из чисто продуктовой или, наоборот, чисто инженерной среды.
Если ты оказался в роли TPM — технического продуктового менеджера — или хочешь туда попасть, главный вопрос, который обычно возникает: а какие вообще навыки нужны?
Ответ, как это часто бывает: это зависит. От компании, индустрии, контекста, людей вокруг. Но если попытаться обобщить, то картина примерно такая.
Во-первых, TPM — это всегда человек на стыке. Он не обязательно пишет код, но должен понимать, как всё работает. Он не менеджер команды в классическом понимании, но всё равно организует совместную работу. Он не архитектор, но знает, какие технические решения возможны, а какие опасны.
Поэтому ключевые скиллы TPM — это:
Техническая эрудиция. Не обязательно глубокие знания по каждому направлению, но хорошее понимание базовых технологий, архитектурных подходов, API, CI/CD, безопасности и ограничений систем.
Продуктовое мышление. Умение сформулировать проблему, вычленить из хаоса реальные потребности, сформулировать гипотезу, найти метрику, по которой будем проверять, и обернуть всё это в фичу, которая решает нужную задачу.
Коммуникация и фасилитация. TPM часто становится переводчиком между бизнесом и инженерами, держит контекст и помогает договариваться, когда кажется, что договориться невозможно.
Системное мышление. Умение видеть не только фичу, но и весь поток изменений, влияние на другие компоненты, процессы доставки и эксплуатации, возможные деградации и сбои.
И самое главное — гибкость и здравый смысл. В реальности всегда будет неидеально: нет времени, нет ресурсов, нет документации. И в этой неопределённости TPM должен находить рабочий путь.
💡 И, пожалуй, тут важно сказать, почему я вообще начал так подробно копать в эту тему. Потому что со стороны системного анализа (а я сам прошёл этот путь) — роль TPM выглядит как очень органичное продолжение. Особенно если ты уже умеешь разбираться в архитектуре, разбираешь процессы, понимаешь, как работает команда — и хочешь не просто описывать, что должно быть сделано, а принимать участие в решении, почему и как это делать.
Дальше — больше. В следующем посте поговорим про типовые ошибки TPM на старте. Особенно если человек приходит из чисто продуктовой или, наоборот, чисто инженерной среды.
👍3
🧩 Ошибки начинающих TPM — и как их избежать
(из личных наблюдений и немного боли)
TPM — вроде бы «идеальная» позиция: ты понимаешь бизнес, шаришь в технике, умеешь говорить с командой и стейкхолдерами. Что может пойти не так?
Спойлер: многое.
За последние годы я видел (и сам проходил через) довольно типичные антипаттерны. Вот самые частые:
🔧 «Я пришёл из разработки — теперь буду всё контролировать»
И начинается: ревью каждой строки, диктовка архитектурных решений, участие во всех daily. В итоге ты превращаешься в микроменеджера, команда тебя боится, а никто не понимает, зачем вообще тут ещё и продакт.
📄 «Я пришёл из аналитики — сейчас всё опишу!»
50 страниц спецификаций, три версии диаграммы, обсуждения по каждой кнопке — и ноль понимания, когда и как это пойдёт в прод. TPM — это не архивариус, TPM — это драйвер. Надо не только понимать требования, но и доводить их до результата.
🧠 «Я слишком технический — про пользователей пусть продакт думает»
Так не работает. Ты всё ещё должен понимать, зачем мы вообще это делаем, для кого и какую боль решаем. Без этого ты не TPM, а просто техлид с расписанием встреч.
🚫 «Я больше не технический, я теперь про процессы»
Ошибка в другую сторону. TPM не обязан писать код, но и «не лезть в технику» — путь в никуда. Ты обязан понимать последствия решений, видеть узкие места и уметь перевести боль команды в действия.
💬 «Я веду 1000 обсуждений — но ни одно не довожу до конца»
Плохой TPM — это хаос. Хороший TPM — это glue, который сшивает всех и всё. Ты не просто созываешь митинг — ты обеспечиваешь, чтобы после него стало понятнее. Чтобы договорились. Чтобы пошли делать.
TPM — это не роль между. Это не медиатор. Это связующее и движущее. Glue & driver.
Если хочешь быть полезным — не прячься за бэкграунд. Используй его. Но иди дальше.
Так что если чувствуете, что роль СА вас ограничивает - велком в ТРМ!
Если было полезно — с радостью услышу в комментах и ваши грабли.
Уверен, их у всех было достаточно.
(из личных наблюдений и немного боли)
TPM — вроде бы «идеальная» позиция: ты понимаешь бизнес, шаришь в технике, умеешь говорить с командой и стейкхолдерами. Что может пойти не так?
Спойлер: многое.
За последние годы я видел (и сам проходил через) довольно типичные антипаттерны. Вот самые частые:
🔧 «Я пришёл из разработки — теперь буду всё контролировать»
И начинается: ревью каждой строки, диктовка архитектурных решений, участие во всех daily. В итоге ты превращаешься в микроменеджера, команда тебя боится, а никто не понимает, зачем вообще тут ещё и продакт.
📄 «Я пришёл из аналитики — сейчас всё опишу!»
50 страниц спецификаций, три версии диаграммы, обсуждения по каждой кнопке — и ноль понимания, когда и как это пойдёт в прод. TPM — это не архивариус, TPM — это драйвер. Надо не только понимать требования, но и доводить их до результата.
🧠 «Я слишком технический — про пользователей пусть продакт думает»
Так не работает. Ты всё ещё должен понимать, зачем мы вообще это делаем, для кого и какую боль решаем. Без этого ты не TPM, а просто техлид с расписанием встреч.
🚫 «Я больше не технический, я теперь про процессы»
Ошибка в другую сторону. TPM не обязан писать код, но и «не лезть в технику» — путь в никуда. Ты обязан понимать последствия решений, видеть узкие места и уметь перевести боль команды в действия.
💬 «Я веду 1000 обсуждений — но ни одно не довожу до конца»
Плохой TPM — это хаос. Хороший TPM — это glue, который сшивает всех и всё. Ты не просто созываешь митинг — ты обеспечиваешь, чтобы после него стало понятнее. Чтобы договорились. Чтобы пошли делать.
TPM — это не роль между. Это не медиатор. Это связующее и движущее. Glue & driver.
Если хочешь быть полезным — не прячься за бэкграунд. Используй его. Но иди дальше.
Так что если чувствуете, что роль СА вас ограничивает - велком в ТРМ!
Если было полезно — с радостью услышу в комментах и ваши грабли.
Уверен, их у всех было достаточно.
👍1
Всем привет! Сегодня буду общаться про лидерство и организацию работы команд. Приходите послушать и позадавать вопросы
🔥2👍1
Forwarded from Эмоции успеха | Елена Логачева
ПОНЕДЕЛЬНИК – 18:00 – ZOOM
Вход свободный после регистрации
→ https://logachevaeq.online/broadcast?utm_source=tg
За каждым успешным проектом стоит лидер, умеющий не просто управлять, но и виртуозно балансировать между крайностями.
Ведь микроменеджмент убивает инициативу и ответственность, а полное отсутствие рамок приводит к хаосу.
Истина, как всегда, посередине, и мы с моим гостем, Иннокентием Бодровым – Продуктовым лидером в Fintech и Edtech,
чётко сформулируем её уже завтра в 18:00 (МСК)!
Благодаря эфиру вы узнаете:
какие сигналы говорят о том, что вы зашли слишком далеко
что именно стоит за этим страхом, и как выстраивать процессы, чтобы не тащить всё на себе
«тащить всё» & «быть удобным»
сохраняем доверие команды, её фокус и результат без выгорания с помощью эффективных инструментов
ВСЕМ, кто хочет трансформировать свой карьерный трек из менеджера, контролирующего процессы, в сторону лидера, вдохновляющего на результат, рекомендую не пропустить этот эфир!
Вы достойны большего, чем формировать свой стиль руководства через опыт проб и ошибок 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
👀 Как выглядит хороший TPM в глазах разработчиков, а не менеджеров
Можно много рассказывать, что TPM — это мост между бизнесом и техникой, glue & driver, и всё вот это.
Но знаешь, когда реально понимаешь, что ты на своём месте?
Когда команда говорит такое:
💬
«Он не говорит мне, что делать. Он помогает понять — зачем»
Не спускает задачи сверху. Вместе разбирается, что важно, зачем это нужно, и как это повлияет на продукт. С такими людьми хочется думать, а не просто пилить тикеты.
💬
«Когда он рядом, фичи не тонут в болоте багов и непонятных требований»
Он следит, чтобы мы не увязли в неопределённости. Принял решение — довёл до продакшена. Знает, кто и где может помочь. Помнит про баги. Помнит, что деливери — это не просто слово.
💬
«Он не мешает, а помогает — потому что сам понимает, как всё устроено»
Знает, что фича — это не просто кнопка. Понимает, что фронт, бэк, API и деплой — это не магия. И поэтому не просит невозможного. Но и не верит в «ну, это сложно».
💬
«Он не делает вид, что всё знает — он спрашивает и слушает»
Нет позы, нет страха сказать «не понимаю». И поэтому с ним безопасно думать вслух, предлагать идеи, спорить. Потому что ты знаешь — он слышит.
Хороший TPM — не тот, кто «ведёт проект»,
а тот, кто делает команду сильнее.
Не кричит «делаем как я сказал», а говорит «давай разберёмся вместе».
И если честно — всё это ужасно похоже на задачи системного аналитика.
Только:
— уровень абстракции выше,
— зона ответственности шире,
— влияние на то, что и как делает команда — больше.
TPM — это как будто аналитик, который в какой-то момент понял:
«Я могу не только описывать, как будет работать,
но и помогать определить, что мы вообще собираемся делать — и зачем».
И да — если ты TPM и хочешь понять, как у тебя дела — не спрашивай менеджмент.
Спроси команду. Они точно знают.
Можно много рассказывать, что TPM — это мост между бизнесом и техникой, glue & driver, и всё вот это.
Но знаешь, когда реально понимаешь, что ты на своём месте?
Когда команда говорит такое:
💬
«Он не говорит мне, что делать. Он помогает понять — зачем»
Не спускает задачи сверху. Вместе разбирается, что важно, зачем это нужно, и как это повлияет на продукт. С такими людьми хочется думать, а не просто пилить тикеты.
💬
«Когда он рядом, фичи не тонут в болоте багов и непонятных требований»
Он следит, чтобы мы не увязли в неопределённости. Принял решение — довёл до продакшена. Знает, кто и где может помочь. Помнит про баги. Помнит, что деливери — это не просто слово.
💬
«Он не мешает, а помогает — потому что сам понимает, как всё устроено»
Знает, что фича — это не просто кнопка. Понимает, что фронт, бэк, API и деплой — это не магия. И поэтому не просит невозможного. Но и не верит в «ну, это сложно».
💬
«Он не делает вид, что всё знает — он спрашивает и слушает»
Нет позы, нет страха сказать «не понимаю». И поэтому с ним безопасно думать вслух, предлагать идеи, спорить. Потому что ты знаешь — он слышит.
Хороший TPM — не тот, кто «ведёт проект»,
а тот, кто делает команду сильнее.
Не кричит «делаем как я сказал», а говорит «давай разберёмся вместе».
И если честно — всё это ужасно похоже на задачи системного аналитика.
Только:
— уровень абстракции выше,
— зона ответственности шире,
— влияние на то, что и как делает команда — больше.
TPM — это как будто аналитик, который в какой-то момент понял:
«Я могу не только описывать, как будет работать,
но и помогать определить, что мы вообще собираемся делать — и зачем».
И да — если ты TPM и хочешь понять, как у тебя дела — не спрашивай менеджмент.
Спроси команду. Они точно знают.
🔥2💯1
🧭 TPM — зрелая версия продуктовой роли
Есть устойчивое ощущение, что TPM — это не стартовая точка.
Это не про «войти в IT» и не про «прокачать софт-скиллы».
Это следующая ступень. Иногда — естественная, иногда — выстраданная.
Ты мог быть кем угодно:
— аналитиком, который устал быть переводчиком между мирами,
— архитектором, которому надоело, что решения уходят «в стол»,
— разработчиком, который хочет видеть дальше, чем код,
— продактом, который понимает, что за красивым UI стоит реальная сложная система.
И в какой-то момент тебе становится тесно.
Тебе уже мало просто «фичи» или просто «метрики».
Ты хочешь видеть и держать всё:
🔁 как работает архитектура,
🏗 как устроена инфраструктура,
👥 как думает команда,
📦 и что на самом деле мешает запуску.
И вот тут TPM — не «ещё один продукт».
Он становится тем, кто:
🧠 понимает, как работает платформа — и зачем она такая,
🪛 разбирается в реальности: API, CI/CD, SLA, нагрузка, стабильность,
🤝 умеет собрать команду, фасилитировать 5 спорящих людей и вывести их к решению,
📦 и не забывает, что «всё это» делается не ради документа, а ради продукта.
Особенно, если ты работаешь на стыке платформ и пользовательских решений — когда нужно не просто «запилить фичу», а сделать из блоков инфраструктуры устойчивый продукт, который можно потом использовать десятки команд.
Это не всегда благодарная роль.
Ты в тени, на конфликтах, в середине между «хочу» и «можно».
Но именно ты удерживаешь систему от распада.
И знаешь, что самое интересное?
Чем дальше — тем больше понимаешь:
именно тут ты нужен. Не чтобы светиться. А чтобы всё работало.
Есть устойчивое ощущение, что TPM — это не стартовая точка.
Это не про «войти в IT» и не про «прокачать софт-скиллы».
Это следующая ступень. Иногда — естественная, иногда — выстраданная.
Ты мог быть кем угодно:
— аналитиком, который устал быть переводчиком между мирами,
— архитектором, которому надоело, что решения уходят «в стол»,
— разработчиком, который хочет видеть дальше, чем код,
— продактом, который понимает, что за красивым UI стоит реальная сложная система.
И в какой-то момент тебе становится тесно.
Тебе уже мало просто «фичи» или просто «метрики».
Ты хочешь видеть и держать всё:
🔁 как работает архитектура,
🏗 как устроена инфраструктура,
👥 как думает команда,
📦 и что на самом деле мешает запуску.
И вот тут TPM — не «ещё один продукт».
Он становится тем, кто:
🧠 понимает, как работает платформа — и зачем она такая,
🪛 разбирается в реальности: API, CI/CD, SLA, нагрузка, стабильность,
🤝 умеет собрать команду, фасилитировать 5 спорящих людей и вывести их к решению,
📦 и не забывает, что «всё это» делается не ради документа, а ради продукта.
Особенно, если ты работаешь на стыке платформ и пользовательских решений — когда нужно не просто «запилить фичу», а сделать из блоков инфраструктуры устойчивый продукт, который можно потом использовать десятки команд.
Это не всегда благодарная роль.
Ты в тени, на конфликтах, в середине между «хочу» и «можно».
Но именно ты удерживаешь систему от распада.
И знаешь, что самое интересное?
Чем дальше — тем больше понимаешь:
именно тут ты нужен. Не чтобы светиться. А чтобы всё работало.
⚡2
Помните, год назад я ходил к Маше на подкаст Радио аналитик?
А теперь Маша делает вебинар вместе с моими друзьями из Аналитического марафона. Маша классный спикер, рекомендую сегодня сходить ее послушать!
А теперь Маша делает вебинар вместе с моими друзьями из Аналитического марафона. Маша классный спикер, рекомендую сегодня сходить ее послушать!
👍1
Forwarded from AM_Chat
Системный анализ БЕЗ системного мышления
Вы замечали, как технически грамотные решения иногда создают новые сложности? Когда оптимизация одного процесса неожиданно усложняет работу других отделов. Когда идеально прописанные требования сталкиваются с человеческим фактором. Когда локальные улучшения незаметно подрывают общую эффективность.
17 июля в 18:00 (мск) приглашаем на откровенный разговор с Марией Серёгиной, опытным аналитиком и ведущим подкастов Про менеджмент и Радио «Аналитик»
❓Что разберём
- Рассмотрим, как системный анализ без системного мышления приводит к локальной оптимизации, а не к решению глобальных проблем
- Обсудим проблемы стратегического мышления и прогнозирования из-за фокуса исключительно на текущем состоянии системы
- Разберемся, почему отсутствие навыков системного мышления приводит к игнорированию человеческого фактора и влияния организационной динамики
❓Для кого: аналитики, руководители и все, кто участвует в изменениях бизнес-процессов
Формат: 20 минут живого разбора + 10 минут ответов на вопросы
Ссылка для подключения
Вы замечали, как технически грамотные решения иногда создают новые сложности? Когда оптимизация одного процесса неожиданно усложняет работу других отделов. Когда идеально прописанные требования сталкиваются с человеческим фактором. Когда локальные улучшения незаметно подрывают общую эффективность.
17 июля в 18:00 (мск) приглашаем на откровенный разговор с Марией Серёгиной, опытным аналитиком и ведущим подкастов Про менеджмент и Радио «Аналитик»
❓Что разберём
- Рассмотрим, как системный анализ без системного мышления приводит к локальной оптимизации, а не к решению глобальных проблем
- Обсудим проблемы стратегического мышления и прогнозирования из-за фокуса исключительно на текущем состоянии системы
- Разберемся, почему отсутствие навыков системного мышления приводит к игнорированию человеческого фактора и влияния организационной динамики
❓Для кого: аналитики, руководители и все, кто участвует в изменениях бизнес-процессов
Формат: 20 минут живого разбора + 10 минут ответов на вопросы
Ссылка для подключения
🔥5
🧱 Technical Product Manager как естественный шаг после системного анализа
Чем больше работаю, тем яснее понимаю: Technical Product Manager — это не просто «один из типов продакта». Это очень органичный, зрелый переход для тех, кто вырос из системного анализа.
Ты умеешь: — разбираться в архитектуре, — общаться со стейкхолдерами, — собирать сложные системы из разрозненных кусочков.
Но в какой-то момент этого становится мало. Хочется не только «описывать, что нужно сделать», а самому принимать решения, влиять на выбор, на приоритеты, на то, как будет работать команда и система.
💡 Именно это и даёт тебе роль TPM: больше ответственности, больше влияния — но всё ещё в техническом контексте, где твой опыт системного анализа играет в плюс.
Для многих это логичный переход: — слишком сложно сразу нырнуть в B2C-продукты, юзабилити-тесты и воронки, — но слишком тесно оставаться просто в рамках «описывания требований».
Я сам прошёл этот путь. И могу сказать честно: TPM — это та роль, в которой ты уже не просто задаёшь вопросы. Ты сам даёшь ответы.
Да, только сейчас я начинаю погружаться в более «маркетинговый» продакт-менеджмент — там, где потребитель, рынок, LTV и всё такое. Но всё, что было до этого, вся моя работа с внутренними платформами, с инфраструктурой, с API, CI/CD, архитектурой — это был классический technical product management. И это был идеальный фундамент.
Если вы сейчас в СА или архитектуре — не обязательно сразу ломать себя и бежать в UX и customer interviews. Есть промежуточная, но очень сильная роль. И она называется Technical Product Manager.
Чем больше работаю, тем яснее понимаю: Technical Product Manager — это не просто «один из типов продакта». Это очень органичный, зрелый переход для тех, кто вырос из системного анализа.
Ты умеешь: — разбираться в архитектуре, — общаться со стейкхолдерами, — собирать сложные системы из разрозненных кусочков.
Но в какой-то момент этого становится мало. Хочется не только «описывать, что нужно сделать», а самому принимать решения, влиять на выбор, на приоритеты, на то, как будет работать команда и система.
💡 Именно это и даёт тебе роль TPM: больше ответственности, больше влияния — но всё ещё в техническом контексте, где твой опыт системного анализа играет в плюс.
Для многих это логичный переход: — слишком сложно сразу нырнуть в B2C-продукты, юзабилити-тесты и воронки, — но слишком тесно оставаться просто в рамках «описывания требований».
Я сам прошёл этот путь. И могу сказать честно: TPM — это та роль, в которой ты уже не просто задаёшь вопросы. Ты сам даёшь ответы.
Да, только сейчас я начинаю погружаться в более «маркетинговый» продакт-менеджмент — там, где потребитель, рынок, LTV и всё такое. Но всё, что было до этого, вся моя работа с внутренними платформами, с инфраструктурой, с API, CI/CD, архитектурой — это был классический technical product management. И это был идеальный фундамент.
Если вы сейчас в СА или архитектуре — не обязательно сразу ломать себя и бежать в UX и customer interviews. Есть промежуточная, но очень сильная роль. И она называется Technical Product Manager.
👍2🔥2⚡1
Media is too big
VIEW IN TELEGRAM
Мы приготовили для вас два насыщенных дня докладов и мастер-классов с экспертами из Контура, Т-Банка, Точки, Positive Technologies и других компаний.
20 августа, онлайн — бесплатно по регистрации, но без смс. В программе:
21 августа, офлайн — встретимся в отеле AZIMUT в Санкт-Петербурге. Кроме докладов, участников ждет:
Будем говорить по душам, обмениваться опытом и улетно тусить на афтепати. Офлайн-день платный, доступна оплата за счет компании.
Программа и билеты по ссылке. До встречи!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Раньше я довольно скептически относился к видео и обсуждениям «про стратегию».
Казалось: ну вот, опять какие-то общие слова, глобальные планы, оторванные от земли.
А сейчас — я начал вытаскивать оттуда по-настоящему ценные смыслы.
Понимать, о чём говорят. Видеть связи с реальностью. Применять.
И это, мне кажется, очень важный маркер роста — когда ты переходишь на уровень, где тебе действительно интересна не только реализация, но и контекст.
Не только «как», но и «зачем» и «куда».
📺 Так что если вам кажется, что «стратегия — это скучно» — возможно, просто не время.
Но иногда — наоборот: самое время начать слушать таких ребят.
Очень часто именно это помогает расти. И в профессии, и в осознанности.
🧠 Про стратегию данных в финтехе
(по мотивам лампового митапа Fintech Data Day)
Данные — не про «нанять дата-сайентиста и внедрить LLM». Это про то, как у тебя устроен бизнес.
Про фундамент. Про то, что ты умеешь считать. Где у тебя метрики. Как ты принимаешь решения.
🔹 Стратегия данных — это не табличка. Это способ мышления.
В ПСБ строят пирамиду: снизу — хранилища, посередине — метрики, наверху — ML.
В Яндекс.Финтехе говорят: у нас всё сразу началось с верхнего уровня — GPT, автоматизация, рекомендации. Почему? Потому что у них данные в ДНК.
❗️Но вот в чём штука:
Крутая модель может быть вредной, если под ней нет инфраструктуры.
Дерево метрик бесполезно, если их обсчитывают вручную.
И никакая дата-стратегия не взлетит, если у компании вообще нет стратегии.
🧩 Стратегия — это не модный термин. Это склейка.
Смыслов, процессов, людей, направлений.
И она работает, только если ты сам способен держать уровень абстракции.
И не боишься думать чуть шире, чем твоя зона ответственности.
P.S. запись пока не выложили в паблик, но я подготовил для вас конспект
Казалось: ну вот, опять какие-то общие слова, глобальные планы, оторванные от земли.
А сейчас — я начал вытаскивать оттуда по-настоящему ценные смыслы.
Понимать, о чём говорят. Видеть связи с реальностью. Применять.
И это, мне кажется, очень важный маркер роста — когда ты переходишь на уровень, где тебе действительно интересна не только реализация, но и контекст.
Не только «как», но и «зачем» и «куда».
📺 Так что если вам кажется, что «стратегия — это скучно» — возможно, просто не время.
Но иногда — наоборот: самое время начать слушать таких ребят.
Очень часто именно это помогает расти. И в профессии, и в осознанности.
🧠 Про стратегию данных в финтехе
(по мотивам лампового митапа Fintech Data Day)
Данные — не про «нанять дата-сайентиста и внедрить LLM». Это про то, как у тебя устроен бизнес.
Про фундамент. Про то, что ты умеешь считать. Где у тебя метрики. Как ты принимаешь решения.
🔹 Стратегия данных — это не табличка. Это способ мышления.
В ПСБ строят пирамиду: снизу — хранилища, посередине — метрики, наверху — ML.
В Яндекс.Финтехе говорят: у нас всё сразу началось с верхнего уровня — GPT, автоматизация, рекомендации. Почему? Потому что у них данные в ДНК.
❗️Но вот в чём штука:
Крутая модель может быть вредной, если под ней нет инфраструктуры.
Дерево метрик бесполезно, если их обсчитывают вручную.
И никакая дата-стратегия не взлетит, если у компании вообще нет стратегии.
🧩 Стратегия — это не модный термин. Это склейка.
Смыслов, процессов, людей, направлений.
И она работает, только если ты сам способен держать уровень абстракции.
И не боишься думать чуть шире, чем твоя зона ответственности.
P.S. запись пока не выложили в паблик, но я подготовил для вас конспект
Telegraph
Митап «Успешная стратегия применения данных в финтехе»
Дата: 23 июня Формат: неформальная дискуссия в тёплой, «ламповой» атмосфере между хорошо знакомыми профессионалами. Повод — запуск конференции Fintech Data Day. Цель: разобраться, что такое стратегия данных, зачем она нужна финтеху и как она внедряется в…
🔥1
🎯 Всем привет! Меня зовут Иннокентий Бодров, и я — автор этого канала.
Здесь я пишу о системном и бизнес-анализе, продуктовом управлении, инженерии и разработке сложных ИТ-систем. Разбираю, как устроены проекты, команды, архитектуры, метрики, процессы — и как всё это влияет на людей, бизнес и конечный результат.
🤖 Почему я вообще об этом рассказываю? Потому что уже 17 лет работаю в IT — и за это время успел пройти путь от системного аналитика до технического продакт-менеджера в европейском финтехе.
Что было по дороге:
внедрение ERP, CRM, ECM и workflow-систем;
автоматизация в нефтегазе, телекоме, документообороте, образовании;
работа в МТС над каталогом продуктов;
оптимизация бэка (финансы, бухгалтерия, операции) в финтех-стартапе Stenn;
построение интеграционной и дата-платформы в европейском необанке для малого бизнеса;
и сейчас — развитие Data Intelligence-продуктов в области KYC, KYB и транзакционного мониторинга.
⚙️ Мой фокус — это техническое продуктовое управление, системный подход, работа на стыке платформ, данных и команд.
🧠 Чем могу быть полезен:
— если вы аналитик или продакт и хотите переехать в Европу — расскажу, как выглядят резюме, какие навыки востребованы, что реально работает;
— если вы развиваетесь в технический продукт — поделюсь опытом, как перейти из аналитики, разработки, архитектуры;
— если вы строите команду — помогу с подбором, выстраиванием процессов, ревью аналитиков, обучением.
📚 Более 4 лет я руководил курсом по системному анализу на Otus, провожу менторинг, обучение команд и индивидуальных специалистов. И да, этот канал — часть моей миссии: делиться опытом, честно, с юмором и по существу.
Если вдруг вам откликнулось — пишите в личку, всегда рад пообщаться.
Здесь я пишу о системном и бизнес-анализе, продуктовом управлении, инженерии и разработке сложных ИТ-систем. Разбираю, как устроены проекты, команды, архитектуры, метрики, процессы — и как всё это влияет на людей, бизнес и конечный результат.
🤖 Почему я вообще об этом рассказываю? Потому что уже 17 лет работаю в IT — и за это время успел пройти путь от системного аналитика до технического продакт-менеджера в европейском финтехе.
Что было по дороге:
внедрение ERP, CRM, ECM и workflow-систем;
автоматизация в нефтегазе, телекоме, документообороте, образовании;
работа в МТС над каталогом продуктов;
оптимизация бэка (финансы, бухгалтерия, операции) в финтех-стартапе Stenn;
построение интеграционной и дата-платформы в европейском необанке для малого бизнеса;
и сейчас — развитие Data Intelligence-продуктов в области KYC, KYB и транзакционного мониторинга.
⚙️ Мой фокус — это техническое продуктовое управление, системный подход, работа на стыке платформ, данных и команд.
🧠 Чем могу быть полезен:
— если вы аналитик или продакт и хотите переехать в Европу — расскажу, как выглядят резюме, какие навыки востребованы, что реально работает;
— если вы развиваетесь в технический продукт — поделюсь опытом, как перейти из аналитики, разработки, архитектуры;
— если вы строите команду — помогу с подбором, выстраиванием процессов, ревью аналитиков, обучением.
📚 Более 4 лет я руководил курсом по системному анализу на Otus, провожу менторинг, обучение команд и индивидуальных специалистов. И да, этот канал — часть моей миссии: делиться опытом, честно, с юмором и по существу.
Если вдруг вам откликнулось — пишите в личку, всегда рад пообщаться.
🔥7⚡2👎1
🎤 Всем привет! Как вы уже, наверное, заметили, я глубоко закопался в тему технического продуктового менеджмента. Посты — это, конечно, здорово, но иногда важно рассказать всё не только буквами, но и словами через рот.
📅 2 августа я буду выступать на конференции NextWay с докладом про роль Technical Product Manager: чем она отличается от классического продакта, почему этот путь так органично продолжает карьеру системного аналитика и какие скиллы действительно важны в этой роли.
Если вам интересно разобраться, зачем компании TPM, чем он помогает продукту и как выглядит эта позиция глазами разработчиков, а не только менеджмента — приходите. Будет живо, практично и с разбором реальных кейсов.
Ссылка на регистрацию будет чуть ниже. Буду рад видеть вас и ваши вопросы на эфире!
📅 2 августа я буду выступать на конференции NextWay с докладом про роль Technical Product Manager: чем она отличается от классического продакта, почему этот путь так органично продолжает карьеру системного аналитика и какие скиллы действительно важны в этой роли.
Если вам интересно разобраться, зачем компании TPM, чем он помогает продукту и как выглядит эта позиция глазами разработчиков, а не только менеджмента — приходите. Будет живо, практично и с разбором реальных кейсов.
Ссылка на регистрацию будет чуть ниже. Буду рад видеть вас и ваши вопросы на эфире!
🔥2
Forwarded from Andrey
Будущее наступило, что дальше?
Приглашаем системных и бизнес-аналитиков на летнюю NextConf, чтобы обсудить изменения рынка, влияние AI на индустрию, актуальные проблемы и новые вызовы.
Мы подготовили три потока докладов и воркшопов:
Архитектура и технологии
Реальные кейсы, проектирование и интеграция систем, стриминговые платформы, инфраструктура - все, что мы любим.
AI в работе и жизни
Превращаем AI в коллегу и партнера: от промптинга для рабочих и личных задач, до технических / продуктовых исследований и разработки прототипов.
Карьера и развитие
Карьерные стратегии в новых реалиях, коммуникации с коллегами и руководством, как спастись от выгорания и найти свое место в пищевой цепочке.
Будем делиться опытом, идеями, наболевшим в уютной безопасной обстановке.
📆 2 августа, онлайн
🔗 Подробности и регистрация на сайте
Приглашаем системных и бизнес-аналитиков на летнюю NextConf, чтобы обсудить изменения рынка, влияние AI на индустрию, актуальные проблемы и новые вызовы.
Мы подготовили три потока докладов и воркшопов:
Архитектура и технологии
Реальные кейсы, проектирование и интеграция систем, стриминговые платформы, инфраструктура - все, что мы любим.
AI в работе и жизни
Превращаем AI в коллегу и партнера: от промптинга для рабочих и личных задач, до технических / продуктовых исследований и разработки прототипов.
Карьера и развитие
Карьерные стратегии в новых реалиях, коммуникации с коллегами и руководством, как спастись от выгорания и найти свое место в пищевой цепочке.
Будем делиться опытом, идеями, наболевшим в уютной безопасной обстановке.
📆 2 августа, онлайн
🔗 Подробности и регистрация на сайте
🔥3👍1
🚀 Я дозрел! С августа запускаю свои курсы!
Я долго думал, как сделать обучение максимально полезным и практичным — и понял, что один большой фундаментальный курс не решает задачу. Поэтому формат будет другой: серия мини-курсов, которые можно проходить по отдельности, а вместе они сложатся в единую систему.
💡 В чем фишка?
— Короткие видео (до 5 минут) на каждый день — формируем привычку и держим темп.
— Небольшие задания после блоков, которые собираются в одну домашку.
— Когортный формат: после сдачи домашек живой вебинар с разбором типичных ошибок.
— Возможность индивидуальной обратной связи на расширенных тарифах.
🎯 Темы первых курсов:
— Как работать с бизнес-проблемами и быстро погружаться в новую предметную область (в том числе с помощью LLM).
— Связка архитектуры и нефункциональных требований: что на что влияет и почему.
— User Stories и Use Cases: когда, как и зачем.
— Архитектура информационной модели и проектирование сервисов (монолит vs микросервисы).
— Работа с командой разработки и тестировщиками.
— Документация, которая реально помогает, а не пылится.
— Технический Product Management: как системному аналитику развивать TPM-навыки.
— Domain-Driven Design и Event Storming для проектирования предметной области.
— Глубинные интервью: выявление потребностей пользователей и стейкхолдеров.
— Аналитика продукта: как понимать, что реально происходит.
— SQL и базы данных: от выбора до правильной интеграции.
📅 Первый курс стартует в середине августа. Остальные — с разницей в 1–2 недели, в зависимости от спроса.
💬 Что дальше?
В ближайшие дни открою предзапись. Чем раньше вы запишетесь (и особенно если попадете в первый поток) — тем больше бонусов и ниже цена. Первые группы будут максимально гибкими: много обратной связи, возможность влиять на материалы, адаптация под реальные запросы.
👉 В комментариях напишите, какой из курсов вам интереснее всего. Это поможет определить, с чего начнем.
Я долго думал, как сделать обучение максимально полезным и практичным — и понял, что один большой фундаментальный курс не решает задачу. Поэтому формат будет другой: серия мини-курсов, которые можно проходить по отдельности, а вместе они сложатся в единую систему.
💡 В чем фишка?
— Короткие видео (до 5 минут) на каждый день — формируем привычку и держим темп.
— Небольшие задания после блоков, которые собираются в одну домашку.
— Когортный формат: после сдачи домашек живой вебинар с разбором типичных ошибок.
— Возможность индивидуальной обратной связи на расширенных тарифах.
🎯 Темы первых курсов:
— Как работать с бизнес-проблемами и быстро погружаться в новую предметную область (в том числе с помощью LLM).
— Связка архитектуры и нефункциональных требований: что на что влияет и почему.
— User Stories и Use Cases: когда, как и зачем.
— Архитектура информационной модели и проектирование сервисов (монолит vs микросервисы).
— Работа с командой разработки и тестировщиками.
— Документация, которая реально помогает, а не пылится.
— Технический Product Management: как системному аналитику развивать TPM-навыки.
— Domain-Driven Design и Event Storming для проектирования предметной области.
— Глубинные интервью: выявление потребностей пользователей и стейкхолдеров.
— Аналитика продукта: как понимать, что реально происходит.
— SQL и базы данных: от выбора до правильной интеграции.
📅 Первый курс стартует в середине августа. Остальные — с разницей в 1–2 недели, в зависимости от спроса.
💬 Что дальше?
В ближайшие дни открою предзапись. Чем раньше вы запишетесь (и особенно если попадете в первый поток) — тем больше бонусов и ниже цена. Первые группы будут максимально гибкими: много обратной связи, возможность влиять на материалы, адаптация под реальные запросы.
👉 В комментариях напишите, какой из курсов вам интереснее всего. Это поможет определить, с чего начнем.
🔥10🤯2