«Хорошие менеджеры по продукту посвящают своё время не продукту, а решению проблем»

Перевод колонки вице-президента по продуктам инструмента для общения с пользователями Intercom Пола Адамса.

Перевод подготовлен командой онлайн-школы английского Skyeng.

Пол Адамс
Пол Адамс

За последние несколько лет мы в Intercom многое узнали о создании продуктов.

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

Есть одна вещь, которую я считаю ключевым фактором наших успехов. А именно: мы глубоко обдумываем проблему, которую должен решить проект. Звучит банально, и все говорят, что делают то же самое, но мы делаем это немного по-другому.

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

Расстановка приоритетов — определение проблемы — проектирование (дизайн) — разработка продукта — бета-тестирование — анонс и запуск
Расстановка приоритетов — определение проблемы — проектирование (дизайн) — разработка продукта — бета-тестирование — анонс и запуск

Если каскадной модели вы предпочитаете гибкую, процесс, вероятно, будет выглядеть так:

«Хорошие менеджеры по продукту посвящают своё время не продукту, а решению проблем»

И будет включать следующие активности:

План — бриф по проекту — исследование пользователей — проверка гипотезы
План — бриф по проекту — исследование пользователей — проверка гипотезы

Может быть, у вас всё не совсем так, и вы, например, возвращаетесь от бета-тестирования назад к разработке и так далее. Это неважно. Этот материал не о том, какая диаграмма идеально изобразит agile, lean, scrum или какой-то другой процесс. Он о том, на что вы тратите своё время.

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

У большинства команд, занимающихся разработкой продукта, время распределяется примерно так:

«Хорошие менеджеры по продукту посвящают своё время не продукту, а решению проблем»

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

Однако иногда всё распределяется вот так:

«Хорошие менеджеры по продукту посвящают своё время не продукту, а решению проблем»

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

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

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

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

Большинство проектов, которые я видел в Facebook, выглядели так:

«Хорошие менеджеры по продукту посвящают своё время не продукту, а решению проблем»

Лучше, чем в Google (исходя из моего опыта), но в стратегии Facebook было два конфликтующих пункта. Вот они, в прекрасной книге, которую все мы получили в день IPO несколько лет назад:

Безжалостная приоритизация
Безжалостная приоритизация

Умение решать проблемы далеко не так важно, как умение выбирать правильные проблемы для решения.

  • Сосредоточьтесь на решении масштабных проблем.
  • Сосредоточьтесь на том, чтобы помочь большинству.
  • Сосредоточьтесь на том, что будет иметь влияние.
Кто побеждает в споре
Кто побеждает в споре

Создавать важнее, чем разговаривать. Важнее, чем быть штатным сотрудником. Важнее, чем хорошо одеваться, складно говорить и быть известным. Важнее, чем быть популярным. Важнее, чем войти в ближний круг Марка (Цукерберга — прим. ред.).

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

На игровом поле все равны. Если вы сможете создать проект, то победите.

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

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

В Intercom мы тратим время примерно так:

«Хорошие менеджеры по продукту посвящают своё время не продукту, а решению проблем»

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

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

Почему мы так поступаем? Потому что хорошее решение зависит от хорошего понимания проблемы. Это неоспоримо. И всё равно большинство команд стараются побыстрее проскочить этап определения проблемы.

Мы изо всех сил стараемся научно подойти к этой громоздкой предварительной работе. У нас трудятся:

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

Иногда мы доходим до стадии бета-тестирования и осознаём, что всё ещё недостаточно хорошо понимаем проблему, и тогда возвращаемся к её определению. Поэтому время от времени происходит следующее:

«Хорошие менеджеры по продукту посвящают своё время не продукту, а решению проблем»

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

  • Это тяжёлая работа. Она требует снова и снова общаться с многочисленными клиентами, копать глубже, выстраивать новые вопросы. Залезать к пользователям в голову. Добираться до их глубинных истинных потребностей, а не довольствоваться первым, что они скажут. Люди часто описывают свои проблемы в форме решения, которое хотят получить. Плохие продуктовые команды довольствуются этим и воплощают это решение. Как правило, оно не достигает цели, поскольку настоящая потребность пользователей зарыта на несколько слоёв глубже. Хорошие продуктовые команды не останавливаются на первых формулировках, они продолжают искать причины. Это эмоционально тяжело и отнимает время.
  • Ей недостаёт эффектности. Что круче: отчёт об исследовании, новый макет интерфейса или работающий прототип чего-то нового? Большинство руководителей любят смотреть на новые продукты, которые вроде как работают, но у них нет времени читать отчёты. В современных компаниях чтение и размышление, которые позволяют приобрести глубокие знания, не считаются чем-то интересным или важным. Это плохо. В работе нет привлекательных и непривлекательных вещей. Только важные.
  • Видимый результат не отражает масштаб проделанной работы и затрудняет справедливую её оценку. Иногда люди работают неделями, а итогом их работы становится простой короткий абзац, в котором сформулирована проблема, требующая решения. Руководству, которое не способно оценить этот процесс, сложно обосновать важность работы, основываясь на её результате.

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

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

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

1818
11 комментариев

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

10
Ответить

Только дополню: Семь раз отмерь, один отрежь.

Ответить

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

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

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

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

1
Ответить

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

3
Ответить

Комментарий недоступен

1
Ответить
Комментарий удалён модератором

Если продукт не решает проблем, то он нафиг не нужен и кто за него будет платить? Сосед из душа?

1
Ответить