При проектном мышлении мы отталкиваемся от боли каждого клиента. У каждого клиента она своя, поэтому каждый проект уникален. А продукт должен быть универсален. Он должен принести пользу как можно большему числу клиентов, а не покрыть боль одного. То есть, продуктовые мышление — умение сделать такой продукт, который удовлетворит потребности большей части рынка.
Нашим коллегам Александру Николаеву из практики BPM и Наталье Ждановой из практики LowCode удалось прокачать два этих паттерна — продуктовый и проектный. В статье они рассказали, в чем видят пользу каждого из типов мышления и как их развить.
Наталья Жданова
Руководитель направления продуктовой деятельности практики LowCode
Ранее я занималась проектами внедрения — вместе с командой мы делали продукты, которые были вспомогательными флагманскому Naumen Service Desk. Но они были «сырыми», в зачаточном состоянии, поэтому мы внедряли их как отдельные проекты. Затем к нам обратился большой клиент, которому нужно было реализовать визуальную аналитику. Тогда родилась идея создать целый продукт «Дашборды», чтобы он был полезен и другим клиентам. Так случился мой переход из проектного мышления в продуктовое.
Продукт с базовым функционалом создали быстро, далее начали развивать — внедрять новые фичи и давать клиентам больше пользы. Затем команда переросла в практику из десяти продуктов, а я теперь занимаюсь стратегией продуктового развития нашей практики.
На своем опыте я почувствовала разницу между проектным и продуктовым мышлением. Поделюсь своим видением.
Проектное мышление VS продуктовое
Проект — ограниченный по времени и бюджету процесс, у которого есть конкретное техническое задание. В проектной работе мы закрываем боль каждого клиента, поэтому проект — явление уникальное. Продукт, в свою очередь, должен быть универсальным и принести пользу как можно большему числу клиентов, а не покрыть боль одного.
В проектах быстро видны результаты: выполнил настройку — сразу получил обратную связь. А для получения фидбека в продукте должно пройти много времени: проверяешь гипотезы, создаешь, выводишь на рынок, продаёшь, ждешь, когда начнут использовать, и только потом получаешь отзыв. Поэтому мыслить «продуктово» сложнее. Важно предугадывать возможные проблемы и сделать такой продукт, который удовлетворит потребности большей части рынка.
Проект нацелен сиюминутно закрывать текущие боли клиента, а продукт живет длительно. Поэтому нужно постоянно валидировать ту ценность, которую вы дали продукту. Узнавать, не изменились ли потребности целевой аудитории, внедрять новые фичи.
Если вы хотите мыслить «продуктово», всегда сомневайтесь — не принимайте на веру все, что вам сказали, опирайтесь только на данные. Проверяйте гипотезы, чтобы добраться до истины. Также будьте заботливыми. Если есть желание принести пользу клиенту, закрыть не только те потребности, которые есть у него сегодня, но и те, что появятся завтра, то вы всегда будете исследовать — какой конкретно нужен функционал в продукте.
Как развивала продуктовое мышление
Продуктовое мышление приходит с опытом. Мне, например, удалось его развить при работе над дашбордами. Тогда я начала собирать требования с внутренних клиентов и проверять гипотезы: зачем нужна та или иная фича, какую проблему она решит и какую ценность даст. Поняла, что запросы разнообразны, а учесть их все невозможно, так как иногда они противоречат друг другу. Решать эти противоречия нужно с помощью исследования рынка, конкурентов и опроса заинтересованных лиц. Это сильно отличалось от проектной деятельности.
Чтобы начать погружаться в продуктовое мышление, рекомендую прочитать книгу Николая Молчанова «Человек покупающий и продающий. Как законы эволюции влияют на психологию потребителя и при чем здесь Люк Скайуокер». Автор на примерах объясняет, почему важно смотреть широко и мыслить не системно. Эту книгу я прочитала, когда только погружалась в продуктовую деятельность. Базовое понимание взяла оттуда: будьте любопытными и недоверчивыми, выясняйте, что, как, зачем и почему, тогда вы быстро прокачаете нужные навыки.
Ещё у меня есть кейс, как проверить, есть ли у вас продуктовое мышление. На собеседованиях часто задаю такой вопрос: «Представьте, что вы занимаетесь разработкой продукта. Приходит клиент и просит сделать доработку. Какие ваши действия?». Вопрос простой, но наглядно показывает, как мыслит человек. Если вы ответили так: «Выясню, для какой цели он просит этот функционал, пойду изучать рынок, общаться с клиентами и узнавать, кому еще нужна такая фича, а только потом реализовывать» — поздравляю, вы мыслите «продуктово»!
Александр Николаев
Руководитель группы бизнес-анализа практики BPM
Более пяти лет я работаю на проектах внедрения и обучаю этому junior-специалистов. Ранее я был руководителем продукта в Naumen Customer Engagement Center. То есть, переходил от проектного мышления к продуктовому и наоборот. Поэтому могу мыслить в двух этих паттернах :)
Проектное мышление VS продуктовое
В проектах мы с командой собирали и закрывали потребность каждого клиента. Позже проектов становилось больше, а качество терять не хотелось — хотелось выводить продукт на новый уровень и давать клиентам больше пользы. То есть, «продавать» ценность, а не часы работы.
В проектном мышлении мы добавляем фичу по просьбе клиента, а в продуктовом сначала проверяем ценность — копаем «вглубь» и выясняем, точно ли этот функционал закроет боль, принесет клиенту доход или уменьшит затраты. Для этого больше общаемся с конечными пользователями, выдвигаем и проверяем гипотезы, проводим кастдевы.
Продуктовое мышление — это умение создать полезный продукт и донести его ценность клиенту.
Приведу кейс «как делать не надо» из опыта нашей команды. Мы увидели, что на рынке набирает популярность Customer Experience и предположили, что рынок будет двигаться в сторону CJM в рамках компании. Подумали: «Как полезно! Можно будет отслеживать клиентский путь и помогать нашим заказчиками выбрать более эффективный канал коммуникации». Сломя голову начали реализовывать и демонстрировать фичу клиенту. В итоге оказалось, что этот функционал не нужен и он висит «обузой» в нашем продукте.
Но благодаря этому кейсу, мы больше не совершали таких ошибок. Например, недавно получили несколько запросов от клиентов, где они просили внедрить маркетинговые кампании. Прежде чем реализовывать, сформулировали гипотезу и пошли уточнять у других клиентов — нужна ли эта фича и в каком виде. Оказалось, что она востребована только как дополнительная функциональность. Клиент не готов покупать её отдельно от остальной части управления клиентским опытом и продажами. Мы выявили более важные фичи, которые помогут клиенту уже сейчас получить прибыль, и он готов купить систему с ними.
Конечно, мыслить «продуктово» не всегда бывает полезно — в проектной деятельности важно закрывать каждый запрос клиента. Но точно необходимо, если вы работаете над развитием продукта.
Как развивал продуктовое мышление
Я пошёл «плохим» путём. Учился на своих ошибках, как в примере выше. То есть, сделал неликвидную фичу → проанализировал, что пошло не так → пробовал ещё раз → получил результат → переиспользовал. Поэтому могу дать пару рекомендаций, которые помогут перейти на продуктовое мышление и не совершать для этого ошибок:
Главное: если вам не стыдно за первую версию продукта — вы уже опоздали. Важно понимать, что идея, которая пришла вам в голову, не доказана и неработоспособна до тех пор, пока ее не проверит рынок. Постоянно думайте, как улучшить продукт.
Фраза «Чем больше — тем лучше» не работает в продукте. Действуйте так: «Чем качественнее — тем лучше».
Чтобы сделать качественно, не внедряйте фичу, пока не проверите гипотезы и не проанализируете рынок. Сначала ценность, потом всё остальное.
Читайте ИТ-классику. Например, «Спроси маму», Роб Фитцпатрик или «На крючке. Как создавать продукты-хиты», Марти Кэган. Теория важна.
Исследуйте! Больше времени проводите за анализом конкурентов, рынка, новой фичи — это основа продуктивного мышления.
Комментарии (2)
itGuevara
06.05.2024 12:46На схожую тему пишу статью. Вот небольшой фрагмент:
Эволюция подходов и орг-штатных структур к управлению организацией (процессами организации)
1 Кустарный подход и мануфактура на примере ДоФордизма
Мелкосерийное производство, изготовление авто на заказ (не на склад). Бригада на первых этапах из «универсальных солдат» (Бригада-У, универсалы) – которые вместе собирают один автомобиль. Это высокопрофессиональные мастера, знающие процесс «сборки от и до».
Бригадир – фактически является владельцем процесса: управляет процессом (руководит), подсказывает (инструктор) и контролирует, оптимизирует процесс и т.п.
Более того, Бригадир – еще и владелец продукта, т.к. заказы индивидуальные и он с Заказчиком детально предварительно проговаривает все индивидуальные особенности заказа (авто). В зависимости от запросов заказчика типовой проект (регулярный процесс) авто мог трансформироваться в «целый проект».
Бригада-Ф (функциональное) уже имеет специализацию, кто-то лучше подгоняет детали между собой (не было стандартных, подгонка была индивидуальная и авто получались даже разных размеров), кто-то лучше регулирует сход-развал или работу двигателя и т.п. Однако это все равно было внутри одной бригады (без «функциональных колодцев»). Каждая бригада собирала свой автомобиль в рамках сквозного процесса (end-to-end), при этом могла получать обратную связь от заказчика на разных этапах производства.
Получается идеальный (абсолютный) «процессный подход», даже процессно-продуктовый, а в случае значительных изменений от типового варианта (стандартной конфигурации): проектно – продуктовый.
Пруфы - см. Вумек, Машина, которая изменила мир и т.п.
Вопросы по статье. К новомодному сегодня «продуктовому подходу»: 20-30 лет назад ровно те же «преимущества»:
а) ориентация на результат и клиенториентированность, б) процесс делится на подпроцессы, в рамках которых специалисты разных направлений вместе выполняют задачу в) много других общих и как-бы правильных фраз
приписывались Процессному подходу. Такое впечатление, что многим хочется продать тот же процессный подход, но в новой «продуктовой» упаковке (обертке).
В чем различие процессного и продуктового подходов? Без высокопарных слов.
Причем «хороший продуктовый подход» часто противопоставляется «плохому проектному», например:
Проект ориентирован на одного клиента и его специфические требования.
А как же типовые проекты?
Результат проекта - есть продукт (по ссылке утверждается, что нет)?
alexhott
Думал будет чета интересное а тут ни очем