Продуктовое мышление

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

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

Продукт и проект: принципиальная разница

Слова «продукт» и «проект» в повседневной речи часто используют как синонимы, но между ними существует фундаментальное различие, понимание которого меняет всё — от планирования до оценки результатов.

Проект по своей природе имеет чёткие границы во времени и пространстве. У него есть дата начала, дата завершения, бюджет, техническое задание и критерии приёмки. Когда все пункты технического задания выполнены и акты подписаны, проект считается завершённым. Команда расходится, подрядчик получает оплату, результат переходит к заказчику. Строительство дома — это проект. Организация конференции — это проект. Разработка сайта по техническому заданию — тоже проект, по крайней мере с точки зрения классического подхода.

Продукт устроен принципиально иначе. У него есть момент рождения, но нет запланированной даты смерти. Продукт — это живая сущность, которая развивается, адаптируется к изменениям рынка, отвечает на действия конкурентов, эволюционирует вместе с потребностями своих пользователей. Команда продукта не расходится после запуска первой версии — она продолжает работать, анализируя данные, собирая обратную связь, выпуская обновления. iPhone — это продукт, который Apple развивает уже почти двадцать лет. Gmail — продукт, который Google постоянно дорабатывает с 2004 года. Успешный интернет-магазин — это продукт, даже если изначально он создавался как проект.

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

Проектное мышление задаёт вопрос: «Как сделать то, что запланировано, в срок и в бюджет?» Продуктовое мышление спрашивает совсем другое: «Что нужно сделать, чтобы создать максимальную ценность для пользователей?» В первом случае успех измеряется соответствием плану, во втором — реальным влиянием на жизнь людей.

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

Ценность как точка отсчёта

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

Различие между функцией и ценностью кажется тонким, но оно меняет всю логику проектирования. Функция — это то, что продукт делает. Ценность — это то, что пользователь благодаря этому получает. Интернет-магазин имеет функцию фильтрации товаров по цене — это техническое описание возможности. Ценность этой функции в том, что покупатель может быстро найти подходящий товар в рамках своего бюджета, не тратя время на просмотр того, что ему не по карману. Календарное приложение имеет функцию интеграции с почтой — это описание технической связи между системами. Ценность в том, что человек не забудет о важной встрече, потому что напоминание придёт ему автоматически.

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

История технологий полна примеров того, как продукты с меньшим количеством функций побеждали более функциональных конкурентов. Первый iPod не был самым продвинутым MP3-плеером на рынке — существовали устройства с большим объёмом памяти, большим количеством поддерживаемых форматов, более гибкими настройками. Но iPod предлагал простой и понятный способ слушать музыку, и этого оказалось достаточно для победы. Dropbox появился на рынке, где уже существовали десятки сервисов облачного хранения, многие из которых предлагали больше бесплатного места и больше возможностей. Но Dropbox работал настолько просто и надёжно, что стал стандартом индустрии.

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

Работа, на которую нанимают продукт

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

Рассмотрим классический пример. Человек приходит в магазин строительных товаров и покупает дрель. Поверхностный анализ скажет: этому человеку нужна дрель. Более глубокий взгляд покажет: ему нужно отверстие в стене. Ещё более глубокий: ему нужно повесить полку. И совсем глубокий: ему нужно организовать пространство в своём доме так, чтобы было удобно жить. Дрель — это всего лишь инструмент, который он «нанимает» для выполнения этой работы в данных обстоятельствах.

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

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

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

Пользователь в центре

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

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

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

Ответы на эти вопросы влияют буквально на всё: на информационную архитектуру, на визуальную иерархию элементов, на формулировки текстов, на последовательность шагов в ключевых сценариях, на то, какие функции действительно необходимы, а какие будут только отвлекать и мешать.

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

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

Минимально жизнеспособный продукт

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

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

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

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

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

Гипотезы и эксперименты

Продуктовое мышление относится к идеям о продукте как к гипотезам, которые нужно проверять, а не как к истинам, которые нужно реализовывать. Это фундаментальный сдвиг в отношении к своим предположениям, который даётся нелегко, но даёт огромные преимущества.

Любое предположение о пользователях, их потребностях, их поведении — это гипотеза. Команда думает, что пользователи хотят определённую функцию, — это гипотеза. Команда предполагает, что люди будут использовать продукт определённым образом, — это гипотеза. Бизнес-план утверждает, что пользователи готовы платить определённую цену, — и это тоже гипотеза. Все эти предположения могут оказаться верными, но могут и не оказаться. История полна примеров продуктов, которые казались очевидно нужными своим создателям, но провалились при встрече с реальным рынком.

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

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

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

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

Готовность признать, что гипотеза не подтвердилась, — важнейшая часть продуктового мышления. Это требует определённого мужества и культуры, которая не наказывает за неудачные эксперименты. Неподтверждённая гипотеза — это не провал, а ценная информация. Лучше узнать, что идея не работает, на этапе бумажного прототипа, чем после года разработки и сотен тысяч долларов инвестиций.

