Какое-то время назад в Product Club была задачка: если бы вы пришли новым продактом в Google Maps, что бы вы сделали в первую очередь? Задачка была с подвохом; многие начали предлагать идеи для разработки и сразу рваться в бой. На самом деле, Google Maps здесь для красного словца – правильный ответ можно применить к любому продукту. У меня есть любимое эссе на эту тему, почитайте:
https://www.kennorton.com/essays/what-to-do-in-your-first-30-days-as-product-manager.htmlНу или вот мой вольный пересказ с комментариями из собственного опыта ;) Итак, что делать, если вы, продакт-менеджер, только вышли на работу?
1. Обговорите с начальством, что от вас ждут и как будет оцениваться ваша работа
Из серии "очевидное, но часто забываемое". Возможно, вы уже говорили про это на собеседовании. Возможно, ваш босс просто душка, и вы верите, что он и так по заслугам оценит вашу работу. Но когда вы стартуете, вам необходимо установить общий контекст и еще раз проговорить ваши цели. Сколько времени вам готовы дать на адаптацию? За что вы отвечаете и в каких решениях вы автономны? Что для вашего руководителя будет показателем успешной работы? Вы пришли не освещать офис своим светлым продуктовым челом, а затыкать определенные дыры, о которых в стартапном угаре вам могут и забыть сказать. Но вы как продакт должны не забыть спросить ;)
2. Познакомьтесь с командой
Во-первых, вам важно установить контакт и убедить окружающих, что вы вполне себе милый котик, открыты к коммуникации и совместной игре на банджо. Для этого сойдет и совместное поедание пиццы или тортиков вечером после работы ;) Во-вторых, вам важно понять, чего от вас как от продакта ждут коллеги. Особенно это критично для компаний, где вы первый продакт: никто не знает, что вы за зверь и чем будете заниматься. Так было, например, в моем берлинском стартапе: у одних вообще не было опыта работы с продактами, у других обязанности продакта сильно отличались от того, что предполагалось для моей позиции. И тут важно сделать несколько вещей:
- для коллег не из разработки (маркетинг, контент, саппорты и тд – все, с кем вы будете общаться) - написать письмо, где вы расскажете, чем будете заниматься и по каким вопросам к вам можно приходить. И провести несколько 1-1 с руководителями/представителями департаментов, чтобы понять: как происходила коммуникация до вашего прихода? Что работало, а что нет? Что можно улучшить?
- для коллег из непосредственно вашей команды - поговорить с каждым лично. Звучит как трата времени, но это окупит себя с лихвой. Вам важно понять, кто за что отвечает, какие есть проблемы с коммуникацией и процессами, и как видят вас в этой цепочке.
3. Поговорите с техлидом
Попросите устроить вам экскурс по технической части продукта. Что используется, почему, какие есть проблемы на данный момент. Вы должны четко представлять себе архитектуру, хотя бы поверхностно понимать, как работают и взаимодействуют компоненты системы, знать о техническом долге и рисках.
Не бойтесь задавать вопросы, рисуйте как можно больше, выписывайте на отдельный листочек незнакомые слова. Это ваше домашнее задание: к концу адаптационного периода понимать их все ;)
4. Почитайте документацию
Ну и вообще – все документы и исследования по продукту. Если времени не так много, попросите руководителя указать вам на самые важные. Это поможет вам быстрее найти общий язык с командой и сэкономит кучу времени, когда вы будете думать о развитии продукта и новых фичах. Вы удивитесь, как много уже было придумано и опробовано до вас ;) Ну и важный момент - познакомитесь со стандартами оформления документов в компании (как, например, здесь принято писать проджект бриф?).
5. Разберитесь с инструментами
Где команда трекает таски и баги? Где смотрит аналитику? Как ведет документооборот и строит роадмап? Возможно, вам повезет, и какие-то из инструментов будут вам знакомы. Но, к примеру, в большинстве крупных компаний многие внутренние сервисы будут самописными; да и в маленьких даже стандартные инструменты могут использоваться по-своему. Заложите время на изучение и конфигурацию рабочего софта под ваши потре