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

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

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

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

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

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

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

• Смотришь документ с декомпозицией текущего редактора
• Уточняешь и анализируешь данные
• Предлагаешь вариант комбинации функционала и объясняешь, почему так
• Обсуждаешь предложение, разбираешь риски с более опытным менеджером
• Идёшь с финальной версией к тимлиду команды
• Обсуждаешь детали в процессе имплементации

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

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

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

• Принимать решения по изменению пользовательского поведения
• Брать на себя ответственность за принятые решения
• Подсчитывать статистику, риски и т.д.
• Искать уязвимые места
• Доносить до стейкхолдеров информацию по прогрессу трека
• Коммуницировать с пользователями, если столкнемся с проблемами

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

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

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

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

• На старте дизайнер проекта была загружена другими задачами, и ей не хватало времени
• У меня не было достаточно информации о продуктовых и инженерных зависимостях компонента, о деталях взаимодействия с другими департаментами
• Я боялся проявлять проактивную позицию

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

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

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

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

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

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

• Я не знал всех нюансов и иногда ориентировался на логику, не спрашивая мнения людей, которые обладают большей экспертизой
• Неправильно сформулированные вопросы привели к очень рискованной форме релиза. Вместо того, чтобы сначала протестировать новую функциональность на внутреннем аккаунте компании, собрать обратную связь и устранить ненайденные баги, мы выпустили релиз сразу на всех пользователей
• То, как я представлял себе всю картину, отличалось от того, как это видели другие команды. Во время презентации функциональности для команд, которые отвечают за коммуникацию с клиентами (Customer Success Organization), я очень коротко описал часть релиза. Это привело к неправильной интерпретации и шумихе

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

• Пассивная позиция — роль губки, впитывающей информацию, а также роль стороннего наблюдателя имеет свои плюсы. Большое видится на расстоянии! Когда кто-то из членов команды сомневался, что было хорошо заметно со стороны, я поддерживал ребят в их решениях лично или публично в зависимости от ситуации
• Высокий уровень интеграции в процессы команды помог мне переосмыслить себя как продуктового аналитика. Я стал лучше понимать, как общаться с разработчиками по поводу задач

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

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

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

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

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

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

• подсветить понятным языком, где конкретно мы рискуем
• объяснить, почему мы не считаем это риском и какие у нас для этого есть аргументы
• рассказать о шагах, которые мы предприняли, чтобы минимизировать риски

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

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

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

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

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

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

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

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

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

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