Итеративность: маленькие шаги вместо большого скачка

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

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

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

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

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

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

Метрики: измеряем то, что важно

Продуктовое мышление опирается на измерения. Это не означает слепого поклонения цифрам, но признаёт фундаментальный факт: если мы не можем измерить результат наших действий, мы не можем понять, движемся ли в правильном направлении. Интуиция и экспертное суждение важны, но они должны подкрепляться данными.

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

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

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

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

Приоритизация: невозможно сделать всё

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

Приоритизация — это не просто составление списка идей в порядке их важности. Это принятие по-настоящему болезненных решений о том, что не будет сделано вообще или будет отложено на неопределённый срок. Сказать «нет» хорошей идее психологически гораздо сложнее, чем сказать «да, но потом». Однако «потом» имеет свойство никогда не наступать, а список отложенных задач имеет свойство бесконечно расти. Честное «нет» освобождает ресурсы и внимание для того, что действительно важно.

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

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

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

Четвёртый принцип — стратегическое соответствие. Куда движется продукт в долгосрочной перспективе? Какую позицию на рынке он должен занять? Функция может быть полезной сама по себе, но уводить продукт в сторону от главного направления развития. Иногда нужно сказать «нет» хорошим идеям просто потому, что они не вписываются в общую картину.

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

Обратная связь: слушать, но не подчиняться

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

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

Классический пример, который часто приводят в этом контексте, связан с Генри Фордом. Ему приписывают фразу: «Если бы я спрашивал людей, чего они хотят, они бы попросили более быструю лошадь». Независимо от того, говорил ли Форд это на самом деле, мысль точно отражает проблему буквального следования запросам пользователей. Люди мыслят в рамках существующих решений и существующего опыта. Они могут попросить улучшения того, что уже знают, но прорывные инновации — радикально новые способы решения старых проблем — невозможно получить из прямых пользовательских запросов.

При этом игнорировать обратную связь — столь же серьёзная ошибка. Если множество пользователей независимо друг от друга говорят об одной и той же проблеме, проблема реальна, даже если предлагаемые ими решения не оптимальны. Задача продуктового мышления — услышать проблему, скрытую за запросом, и найти лучшее возможное решение, которое может отличаться от того, что просят.

Особенно ценна обратная связь в форме поведения, а не слов. Что люди делают, важнее того, что они говорят. На интервью человек может искренне утверждать, что функция ему очень нужна, что он обязательно будет ей пользоваться, что именно её не хватает для счастья. Но когда функция появляется, данные показывают, что он открывал её два раза за месяц. Это не значит, что человек врал — он сам верил в то, что говорил. Но его представления о собственном поведении не соответствовали реальности. В таких случаях верить нужно данным, а не декларациям.

Продуктовое мышление для заказчика

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

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

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

Заказчик с продуктовым мышлением опирается на данные при принятии решений. Он не настаивает на изменениях только потому, что лично ему так нравится или потому что так считает его начальник. Он спрашивает: что говорят пользователи? Что показывают метрики? Какие гипотезы мы можем проверить, прежде чем вкладывать ресурсы в реализацию? Он готов изменить своё мнение, если данные показывают, что он ошибался.

Заказчик с продуктовым мышлением принимает ответственность за приоритеты. Он не перекладывает все решения на подрядчика, ожидая, что тот сам разберётся, что важно, а что нет. Он не требует «сделайте всё и сразу», понимая, что это физически невозможно. Он участвует в процессе приоритизации, делает выбор, принимает на себя последствия этого выбора и защищает принятые решения перед своей организацией.

Распространённые ошибки

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

Влюблённость в собственное решение — пожалуй, самая опасная из всех ошибок. Создатель продукта настолько привязывается к своей идее, что начинает игнорировать все сигналы о её несостоятельности. Пользователи не понимают продукт? Значит, пользователи недостаточно умны или недостаточно образованы. Метрики показывают провал? Значит, метрики неправильно настроены или не отражают реальную ценность. Эксперты высказывают сомнения? Значит, эксперты не понимают революционности идеи. Для каждого негативного сигнала находится объяснение, почему его можно игнорировать. Лекарство от этой болезни — дисциплинированное отношение к своей идее как к гипотезе, которая может не подтвердиться, и готовность признать провал, если доказательства его очевидны.

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

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

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

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

Резюме главы

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

Продукт принципиально отличается от проекта тем, что это живая сущность, которая постоянно развивается и адаптируется, а не фиксированный результат с чёткими границами. Ценность — это не то, что продукт умеет делать, а та польза, которую благодаря ему получает конкретный человек. Люди «нанимают» продукты для выполнения определённой работы в своей жизни, и понимание этой работы открывает неожиданные перспективы для проектирования.

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

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

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

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