Продукт и проект в чем разница
Продукт не проект!
К этой статье меня подтолкнул большой перекос, который я вижу в массовом сознании и сознании профессионального сообщества менеджеров IT компаний. Увы, сайтов про управление проектами море, а про управление продуктами — кот наплакал.
Это как если бы было море книг, тренингов, целых институтов о том, как правильно ходить, и ни одной брошюрки про то, как выбрать направление пути.
В книгах по управлению проектами (особенно для новичков) авторы очень любят начинать с тезиса о том, что мир состоит из проектов, проекты везде. Готовите еду — проект, лечитесь у доктора — проект, ковыряетесь в носу или занимаетесь любовью, даже отпуск — всё проекты.
Конечно музыкант и в повседневной жизни повсюду слышит музыку, кинооператор выстраивает кадр, а парикмахер опознает людей по прическе. Но с проектным мышлением и проектной терминологией мир сошел с ума зашел слишком далеко.
Дальше я приведу несколько примеров, чем это вам может грозить.
Затевая очередную авантюру, мы говорим, что начинаем проект. Рассказывая другу о каком-то сайте, мы называем его проектом. На собеседовании рассказываем о проектах, над которыми работали.
Проектами называют организации, изобретения, дома, пароходы, музыкальные и различные группы, художественные произведения, фильмы, программные продукты, документы, иллюстрации и многое многое другое.
За простым изменением текста часто явно или неявно скрывается мина замедленного действия, корень которой — в изменении смысла и восприятия.
Ликбез
Что такое проект? Проект это деятельность (процесс), определяющийся тремя главными свойствами:
Что такое продукт? Продукт это нечто (часто результат чьего-то труда), что продается, покупается и используется.
Еще проще: проект — это процесс, продукт это результат.
So what?!
Мы (люди, организации с которыми и в которых я работал, о работе которых я знаю не по наслышке) слишком часто излишнее внимание уделяем процессу, а не конечному результату. Без хорошего процесса сложно получить хороший результат, но результат гораздо важнее.
1. Live long and prosper или рукописи не горят
Любому проекту всегда приходит конец. Действительно успешные продукты обычно переживают своих создателей (вспоминаем Джобса, Диснея, фараонов с их пирамидами, Христа с его учением и так далее вплоть до известных ученых, изобретателей).
Мысля в пространстве проекта, вы невольно настраиваете себя на то, что все это рано или поздно кончится. Но с концом одного проекта в реальной жизни все только начинается (если вы не плохонький аутсорсер, которому надо побыстрее избавиться от очередного заказа).
Мысля продуктом, вы подталкиваете свой мозг заглядывать чуть дальше, мысленно пропуская сам процесс достижения результата. Как будто он уже пройден.
2. Show me the f*cking money!
Никто в наши дни не плачет по несчастным толпам рабов, погибших на строительстве пирамид и других чудес света. Никто не пытается выяснить какова была эффективность производства. Но все восхищаются результатом.
Никто не покупает помидоры за тысячу рублей, если рядом продаются такие же за сто. Не смог уложиться по себестоимости в цену конкурентов — ты прогорел, но это твои проблемы. Человек всегда покупал и будет покупать продукты, оптимальные по его личным критериям цена/качество/удовлетворенность, мало задумываясь о том, какой процесс привел к этому результату.
Рассуждая о том, что вы делаете как о продукте, вы чаще становитесь на тот же берег реки, где стоит ваш покупатель. И чаще задаетесь ключевыми вопросами (каким должен быть продукт? сколько он должен стоить? как нам его продавать? кому он нужен? куда его развивать?) и под эти ответы подстраиваете ваши процессы, а не наоборот.
3. Продукт это конкретно
Проект может умереть, едва начавшись, а может длиться вечно, он может быть хорошим, плохим, замороженным, запутанным, затянутым, интересным, унылым, тяжелым, дорогим, сложным, дешевым, а нередко сначала дешевым и интересным, а потом внезапно унылым и дорогим…
А продукт либо есть, либо нет.
Проект это абстракция для большой совокупности процессов, это довольно тонкая и сложная материя. Ее не просто объективно и конкретно оценивать, описывать и управлять. Для этого и существует отдельная дисциплина на грани искусства «проектное управление», а вы как думали!
А продукт либо есть, либо его нет. Он может быть плохим, хорошим, удачным, глючным, неактуальным, синеньким, неработающим, великолепным и т. д. С ним тоже не все так просто.
Но грань между «продукт готов» или «не готов» гораздо четче. И это дает гораздо более точно понимание и оценку мира: насколько мы хорошо делаем работу, идем к цели. Если наша конечная цель — какой-то продукт.
4. Хороший проект не гарантирует нужный результат
Более того, иногда хороший результат получается не благодаря, а вопреки процессу. Одна из причин этого творческая природа процесса разработки софта: по внутренним механизмам это гораздо ближе к созданию картины или кинофильма, чем к строительству типовых коттеджей.
Можно взять проверенный сюжет, нанять крутых спецов, вложить много денег в продвижение и получить полный провал (пруфлинк раз и два), а можно на пустом месте создать шедевр (раз и два).
Опасность в том, что критерием успешности какого-то предприятия может стать качество проекта — насколько круто мы «скрамимся», как чудно у нас рисуются диаграммы, как великолепно документируется код и шикарно налажена коммуникация с юзабилистами.
Это может дать ложное ощущение того, что все идет хорошо. Что движемся верной дорогой к правильной цели. Обдумывать саму цель, сам продукт при этом уже лень либо некогда: ни на стратегическом, ни на тактическом уровне.
Наглядные примеры (помимо голливудских, указанных выше): третий рейх, СССР, многие дотком-баббл стартапы и т. д.
Все это крутится вокруг одного простого наблюдения-вывода: на самом деле мир состоит из продуктов. Даже ты, дорогой читатель, продукт любви своих родителей.
Помните о том, что в вашем деле сейчас важнее — процесс или результат.
Проект vs продукт: такая ли существенная между ними разница
С развитием продуктового мышления и применения продуктового подхода к разработке количество статей на различных ресурсах про отличия проекта и продукта увеличилось в несколько раз.
Специалисты начинают изучать новые для себя направления и погружаться в суть вещей, отказываясь от формы и красивых названий. Однако, в России продуктовый подход еще недостаточно распространен, поэтому, очень часто, он рассматривается просто как работа с аналитикой и проведение опросов пользователей продукта и происходит подмена понятий.
Теперь же к нашей теме: проект vs продукт, в чем отличия и такая ли огромная между ними пропасть. Нужно подчеркнуть тремя жирными линиями, что мы рассматриваем эти понятия с точки зрения IT-сферы. Потому что булочки, например-это продукт, а выпекание хлеба-проект (хотя я и не согласна с этим), но нас это не сильно интересует.
В интернете можно найти уйму отличий проекта от продукта. Иногда они оформлены в красивые таблички, как, например, вот эта (очень вероятно, что ее вы уже видели):
Многие авторы рассматривают проект именно как процесс (разработка сайта, организация логистики и т.д., как описано в табличке выше), я же согласиться с этим не могу.
Проект так же имеет какой-то конечный результат, а разработка сайта (по своей сути) – это именно процесс. Процесс достижения этого конечного результата.
Это часть проекта, как и продукта. Приходим к тому, что проект и продукт состоят из процессов, очень часто схожих, но по-разному детализированных. Соответственно, мы уже не можем рассматривать какой-либо процесс только как проект (как в табличке выше, где одно из главных отличий проекта от продукта – результат).
Последний вопрос – наиболее актуален в данной теме и крутится в моей голове уже несколько месяцев и после ответа на него можно сделать вполне закономерный вывод: любой проект должен стремиться к тому, чтобы стать продуктом, чтобы быть «увековеченным» в мобильных телефонах/планшетах/ноутбуках пользователей, чтобы постоянно развивать его.
Почему никто не рассматривает эту сторону?
Я думаю, это связано с несколькими взглядами на сами понятия продукта и проекта (конечно, можно обращаться к таким авторитетным изданиям, как PMBook, однако всех вопросов это не разрешит). Проект – как процесс, продукт – как результат. Продукт состоит из проектов (= процессов). Тогда одно – лишь составная часть другого и сравнивать их не имеет смысла (но это необязательно, ведь бывают проекты, по окончанию которого результатом будет не часть продукта, а что-либо другое).
Можно сказать, что проект и продукт – разные стадии развития одного и того же. Со своими процессами, организацией работы, команды и т.д., но суть одна – проект должен стремиться к тому, чтобы стать продуктом.
Продукт VS проект: отличия подходов
На связи Factory5 (входит в группу Ctrl2GO) — российский разработчик аналитических решений для бизнеса на базе умных алгоритмов обработки данных. У нас в компании есть опыт объединения двух разных команд, и мы хотели бы им поделиться. С одной стороны, мы развиваем свой продукт, который активно распространяется через партнерскую сеть. И есть команда, которая этим занимается — продуктовая. С другой стороны, мы занимаемся коммерческой разработкой. И для этого тоже есть команда — проектная.
И там и там разработчики, тестировщики, devops-ы, аналитики, менеджеры. Они обмениваются знаниями, напитывают друг друга идеями. Продуктовая команда может передать проект для проверки технологических и продуктовых гипотез в проектную команду, а проектная — может сложить результат проекта как технологию в продукт. И то и другое вполне легально происходит, но вот люди из одной команды в другую не переходят никогда. Так как между ними есть большая разница. Она заключается и в процессах работы, и структуре, и целеполагании, и даже профиле новых кандидатов. Это бывает сложно объяснить тем, кто не погружен, но Резеда Несынова, исполнительный директор Factory5, разложила всё по полочкам.
Продукт и проект — основные отличия
Начнем с азов продуктовой и проектной разработки. Ниже — сравнительная таблица, которая поможет определить важные составляющие подходов, например, временные промежутки, наборы операций, команду и другое.
Платформа анализа больших данных производственных предприятий Factory5, созданная для повышения эффективности бизнеса за счет аналитики и управления данными — это продукт. А создание алгоритма оптимизации производственной программы, функционирующий на этой платформе, для конкретного клиента — это проект.
Решение для мониторинга эксплуатации и прогноза технического состояния оборудования — это продукт, а внедрить инструмент расчета остаточного ресурса газотурбинной установки у конкретного клиента — это проект.
По азам прошлись, а теперь попробуем погрузиться в это более детально. Рассмотрим, как строится процесс и работает команда, кто и за что несёт ответственность.
Объект управления
В проектном бизнесе объектом управления становятся проекты клиентов, идущие в определённом ритме. Рано или поздно каждый из них заканчивается, и результат проекта переходит в поддержку, либо передается в следующий проект для развития.
Задача руководителя — обеспечить максимальную, в идеале, конечно, стопроцентную, утилизацию ресурсов. Участники команды проекта задействованы неравномерно и не всегда 100% своего времени. Сотрудник может участвовать сразу в нескольких проектах — это возможность эффективно использовать ресурсы. Тут есть много нюансов и рисков, к этому нужно подходить правильно. Уверены, эта тема достойна отдельной статьи.
Создание продукта — это процесс, стремящийся к бесконечности. Объект управления — метрики успешности и качества продукта. Команда тоже работает ритмично, но эти ритмы складываются в циклы постоянного улучшения продукта. Схематично классический процесс продуктового управления выглядит так:
Для себя мы определили жесткое правило: между проектной и продуктовой разработкой нужно строить железобетонную стену, иначе срочные проекты гарантированно сместят все продуктовые задачи без заданного дедлайна «на потом». Ни один проект ещё никогда не шёл по плану, точнее шёл по плану, но только по другому.
В какой-то момент руководитель проекта, сроки которого горят, обязательно подойдёт к руководителю разработки продуктов со словами: «Спасай, мне нужны люди» или, что еще сложнее: «У меня есть контракт на много миллионов, давай сделаем».
Эффективность — на что ориентируемся
не превысить плановую себестоимость,
выполнить требования заказчика.
маржинальность, за счет монетизации и продвижения,
перспективы дальнейшего развития и тиражируемости.
Требования — как ими управлять
Проектная группа ожидает указаний заказчика, да бывает, что проектная команда может предложить какие-то решения, но конечное решение всегда за заказчиком. В любом проекте на старте мы получаем цель и требования к конечному результату, а зачастую заказчик диктует также методы и инструменты реализации.
А основная задача продуктовой команды — обнаружить проблему и потребности пользователей через мониторинг рынка, исследования, интервью с пользователями и так далее. Это главное отличие продукта от проекта. Команда ежедневно формирует гипотезы по развитию своего продукта и проверяет их с точки зрения влияния изменений в продукте или методах его продвижения на его масштабирование на рынок. Для этого используется множество различных методик: конкурентный анализ, аналитика рынка, customer development и др.
Как пример, в команде появляется гипотеза, что клиентам в продукте нужен определенный тип диаграмм. Дальше команда формирует перечень, интересующих нас клиентов, материал для представления — схемы, макеты, описание — планирует структуру интервью, определяют показатели, которые подтвердят или опровергнут их гипотезу и договаривается о встречах с клиентами. На основании проведенных интервью и анализа того, сколько дополнительной выручки мы сможем привлечь, принимается решение о реализации данного функционала в продукте.
Структура работы — как работаем
Реализацию проекта разбивают на маленькие задачи и выполняют их чаще всего последовательно. В целом, когда мы говорим о проектах для клиента — это перечень конкретных задач, сроки и методы реализации, о которых мы заранее договариваемся с заказчиком. Мы можем делать что-то параллельно и даже использовать методику работы по спринтам, но работы сдаются чаще всего по план-графику с жесткими сроками и стоимостью.
Основной принцип продуктовой работы — это проверка продуктовых гипотез, итерационная разработка и постоянный пересмотр приоритетов. Бэклог продукта имеет длину до луны и обратно, и задача менеджера не только генерить и проверять идеи, но и постоянно оценивать, какие из задач бэклога на текущий момент более приоритетные. А после сформировать стратегию релиза нового функционала.
Прежде, чем задача попадёт в бэклог, мы стараемся всеми правдами и неправдами проверить её до того, как начнется разработка. В ход идут и просто исследования, и ux-тестирования, а иногда приходится из дизайн макетов собирать прототип. Лишь после получения обратной связи от достаточного количества клиентов, гипотеза валидируется и берётся в разработку.
Таким образом, одновременно в продукте может быть в проработке несколько гипотез на разной стадии. Задача в разработку переходит тоже дополнительно обработанная. Сначала мы выделяем MVP — минимально-жизнеспособный продукт, который проверяется на некотором количестве клиентов. Если показывать схематично, то работа с продуктом выглядит так:
На данный момент многие проекты используют концепцию MVP в рамках реализации каждой функциональности. И это помогает избежать лишних затрат на разработку ненужной или неэффективной функции, тем самым снижая себестоимость проекта и повышая удовлетворенность клиента.
Ответственность — кто за что отвечает
В проекте клиент берёт на себя ответственность за выбор цели. Задача подрядчиков в данном случае быть профессиональными, быстрыми и системными в достижении этой цели. Не исключено, что команда проекта и клиент могут стать партнерами, которые договариваются об общих целях и способах их достижения, но окончательный выбор всегда за заказчиком.
В создании продукта за постоянный выбор и проверку цели несёт ответственность команда. Среди противоречивых требований и ожиданий многочисленных потребителей важно выявлять те, что позволят максимально масштабировать продукт. Клиенты в данном случае не разделяют с вами ответственность за результат. Продуктовая команда отвечает за окупаемость и масштабируемость, приоритеты в разработке, сервис, продвижение и выбор между быстрыми деньгами и долгосрочным развитием.
Особенности работы в продукте и проекте
Сравним, как отличается работа в продукте и проекте для команды. Возьмем за характеристики временные промежутки для работы, формат работы — постоянный, параллельный, переменный — время достижения результата и другое.
Проект не равно продукт
Есть мнение, что результатом проекта является продукт. Это не правда.
Если такое случается, то очень редко, как встретить настоящего единорога в парке Горького. И вот почему:
Проект ориентирован на одного клиента и его специфические требования.
Проект очень редко учитывает требования надежности и безопасности, необходимой для выхода на рынок.
ПО не становится продуктом пока не обрастет артефактами, необходимыми для вывода его на рынок:
материалы для продаж,
настроенная служба поддержки и т.д.
Для упаковки ПО в продукт, даже если Вам повезло и по результату проекта получился универсальный функционал, в любом случае нужны вложения и перестройка всех процессов компании для непрерывного развития продукта. После проекта, скорее всего, может появиться технология, которой ещё нужны клиенты и дополнительная ценность.
Резюмируем
В проектной работе вас ждут быстрые результаты, драйв от жёстких дедлайнов, работа в режиме многозадачности, следование требованиям клиента и ограничения в ответственности.
В продуктовой же разработке время уделяется генерации идей, здесь есть причастность к чему-то большому и значимому, много работы в неопределенности и условиях изменяющегося рынка и ответственность за свои решения.
Продукт VS проект: отличия подходов
На связи Factory5 — российский разработчик аналитических решений для бизнеса на базе умных алгоритмов обработки данных. У нас в компании есть опыт объединения двух разных команд, и мы хотели бы им поделиться. С одной стороны, мы развиваем свой продукт, который активно распространяется через партнерскую сеть. И есть команда, которая этим занимается — продуктовая. С другой стороны, мы занимаемся коммерческой разработкой. И для этого тоже есть команда — проектная.
И там и там разработчики, тестировщики, devops-ы, аналитики, менеджеры. Они обмениваются знаниями, напитывают друг друга идеями. Продуктовая команда может передать проект для проверки технологических и продуктовых гипотез в проектную команду, а проектная — может сложить результат проекта как технологию в продукт. И то и другое вполне легально происходит, но вот люди из одной команды в другую не переходят никогда. Так как между ними есть большая разница. Она заключается и в процессах работы, и структуре, и целеполагании и даже профиле новых кандидатов. Это бывает сложно объяснить тем, кто не погружен, но мы постараемся разобрать всё по полочкам.
Продукт и проект — основные отличия
Начнем с азов продуктовой и проектной разработки. Ниже — сравнительная таблица, которая поможет определить важные составляющие подходов, например, временные промежутки, наборы операций, команду и другое.
Платформа анализа больших данных производственных предприятий Factory5, созданная для повышения эффективности бизнеса за счет аналитики и управления данными — это продукт. А создание алгоритма оптимизации производственной программы, функционирующий на этой платформе, для конкретного клиента — это проект.
Решение для мониторинга эксплуатации и прогноза технического состояния оборудования — это продукт, а внедрить инструмент расчета остаточного ресурса газотурбинной установки у конкретного клиента — это проект.
По азам прошлись, а теперь попробуем погрузиться в это более детально. Рассмотрим, как строится процесс и работает команда, кто и за что несёт ответственность.
Объект управления
В проектном бизнесе объектом управления становятся проекты клиентов, идущие в определённом ритме. Рано или поздно каждый из них заканчивается, и результат проекта переходит в поддержку, либо передается в следующий проект для развития.
Задача руководителя — обеспечить максимальную, в идеале, конечно, стопроцентную, утилизацию ресурсов. Участники команды проекта задействованы неравномерно и не всегда 100% своего времени. Сотрудник может участвовать сразу в нескольких проектах — это возможность эффективно использовать ресурсы. Тут есть много нюансов и рисков, к этому нужно подходить правильно. Уверены, эта тема достойна отдельной статьи.
Создание продукта — это процесс, стремящийся к бесконечности. Объект управления — метрики успешности и качества продукта. Команда тоже работает ритмично, но эти ритмы складываются в циклы постоянного улучшения продукта. Схематично классический процесс продуктового управления выглядит так:
Для себя мы определили жесткое правило: между проектной и продуктовой разработкой нужно строить железобетонную стену, иначе срочные проекты гарантированно сместят все продуктовые задачи без заданного дедлайна «на потом». Ни один проект ещё никогда не шёл по плану, точнее шёл по плану, но только по другому.
В какой-то момент руководитель проекта, сроки которого горят, обязательно подойдёт к руководителю разработки продуктов со словами: «Спасай, мне нужны люди» или, что еще сложнее: «У меня есть контракт на много миллионов, давай сделаем».
Эффективность — на что ориентируемся
не превысить плановую себестоимость,
выполнить требования заказчика.
маржинальность, за счет монетизации и продвижения,
перспективы дальнейшего развития и тиражируемости.
Требования — как ими управлять
Проектная группа ожидает указаний заказчика, да бывает, что проектная команда может предложить какие-то решения, но конечное решение всегда за заказчиком. В любом проекте на старте мы получаем цель и требования к конечному результату, а зачастую заказчик диктует также методы и инструменты реализации.
А основная задача продуктовой команды — обнаружить проблему и потребности пользователей через мониторинг рынка, исследования, интервью с пользователями и так далее. Это главное отличие продукта от проекта. Команда ежедневно формирует гипотезы по развитию своего продукта и проверяет их с точки зрения влияния изменений в продукте или методах его продвижения на его масштабирование на рынок. Для этого используется множество различных методик: конкурентный анализ, аналитика рынка, customer development и др.
Как пример, в команде появляется гипотеза, что клиентам в продукте нужен определенный тип диаграмм. Дальше команда формирует перечень, интересующих нас клиентов, материал для представления — схемы, макеты, описание — планирует структуру интервью, определяют показатели, которые подтвердят или опровергнут их гипотезу и договаривается о встречах с клиентами. На основании проведенных интервью и анализа того, сколько дополнительной выручки мы сможем привлечь, принимается решение о реализации данного функционала в продукте.
Структура работы — как работаем
Реализацию проекта разбивают на маленькие задачи и выполняют их чаще всего последовательно. В целом, когда мы говорим о проектах для клиента — это перечень конкретных задач, сроки и методы реализации, о которых мы заранее договариваемся с заказчиком. Мы можем делать что-то параллельно и даже использовать методику работы по спринтам, но работы сдаются чаще всего по план-графику с жесткими сроками и стоимостью.
Основной принцип продуктовой работы — это проверка продуктовых гипотез, итерационная разработка и постоянный пересмотр приоритетов. Бэклог продукта имеет длину до луны и обратно, и задача менеджера не только генерить и проверять идеи, но и постоянно оценивать, какие из задач бэклога на текущий момент более приоритетные. А после сформировать стратегию релиза нового функционала.
Прежде, чем задача попадёт в бэклог, мы стараемся всеми правдами и неправдами проверить её до того, как начнется разработка. В ход идут и просто исследования, и ux-тестирования, а иногда приходится из дизайн макетов собирать прототип. Лишь после получения обратной связи от достаточного количества клиентов, гипотеза валидируется и берётся в разработку.
Таким образом, одновременно в продукте может быть в проработке несколько гипотез на разной стадии. Задача в разработку переходит тоже дополнительно обработанная. Сначала мы выделяем MVP — минимально-жизнеспособный продукт, который проверяется на некотором количестве клиентов. Если показывать схематично, то работа с продуктом выглядит так:
На данный момент многие проекты используют концепцию MVP в рамках реализации каждой функциональности. И это помогает избежать лишних затрат на разработку ненужной или неэффективной функции, тем самым снижая себестоимость проекта и повышая удовлетворенность клиента.
Ответственность — кто за что отвечает
В проекте клиент берёт на себя ответственность за выбор цели. Задача подрядчиков в данном случае быть профессиональными, быстрыми и системными в достижении этой цели. Не исключено, что команда проекта и клиент могут стать партнерами, которые договариваются об общих целях и способах их достижения, но окончательный выбор всегда за заказчиком.
В создании продукта за постоянный выбор и проверку цели несёт ответственность команда. Среди противоречивых требований и ожиданий многочисленных потребителей важно выявлять те, что позволят максимально масштабировать продукт. Клиенты в данном случае не разделяют с вами ответственность за результат. Продуктовая команда отвечает за окупаемость и масштабируемость, приоритеты в разработке, сервис, продвижение и выбор между быстрыми деньгами и долгосрочным развитием.
Особенности работы в продукте и проекте
Сравним, как отличается работа в продукте и проекте для команды. Возьмем за характеристики временные промежутки для работы, формат работы — постоянный, параллельный, переменный — время достижения результата и другое.
Проект не равно продукт
Есть мнение, что результатом проекта является продукт. Это не правда.
Если такое случается, то очень редко, как встретить настоящего единорога в парке Горького. И вот почему:
Проект ориентирован на одного клиента и его специфические требования.
Проект очень редко учитывает требования надежности и безопасности, необходимой для выхода на рынок.
ПО не становится продуктом пока не обрастет артефактами, необходимыми для вывода его на рынок:
материалы для продаж,
настроенная служба поддержки и т.д.
Для упаковки ПО в продукт, даже если Вам повезло и по результату проекта получился универсальный функционал, в любом случае нужны вложения и перестройка всех процессов компании для непрерывного развития продукта. После проекта, скорее всего, может появиться технология, которой ещё нужны клиенты и дополнительная ценность.
Резюмируем
В проектной работе вас ждут быстрые результаты, драйв от жёстких дедлайнов, работа в режиме многозадачности, следование требованиям клиента и ограничения в ответственности.
В продуктовой же разработке время уделяется генерации идей, здесь есть причастность к чему-то большому и значимому, много работы в неопределенности и условиях изменяющегося рынка и ответственность за свои решения.