Comments 8
Ложное впечатление складывается потому, что о b2c продакт-менеджменте много говорят. Помимо внутренних продуктов есть еще и b2b (особенно Enterprise), а также реальные продукты (производство). Это все большие пласты управления продуктами со своими подходами.
А еще я рекомендую не менять нишу. Если вам нравится работать с внутренними продуктами - работайте. Развивайте методику в них. Будьте экспертом. Хотя это и сложно, не втягиваться в движение CJM, MAU, "retention" и уж простите "юнит экономику"
Полностью согласен, что быть владельцем внутреннего продукта - это вам не это) Это ниша и она специфичная. Не могу назвать себя полноправным владельцем внутренних продуктах, но, скажем так, связан с этой областью. Поделюсь своими наблюдениями.
Тот факт, что продукт внутренний, не означает, что на рынке нет аналогов. Кто-то из пользователей работал на прошлом месте с "аналогом Jira", кто-то читал статьи, а кто-то возможно даже начал паралелльно использовать какой-то внешний или развёрнутый на коленке сервис. Все эти ситуации могут быть источником обратной связи и гипотез.
Крайне важно разделять роли заказчика (бизнес-владельца), спонсора и технического владельца (провайдера) сервиса. Это помогает снизить административное влияние на продукт. Если внутренний продукт решает задачи бизнеса, руководитель IT департамента не должен влиять на приоритезацию задач, например.
Эффективность автоматизаций. Имеет смысл оценивать изменение количества операций и занимаемое ими время. А после этого собрать обратную связь у пользователей и менеджмента: действительно ли высвободилось время и на что оно теперь тратится? Если благодаря вашей автоматизации пользоватли стали больше тусоваться на кухне, бизнес-выгода вашей автоматизации может быть низкой - и это может стать вашей проблемой.
Тикеты в саппорт и посещение страниц инструкций и т.п. В идеале задачи, поступающие в саппорт, должны соотноситься с сервисами команды. Анализ задач по продукту - также источник обратной связи. Причём не только со стороны пользователей. Например, стОит обратить внимание сколько времени уходит на решение у саппорта, как много задач проваливается вплоть до L3.
Из того, что сразу пришло на ум.
кажется, что для внутреннего трекера метрикой может быть стоимость решения по сравнению с джирой при сопостовимом функционале, потому как если внутренний трекер не дешевле, но кривее, то зачем?
это скорее может быть аргументом для решения идти вообще в разработку продукта или нет. А вот как отслеживать успешность или развитие продукта - вот это вопрос.
Я бы тут скорее пошёл в сторону оценки процессов планирования задач или ведения бэклогов, приоритизации и чего-то такого. т.е. из логики, что вести спринты - это необходимость для команд, а вот если сервис используют и для других задач - значит, он действительно удобный
Вообще, тема различий в приложениях для внешнего мира и для внутренних процессов компании очень интересна. Например, тот же мессенджер у них разные задачи и приоритеты. Предлагаю продолжить исследовать тему. Так держать!
«А вы точно продакт?»