Продакт без продукта — не продакт

Отличается ли работа продакта, когда у него есть продукт, и когда продукта еще нет? И можно ли вообще назвать его продактом в таком случае? Присоединяйтесь к обсуждению. Вот мои мысли по этому поводу.

Думаю, что главное отличие — это наличие или отсутствие пользовательских данных.

— Делает большой упор на анализ рынка: конкурентов, спроса, объема, чтобы понять и ориентироваться в каком поле он будет работать.

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

— Плотно работает с аналитиком/ми (бизнес процесс для гипотез, анализ данных сущностей для интерфейса и БД, взаимодействие с тех. анализом и анализом ux) . Если их нет, то проводит эту аналитику. Результатом является пачка требований с оценкой сроков и стоимостью, распределенная по вехам и переданная в проектное управление. Если нет ПМ-а, то и управляет проектом)

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

— Ищет кратчайшие способы вывода продукта на рынок.

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

— Регулярно собирает данные продукта для формирования отчетов по метрикам. Делает расчеты, а из них делает выводы, что такая-то функция не отрабатывает правильно, такая-то работает хорошо, но могла бы лучше, тем самым запуская в работу котел разработки. Некоторые продукты настолько сложные и имеют настолько много данных, что потребность в написания SQL запросов и элементарных классов обработки на Python становятся необходимостью. Иначе данные для принятия решения об изменениях будут некорректными.

— Все, что не получается вытащить из данных собирается в интервью с пользователями, чтобы узнать их проблемы, в особенности почему они перестали платить или не хотят платить больше. Часть обнаруженных проблем можно передать на интервью UX-еру.

— Актуализировать данные рынка, делать переоценку спроса, изучать новые фичи конкурентов, быть в курсе трендов рынка своего продукта.

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

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

Первый больше в архитектуре, больше в подготовке продукта. Второй больше в данных, в подкрутке и докрутке, выводе новых фичей, чтобы повлиять на имеющиеся метрики, держать руку на пульсе каждый день. Открыл глаза — "что там с моим малышом, все ли работает".На самом деле их формат работы настолько отличается друг от друга, что если долго засидеться в одном формате, то можно напрочь отбить навыки для второго и наоборот.

Что думаете?

Ребят, подписывайтесь на канал нашей студии и стартапа. Я поднимаю темы управления продуктом, философии сознания, делюсь хаками управления компанией и командой простым языком, буднями душевной студии Пять утра)