Облако тем, которые были в этом канале за последние недели репостов. Чем больше шрифт, тем чаще тема встречается.

Спасибо автору @data_bar за труды! ❤️

Как сделать свою первую публикацию в СМИ?

Разбираем пошаговую инструкцию.

1. Находим площадки, где планируем разместить первую статью.
(это могут быть как традиционные СМИ, так и новые медиа: Дзен и Telegram-каналы и тд.)

2. Готовим 5 тем, в которых вы круто можете показать свою экспертность. Рекомендую делать акцент на то, что будет полезно вашей аудитории.

3. Открываем контакты издания (на сайте чаще всего есть эл.почты), находим журналиста, который пишет на вашу тему и готовим письмо. Если это автор телеграм-канала, в описании всегда есть контакт для связи. В этом посте рассказывала, как подготовить правильное письмо и зацепить редактора.

4. Делаем рассылку.
Самое главное — если журналист сказал вам нет, это не значит, что с вами что-то не так. Повестка может быть другой или тема пока неактуальна. Вернитесь чуть позже с темами, аккуратно напоминайте о себе редактору и результат не заставит себя ждать.

Кстати, хотите официальное признание? Я — сапожник без сапог. За почти 5 лет работы в PR я ни разу не предлагала себя как эксперта журналистам. Всегда пряталась за спинами клиентов, считая продвижение себя последним делом (синдром самозванца на лицо). А зря!

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

Делитесь в комментариях в каких медиа и с какими темами вы бы хотели выйти, как эксперт. Если понадобится помощь, буду рада направить и сформулировать правильно темы.

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

Как продакт выбирает методологию: вопрос, который определяет судьбу продукта?

На недавнем собеседовании мне задали, казалось бы, простой вопрос: «Какими методологиями продуктовой разработки вы пользуетесь?»
Для позиции CPO он звучит почти буднично — но я задумалась. Действительно: как мы, продакты, выбираем метод, по которому пойдёт разработка? Ведь с учётом метрик вроде Time to Market и стоимости реализации — это не просто выбор инструмента, а стратегическое управленческое решение. Оно напрямую влияет на скорость, ошибки и качество вывода продукта на рынок. И, что критично, часто его принимает один человек — продакт которому доверили реализацию этой задачи. Его опыт, насмотренность и управленческая смелость определяют, пойдёт ли команда по проторенной дорожке или найдёт способ сделать быстрее, дешевле и лучше.

Я провела короткое «исследование на своих», поэтому не претендую на полную точность. и выделила три типовых модели поведения в точке выбора методологии:

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

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

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

📌 Чтобы не останавливаться на интуиции и привычке, 👉собрала и структурировала ключевые методологии продуктовой разработки — с пояснением, в каком контексте каждая из них работает лучше всего. Дополнительно — сравнение фреймворков для поиска бизнес-моделей: от BMC и Lean Canvas до Blue Ocean Strategy.
Там много букв и надо еще это все приземлить на коллективный опыт и получить обратную связь, но есть над чем подумать.

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

Место редактора в IT-компании

Насчитала шесть направлений, которыми может заниматься редактор в IT-компании — делюсь с вами.

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

🔹️ Маркетинг. Для продвижения IT-продуктов нужен контент: лендинги, кейсы, посты в соцсетях, статьи, колонки в СМИ, рекламные объявления и многое другое.

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

🔹️ Продукт. Некоторые редакторы занимаются текстами внутри продуктов. Придумывают кнопки, навигацию, подсказки — все, что мы видим в приложениях каждый день.

Я никогда не занималась UX-редактурой, но проводила прямой эфир с Кирой Калимулиной, где она подробно рассказала про профессию. Посмотрите, если интересуетесь этим направлением.

🔹️ Поддержка. Еще бывает, что нужен контент для техподдержки. Например, тексты для справочного центра или грамотные скрипты для сотрудников, общающихся с клиентами. Это тоже работа редактора.

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

Если речь о найме айтишков, то для формирования HR-бренда обычно пишут статьи на Хабр в духе "какие продвинутые технологии мы используем в работе". Так делают, поскольку айтишникам недостаточно предложить денег, нужно, чтобы им было интересно.

🔹️ Внутренние коммуникации. По сути, тот же HR-бренд, но не для привлечения новых сотрудников, а для удержания старых.

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

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

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

В очередной раз структурирую свой опыт по производству кейсов для Purrweb. Вспомнил прикольную историю. Поделюсь с вами.

Короче это был конец 22 года. Я искал авторов, которые будут писать кейсы для нас. Это был тот момент, когда мы играли в перфекционизм, пытались сделать что-то такое эдакое. Ну сами посудит по отрывку тестового:

Мы не хотим делать стандартный кейс типа Ситуация → Проблема → Процесс решения → Результат. Это скучно. Вместо этого хочется взять какой-то уникальный аспект проекта и через него выстроить историю, которую интересно было бы прочитать не только стартаперам, но и всей аудитории vc.ru. В итоге ожидаем, что читатель после прочтения скажет «вау, как они делают», а стартапер придёт к нам делать своё подобное приложение.

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

Ёлки, да вы сделайте это нормально! Когда делают нормальные спокойные кейсы про ситуацию, проблему и решение, всё получается круто, интересно и релевантно. Все эти влажные фантазии, что предприниматели на Виси сейчас всё бросят и побегут к вам — это признак чего-то нездорового. Короче, чуваки конкретно ждут от вас мост хрустальный за 7—14к.

Тогда я думал, мол да, все так, но у нас-то оСобЕНнаЯ ситуация — мы точно знаем, что это ключ к успеху.

Спустя 2,5 года ответственно заявляю — МАКСИМ БЫЛ ПРАВ ахаха

→ Если хотите прочитать его полный пост + само тестовое, вот ссылочка.