В поисках продукта

Что всё-таки важнее для продуктовой компании: делать продукт правильно и эффективно с точки зрения равномерной загрузки ресурсов, или, не взирая ни на что, делать правильный продукт, который будет востребован клиентами?

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

Оригинал: http://www.svpg.com/product-discovery/


Вам же знакома такая ситуация?

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

«Никаких проблем» — отвечаете вы (в конце концов, вам обычно дают лишь считанные дни на подготовку, так что 4 недели кажутся вам отличным раскладом). Вы начинаете с оценки продуктовых возможностей, чтобы понять проблему, которую будет решать ваш новый продукт.

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

Это то, как оно должно быть...

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

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

Отведённые вам 4 недели уже истекли, и разработчики готовы приступить к работе. В течение следующих 3–6 месяцев они реализуют все тот же неудобный и не вызывающий никакого восторга продукт, который вы воплотили в прототипе. В итоге вы выпускаете продукт на рынок, а менеджмент, конечно же, разочарован результатом.

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

В чём же смысл?

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


Отношение к подготовке требований и разработке дизайна как к последовательным, предсказуемым и планируемым этапам процессам создания продукта слишком засело в нашем сознании!

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

Разработка или поиск?

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

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

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

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


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

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

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

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

Виноват ли менеджмент?

Больше всех остальных за жесткое планирование выступает именно менеджмент. Как мне кажется, на это есть две важные причины:

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

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


Ирония заключается в том, что это и есть те самые причины, которые ведут к напрасной трате ресурсов разработчиков.

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

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

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

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


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

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

Спасение рук утопающих

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

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

Желаю удачных поисков, интересных проектов и по-настоящему крутых продуктов!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.