🔥 Лето, которое мы заслужили
В Лиссабоне уже который день подряд стабильно под 40 градусов. Мозг плавится.
Все благие намерения написать пост, поработать с материалами, подумать про курс — разбиваются об одно простое желание: пойти в душ.
И вот ты сходил. И у тебя есть… минут 15. Иногда 20. Пока мозг снова не закипел.
Работать в таком режиме, скажем честно, мягко говоря, не вдохновляет.
Особенно когда и на пляж не вырваться — ребенок приболел, так что океан пока под запретом.
Кондиционеры — единственное спасение. Ну и, может, стакан воды с льдом и мятой. Или без мяты. Или просто лед.
В общем, Лиссабон сейчас больше похож на тостер, чем на европейскую столицу.
А у вас как лето началось? Есть свои погодные испытания или другие первые летние боли?
Рассказывайте. Мне хотя бы почитать будет не так жарко 😅
В Лиссабоне уже который день подряд стабильно под 40 градусов. Мозг плавится.
Все благие намерения написать пост, поработать с материалами, подумать про курс — разбиваются об одно простое желание: пойти в душ.
И вот ты сходил. И у тебя есть… минут 15. Иногда 20. Пока мозг снова не закипел.
Работать в таком режиме, скажем честно, мягко говоря, не вдохновляет.
Особенно когда и на пляж не вырваться — ребенок приболел, так что океан пока под запретом.
Кондиционеры — единственное спасение. Ну и, может, стакан воды с льдом и мятой. Или без мяты. Или просто лед.
В общем, Лиссабон сейчас больше похож на тостер, чем на европейскую столицу.
А у вас как лето началось? Есть свои погодные испытания или другие первые летние боли?
Рассказывайте. Мне хотя бы почитать будет не так жарко 😅
🤯5😱1
Всем привет! Дружеская интеграция. Как вы знаете, я сейчас в активных поисках работы (про это как-нибудь сделаю отдельный пост) и все больше убеждаюсь, что: Проходить собеседования — это навык. Навык, который надо качать, который устаревает и атрофируется, который дает буст при трудоустройстве.
Если в 2025-м вы хотите
— меньше волноваться на собесах,
— эффективнее отвечать на вопросы и грамотно задавать их,
читайте канал про собеседования в IT, где собран опыт кандидата.
——————
🔹Булат ходит на собесы из азарта и интереса и пишет, какие были этапы, какие задавали вопросы.
Раз — собес в известный темно-розовый бренд, задачка в комментариях
Два — собес, про который долго не хотел писать
Три — собес, после которого был отказ
—————
✅Подписывайтесь, чтобы быть готовыми к собеседованию, а в случае отказа — сохранять здравую самооценку.
https://t.iss.one/tryoutonadancefloor
Если в 2025-м вы хотите
— меньше волноваться на собесах,
— эффективнее отвечать на вопросы и грамотно задавать их,
читайте канал про собеседования в IT, где собран опыт кандидата.
——————
🔹Булат ходит на собесы из азарта и интереса и пишет, какие были этапы, какие задавали вопросы.
Раз — собес в известный темно-розовый бренд, задачка в комментариях
Два — собес, про который долго не хотел писать
Три — собес, после которого был отказ
—————
✅Подписывайтесь, чтобы быть готовыми к собеседованию, а в случае отказа — сохранять здравую самооценку.
https://t.iss.one/tryoutonadancefloor
👍4👎3🔥2
🛠 Продолжаю давно обещанную тему про технический продуктовый менеджмент.
Этот пост — больше подготовка. Давайте сначала разберемся: а откуда вообще люди попадают в продуктовку?
🎓 Спойлер: крайне редко кто-то становится продуктом "с нуля". Обычно за плечами уже есть какой-то опыт — и чаще всего он идет из одной из трёх сторон:
1️⃣ Из бизнеса — человек работал в операциях, продажах, поддержке, хорошо понимает, как всё устроено, и начинает делать продукты, которые закрывают реальные боли.
2️⃣ Из маркетинга — с пониманием пользователей, воронок, поведения, каналов. Отсюда часто приходят в роль product marketing manager’ов, а потом и дальше в продукт.
3️⃣ Из технологий — разработчики, аналитики, архитекторы, дата-инженеры. Те, кто понимает, как работают "кишки", и знают, что такое API, фреймворки, DevOps, и как идет выкатка в прод.
В Finom у нас, например, было довольно много ребят из первых двух направлений. И, как ни странно, даже у тех, кто пришёл из разработки, могут быть гэпы — не в коде, а в техническом "ландшафте": как работает деплой, как связаны команды, почему релиз занимает не 2 дня, а 2 недели.
🎯 Вот тут и появляется роль технического продакт-менеджера — человека, который понимает не только продукт и его ценность, но и то, как этот продукт вообще живёт, дышит, выкатывается и мониторится.
Такой TPM может:
-глубже говорить с разработкой (и быть услышанным),
-понимать, где реальный bottleneck,
-управлять совместными релизами,
-разруливать стыки между командами,
-и при этом — точно так же работать с метриками, гипотезами и пользователями.
⚖️ При этом он, может быть, чуть меньше вовлечён в маркетинг, но сильно лучше понимает инфраструктуру, совместимость, архитектуру, CI\CD и всё вот это.
В следующем посте поговорим: а как туда попасть? Особенно если ты сейчас аналитик или архитектор.
Stay tuned.
Этот пост — больше подготовка. Давайте сначала разберемся: а откуда вообще люди попадают в продуктовку?
🎓 Спойлер: крайне редко кто-то становится продуктом "с нуля". Обычно за плечами уже есть какой-то опыт — и чаще всего он идет из одной из трёх сторон:
1️⃣ Из бизнеса — человек работал в операциях, продажах, поддержке, хорошо понимает, как всё устроено, и начинает делать продукты, которые закрывают реальные боли.
2️⃣ Из маркетинга — с пониманием пользователей, воронок, поведения, каналов. Отсюда часто приходят в роль product marketing manager’ов, а потом и дальше в продукт.
3️⃣ Из технологий — разработчики, аналитики, архитекторы, дата-инженеры. Те, кто понимает, как работают "кишки", и знают, что такое API, фреймворки, DevOps, и как идет выкатка в прод.
В Finom у нас, например, было довольно много ребят из первых двух направлений. И, как ни странно, даже у тех, кто пришёл из разработки, могут быть гэпы — не в коде, а в техническом "ландшафте": как работает деплой, как связаны команды, почему релиз занимает не 2 дня, а 2 недели.
🎯 Вот тут и появляется роль технического продакт-менеджера — человека, который понимает не только продукт и его ценность, но и то, как этот продукт вообще живёт, дышит, выкатывается и мониторится.
Такой TPM может:
-глубже говорить с разработкой (и быть услышанным),
-понимать, где реальный bottleneck,
-управлять совместными релизами,
-разруливать стыки между командами,
-и при этом — точно так же работать с метриками, гипотезами и пользователями.
⚖️ При этом он, может быть, чуть меньше вовлечён в маркетинг, но сильно лучше понимает инфраструктуру, совместимость, архитектуру, CI\CD и всё вот это.
В следующем посте поговорим: а как туда попасть? Особенно если ты сейчас аналитик или архитектор.
Stay tuned.
🔥7
Всем привет! Моя бывшая коллега Марина опубликовала гайд по работе с LinkedIn.
Посмотрел, несмотря на то, что старался вылизать свой LinkedIn в процессе поиска работы - тоже забрал себе несколько пунктов.
Ну и в целом - Марина очень сильный продакт, я реально горжусь, что был ее бадди, когда она пришла в Finom и помог влиться в работу.
Она пишет много про продуктовые темы и около них, так что велком к ней на канал.
Посмотрел, несмотря на то, что старался вылизать свой LinkedIn в процессе поиска работы - тоже забрал себе несколько пунктов.
Ну и в целом - Марина очень сильный продакт, я реально горжусь, что был ее бадди, когда она пришла в Finom и помог влиться в работу.
Она пишет много про продуктовые темы и около них, так что велком к ней на канал.
👍3
Forwarded from Продакт в здании
Гайд по LinkedIn.pdf
1.4 MB
Бесплатный гайд по LinkedIn
Раньше я очень недооценивала LinkedIn. Когда-то я скопировала данные из резюме в профиль, добавила коллег и ребят с универа и изредка отправляла инвайты людям из предложки. В то время я была Senior, а затем Lead frontend разработчиком и в целом, этого хватало. Мне писали HR рекрутёры с предложениями о работе, иногда я соглашалась на собесы - расслабленная жизнь айтишника во времена расцвета спроса на разработчиков.
А потом я перешла в продакт менеджмент и сообщения от рекрутёров исчезли. Даже через несколько лет в профессии - ни одного входящего приглашения. Я думала, что дело в специальности и продакты просто менее востребованы, чем программисты. И что тут для поиска работы нужно приложить гораздо больше усилий.
Но недавно я начала целенаправленно развивать LinkedIn. Регулярно добавлять контакты, причём по стратегии - людей из международных компаний, топов, из нужных сфер. Причесала профиль, начала выкладывать посты. И внезапно входящие снова начали появляться, несмотря на кризис айти найма, о котором везде пишут. И сейчас мне каждую неделю прилетают предложения от международных компаний, с хорошими условиями.
Теперь я вижу, насколько это мощный инструмент, и планирую активно развивать его дальше. Поэтому активно изучаю материалы по площадке и решила собрать всё изученное в Гайд по профессиональному росту с помощью LinkedIn. Собрала в нём все знания, лайфхаки и собственный опыт.
🔥Что внутри гайда?
1. Как работает LinkedIn: для чего нужна эта площадка, логика сети и алгоритмов
2. Как оформить профиль: best practices сильных страниц, наполнения и оформления всех разделов, SEO страницы в поисковых алгоритмах
3. Как растить сеть контактов: тактика набора не просто рандомных контактов, а полезных связей
4. Как вести LinkedIn для прокачивания профессионального личного бренда: советы для органического роста на площадке
5. Как искать работу через LinkedIn: фишки поиска и лайфхаки для откликов, после которых приглашают на интервью
6. План прокачки LinkedIn за 7 дней: простые и конкретные шаги для развития соцсети
Поблагодарить меня за создание гайда можно реакциями и комментариями❤️
Раньше я очень недооценивала LinkedIn. Когда-то я скопировала данные из резюме в профиль, добавила коллег и ребят с универа и изредка отправляла инвайты людям из предложки. В то время я была Senior, а затем Lead frontend разработчиком и в целом, этого хватало. Мне писали HR рекрутёры с предложениями о работе, иногда я соглашалась на собесы - расслабленная жизнь айтишника во времена расцвета спроса на разработчиков.
А потом я перешла в продакт менеджмент и сообщения от рекрутёров исчезли. Даже через несколько лет в профессии - ни одного входящего приглашения. Я думала, что дело в специальности и продакты просто менее востребованы, чем программисты. И что тут для поиска работы нужно приложить гораздо больше усилий.
Но недавно я начала целенаправленно развивать LinkedIn. Регулярно добавлять контакты, причём по стратегии - людей из международных компаний, топов, из нужных сфер. Причесала профиль, начала выкладывать посты. И внезапно входящие снова начали появляться, несмотря на кризис айти найма, о котором везде пишут. И сейчас мне каждую неделю прилетают предложения от международных компаний, с хорошими условиями.
Теперь я вижу, насколько это мощный инструмент, и планирую активно развивать его дальше. Поэтому активно изучаю материалы по площадке и решила собрать всё изученное в Гайд по профессиональному росту с помощью LinkedIn. Собрала в нём все знания, лайфхаки и собственный опыт.
🔥Что внутри гайда?
1. Как работает LinkedIn: для чего нужна эта площадка, логика сети и алгоритмов
2. Как оформить профиль: best practices сильных страниц, наполнения и оформления всех разделов, SEO страницы в поисковых алгоритмах
3. Как растить сеть контактов: тактика набора не просто рандомных контактов, а полезных связей
4. Как вести LinkedIn для прокачивания профессионального личного бренда: советы для органического роста на площадке
5. Как искать работу через LinkedIn: фишки поиска и лайфхаки для откликов, после которых приглашают на интервью
6. План прокачки LinkedIn за 7 дней: простые и конкретные шаги для развития соцсети
Поблагодарить меня за создание гайда можно реакциями и комментариями❤️
🔥4👍2
В основе любого сильного проекта стоит сильный специалист.
В IT-мире сложно представить востребованного специалиста, который не разбирается в том, как работают: архитектура, API, базы данных, алгоритмы.
Без этого никуда.
И не страшно, если вы пока плохо разбираетесь в каких-то современных системах. Хуже, если продолжаете игнорировать свои пробелы в hard skills.
Начните с бесплатных уроков по архитектуре и интеграциям:
▪️мощный инструмент — SOAP UI
▪️подробное описание процесса загрузки сайта
▪️модель TCP/IP и устройства
▪️XML — это вам не ХSD
Присоединяйтесь в чат-боте по ссылке:
👇
@studyit_help_bot
🚀 Скидка на полный курс от канала — 1 000 ₽ на Stepik по промокоду SPHERI до конца июля.
В IT-мире сложно представить востребованного специалиста, который не разбирается в том, как работают: архитектура, API, базы данных, алгоритмы.
Без этого никуда.
И не страшно, если вы пока плохо разбираетесь в каких-то современных системах. Хуже, если продолжаете игнорировать свои пробелы в hard skills.
Начните с бесплатных уроков по архитектуре и интеграциям:
▪️мощный инструмент — SOAP UI
▪️подробное описание процесса загрузки сайта
▪️модель TCP/IP и устройства
▪️XML — это вам не ХSD
Присоединяйтесь в чат-боте по ссылке:
👇
@studyit_help_bot
🚀 Скидка на полный курс от канала — 1 000 ₽ на Stepik по промокоду SPHERI до конца июля.
👍4👎2🔥1
🔧 Чем на самом деле занимается TPM?
Окей, разобрались, как люди становятся TPM. А теперь — вопрос не менее интересный: чем вообще занимается Technical Product Manager в реальной жизни?
Если коротко — всем, чем не заняты другие, но что всё равно нужно для того, чтобы продукт заработал.
Но если чуть подробнее — вот мой взгляд:
🧩 TPM — это связка между продуктом, техникой и здравым смыслом.
Он понимает, как всё устроено внутри. Может объяснить, почему «просто подключить нового провайдера» — это 3 месяца работы и миграция схемы данных. И при этом не скатывается в «ну, это невозможно», а помогает найти реалистичный путь.
📦 TPM занимается "внутренней стороной" продукта.
Платформенные штуки, интеграции, API, data pipeline, внутренние сервисы, инфраструктура, процессы доставки фич — всё, что не видно конечному пользователю, но без чего ничего не поедет.
🧠 TPM — это продуктовый инженер.
Он не пишет код, но отлично понимает, что там происходит. Он не продакт-маркетинг менеджер, но знает, как работает onboarding, авторизация, документация, SDK. Он может читать backlog и видеть, где начинается боль.
🧮 TPM разбирается в приоритетах и трейд-оффах.
Вот тут начинается настоящая магия: у тебя есть ограничения на людей, время и систему. Надо выбрать, что сделать, в какой последовательности, с какими долгами, чтобы это не взорвалось. TPM — тот, кто принимает эти решения или помогает принять их техкоманде и бизнесу вместе.
🎯 TPM — это glue role.
Он говорит на нескольких языках: с разработкой — на языке latency, SLA и циклов деплоя, с бизнесом — про «как это поможет клиенту». И умеет переводить с одного на другой.
📉 И да, TPM часто берёт на себя "скучные" куски.
Согласование требований, управление документацией, объяснение архитектуры другим командам, таблицы совместимости, миграционные планы. Всё то, что помогает команде работать без хаоса.
⚠️ Что TPM не делает (в идеале):
— не превращается в project-менеджера по задачкам;
— не пишет код сам (хотя может помочь разобраться);
— не теряет пользовательскую перспективу, даже если фича касается внутренней шины сообщений.
В следующем посте — поговорим, как роль TPM отличается в разных странах и типах компаний.
А вы видели у себя в компании хороших TPM? Или, может, сами такой? Расскажите, чем занимаетесь — сравним опыты.
Окей, разобрались, как люди становятся TPM. А теперь — вопрос не менее интересный: чем вообще занимается Technical Product Manager в реальной жизни?
Если коротко — всем, чем не заняты другие, но что всё равно нужно для того, чтобы продукт заработал.
Но если чуть подробнее — вот мой взгляд:
🧩 TPM — это связка между продуктом, техникой и здравым смыслом.
Он понимает, как всё устроено внутри. Может объяснить, почему «просто подключить нового провайдера» — это 3 месяца работы и миграция схемы данных. И при этом не скатывается в «ну, это невозможно», а помогает найти реалистичный путь.
📦 TPM занимается "внутренней стороной" продукта.
Платформенные штуки, интеграции, API, data pipeline, внутренние сервисы, инфраструктура, процессы доставки фич — всё, что не видно конечному пользователю, но без чего ничего не поедет.
🧠 TPM — это продуктовый инженер.
Он не пишет код, но отлично понимает, что там происходит. Он не продакт-маркетинг менеджер, но знает, как работает onboarding, авторизация, документация, SDK. Он может читать backlog и видеть, где начинается боль.
🧮 TPM разбирается в приоритетах и трейд-оффах.
Вот тут начинается настоящая магия: у тебя есть ограничения на людей, время и систему. Надо выбрать, что сделать, в какой последовательности, с какими долгами, чтобы это не взорвалось. TPM — тот, кто принимает эти решения или помогает принять их техкоманде и бизнесу вместе.
🎯 TPM — это glue role.
Он говорит на нескольких языках: с разработкой — на языке latency, SLA и циклов деплоя, с бизнесом — про «как это поможет клиенту». И умеет переводить с одного на другой.
📉 И да, TPM часто берёт на себя "скучные" куски.
Согласование требований, управление документацией, объяснение архитектуры другим командам, таблицы совместимости, миграционные планы. Всё то, что помогает команде работать без хаоса.
⚠️ Что TPM не делает (в идеале):
— не превращается в project-менеджера по задачкам;
— не пишет код сам (хотя может помочь разобраться);
— не теряет пользовательскую перспективу, даже если фича касается внутренней шины сообщений.
В следующем посте — поговорим, как роль TPM отличается в разных странах и типах компаний.
А вы видели у себя в компании хороших TPM? Или, может, сами такой? Расскажите, чем занимаетесь — сравним опыты.
👍2🔥2
🌍 TPM в США, Европе, России: где ты работаешь, там ты и TPM
Продолжаем наш сериал про Technical Product Manager’ов. Сегодня поговорим про то, как TPM-роль устроена в разных странах и типах компаний.
Спойлер: везде по-разному. И это ок.
🗽 В Штатах TPM — это инженер с фокусом на продукт.
Сильно завязано на технический бэкграунд. Часто бывшие разработчики. Часто в FAANG-подобных компаниях: Meta, Google, Amazon и прочих. Там TPM — это glue role между продактом и инженерами. Он отвечает за архитектуру решений, roadmap фичей, stakeholder-менеджмент — но руками не кодит.
📈 В Европе TPM — это чуть ближе к платформенным продактам.
В большинстве европейских компаний TPM скорее про инфраструктурные решения, архитектурные вызовы и согласование кросс-командной работы. Может быть продактом внутренних платформ, API, data layer, IAM и прочих внутренних штук. Очень часто совмещает роли системного аналитика, платформенного продакта и деливери менеджера в одном лице.
🌍 В России (и странах постсовка) TPM — это почти всегда либо:
— продакт, у которого просто технарский бэкграунд (и его за это очень уважают);
— системный аналитик, который тащит на себе ещё и продуктовые куски, потому что “ну а кто ещё?”.
А иногда — разработчик, который стал писать задачи в джиру и стал продактом.
📊 В стартапах TPM — это "всё и сразу".
Отвечает за то, чтобы фича заработала и попала в релиз. Пишет требования, проверяет архитектуру, договаривается с соседними командами, деплоит с командой ночью, а потом ещё пишет документацию. И если повезёт — поговорит с пользователями.
🏢 В корпорациях TPM — это менеджер зависимостей.
Если твоя команда делает кусок, который зависит от 8 других команд, и ты не хочешь превратиться в хаос — вот тут нужен TPM. Он следит за API, схемами, контрактами, SLA, и отвечает, чтобы всё приехало вовремя и не взорвалось.
💡 Общая идея — TPM закрывает дырку между продуктом и инженерией.
Где она будет — зависит от зрелости компании, состава команды, и просто от культуры. Где-то TPM будет про архитектуру, где-то — про delivery, где-то — про приоритезацию внутреннего техдолга, где-то — про API как продукт.
В следующем посте — разберём, какие скиллы нужны TPM и как их качать.
А у вас TPM чем занимается? Или, может, ваша команда сама решает без TPM? Поделитесь опытом — интересно, насколько у всех по-разному.
Продолжаем наш сериал про Technical Product Manager’ов. Сегодня поговорим про то, как TPM-роль устроена в разных странах и типах компаний.
Спойлер: везде по-разному. И это ок.
🗽 В Штатах TPM — это инженер с фокусом на продукт.
Сильно завязано на технический бэкграунд. Часто бывшие разработчики. Часто в FAANG-подобных компаниях: Meta, Google, Amazon и прочих. Там TPM — это glue role между продактом и инженерами. Он отвечает за архитектуру решений, roadmap фичей, stakeholder-менеджмент — но руками не кодит.
📈 В Европе TPM — это чуть ближе к платформенным продактам.
В большинстве европейских компаний TPM скорее про инфраструктурные решения, архитектурные вызовы и согласование кросс-командной работы. Может быть продактом внутренних платформ, API, data layer, IAM и прочих внутренних штук. Очень часто совмещает роли системного аналитика, платформенного продакта и деливери менеджера в одном лице.
🌍 В России (и странах постсовка) TPM — это почти всегда либо:
— продакт, у которого просто технарский бэкграунд (и его за это очень уважают);
— системный аналитик, который тащит на себе ещё и продуктовые куски, потому что “ну а кто ещё?”.
А иногда — разработчик, который стал писать задачи в джиру и стал продактом.
📊 В стартапах TPM — это "всё и сразу".
Отвечает за то, чтобы фича заработала и попала в релиз. Пишет требования, проверяет архитектуру, договаривается с соседними командами, деплоит с командой ночью, а потом ещё пишет документацию. И если повезёт — поговорит с пользователями.
🏢 В корпорациях TPM — это менеджер зависимостей.
Если твоя команда делает кусок, который зависит от 8 других команд, и ты не хочешь превратиться в хаос — вот тут нужен TPM. Он следит за API, схемами, контрактами, SLA, и отвечает, чтобы всё приехало вовремя и не взорвалось.
💡 Общая идея — TPM закрывает дырку между продуктом и инженерией.
Где она будет — зависит от зрелости компании, состава команды, и просто от культуры. Где-то TPM будет про архитектуру, где-то — про delivery, где-то — про приоритезацию внутреннего техдолга, где-то — про API как продукт.
В следующем посте — разберём, какие скиллы нужны TPM и как их качать.
А у вас TPM чем занимается? Или, может, ваша команда сама решает без TPM? Поделитесь опытом — интересно, насколько у всех по-разному.
🔥2
🧠 Навыки 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