Product manager или project manager что выбрать
Так Product или Project Manager?
Уже рассуждал о том, что пm-ом называют менеджера всего и вся. Давайте теперь разберемся, в чём разница между продакт и проджект менеджером.
Тут у меня в голове сразу три варианта возникают:
Как же быть? Как назвать?
Для начала разберемся в понятиях. Проект это организационная единица. Он существует в рамках компании с чисто проектным способом работы, когда нет функциональных департаментов. Что редкость.
И проекты, с другой стороны, которые переплетаются с функциональными единицами, задействуют тех же людей, с двойственными функциями и подчинением. Самая распространенная история.
Продукт к организационной структуре не имеет отношения. Продукт это то «что» мы делаем. Проект это то «как» мы делаем, точнее как мы организовываем работу над каким-либо «что». То есть формально у нас почти всегда есть и продукт и проект, если мы продуктом называем любой измеримый результат деятельности.
Ключевой момент здесь в фокусе.
В этой парадигме я считаю нецелесообразным менеджера называть продактом. Да он руководит технической разработкой продукта, но у него зачастую нет ни времени, ни ресурсов не полномочий заниматься всеми его аспектами.
Резюмирую:
Часто продакт совмещает в себе две роли на ранних стадиях. То есть и о стратегии думает, и операционкой руководит. Но это непросто.
И наоборот. Кратко или среднесрочные задачи, с внятными требованиями и операционкой каждый день? Типа постановки задач и контроля за реализацией, первичное тестирование и все то что нужно чтоб конкретная фича была разработана и выполняла свою функцию? Это проджект.
И вот вы сами легко ответили на вопрос из заголовка. И ребенку картину мира расширили.
Продакт и проджект: кто такие, чем отличаются и как ими стать
Как выучиться на самые актуальные менеджерские профессии
Продакт- и проджект-менеджер — две разные, но одинаково популярные современные профессии.
На примере двух героев разберемся, чем продакт отличается от проджекта и как стать тем и другим.
Когда-то я три года работал менеджером в официальном дилерском центре — продавал клиентам автозапчасти. В какой-то момент меня переклинило: я понял, что это не то, чего хочу, и в 2016 году ушел в предпринимательство.
Я был экспертом в автозапчастях, поэтому запустил продукт в этой же сфере. Мы быстро развивались и уже к четвертому кварталу 2016 года достигли потолка. Я не представлял, как дальше развивать бизнес, а потом узнал о продактах. Тогда в России плохо понимали эту профессию. Казалось, что эти ребята обладают сакральным знанием, которое нужно мне для того, чтобы пробить потолок и расти дальше.
На самом деле продакт анализирует рынок и конкурентов, общается с пользователями, закапывается в аналитику, проводит эксперименты, анализирует и разрабатывает пользовательские сценарии.
Легче сказать, чего он не делает. Это позиция, которая сильно отличается по набору задач и целей от компании к компании. Где-то есть продакты, которые отвечают за привлечение и активацию пользователей, кто-то отвечает за монетизацию, а еще есть продакты с функциями проджектов.
Для меня продакт-менеджер — это человек, которому больше всех надо. Его основная задача — сделать такой продукт, который будет востребован у пользователей и заработает деньги для бизнеса. Продуктом может быть любая вещь, с которой взаимодействует пользователь, но чаще всего в современном мире это веб-сервисы и мобильные приложения.
В 2016 году я проходил курсы по продуктовому менеджменту от «Нетологии», но они на самом деле были больше про проджект-менеджмент и управление проектами, поэтому не сильно помогли. Реальные знания пришли с опытом, первыми шишками, болью и страданиями. Из академического были только статьи и книги, например «Спроси маму», «Бизнес с нуля. Lean Startup».
Как победить выгорание
Как еще можно стать продактом
Курсы. На рынке много глубоких курсов для продактов — какие-то чуть хуже, какие-то лучше, но все довольно хорошие. Длятся они, как правило, год, некоторые — 14 месяцев. Они хорошо погружают в профессию, ее специфику и весь пул задач. Можно пройти длинный курс, а можно — двухмесячный Go Practice. Он тоже будет считаться кейсом, который можно прикрепить в портфолио. Go Practice — это крутая штука, которая за два месяца научит мышлению продакта и тому, как подходить к задачам с точки зрения данных.
Но надо помнить, что обучение на курсах кардинально отличается от реальности. Там рассказывают, как работать только с одним вариантом событий, но не показывают, как действовать в остальных. Продакт-менеджмент не математика, где сложил два и два и получил четыре. Это огромное количество сценариев решения одной и той же задачи, а в рамках курсов обычно показывают прямолинейный подход. После них человек сталкивается с действительностью и зачастую начинает теряться: ему говорили одно, а в жизни все немного иначе.
Менторство. Опыт хорошего ментора поможет свыкнуться с реальностью и преодолеть ее. Джуны без присмотра часто решают задачи по своему усмотрению, но их действия могут быть неправильными, а они об этом даже не узнают. Они привыкли делать A/B-тесты и радуются этому, но их тесты могут не учитывать множество мелочей и нюансов. Хороший ментор сделает получаемый опыт максимально полезным и релевантным.
Стать продактом в своей компании. В большой компании, где есть культура продуктового менеджмента, можно прийти к CPO своего направления или к Head of Product и сказать ему, что вам хочется пойти в продакты. Неплохих специалистов компании хотят удержать, поэтому могут попытаться устроить на желаемую должность. Возможно, предложат быть помощником квартал или два — и если откроется позиция, то переведут на нее.
Ошибки на старте и эффект Даннинга — Крюгера
Основная ошибка — засидеться в джуниорах, ничего не делать, не прокачиваться и не стараться вырасти. Компании набирают продактов-джунов крайне редко, открытых вакансий на рынке мало, и если все-таки удалось попасть в нишу, нужно всеми силами стараться перерасти в мидла.
Рынок продактов перегрет, но мидлов набирают чуть более охотно. Из джуниоров побеждает тот, кто больше всех хочет, запускает параллельно несколько продуктов, добавляется в друзья к классным продактам в «Фейсбуке» и просится, чтобы они стали его менторами.
В начале карьеры легко столкнуться с эффектом Даннинга — Крюгера. Сперва все получается, а потом при встрече с реальностью вы впадаете в отчаяние и понимаете, что область задач и проблем гораздо шире и глубже.
Это можно преодолеть только эволюционно. Придется погрузиться в детали, увидеть, что существует множество сложностей, понять, что вы умеете решать далеко не все задачи. Только со временем можно преодолеть спесь и эффект Даннинга — Крюгера. Нечасто люди готовы осознать на старте, что они мало знают, имеют недостаточно опыта и пока что не очень хорошие специалисты.
Как я набираю новых продактов
Я сам продакт-неудачник: прошел через тестирование 30 продуктов и только три из них выстрелили. Поэтому в других ценю не успешные запуски, а желание развиваться и тащить продукт. В основном выбираю тех, кто близок мне по духу. У людей, которые запустили что-то свое, гораздо выше вероятность попасть ко мне в команду, чем у кого-то другого.
После выполнения тестового формируется огромная табличка. Я создаю воронку: оцениваю кандидатов по четырем критериям, отбираю топ-10 и созваниваюсь с ними по «Зуму». На этом этапе важно определить их культурный код: насколько человек близок мне по духу и кайфово ли будет с ним работать. Тут нет определенных критериев — только ощущения и интуиция.
Я задаю им 20—30 объемных вопросов. Есть базовые, чтобы понять, что вдохновляет человека и как он решил стать продактом. Спрашиваю про задачи и о том, что принесло наибольшее удовлетворение за последний год. Когда последний раз учился и чему, с каким руководителем хотел бы работать, что важно в работе. Эти вопросы раскрывают мотивацию человека.
То, как человек отвечает на вопрос, показывает, насколько он открыт к диалогу, готов ли учиться и воспринимать критику.
Стоит ли идти в профессию
Понять, ваше это или нет, можно только в боевых условиях. Курсы, книги и лекции нужны скорее для общего понимания. Они также помогут для расширения навыков, когда вы уже определились.
Финансовые перспективы продактов. В Москве талантливые джуны могут зарабатывать от 70 до 120 тысяч рублей. Мидлы — от 120 до 200 тысяч, но чаще в районе 150—160 тысяч рублей. Сениоры — от 200 до 260 тысяч рублей, CPO и Head of Product получают от 260 тысяч и выше.
До университета я за деньги настраивал и восстанавливал компьютеры знакомым. Во времена учебы работал учителем английского и техническим переводчиком. А после открыл собственный бизнес — магазин лицензионных видеоигр для консолей. Попутно запустил кальянный кейтеринг.
В конце 2018 года почувствовал, что перестал получать удовольствие от работы, и захотел все поменять. Мои проекты были связаны со сферой обслуживания, а денег в городе больше не становилось. Передо мной стоял выбор: или кредитоваться, чтобы расширить бизнес и отъесть доли конкурентов, или закрываться. Я не чувствовал, что готов брать кредит, поэтому разбирался, какие у меня есть профессиональные возможности дальше.
Проджект — главное связующее звено между заказчиком и командой разработки. Его роль в команде — превращать идеи заказчика в понятные задачи для команды.
Моя работа заключается в том, что я структурирую хаотичный список задач и делаю из него детальный план действий, на который смогут ориентироваться как заказчик, так и команда. Кроме того, помогаю прояснять любые возникающие вопросы обеим сторонам, минимизирую риски по проекту, отвечаю за настрой команды и уверенность, что путь, которым мы движемся, верен и соответствует ожиданиям заказчика.
Еще я тесно взаимодействую с командой, с которой регулярно обсуждаю, что можно улучшить в проекте, и утверждаю такие улучшения с заказчиком. К примеру, заказчик попросил добавить кнопку в интерфейс. Если эта кнопка вызывает у меня и команды сомнения, то я выясняю, какую проблему заказчик хочет решить с помощью этой кнопки. Затем мы думаем, как эту проблему можно решить эффективнее и правильнее с точки зрения UX. Потом я возвращаюсь к заказчику, чтобы обсудить придуманные с командой варианты. Вместе мы приходим к оптимальному решению, которое устроит всех и даст наилучший опыт для пользователя.
В отличие от продакта, который деятельно погружается в продукт и работает с метриками, проджект отвечает за достижение результатов в оговоренный срок, за команду, настрой на проекте.
До ИТ у меня уже был практический опыт управления проектами и собственными бизнесами, но при этом я никогда не управлял разработкой. Во всякие курсы я не верю: считаю, что при наличии интернета и умения искать можно и самому набраться знаний, чтобы попасть в проджекты. Я читал много материалов на «Хабре» и vc.ru, в которых люди делились историями о проблемах в разработке, — мне помогло.
В 2019 году я устроился на позицию проджекта-джуна в ИТ-аутсорс-компанию Fora Soft, которая специализируется на создании мультимедиарешений, таких как видеостриминг и видеозвонки, для зарубежных заказчиков.
Спустя пару недель после трудоустройства один из проджектов ушел в отпуск, и в это время я управлял его проектами. Это помогло подтвердить мои навыки и пройти испытательный срок раньше положенных трех месяцев.
У нас крутая компания, и в ней много хороших специалистов. Именно там я начал регулярно общаться с разработчиками, узнавать технические подробности и особенности того, чем мы занимаемся. Например, если у нас был проект, связанный с видео, то я изучал, как конкретно он работает «под капотом» и почему именно так. На некоторых проектах активно лез в код, изучал его, гуглил неизвестное. Как обычно, помогал «Хабр»: к примеру, у команды разработки «Одноклассников» хорошие статьи про видео.
В итоге спустя шесть месяцев работы в компании я прошел аттестацию и стал просто проджектом, без приставки «джун». На этом не остановился и продолжал читать технические статьи и всякое разное про менеджмент. Неплохими книгами показались «Scrum и Kanban: выжимаем максимум», «Человеческий фактор. Успешные проекты и команды» и «45 татуировок менеджера. Правила российского руководителя». Кроме чтения книг и статей, все это время я наращивал практический опыт просто в процессе работы. Еще через полгода я прошел аттестацию и получил повышение до сениор-проджект-менеджера.
В ИТ нельзя стоять на месте: технологии регулярно обновляются, поэтому очень важно продолжать развиваться. Если бы я только работал и не изучал ничего, то быстро бы потерял работу.
Мой рабочий день на 40% состоит из разговоров — и если ненавидеть всех людей, то долго так не протянуть. Я налаживаю отношения с заказчиками, выясняю их ожидания, провожу собрания, созвоны и встречи.
Отличительная черта хорошего проджекта — он всегда отвечает за свои слова, в противном случае это плохой менеджер. Поэтому важно выявлять риски, снижать их, контролировать проектную документацию. Я делаю все это, но кроме прочего, составляю и согласовываю задания по проекту, расставляю приоритеты по задачам, распределяю задачи по команде, контролирую качество и сроки в рамках бюджета.
Как стать проджектом
Основные ошибки, с которыми сталкиваются проджекты, можно разделить на три типа.
Неверно рассчитывать сроки. Если разработчик сказал, что сделает задачу за день, то нельзя говорить заказчику эту же оценку, так как обязательно что-то пойдет не так. Всегда надо давать сроки с запасом. Если быстрее сделаете, то раньше отдадите и порадуете заказчика.
Не выяснять требования. Для любой задачи, даже самой маленькой, необходимо подготавливать детальные требования, где не останется каких-либо вопросов или неясностей. Если не сделаете это сразу, то потом обязательно аукнется.
Не контролировать все этапы работы. Столкнулся с этой проблемой на удаленке. Когда все работали из офиса, то было легко понять, работает сотрудник или нет. А на удаленке такой возможности нет. На ежедневных созвонах сотрудник уверял, что все идет по плану, а в реальности сидел и ничего не делал. Это вскрылось, когда пришло время первого демо заказчику. У нас оказалось ничего не готово, и в итоге мы потеряли проект. Сотрудника уволили, а я стал регулярно проверять, что актуальный код лежит в репозитории компании.
Чтобы стать проджектом, просто знаний недостаточно. На мой взгляд, нужно еще любить помогать людям, общаться с ними. Но в целом достаточно уметь слышать и слушать людей, адекватно оценивать сроки и риски и не пускать все на самотек. С такими исходными данными можно погружаться в процесс разработки, изучить, как все работает, и пробовать подавать резюме.
Есть ли на самом деле разница между Project Manager, Product Owner и Product Manager
Несмотря на рост популярности и понимание методологий управления проектами, включая Agile, многие люди часто путаются в определении кем он хочет стать или кого ищет компания себе в штат. В случае Project Manager, Product Owner и Product Manager вы, наверное, сталкивались с путаницей в понимании ролей и обязанностей сотрудников.
Итак, попробуем разобраться в чем разница и есть ли она между Project Manager, Product Owner и Product Manager?
Давайте для начала проясним, что такое “проект” и “продукт”.
Проект — временная активность, направленная на создание уникального продукта или услуги.
У проекта есть критерии успеха, по достижению которых проект считается завершенным, или когда проект прекращается в связи с тем, что его цели не будут или не могут быть достигнуты.
Продукт — товар или услуга, которую можно предложить для рынка, и которая будет удовлетворять потребности пользователей.
Продукт можно улучшать и за счет запуска и выполнения новых проектов.
В рамках одного продукта может существовать множество подпродуктов и подпроектов.
Чтобы понять роли более четко и иметь возможность различать Project Manager, Product Owner и Product Manager, давайте углубимся в набор обязанностей, которые фактически воплощает каждая роль.
Project Manager
Роль Project Manager появилась самой первой в виду необходимости иметь ответственного координатора за реализуемый проект. Изначально все проекты следовали методологии Waterfall, координируя действия команды проекта.
Project Manager берет на себя управление определенной фазой продукта или услуги, например, выпуском нового продукта, а также отвечает за удовлетворение потребностей: потребностей задач, потребности проектов и индивидуальных потребностей членов команды. Но его ответственность может быть расширена на основе дополнительных обязанностей или бизнес процессов в компании.
Основные обязанности Project Manager’a:
Product Owner
Роль Product Owner возникла после появления на свет методологии управления проектами — Agile Project Management. Обязанности Product Owner похожи на роль Project Manager, но Product Owner работает в относительно лучшей координации со всей командой Agile. Какой тип лидера будет наиболее эффективным, зависит от того, на какой философии построен проект.
Project Manager вступает в игру, когда проект использует более традиционный подход Waterfall, тогда как проект, разработанный с учетом гибкого подхода Agile, будет возглавляться Product Owner. Project Manager предпочитают диаграммы Ганта (Gantt chart), а Product Owner предпочитают Agile-инструменты.
Способ, которым Project Manager или Product Owner решает задачу, должен быть гибким, но всегда будут существовать некоторые конкретные различия в подходе. Идеи, лежащие в основе роли Product Owner и философии управления Agile, выросли и развились на основе идей, разработанных в методе Waterfall.
Product Manager
В отличие от проекта, который может иметь временные рамки, сам продукт является чем-то более долгосрочным. По сути, управление продуктом вращается вокруг продукта или услуги, то есть всего, что может быть предложено рынку для решения проблемы или удовлетворения потребности.
Product Manager отвечает за успех продукта на протяжении всего жизненного цикла продукта. Он сосредотачивает внимание больше на вопросе «что?», чем на «как?». Product Manager отвечает за верхнеуровневое планирование и отвечает за рост и развитие продукта.
Основные обязанности Product Manager:
В итоге выделим самое главное:
Роли Project Manager, Product Owner и Product Manager имеют разные обязанности и набор необходимых знаний.
Основное различие между Project Manager и Product Owner можно найти в направлении проекта, которым необходимо управлять. Если это тип проекта, который должен быть построен из надежного плана, в котором изложены все шаги в том порядке, в котором они должны быть завершены до начала следующего шага, Project Manager поможет вам туда добраться.
С другой стороны, проект, подразумевая продукт, который нуждается в гибкой разработке функционала, то для такого проекта Product Owner будет лучшим решением.
Продакт vs. Проджект: чем отличаются профессии, которые часто путают
Ольга Стратанович, Program Director в ProductSense и Chief Product Officer в «Киноплан», рассказала о ключевых отличиях в мышлении и навыках менеджера продукта и менеджера проекта.
Профессия «менеджер продуктов» пока еще молодая в СНГ, но уже востребована на рынке. Компании с собственной разработкой ищут человека, который сможет выпустить и сопровождать продукт. Заказная разработка тоже нуждается в продуктовом подходе. Но хороших менеджеров продуктов на всех не хватает, поэтому возникает необходимость брать джуниоров из других областей.
Самой близкой областью считается менеджмент проектов. Я часто встречаю бывших менеджеров из заказной разработки, которые перешли в менеджмент продуктов. Они не понимают, какие изменения должны произойти на новой работе. Обычно они думают, что это всего лишь следующая ступень проектного менеджмента.
Давайте разберем, чем отличается менеджер продукта от менеджера проекта.
Зона ответственности
Главные метрики успешности проекта — срок, бюджет и объем задач. Менеджер проекта должен получить требования от стейкхолдеров, согласовать бюджет и проследить, чтобы проект сдали в срок. Его не интересует, что произойдет дальше:
— как конечный пользователь получит проект и будет его использовать,
— как проект будет или не будет развиваться.
Для менеджера продукта главное — донести пользу до клиента. Создание продукта — только небольшая часть ответственности менеджера продукта. Ему нужно думать о необходимости и эффективности функционала, «упаковке», доставке, сопровождении и развитии продукта.
Генерация и валидация гипотез
Менеджер проекта не генерирует идеи: к нему поступает задача, которую он обязан выполнить эффективно. Хороший менеджер уточнит у заказчика цель проекта, вместе с ним подумает над оптимальным решением и может быть предложит свое. Но он не выдвигает и не проверяет гипотезы — этим обычно занимаются владелец бизнеса, заказчик и другие стейкхолдеры.
Основная задача менеджера продукта — выявлять потребности и предлагать идеи для улучшения продукта. Менеджер продукта много общается с пользователями, проводит глубинные интервью, выдвигает, проверяет и отвергает гипотезы. Все это он может выполнять даже без команды разработки. Он не знает, что ему делать, но ищет свой путь.
Условия неопределенности
Менеджер проекта действует в заранее обозначенных условиях: объем задач известен (его можно уменьшить, но не намного), сроки и бюджет согласованы. Обязанности менеджера обычно четко прописаны в гайдах, внутренних регламентах и правилах компании.
Менеджеру продукта повезло меньше: он никогда точно не знает, что должен сделать. Какая гипотеза окажется провальной, а какая принесет прибыль? Здесь появляются MVP, экономические расчеты, метрики, A/B тесты, валидация прототипов — всё, что помогает оценить идею.
Менеджеру продукта надо признавать провал экспериментов и безжалостно удалять функционал, который не приносит ожидаемой пользы. Ему приходится отказываться от собственных идей и пожеланий клиентов.
Метрики
На собеседовании я всегда прошу кандидата рассказать, какие метрики были у его последнего продукта или какие метрики он бы выбрал, если бы был владельцем продукта. Бывшие менеджеры проектов отвечают: «Количество пользователей» или «Мы прикручивали аналитику, но я туда не заглядывал».
Менеджер продукта всегда смотрит глубже: метрик много, и каждый продукт требует своего подхода. Умение выбрать метрики, проанализировать и принять на основе анализа решение — один из важнейших навыков в этой профессии.
Экономика
Менеджер проекта не думает об окупаемости, его задача — уложиться в согласованный бюджет.
Для менеджера продукта окупаемость стоит на первом месте. Сколько мы потратим? Какую модель монетизации выбрать? Как привлекать пользователей и увеличивать Lifetime Value? Как получить дополнительную прибыль? Это вопросы, на которые мы ищем ответы постоянно.
Продажи, внедрение и сопровождение
С этим менеджер проекта обычно не сталкивается. Проект принят, документы подписаны — на этом его зона ответственности заканчивается. Если проект нужно сопровождать или что-то в нем дорабатывать, компания заключит новый контракт или запустит внутренний проект с новым бюджетом, объемом задач и сроками.
Для менеджера продукта готовый функционал — это только начало. Нужно договориться со смежными отделами, «упаковать» продукт, доставить клиенту, объяснить ценность отделу продаж. Важно убедиться, что продукт сопровождают качественно: например, в b2b сопровождение не менее важно, чем функционал продукта.
Взаимодействие между командами и построение эффективных процессов — еще один вызов для менеджера продукта.
Коммуникации
Менеджер проекта принимает требования от стейкхолдеров и передает команде разработки.
У менеджера продукта коммуникаций гораздо больше. Он — точка входа в команду для всех смежных отделов. К нему стекается весь поток вопросов от отделов продаж, маркетинга и сопровождения. Он постоянно общается с клиентами. Топ-менеджеры транслируют ему свое видение.
Эффективные коммуникации и фильтрация входящего потока — это первое, чему должен научиться менеджер продукта.
Стратегия и видение
Менеджер проекта действует в рамках срока проекта — обычно он длится не более года. Цели чаще всего ставят владелец бизнеса или заказчики. Менеджер проекта управляет только контрольными точками в рамках этого срока.
Менеджер продукта формирует собственное видение, куда движется его продукт и каким он станет через 1−3−5 лет. Он должен четко понимать, как та или иная задача приближает продукт к цели, и иногда жертвовать краткосрочными результатами.
Риск-менеджмент
Хороший менеджер проектов всегда думает о рисках и минимизирует их негативное влияние.
Менеджер продукта думает о возможностях. Любая неопределенность или проблема — это потенциальная возможность улучшить продукт. Менеджер продукта думает, как извлечь дополнительную выгоду и сделать то, чего еще никто не делал.
Вдохновление
Менеджер проекта должен принести в команду хорошо описанную понятную задачу: Что делать? Как делать? В какие сроки делать?
Менеджеру продукта надо «продать» боль пользователя и вместе с командой выработать оптимальное решение этой боли. Команде с продуктовым мышлением нельзя просто принести задачу — они начинают задавать сложные вопросы. Это очень хорошо для продукта, но требует от менеджера навыков продвижения своих идей, вдохновления команды, объяснения проблем.
В бизнесе много говорят о продуктовом мышлении команд. Появляется определение продуктового инженера — разработчика, который не просто берет и делает задачу, но думает о пользователе, предлагает свои решения.
Карта компетенций
Профессия менеджера проектов давно сформировалась. Набор его навыков определен и понятен.
Профессия менеджера продуктов еще молодая. В разных компаниях у него могут быть разные обязанности, поэтому навыки должны быть шире. Это не только управление, но и маркетинг, основы экономики, аналитика, умение вести переговоры, лидерство, основы дизайна и многое другое.
Менеджер продукта «болеет» за продукт. Продукт плохо продается — это его проблема. Нужно идти в отдел продаж и выяснять причины, помогать построить процесс, подготовить маркетинговые материалы. Нет ресурсов на разработку — идти к HR (это не обязанность менеджера, но что если важные задачи тормозит нехватка разработчиков?). Нет дизайнера — рисовать макеты самостоятельно. Пусть это будет непрофессионально, но целью должен быть не идеальный макет, а польза для клиента.
Важно, чтобы менеджер продукта мог сделать что-то самостоятельно, если делать некому, или найти человека, которому это можно делегировать. Менеджеру продукта нельзя говорить: «Это не моя обязанность, я не буду за это отвечать». Ему надо делать все возможное, чтобы продукт был успешен.
Подведем итог
У меня нет цели показать, что менеджеры продукта круче, чем менеджеры проекта. Я видела прекрасных продуктологов, которые никогда не смогли бы вести сложные проекты и писать подробные ТЗ. Я хотела показать разницу в мышлении и сфере ответственности. Если вы решите перейти из проектной разработки в продуктовую, вам придется: