Человек несовершенен, но тщательно старается об этом забыть. Даже в таких рациональных делах, как строительство, ведение бизнеса и создание электронных устройств. Продуктовый подход — это способ мышления, который учитывает эти несовершенства при разработке продуктов и таким образом увеличивает вероятность успеха. Меня зовут Дмитрий Латыпов, Product Manager в Napoleon IT, и сегодня я расскажу, какие слабости нивелирует продуктовый подход и на каких основных принципах он строится.

Ожидание и реальность

Как правило, при планировании крупных проектов существует большая вероятность ошибиться с прогнозом о сроках их завершения. Например, международный аэропорт Денвера в США планировали построить за четыре с половиной года, а закончили только через шесть лет и превысили бюджет на два миллиарда долларов. Сиднейский оперный театр в Австралии планировали реализовать за восемь лет, в итоге строили 14 лет, то есть опоздали на шесть лет, и превысили бюджет в 15 раз, потратив 102 миллиона долларов вместо семи. 

Таких примеров очень много, в том числе и в России: «Газпром Арена» в Санкт-Петербурге тоже была построена на 6 лет позже, чем планировалось.  Подобные несостыковки между планом и реальностью могут быть связаны с размерами проектов, использованием государственных средств, бюрократией или, возможно, коррупцией.

Но похожие результаты получаются и в примерах с отдельными людьми. Например, среди студентов проводился такой научный эксперимент: учащихся попросили спрогнозировать, когда их академические проекты будут сданы с 50% вероятностью (минимально уверенный прогноз), с вероятностью 75% (достаточно уверенный прогноз) и вероятностью 99% (максимально уверенный прогноз, который учитывает большинство форс-мажоров).

Как показали итоги этого эксперимента, по факту только 13% студентов уложились в минимально уверенный прогноз, 19% уложились в срок, в котором они были достаточно уверены, и 45% уложились в срок, который учитывал любые форс-мажоры. При этом 23% студентов вообще не уложились ни в один из этих прогнозов, то есть даже в тот, который они назвали, исходя из самых осторожных предсказаний. Подобные примеры показывают, что люди на самом деле плохо предсказывают будущее. Это первое несовершенство, которое нам нужно принять.

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

Проектный подход

При работе с проектным подходом мы часто не признаем наши слабости. Например, когда составляем планы проекта, мы прогнозируем будущее с точностью до дня и считаем, что каких-то форс-мажоров не должно случится. Либо думаем, что точно знаем, что нужно будущим пользователям продукта. Также мы часто недооцениваем важность коммуникации и закладываем мало ресурсов, чтобы начать действительно понимать друг друга, в том числе наших клиентов. Кроме того, мы довольно часто закладываем в ожидания бизнеса соответствие техническому заданию, сроки, бюджеты, а не сам результат. Хотя проект был запланирован в первую очередь ради этого результата.

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

Продуктовый подход и его принципы

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

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

1. Всегда отталкиваемся от цели

Чтобы ожидания совпадали с реальностью, нужно правильно понять поставленную задачу — это первый базовый принцип. Для этого нужно прояснить цель, потому что постановщик задачи часто приходит с решением, которое он смог себе представить, но это не единственный вариант. Часто даже это не самый хороший вариант, не тот, который лучше всего закроет его потребности. Чем глубже проясняется цель, тем больше вероятность сделать то, что действительно нужно, а не то, что было запрошено. Прояснить цель поможет правило 5Why, если задавать вопрос к цели, а не произошедшему инциденту.

2. Фокусируемся на бизнес-результате

После ответа на все «зачем» и «почему» нужно уточнить, а является ли цель бизнесовой. То есть целью, которая будет отражать востребованность продукта, а не качество проекта. Если продуктовая команда двигалась строго по плану и уложилась во все сроки, в бюджет и в другие ресурсы, которые были обозначены, но продукт не востребован клиентами, то это плохой результат с точки зрения продуктового подхода. При правильном подходе необходимо принести ценность, а не просто выполнить формальные обязательства. Клиенты будут недовольны, если ожидаемые результаты не соотносятся с итоговыми. 

Если бы на начальном этапе сложного проекта удалось уточнить требования от заказчика, то команда разработки, например, поняла бы, что проект не удастся выполнить в рамках данного бюджет. Возможно, придется передоговариваться на другой бюджет или на другие сроки, потому что отталкиваться надо именно от бизнес-результата.

Давайте рассмотрим реальный пример. В 2006 году Microsoft хотели составить конкуренцию Apple на рынке музыкальных плееров. Они выпустили устройство Zune 30, который было в целом довольно хорошим: оно был дешевле iPod, обладало более высоким качеством звука и функцией обмена музыкой через Wi-Fi. 

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

3. Опираемся на данные

После того, как все определились с целью, выяснили, что она бизнесовая, дальше нужно цель оцифровать, чтобы отслеживать прогресс по ее достижению. Иначе нельзя будет понять, двигаемся ли команда в нужном направлении и с нужной скоростью. Еще важно получать данные об окружающем мире, чтобы продукт не разбился о суровую реальность. Как если бы команда плыла на корабле и не видела, куда плывет, какие есть впереди острова и так далее.

Это могут быть данные о том, что рынок слишком маленький или на нем есть монополист, у которого неограниченное количество ресурсов. Когда появляется много данных, это очень здорово, но только в том случае, если уметь с ними работать и делать правильные выводы. То есть, если появилась информация о том, что есть монополист с неограниченным количеством ресурсов, то этих данных недостаточно для того, чтобы принять какое-то решение. Чтобы изменить продукт, необходимо сделать из этого правильный вывод для того, чтобы что-то противопоставить этому монополисту.

4. Понимаем своего пользователя

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

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

5. Делаем упор на качество, а не на количество

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

Снова посмотрим на реальный пример. Популярная соцсеть «ВКонтакте» имеет целую экосистему продуктов VK. Но на самом деле большая их часть существует внутри приложения «ВКонтакте». Только пользователи об этом могут не знать. В нем есть почтовый клиент, приложение для бега и даже женский календарь. Однако в отзывах пользователей часто говорится о том, что приложение постоянно перегружено, медленно работает и перестало быть таким удобным, как раньше. Поэтому некоторые отдают предпочтение другим социальным сетям. Это как раз пример того, как можно терять аудиторию, а не наращивать ее, когда добавляется новый функционал.

6. Быстрее и чаще сверяемся с реальностью

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

7. Улучшаемся итеративно

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

В качестве примера можно привести историю первых недель создания приложения Instagram* (принадлежит Meta, которая признана в РФ экстремистской и запрещена). На начальном этапе приложение называлось Burbn. До того, как нащупать ценность в приложении, создатели два раза меняли направление в создании продукта. Первые прототипы, которые были не совсем тем, что было бы востребовано, все равно проверялись на реальных пользователях, а создатели в целом не стеснялись идти и привлекать инвестиции. После того, как они уже рассказали свою идею, все равно меняли продукт и искали ту конфигурацию, которая поможет дать ценность пользователям. В какой-то момент у них получался «монстр Франкенштейна» с кучей функций. Но в конечном итоге создатели решили сосредоточиться на основной ценности — фотографиях. Спустя какое-то время они доделали приложение с публикациями фото, дальнейшая судьба успешного приложения всем известна.

Ограничения продуктового подхода

Продуктовый подход вполне эффективен, но это вовсе не значит, что он подходит для всех задач. У такого подхода есть и свои ограничения.

1. Продуктовый подход требует много ресурсов на исследования, общение с клиентами, проверку гипотез, и не все готовы с этим работать. Кто-то считает свою идею единственно верной и не хочет тратить время и ресурсы на то, чтобы осуществить несколько подходов и нащупать идею, которая будет нужна пользователю.

2. Продуктовый подход довольно сложно внедрять в тех компаниях, которые его не используют и не принимают. Мы вместе с бизнес-заказчиками должны принять тот факт, что мы не самые экспертные и не знаем всего на свете, но будем в этом разбираться и на основе полученных данных делать продукт. Если заказчики не набили шишки и не поняли, что не все их идеи жизнеспособны, они не услышат и не согласятся применять продуктовый подход в своей работе. 

3. Продуктовый подход предполагает более высокий уровень ответственности. Главное, что мы берем ответственность за бизнес-результат, а не за сроки или бюджеты. Но из-за того, что бизнес-результат зависит от многих факторов, его на самом деле невозможно гарантировать на 100%. Но правильно примененный продуктовый подход увеличивает вероятность хорошего результата.

4. Для того, чтобы вероятность успеха была выше, нужно обладать довольно широкой экспертизой в разных сферах. Например, продуктовый подход затрагивает и маркетинг, и аналитику, и продажи, то есть это все работает в комплексе. Для того, чтобы применять такой подход, нужна довольно экспертная команда.

5. Продуктовый подход не подходит для негибких сфер, например строительства. Невозможно во время постройки дома решить, что зданию вовсе не нужен третий этаж, или что-то глобально поменять, когда проект уже завершен. Если же работать с цифровыми продуктами, то изменение в процессе реализации проекта вполне возможны, и как раз этим и пользуется продуктовый мышление.

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

Напишите в комментариях, а какой вы используете подход в реализации своих проектов или продуктов? Встречали ли вы удачные примеры сочетания проектного и продуктового подхода?