Ассистент продакт-менеджера / младший проджект
Описание
Суть роли Мы делаем сервисы для SEO-специалистов и агентств. Продуктом занимается основатель, и ему нужен человек, который заберёт всю работу вокруг решений: сбор информации, оформление задач, контроль исполнения, приёмка. Схема простая: вы собираете, структурируете и предлагаете — решение принимает основатель. Дальше вы доводите его до результата через разработчика и подрядчиков. Это позиция для того, кто хочет вырасти в продакта или руководителя. Продуктовая работа здесь с первого дня, а не «когда-нибудь потом». Задачи Работа с разработкой Превращать быстрые описания основателя в нормальные задачи для программиста Ставить задачи, контролировать сроки, принимать результат Тестировать интерфейс: находить, что сломалось, что неудобно, что не соответствует задаче Вести бэклог: приоритеты, статусы, актуальность Исследование рынка Регулярно разбирать конкурентов: что появилось, что изменилось, как это устроено Приводить собранное в структурированный вид, пригодный для решения Предлагать свои идеи по улучшению продукта — с аргументацией, а не просто списком Подрядчики Искать исполнителей под задачи, отбирать, договариваться Ставить ТЗ, контролировать сроки, принимать работу Держать процесс так, чтобы основателю не приходилось вмешиваться Клиентские проекты Вести 5 небольших проектов в нашем сервисе Задача не только в самих проектах: работая в продукте руками, вы начинаете понимать клиента, можете консультировать пользователей и видите, что в продукте стоит улучшить Контент и публикации Новости и обновления продукта: сайт, email, Telegram, ВК, бот. Вы принимаете задачи у разработчика — значит лучше всех понимаете, что изменилось и почему это важно клиенту Ведение соцсетей: основатель даёт тему и экспертизу, вы через ИИ по готовому промпту готовите пост и публикуете по каналам Это примерно 15% рабочего времени, по готовым шаблонам и промптам. Не прячем: рутина в роли есть, но она не основная.После передадите маркетологу. Всё новое По мере роста будут появляться задачи, которых сейчас нет. На каждую пишется инструкция, дальше она ваша Кого ищем Структурность. Умение из кучи разрозненной информации сделать понятную картину — это ключевой навык на этой позиции Умение писать так, чтобы вас поняли однозначно: ТЗ разработчику и подрядчику — это половина работы Внимание к деталям: тестирование интерфейса — это про способность заметить то, мимо чего все проходят Самостоятельность: приходить с предложением, а не с вопросом «что делать» Базовая техническая грамотность: понимать, как устроены веб-сервисы, не бояться таск-трекеров и разговоров с разработчиком Опыт от года в проджект/продакт-роли, агентстве или продуктовой команде. Либо готовность доказать делом, что тянете Опыт в SEO не обязателен — научим, но интерес к теме нужен. Как мы работаем Асинхронно, с ежедневным коротким созвоном для разбора непонятного. Правило одно: если не знаете, как поступить, — приходите с вариантом, а не с вопросом. Вариант может быть неправильным, это нормально, обсудим. Но думать первым должны вы. Первые полтора-два месяца ТЗ для разработчика вы согласовываете с основателем перед передачей в работу. Дальше — самостоятельно. Куда это растёт Через 6–12 месяцев — самостоятельное ведение продуктовых направлений: своя гипотеза, своё исследование, своё решение, согласование вместо постановки задач. Дальше в команду выходит маркетолог, направления расширяются, и появляется управленческий трек. Это не обещание должности к конкретной дате. Это направление, в котором роль реально движется, если человек тянет. Условия Удалённо, 5\2, 8ч ГПХ 40-50 тыс., пересмотр через 3 месяца Прямая работа с основателем, без прослоек и согласований Бюджет на подрядчиков и инструменты в вашем распоряжении Отбор Отклик с ответами на вопросы ниже Созвон 30 минут Тестовое задание, 2–3 часа, оплачиваемое — на реальных задачах: разобрать наш интерфейс и превратить короткое описание в ТЗ Оффер Как откликнуться Напишите на отклик: Задача, где вам пришлось разобраться в чужом продукте или рынке и сделать выводы. Что собирали, как структурировали, что получилось. Приходилось ли ставить задачи разработчикам или подрядчикам? Расскажите про случай, когда сделали не то, что вы имели в виду — и что вы поменяли после. Любой интерфейс, которым вы пользуетесь, — что бы вы в нём исправили и почему? Отклики без ответов не рассматриваем.