что такое продуктовый подход в бизнесе
Продуктовый подход — польза и для бизнеса, и для разработчика
Я продуктовый разработчик, но так было не всегда. Лет 5 назад я впервые услышал фразу «продуктовая разработка», но я тогда не совсем понимал, что это значит. Мне говорят — вот у нас продукт, ну а я пишу код и пишу, чего такого-то. Есть ТЗ — и славно, нет ТЗ — как говорится, и результат будет ХЗ
Но это на самом деле своего рода проектный подход. Вот есть у вас ТЗ, а за ним — много тяжелой, усердной работы. Люди упорно гребут, в голове у них только код. Потом проект закончился, все молодцы.
Потом что-то поменялось в моей работе — ТЗ не стало. Это такой следующий шажок. Вот мы в продукте работаем, а теперь у нас еще и ТЗ нет. И что делать? Началось осознание того, что происходит.
Во-первых, продукт не имеет четкого начала и конца. Нет каких-то границ. Вот в проекте у нас были границы. Например, количество функций, которые нужно сделать, количество разработчиков, которые работают над проектом, дедлайны всякие, когда проект должен закончиться. У продукта же таких границ нет, он живёт, и его надо развивать.
Приходит к нам бизнес и говорит — давайте экономить. Конкретно на SMS и на платежной форме. Мы соглашаемся. У нас так вышло, что в тот момент наша команда знала продукт лучше, чем владелец продукта, так бывает. Мы знали особенные кейсы, мы знали, что мы где-то лишних SMS немного тратим. А значит, примерно знали, где можно что поделать.
Так что мы взяли спринт на анализ, и за этот спринт мы не написали ни строчки кода. Вообще.
Зато мы много общались, много обсуждали, брейнштормили, накидывали гипотезы, оценивали их, предлагали, что можно сделать. Мы находили сценарии, где отправляются лишние смски, прикидывали, сколько этих SMS лишних мы отправляем. Мы же знаем стоимость одной SMS и, соответственно, знаем, сколько мы можем сэкономить. И по каждому сценарию примерно прикидывали, сколько будет стоить всё это сделать.
Затем мы из этих задач выстроили роадмап. В начало поставили такие низковисящие фрукты, которые легко сделать и которые дают явный эффект. А в конец — задачки посложнее, у одних из них эффект был послабее, а у других — более заметный.
Примеры задач
Например, вот задачка совсем простая. Есть пользователи, которые в настройках поставили галочку «логиниться только по паролю». А мы им зачем-то предлагаем логиниться по SMS. И они зачем-то эти SMS отправляют. Потом они вводят SMS, а потом они еще вводят пароль, хотя SMS можно было не вводить вообще. И пофиксить этот сценарий — это просто, что мы первым делом и сделали.
А вот посложнее задачка — перевести все SMS на пуши. Задачка достаточно грандиозная, у нас до сих пор идут работы, чтобы зафиналить этот перевод, потому что там много рефакторингов было, и мы написали много новых микросервисов и новые хранилки.
Вот мы написали роадмап, декомпозировали его, прикинули, составили план для каждой задачки, стали делать. Планомерно каждый спринт делали какую-то задачку, которая часть SMS срубала. И смотрели в реалтайме прямо на график, как меняется количество SMS. Мы видели, что продукт экономит. Прямо на глазах. Экономит — значит зарабатывает. Вот я смотрю на график и понимаю, что мы окупились в этот же спринт. Это очень круто по бизнес-эффекту. И понимаю, что мы как команда полезные. Мы окупаемся.
И еще на будущее вперед. Это же долгоиграющая штука, мы же теперь каждый месяц экономим много-много SMS. Меня лично это ощутимо мотивирует. И я очень рад осознавать, что я полезный.
Плюсы подхода
У этого подхода (когда разработчика пускают на ранний этап) есть несколько плюсов и для бизнеса, и для самих разработчиков.
Я начну с плюса для бизнеса. Разработчик может предложить решение по принципу Парето. То есть за 20% времени можно сделать 80% бизнес-эффекта, и бизнесу это в большинстве случаев ОК. Можно на раннем этапе привлечь разработчика и ограничить какое-то количество функциональности, чтобы сделать ни больше и ни меньше.
Разработчик, допустим, такой вот грамотный парень, бизнес-ориентированный, который понимает, зачем, что, как внутри рефакторить, он может предложить такой рефакторинг, который откроет портал в инженерный рай и оттуда начнут сыпаться фичи. Сами.
То есть не просто там кодить какие-то технически упоротые вещи, а именно сделать рефакторинг ради бизнеса. Ну мы так открыли портал в инженерный рай и оттуда насыпалось на форму оплаты несколько новых фич. Среди них — новый способ оплаты, да еще и пару багов пофиксили одним рефакторингом.
А ещё разработчик может на раннем этапе оценить стоимость разработки задачи. Понятно, что если это какая-то нереальная вещь, у нее сомнительный бизнес-эффект, ее можно дальше не прорабатывать и не собирать для нее какие-то бизнес-требования, а просто отложить и пойти дальше, что-то более приоритетное взять.
Разработчик, у которого есть знание доменной области и знание SQL, может посчитать количество SMS, которые отправляются в месяц по какому-то сценарию. И исходя из этого количества SMS можно понять, сколько денег эта задача принесет. То есть бизнес-эффект тоже можно оценивать с помощью разработчика. Причём для этого не нужен какой-то отдельный аналитик. Понятно, что разработчик это сделает с какой-то погрешностью, но все-таки это возможно.
Обычно у фронтендеров такой майндсет и такая насмотренность, что они могут набросать макет. А если этот человек в офисе, то он может этот макет людям показывать и проводить коридорное тестирование. Тоже плюс.
Самый главный пункт, на мой взгляд, это когда мы в команде задачу сами придумали, когда мы ее сами декомпозировали, предоценили, потом мы ее взяли делать, потом мы ее довели до продакшена и еще собрали постоценку (в идеале). Тут есть ощущение, что вот это моя фича, это наша задача, она становится частичкой нас. И отсюда большая мотивация, чтобы задачу протащить через все этапы, чтобы везде ее сопроводить, и в конце концов понять — была ли твоя работа полезной.
Отсюда следует первый плюс для разработчика — это дополнительная мотивация. Как я и сказал, когда я задачу прорабатываю, я с ней сближаюсь и хочу ее делать. И другие задачи я тоже хочу делать. Это работает сильнее, чем зарплаты и прочее. Вот просто хотеть делать задачи, чтобы чувствовать себя полезным.
Следующее — это прокачка скиллов. И хард-скиллы типа SQL, и софт-скиллы. Некоторым разработчикам сложно выйти из команды, чтобы пойти куда-то там наружу с другой командой договариваться. И вот это очень хороший толчок к развитию этого навыка.
Отдельным пунктом я вынес прокачку бизнес-мышления. Это очень важный навык для продуктового разработчика и не только. В принципе, если вы хотите основать стартап или занять ведущую роль в стартапе или в Big Tech компании, то понимать бизнес, понимать, как это работает на всех этапах, это прямо обязательно. И продуктовая разработка такого плана, когда ты задачу сам придумываешь и сам предоцениваешь, она заметно способствует тому, чтобы прокачаться в бизнес-мышлении.
Следующий пункт — нетворкинг. Когда человек идет из команды с кем-то общаться — с инфобезопасниками, с юристами, еще кем-то внешним — он приходит к людям, знакомится с ними. И в следующий раз, когда он к ним приходит, они знают, зачем он пришел и что ему надо, и многие вопросы решаются гораздо легче.
Ещё один пункт, я уже говорил про мотивацию, но есть еще мотивация другая. Когда приносишь больше пользы продукту, можно рассчитывать на взаимность. Когда есть реальный измеримый в деньгах эффект от твоей работы, можно рассчитывать и на какой-то быстрый хороший карьерный рост, на какую-то хорошую зарплату, и вот эта внутренняя мотивация — это тоже такое вознаграждение.
И последний пункт. Просто нравится. Попробуйте, может, вам тоже понравится.
Но есть нюансы
Мы в команде начинаем с того, что придумываем, а заканчиваем тем, что выкатываем в прод. А это же новые зоны ответственности, мы их раньше не брали на себя, и надо сделать это более качественно.И я тут не только про отсутствие багов, а больше про качественную предоценку и подготовку задач. У нас для того, чтобы сделать качественно, есть инструменты.
По сути, это чеклисты. Я рекомендую эти инструменты, даже если у вас не скрам, не аджайл, если вы вот это все ненавидите. Инструменты скрамовские, но вы можете их применять, даже если у вас вотерфолл — они просто помогут. Это не какие-то ограничители, это шпаргалки.
Вот есть шпаргалка для проработки задачи. Definition of Ready for sprint. Этот чеклист мы писали сами.
Это шпаргалка, но это не барьер. Мы можем на него посмотреть и подумать, что по задачке можно еще поделать предварительно, чтобы ее успеть в спринте. Но если владелец продукта говорит — надо, мы соглашаемся, мы ее возьмем, но мы ни на что не коммитимся.
То есть с большой вероятностью там вскроется какая-то неизвестность в спринте, которая нас затормозит, и мы что-то не сможем. Увы, такое бывает. Но не барьер, это важно.
А вот Definition of done — это барьер. Что такое Definition of done?
Бывает же, что программист говорит: — Я сделал.
А у него спрашивают: — Что ты сделал?
Отвечает: — Я код написал.
Если программист говорит, что он написал код, это даже не всегда значит, что он его отладил. Но для бизнеса нет никакой ценности от написанного кода. Просто написанного кода. Потому что нужно еще отладить, поревьювить, поправить после ревью, оттестировать, вывести в продакшен, обвесить мониторингом и собрать постоценку. Это в идеале.
DoD — чеклист, который позволяет договориться, когда говорить “Сделано” по задаче. Про DoD я сказал, что это барьер. Почему барьер? Потому что мы договорились с бизнесом, что мы продукт поддерживаем вот на таком уровне качества, не ниже. Этот чеклист — он про фиксацию уровня качества. Не Definition of Done команды, не Definition of Done компонента, а Definition of Done всего продукта.
И если мы что-то по Definition of Done, не успели за спринт сделать — печальная ситуация, но бывает. То мы берем эту несделанную работу и кладем ее в бэклог. И продакту нужно понимать, что есть некоторая несделанная работа, техдолг. Что ее придется потом когда-то сделать. А если ее не делать, она нас в будущем затормозит.
Мы все делаем сами. И чеклисты мы сами составляли, и процессы мы можем сами двигать как-то, если видим потребности, мы сами прорабатываем задачу, мы сами катим ее в продакшн, мы сами собираем постоценку.
Через это мы получаем некоторые профиты. Пять лет назад я не особо задумывался, пишу код и пишу. Это когда ты приходишь, в 9 утра начинаешь писать код, в 6 вечера можешь закончить и уйти домой.
Потом что-то менялось, и в какой-то момент пришло осознание — то как мы работаем, то зачем мы на работу приходим, оно очень сильно влияет на качество нашей жизни в целом.
На ментальное здоровье, на физическое здоровье, на отношение с близкими. Мы на работе проводим 80% времени. И очень важно то, как мы на работе кайфуем.
Я вам очень советую задуматься о ваших рабочих процессах и попробовать взять на себя больше ответственности по задачам. Вы можете попросить об этом своих тимлидов и менеджеров. А если вы сами тимлиды, то вы можете эту ответственность ребятам дать.
Если вам интересен взгляд на продуктовую разработку изнутри — подписывайтесь на мой TG-канал «Product Developer».
Продукт VS проект: отличия подходов
На связи Factory5 (входит в группу Ctrl2GO) — российский разработчик аналитических решений для бизнеса на базе умных алгоритмов обработки данных. У нас в компании есть опыт объединения двух разных команд, и мы хотели бы им поделиться. С одной стороны, мы развиваем свой продукт, который активно распространяется через партнерскую сеть. И есть команда, которая этим занимается — продуктовая. С другой стороны, мы занимаемся коммерческой разработкой. И для этого тоже есть команда — проектная.
И там и там разработчики, тестировщики, devops-ы, аналитики, менеджеры. Они обмениваются знаниями, напитывают друг друга идеями. Продуктовая команда может передать проект для проверки технологических и продуктовых гипотез в проектную команду, а проектная — может сложить результат проекта как технологию в продукт. И то и другое вполне легально происходит, но вот люди из одной команды в другую не переходят никогда. Так как между ними есть большая разница. Она заключается и в процессах работы, и структуре, и целеполагании, и даже профиле новых кандидатов. Это бывает сложно объяснить тем, кто не погружен, но Резеда Несынова, исполнительный директор Factory5, разложила всё по полочкам.
Продукт и проект — основные отличия
Начнем с азов продуктовой и проектной разработки. Ниже — сравнительная таблица, которая поможет определить важные составляющие подходов, например, временные промежутки, наборы операций, команду и другое.
Платформа анализа больших данных производственных предприятий Factory5, созданная для повышения эффективности бизнеса за счет аналитики и управления данными — это продукт. А создание алгоритма оптимизации производственной программы, функционирующий на этой платформе, для конкретного клиента — это проект.
Решение для мониторинга эксплуатации и прогноза технического состояния оборудования — это продукт, а внедрить инструмент расчета остаточного ресурса газотурбинной установки у конкретного клиента — это проект.
По азам прошлись, а теперь попробуем погрузиться в это более детально. Рассмотрим, как строится процесс и работает команда, кто и за что несёт ответственность.
Объект управления
В проектном бизнесе объектом управления становятся проекты клиентов, идущие в определённом ритме. Рано или поздно каждый из них заканчивается, и результат проекта переходит в поддержку, либо передается в следующий проект для развития.
Задача руководителя — обеспечить максимальную, в идеале, конечно, стопроцентную, утилизацию ресурсов. Участники команды проекта задействованы неравномерно и не всегда 100% своего времени. Сотрудник может участвовать сразу в нескольких проектах — это возможность эффективно использовать ресурсы. Тут есть много нюансов и рисков, к этому нужно подходить правильно. Уверены, эта тема достойна отдельной статьи.
Создание продукта — это процесс, стремящийся к бесконечности. Объект управления — метрики успешности и качества продукта. Команда тоже работает ритмично, но эти ритмы складываются в циклы постоянного улучшения продукта. Схематично классический процесс продуктового управления выглядит так:
Для себя мы определили жесткое правило: между проектной и продуктовой разработкой нужно строить железобетонную стену, иначе срочные проекты гарантированно сместят все продуктовые задачи без заданного дедлайна «на потом». Ни один проект ещё никогда не шёл по плану, точнее шёл по плану, но только по другому.
В какой-то момент руководитель проекта, сроки которого горят, обязательно подойдёт к руководителю разработки продуктов со словами: «Спасай, мне нужны люди» или, что еще сложнее: «У меня есть контракт на много миллионов, давай сделаем».
Эффективность — на что ориентируемся
не превысить плановую себестоимость,
выполнить требования заказчика.
маржинальность, за счет монетизации и продвижения,
перспективы дальнейшего развития и тиражируемости.
Требования — как ими управлять
Проектная группа ожидает указаний заказчика, да бывает, что проектная команда может предложить какие-то решения, но конечное решение всегда за заказчиком. В любом проекте на старте мы получаем цель и требования к конечному результату, а зачастую заказчик диктует также методы и инструменты реализации.
А основная задача продуктовой команды — обнаружить проблему и потребности пользователей через мониторинг рынка, исследования, интервью с пользователями и так далее. Это главное отличие продукта от проекта. Команда ежедневно формирует гипотезы по развитию своего продукта и проверяет их с точки зрения влияния изменений в продукте или методах его продвижения на его масштабирование на рынок. Для этого используется множество различных методик: конкурентный анализ, аналитика рынка, customer development и др.
Как пример, в команде появляется гипотеза, что клиентам в продукте нужен определенный тип диаграмм. Дальше команда формирует перечень, интересующих нас клиентов, материал для представления — схемы, макеты, описание — планирует структуру интервью, определяют показатели, которые подтвердят или опровергнут их гипотезу и договаривается о встречах с клиентами. На основании проведенных интервью и анализа того, сколько дополнительной выручки мы сможем привлечь, принимается решение о реализации данного функционала в продукте.
Структура работы — как работаем
Реализацию проекта разбивают на маленькие задачи и выполняют их чаще всего последовательно. В целом, когда мы говорим о проектах для клиента — это перечень конкретных задач, сроки и методы реализации, о которых мы заранее договариваемся с заказчиком. Мы можем делать что-то параллельно и даже использовать методику работы по спринтам, но работы сдаются чаще всего по план-графику с жесткими сроками и стоимостью.
Основной принцип продуктовой работы — это проверка продуктовых гипотез, итерационная разработка и постоянный пересмотр приоритетов. Бэклог продукта имеет длину до луны и обратно, и задача менеджера не только генерить и проверять идеи, но и постоянно оценивать, какие из задач бэклога на текущий момент более приоритетные. А после сформировать стратегию релиза нового функционала.
Прежде, чем задача попадёт в бэклог, мы стараемся всеми правдами и неправдами проверить её до того, как начнется разработка. В ход идут и просто исследования, и ux-тестирования, а иногда приходится из дизайн макетов собирать прототип. Лишь после получения обратной связи от достаточного количества клиентов, гипотеза валидируется и берётся в разработку.
Таким образом, одновременно в продукте может быть в проработке несколько гипотез на разной стадии. Задача в разработку переходит тоже дополнительно обработанная. Сначала мы выделяем MVP — минимально-жизнеспособный продукт, который проверяется на некотором количестве клиентов. Если показывать схематично, то работа с продуктом выглядит так:
На данный момент многие проекты используют концепцию MVP в рамках реализации каждой функциональности. И это помогает избежать лишних затрат на разработку ненужной или неэффективной функции, тем самым снижая себестоимость проекта и повышая удовлетворенность клиента.
Ответственность — кто за что отвечает
В проекте клиент берёт на себя ответственность за выбор цели. Задача подрядчиков в данном случае быть профессиональными, быстрыми и системными в достижении этой цели. Не исключено, что команда проекта и клиент могут стать партнерами, которые договариваются об общих целях и способах их достижения, но окончательный выбор всегда за заказчиком.
В создании продукта за постоянный выбор и проверку цели несёт ответственность команда. Среди противоречивых требований и ожиданий многочисленных потребителей важно выявлять те, что позволят максимально масштабировать продукт. Клиенты в данном случае не разделяют с вами ответственность за результат. Продуктовая команда отвечает за окупаемость и масштабируемость, приоритеты в разработке, сервис, продвижение и выбор между быстрыми деньгами и долгосрочным развитием.
Особенности работы в продукте и проекте
Сравним, как отличается работа в продукте и проекте для команды. Возьмем за характеристики временные промежутки для работы, формат работы — постоянный, параллельный, переменный — время достижения результата и другое.
Проект не равно продукт
Есть мнение, что результатом проекта является продукт. Это не правда.
Если такое случается, то очень редко, как встретить настоящего единорога в парке Горького. И вот почему:
Проект ориентирован на одного клиента и его специфические требования.
Проект очень редко учитывает требования надежности и безопасности, необходимой для выхода на рынок.
ПО не становится продуктом пока не обрастет артефактами, необходимыми для вывода его на рынок:
материалы для продаж,
настроенная служба поддержки и т.д.
Для упаковки ПО в продукт, даже если Вам повезло и по результату проекта получился универсальный функционал, в любом случае нужны вложения и перестройка всех процессов компании для непрерывного развития продукта. После проекта, скорее всего, может появиться технология, которой ещё нужны клиенты и дополнительная ценность.
Резюмируем
В проектной работе вас ждут быстрые результаты, драйв от жёстких дедлайнов, работа в режиме многозадачности, следование требованиям клиента и ограничения в ответственности.
В продуктовой же разработке время уделяется генерации идей, здесь есть причастность к чему-то большому и значимому, много работы в неопределенности и условиях изменяющегося рынка и ответственность за свои решения.
Продуктовый подход: польза для бизнеса и компаний
Спрос на внедрение продуктового подхода — важный тренд для финансовых компаний, поскольку темп развития рынка финтех-услуг и конкуренция на нем сегодня запредельные. Почему ни один крупный банк не может быть успешным без сильной команды продакт-менеджеров, как можно обучить команду продуктовому подходу и чем практики продакт-менеджмента будут полезны в повседневной жизни, рассказал генеральный директор и сооснователь ProductStar Михаил Карпов.
«Горячие» задачи финтеха
Банковская сфера стремительно меняется прямо на наших глазах. Во-первых, перестраивается парадигма клиентского обслуживания: на смену традиционным офисам приходит гибридный формат, где большую часть вопросов решают уже даже не удаленные сотрудники, а искусственный интеллект. В банковский офис мы ходим все реже — подписать кредитные документы или забрать новый пластик. Во-вторых, располагая большими данными о клиентах, их предпочтениях и финансовых привычках, банки взяли ориентир на извлечение дополнительной выгоды из своей аудитории. Они выводят на рынок как новые услуги, так и собственные экосистемы сервисов из области телекома, медиа, доставки и многих других. Этой стратегии придерживаются все крупные игроки: «Сбер», «Тинькофф», ВТБ, Альфа-Банк, МТС Банк и другие. Продолжается процесс развития мобильных сервисов и продуктов: банкам важна продуктовая экспертиза и этого рынка.
Кроме того, увеличиваются объемы данных, а вместе с ними — стоимость решений, принимаемых руководителями отделов. Цена ошибки высока, поэтому растет популярность принятия решений на основе больших данных и глубокой аналитики. Это снижает риски человеческого фактора и делает шаги по развитию продуктов более взвешенными и точными.
Также от банков требуется держать баланс между стабильностью сервисов и безопасностью данных, чтобы все работало надежно и без сбоев. При высокой скорости разработки требования к продуктам очень высокие, поэтому для их создания требуются принципиально иные подходы. В этой новой реальности продакт-менеджер становится центральным звеном, который может обеспечить гибкую разработку и выход успешных продуктов на рынке. Чтобы перестроиться, этому можно и нужно учиться.
Зачем нужны продакт-менеджеры в финтехе?
Менеджер по продукту в финтех-компании — это своеобразный «бизнесовый осьминог». Ему важно балансировать как с развитием и усилением текущих банковских сервисов, так и анализировать рынок, придумывая и реализуя с командой новые продукты. Также во многих компаниях принято совмещать роли продуктового и проектного менеджера: таким образом, продакту важно не только заниматься бизнесовой концепцией, но и контролировать ее непосредственную реализацию.
В финтехе есть своя, достаточно ярко выраженная отраслевая специфика, поэтому адаптация нового сотрудника здесь занимает больше времени. Часто компании предпочитают выращивать продакт-менеджеров внутри компании из других ролей — проектных менеджеров, представителей бизнеса, иногда и из маркетологов или тимлидов команд разработки. При переходе в финтех-сферу менеджерам по продукту чаще всего приходится подтягивать навыки работы с большим числом бизнес-заказчиков, разбираться с существующей и часто нетривиальной IT-инфраструктурой, а также понимать нюансы, термины и подходы работы в данной отрасли.
Для старта карьеры в финтехе я чаще всего рекомендую продакт-менеджерам изучить те компании, в которых продуктовый подход внедрен свыше трех лет, а в команде работает минимум десять таких специалистов: как правило, это является опережающим показателем того, что в компании развиваются продуктовая культура и ценности, а значит, новичок сможет быстрее разобраться в отрасли, ему будет у кого поучиться продакт-менеджменту. Далее, по мере роста в сторону менеджера по продукту среднего звена, можно уже выбирать дальнейшую карьерную развилку — расти в компании в сторону управления группой продуктов или, наоборот, посмотреть себе место в каком-то из зарождающихся финтех-стартапов с небольшой, но быстро развивающейся командой.
Многие крупные компании отправляют своих сотрудников на корпоративные программы, чтобы обучить их продуктовому подходу. Приведу пример. В таком индивидуальном ключе мы сотрудничали со «Сбером», ВТБ, «Тинькофф», Raiffeisen, Газпромбанком, Альфа-Банком, «Ренессанс Капиталом», банком «Открытие», Росбанком, ЦФТ, «Яндекс.Деньгами» и рядом других организаций.
Что получают те, кто проводит обучение сотрудников продуктовому направлению?
Ключевые показатели для компаний — это ускорение адаптации новых специалистов в роли владельца продукта, а также синхронизация внутри команды общих продуктовых понятий, подходов и навыков. Все это увеличивает скорость и продуктивность работы команды над развитием продуктов.
База продуктового подхода — гибкость, понимание IT-сферы, знания инструментария анализа пользователей и принятие решений на основе больших данных. Специальные знания раньше были только у людей с должностью big data product manager (продакт-менеджеры, кто работает с большими данными), но в ближайшем будущем эти навыки понадобятся всем. Скоро в руководстве банков не останется менеджеров, не понимающих основ продуктового подхода. Но он нужен не только им, а всей команде в целом: тогда все сотрудники будут понимать, в чем состоит цель компании и как конкретно их действия ведут к общему результату.
Продуктовый подход делает цифровую трансформацию компаний проще, страхует риски за счет фокуса на данных. Когда он становится частью культуры бизнеса, сопротивление сотрудников снижается: наоборот, у них появляются новые идеи. Чтобы пройти цифровую трансформацию и выжить в конкурентной гонке, банкам нужно будет приложить усилия по переобучению сотрудников и найму новых. Только это поможет им встроиться в активно формирующуюся цифровую экономику.
Как применить практики продакт-менеджмента в жизни
Сами методы продуктового подхода применимы и вне рабочего поля — при улучшении личных и бытовых задач. Любые ситуации, будь то планирование путешествия, помощь семье, занятия спортом, можно рассмотреть как продукт и выбрать для них подходящее решение.
Важно учесть ключевые части продуктового подхода, понять, что является минимально жизнеспособной версией вашего продукта для быстрой проверки гипотезы (например, чтобы по полгода не готовиться к каким-либо соревнованиям, а потом понять, что они вам не интересны). Выяснить, кто является пользователем вашего продукта (лично вы, семья, другие люди) и научиться регулярно получать от них обратную связь для улучшения качества вашего продукта.
Сделать фокус на измеримые цели, внедрить регулярную аналитику для поиска точек роста и развития. Как продукт можно рассмотреть и самого себя: вашу карьеру, личностное и физическое развитие, а затем построить стратегию развития своих характеристик. Здесь методы продуктового подхода тоже станут хорошей основой для проведения изменений.
Практики продакт-менеджмента можно использовать при старте собственного бизнеса — они помогают максимизировать вероятность успеха: от выбора ниши до первых денег. Также их используют, чтобы продвинуться по карьерной лестнице или улучшить результаты своего бизнеса: владение основами продуктового подхода высоко ценится в современных компаниях.
Мнение автора может не совпадать с мнением редакции