«Хорошие менеджеры по продукту посвящают своё время не продукту, а решению проблем»
Перевод колонки вице-президента по продуктам инструмента для общения с пользователями Intercom Пола Адамса.
В избранное
В избранном
Перевод подготовлен командой онлайн-школы английского Skyeng.
За последние несколько лет мы в Intercom многое узнали о создании продуктов.
Какие-то идеи оказались более удачными, а какие-то не «выстрелили». Чтобы научиться повторять свой успех и показать новым сотрудникам, что на самом деле работает, мы много размышляли над своими процессами.
Есть одна вещь, которую я считаю ключевым фактором наших успехов. А именно: мы глубоко обдумываем проблему, которую должен решить проект. Звучит банально, и все говорят, что делают то же самое, но мы делаем это немного по-другому.
Вот как выглядит стандартный процесс разработки продукта, которого более или менее придерживается большинство компаний:
Если каскадной модели вы предпочитаете гибкую, процесс, вероятно, будет выглядеть так:
И будет включать следующие активности:
Может быть, у вас всё не совсем так, и вы, например, возвращаетесь от бета-тестирования назад к разработке и так далее. Это неважно. Этот материал не о том, какая диаграмма идеально изобразит agile, lean, scrum или какой-то другой процесс. Он о том, на что вы тратите своё время.
Представьте, что время, которое вы отводите на проект, можно поделить на сто единиц. Сюда включена работа менеджеров по продукту, дизайнеров, исследователей, аналитиков, разработчиков и так далее.
У большинства команд, занимающихся разработкой продукта, время распределяется примерно так:
Небольшая предварительная работа по расстановке приоритетов, затем определение проблем. Значительно дольше длится проектирование, а основная часть времени уходит на разработку.
Однако иногда всё распределяется вот так:
Такое происходит, когда у кого-то из руководства появляется идея, которую он хочет увидеть воплощённой в жизнь. Эта «очень важная идея» обычно посещает его в машине, иногда — в душе, иногда — после разговора с соседом, которого он, как «обычного человека», спросил, как можно улучшить продукт.
Как только идея сформулирована, нельзя терять ни минуты, сразу нужно разрабатывать и собирать. Эта «идея очень важного человека» может быть большой или маленькой. Хуже всего, когда план работы целиком состоит из множества мелких, постоянно меняющихся «идей очень важного человека», большая часть которых никак между собой не связаны.
То, как мы решаем работать, зависит от нашего прошлого опыта. В моём случае я часто сталкивался с «идеями важного человека», когда работал над проектами в Google. Много было таких людей с большими идеями из машины, душа или разговора с соседом. Большинство этих проектов провалились. Я знаю, что с другими проектами Google дела обстояли лучше, но мой опыт таков.
Подобные вещи — распространённая практика для стартапов, которые в итоге провалились. Когда я разговариваю с людьми из этих стартапов и спрашиваю их о том, как они работают, они описывают именно этот принцип. Они могут говорить об исследованиях и общении с клиентами, но это всего лишь формальности и пустые слова.
Большинство проектов, которые я видел в Facebook, выглядели так:
Лучше, чем в Google (исходя из моего опыта), но в стратегии Facebook было два конфликтующих пункта. Вот они, в прекрасной книге, которую все мы получили в день IPO несколько лет назад:
Умение решать проблемы далеко не так важно, как умение выбирать правильные проблемы для решения.
- Сосредоточьтесь на решении масштабных проблем.
- Сосредоточьтесь на том, чтобы помочь большинству.
- Сосредоточьтесь на том, что будет иметь влияние.
Создавать важнее, чем разговаривать. Важнее, чем быть штатным сотрудником. Важнее, чем хорошо одеваться, складно говорить и быть известным. Важнее, чем быть популярным. Важнее, чем войти в ближний круг Марка (Цукерберга — прим. ред.).
Задача проста: создавайте то, что будет решать масштабные проблемы. Если вы не можете этого сделать, ничто другое не имеет значения. Если можете, ничто другое тоже не имеет значения.
На игровом поле все равны. Если вы сможете создать проект, то победите.
Я не согласен, что время, потраченное на написание кода, важнее определения проблемы. Готовый код может быть неплохим аргументом в споре о выборе решения, но его успешность зависит от понимания сути проблемы.
Случалось, что кто-то писал код, чтобы помочь понять проблему, но это обычно касалось технических проблем, а не потребностей клиентов. Эта зацикленность на разработке заставляет людей слишком быстро проходить этап определения проблемы.
В Intercom мы тратим время примерно так:
Сорок из ста наших единиц оказываются потрачены ещё до стадии разработки. Мы много времени и ресурсов тратим на приоритизацию и определение проблемы.
Иногда я свожу коллег с ума, допытываясь, достаточно ли глубоко мы понимаем проблему, которую пытаемся решить. Мы призываем менеджеров по продукту открыто делиться и обсуждать ранние формулировки проблем, которым мы пытаемся дать определение.
Почему мы так поступаем? Потому что хорошее решение зависит от хорошего понимания проблемы. Это неоспоримо. И всё равно большинство команд стараются побыстрее проскочить этап определения проблемы.
Мы изо всех сил стараемся научно подойти к этой громоздкой предварительной работе. У нас трудятся:
- команда клиентской поддержки (они размечают каждый разговор с клиентом, которые затем изучат наши менеджеры по продукту, для этого мы, конечно, используем Intercom);
- команда продаж и команда маркетологов (они строят матрицу продукта и рынка на основе собранной информации);
- команда исследователей (в них мы основательно вложились с самого начала);
- команда аналитиков (это направление мы активно развиваем сейчас).
Иногда мы доходим до стадии бета-тестирования и осознаём, что всё ещё недостаточно хорошо понимаем проблему, и тогда возвращаемся к её определению. Поэтому время от времени происходит следующее:
Возникает вопрос: если хорошее решение напрямую зависит от хорошего понимания проблемы, то почему столько компаний и команд стремятся побыстрее проскочить эту часть работы? Думаю, на то есть три больших причины:
- Это тяжёлая работа. Она требует снова и снова общаться с многочисленными клиентами, копать глубже, выстраивать новые вопросы. Залезать к пользователям в голову. Добираться до их глубинных истинных потребностей, а не довольствоваться первым, что они скажут. Люди часто описывают свои проблемы в форме решения, которое хотят получить. Плохие продуктовые команды довольствуются этим и воплощают это решение. Как правило, оно не достигает цели, поскольку настоящая потребность пользователей зарыта на несколько слоёв глубже. Хорошие продуктовые команды не останавливаются на первых формулировках, они продолжают искать причины. Это эмоционально тяжело и отнимает время.
- Ей недостаёт эффектности. Что круче: отчёт об исследовании, новый макет интерфейса или работающий прототип чего-то нового? Большинство руководителей любят смотреть на новые продукты, которые вроде как работают, но у них нет времени читать отчёты. В современных компаниях чтение и размышление, которые позволяют приобрести глубокие знания, не считаются чем-то интересным или важным. Это плохо. В работе нет привлекательных и непривлекательных вещей. Только важные.
- Видимый результат не отражает масштаб проделанной работы и затрудняет справедливую её оценку. Иногда люди работают неделями, а итогом их работы становится простой короткий абзац, в котором сформулирована проблема, требующая решения. Руководству, которое не способно оценить этот процесс, сложно обосновать важность работы, основываясь на её результате.
Вот почему большинство компаний не занимаются этим. Это тяжёлая работа, её несправедливо считают неинтересной, а первые результаты сложно оценить. И всё-таки я считаю, что это одна из наиболее важных вещей, которые мы делаем, и один из главных факторов успеха наших проектов.
Эта работа существенно снижает вероятность того, что вы создадите что-то ненужное или бесполезное, и вам не придётся выяснять это уже после того, как вы потратили время на разработку и сборку.
Попытайтесь изменить принцип распределения времени. Начните с малого, целиком сосредоточьтесь на формулировке проблемы, и тогда вы быстро поймёте, что нужно делать. Когда вы создадите продукт, то увидите, что клиенты его оценят, ведь вы поняли, в чём они нуждаются.
#кейсы
© vc.ru
