Из аналитика в продакты и обратно

«Берешь на себя какие-то новые обязанности, делаешь их хорошо, затем растешь и занимаешь ту роль, которую хочешь» — такой совет однажды мне дал опытный продакт-менеджер в Wrike. В этой статье я расскажу, как последовал совету и временно стал совмещать роли аналитика и менеджера. Поделюсь историями совершенных ошибок и попытаюсь превратить свой опыт в рекомендации о том, как их избежать.

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

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

Задача — переписать с нуля редактор комментариев.

Более 100 тысяч пользователей в неделю пишут комментарии. Редактор комментариев — это возможность писать текст и форматировать его, добавлять файлы и убирать лишние, здесь же поддержка эмоджи, эргономичное расположение элементов и т.д.

У меня не было опыта в роли PM, поэтому Юра (Lead product manager) предложил мне такой формат работы:

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

На этом этапе Юра посоветовал мне определить, как я вижу свою роль в команде и какие критерии успеха я для себя определяю на этой позиции.

Роль в команде я определил так:

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

Команда сказала, что моя основная задача — взять на себя ответственность за изменение UX: валидировать, доносить и отстаивать позицию. На деле это значило — быть крайним.

Важная часть работы продуктового менеджера — помощь в планировании работ по разработке фичи. В идеальной ситуации UX-дизайнер вместе с PM сначала продумывают возможные варианты того, как должна выглядеть фича и из каких функциональных и визуальных компонентов она состоит. Затем они валидируют свое видение разными способами, в том числе через продуктовых аналитиков, которые проверяют выдвинутые гипотезы. В моем случае я был и за менеджера, и за аналитика.

С какими проблемами я столкнулся на этапе планирования:

Команда еще до нашего с дизайнером появления начала переписывать компонент по безрисковому сценарию – не меняя пользовательское поведение и внешний вид. Когда мы подключились к работе, дизайнер параллельно занималась несколькими другими проектами и была сильно загружена. Мне же не хватило смелости сразу остановить работы и сказать, что будем идти другим путем. У меня в голове была другая картина, к которой мы в итоге и пришли.

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

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

На этапе разработки PM помогает в спорных моментах, разбирается в нюансах, которые, возможно, необходимо будет донести до других команд, менеджеров и стейкхолдеров.

Хотелось бы сказать, что я принимал активное участие там, где мог помочь, но это было бы неправдой. Половину времени разработки я занимал пассивную позицию. Команда делала все в целом хорошо. Мне казалось, что на этом этапе я — лишнее звено, и, если понадобится моя помощь, то о ней попросят. Сейчас я понимаю, что это была ошибка: не нужно постоянно вмешиваться в процесс, если все идет хорошо, но лидерство — это точно не про пассивное наблюдение.

Какие еще ошибки я совершил на этом этапе:

А вот то, что получилось хорошо:

Подготовка к релизу — это не только напряженная работа команды, которая исправляет последние известные баги, активно занимается тестированием, но и много работы PM в плане коммуникации. Надо написать Q&A для сотрудников поддержки, анонсы во всевозможные каналы, провести несколько презентаций, подготовить материалы для поста на форуме в Community и т.д.

Поделюсь несколькими, возможно, банальными советами, которые помогли мне на этом этапе:

Обратная связь от коллег помогает исправлять ошибки. Я не понимал цель одного из анонсов для внутреннего канала, поэтому текст вышел слабым. Я попросил опытного продакта посмотреть черновик, и он дал мне очень развернутый комментарий:

Текст нужен для того, чтобы подстраховаться и, если что, сослаться на него. А также чтобы у «боссов» была возможность его прочитать и задать вопросы, если они видят какие-то риски, которые мы упустили.

В итоге цели анонса я обозначил для себя так:

Важно четко структурировать текст, избавиться от лишних слов.

Такой конструктивный и полный фидбек помогает исправлять ошибки и расти. Об этом стоит помнить и не стесняться просить его.

Вот так изменился редактор комментариев после релиза

Несмотря на то, что этот релиз был без промежуточных шагов, проблем оказалось не очень много. Баги всегда есть — это нормально, команда оперативно их исправляла. Классно было читать отзывы пользователей про то, что редактор комментариев выглядит круто. Некоторые говорили, что даже хочется писать больше комментариев.

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

Я себя ругал в этой статье, но в голове всегда было оправдание — я учился. Нет ничего плохого в ошибках, если ты их не повторяешь. Ошибки позволяют по-новому взглянуть на вещи, на них мы растем как специалисты и как личности.

Не стану перечислять все, но напомню о главных:

Этот кейс нужен был мне для того, чтобы понять, хочу ли я в будущем стать продактом и получится ли у меня делать эту работу хорошо. После пройденного пути ответ есть: я хочу стать ПМом, но на данный момент я к этому не готов (а можно ли вообще быть к этому готовым?) и приношу бóльшую ценность в роли аналитика. В любом случае процесс изменений запущен, ответы на такие вопросы не проходят бесследно, а такой опыт помогает скорректировать вектор развития.

П.С. Надеюсь, моя история будет полезна другим. Да, ошибки часто индивидуальны, и мало людей учатся на чужих, но вероятность их снижается. Если статья поможет хотя бы одному человеку избежать таких же ошибок, все не зря!