Алексей Арефьев

Это сто про.

Не могу согласиться до конца. Вопрос фокуса и специфики продукта. Может и так и так работать на деле, но представление хотя бы на уровне схемы архитектуры иметь должен сто процентов.

Рады стараться. Если интересно можно глубже изучить компетенции, которые необходимы, тут выпускал отдельную статью - https://www.alexcouncil.com/oczenka-kompetenczij-it-speczialistov/

Профессия продакта по факту это предприниматель. Человек, который знает все аспекты управления компанией, в том числк и продажи.

Как правило, крутые продакты вырастают как раз из тех, кто позапускал свсвоих продуктов и прогорел. Негативный опыт самый ценный, врезается в память навсегда.

Дописывайте свои, если что-то не учел в материале. Дополню.

"Прелесть. Прям готовая инструкция "как слить бюджет проекта в унитаз и не выпустить вообще ничего рабочего".

Изменения в чем у вас неизбежны? В БТ? Как и почему они поменялись? Тут причин может быть две: 1) Херово собрали БТ, 2) Заказчик отказался от продукта. В ТЗ? Так ТЗ реализует БТ, если они неизменны, то и ТЗ не меняется"

Заметил, что фигурирует слово "проект". Мне кажется, на этом и ломается логика. Как только мы начинаем называть продуктовые изменения проектом, оунерства продуктового не происходит. Появляется проджект, который, как вы правильно описали, ходит за заказчиком и фиксирует БТ. Есть ощущение, что роли немного спутаны, в материале, хотелось больше про продакт оунеров говорить (опять же, если оперировать вашей терминологией).

И да, видимо, надо было мне слово "Заказчик" поменять на другое слово, типа "Stakeholder/Заинтересант". Помогло бы снизить привкус "проектности" в материале.

Спасибо за развернутые ответы, по делу.

"На такой вопрос есть только один правильный ответ: в установленные графиком работ сроки. И этот ответ вы почему-то считаете неверным."

- Посмотрите немного шире на пример ответа. Неправильность не в форме самого ответа с план-графиком, а в том, что продакт довел до ситуации, где заказчик/стейкхолдер не понимает что происходит. Тут про прозрачность и управление ожиданиями.

"Это не продакт менеджер, а product owner (с немного другой мотивационной схемой, кстати). Тот да, берет на себя еще и всю бизнес составляющую и отвечает за успех или провал. А продакт менеджер отвечает за продукт и его соответствие бизнес-требованиям заказчика"

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

По теме product manager/owner как роли в РФ это примерно про одно и то же. У тебя есть бизнесовая цель и ты отвечаешь за нее через продукт и доверенный ресурс (команда разработки). За бугром функционал ролей может разниться.

"То, о чем пишите вы - это не про коммуникацию, а про умение ставить ТЗ"

Согласен.

По пунктам далее прокомментирую.

П.1 Дополню, можно и не собирать на самом деле БТ, а сильно экономить время и в процессе диалога сразу выяснить "Зачем? И как это поможет нашим целям?". Тупо сэкономите время.

Но такое возможно опять же, если роль продакта полноценная, оунерская вашими словами.

П.2.3 Да, обычная операционка.

Немного откорректирую тезис "прокладка":

- если сам не отвечает за вверенный кусок продукта или продукт целиком, то это не продакт уже, а проджект (говорят что делать)
- если же ответственность на нем + команда, то уже полноценный продакт-менеджер получается (с целями, стратегией, управлением приоритетами и прочим)

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

Здесь вопрос в том, как именно ты отказываешься. Если в общении с кем-то в компании просто говоришь "нет" без объяснения и желания понять, что другие люди предлагают, то рано или поздно изолируешь себя от возможностей.

В идеале, нужно копать ценность и смыслы, потом прикладывать к своему продукту и уже решать, поможет поставленным целям изменение или нет.

Профессия в целом непростая и затрагивает огромное кол-во областей знаний. Может как-нибудь статью отдельную про это соберу...

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

Рады стараться. Но как выше написали, нельзя забывать про постоянное обучение в том числе. Еще одной ошибкой будет остановка в изучении нового, которая тебя затормозит.

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

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

На самом деле скорее всего проблема в том, как использована сама методология и на сколько ее нормально "продали" в команду.

То есть, бывает так, что тупо берут 30% практик от нужного, а потом говорят, что не работает.

Или через колено засовывают "Надо agile и все" , а потом удивляются почему люди отторгают подходы.

В целом, это просто инструмент, только нужно объяснить зачем он нужен и использовать его полностью.

Это отдельная тема, на котрую в свое время положили кучу сил. И это того стоило.

У нас это решается как раз за счет продуктовой команды. Внутри у тебя есть все спецы, который способны вносить изменения на все платформы.

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

Есть, конечно, нюансы, связанные с необходимостью полной загрузки команды, потому как бывают фичи, которые везде не запихнешь (типа вибрации смартфона, которая только на app подходит), но стараемся точечно с этим работать.

Спасибо, рады стараться!

Новую уже выпустим когда мяса полезного наберем. Пока текущая структура команд актуальна и приносит пользу.

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

Ну, а дальше уже, чем лучше мы продуктом решаем задачу клиента, тем он счастливее, а значит и фин.результат будет выше.

Спасибо, продолжаем тюнить конфигурацию, но основной фундамент заложен.

Спасибо, что читаете :)

Спасибо, что поделились.

Очень сжатая программа. Для галочки, что поучился на продакта хватит, но для понимания профессии явно нет.

Я вот тоже этого боюсь...

Кайфово, спасибо! А где-то еще учился?

Рады стараться.

Поделитесь ссылочками, плиз, на курсы в ВШЭ за 40 тыс.на 8 месяцев. Интересно посмотреть.

Не слышал в комьюнити отзывы на них.

Проходил сам?

Согласен полностью. Очень прикладная штука в разных областях.

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

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