Julie Zhuo, директор по продуктовому дизайну в Facebook, однажды выступала на «TNW Europe», и рассказывала о фрэймворке, который используется в Facebook, чтобы сфокусироваться на разработке продукта.
Работа над этой речью заставила меня подумать о других уроках, которые я усвоила с годами о том, как сделать великие вещи.
Этот список не идеальный и не полный. Если бы была какая-то пошаговая инструкция (Шаг 1: Идея. Шаг 2: ??? Шаг 3: Профит!), тогда я бы потратила на неё хорошие деньги, а потом похлопала нас по спинам и смотрела бы, как новые потрясающие продукты цветут вокруг нас, словно цветочные поля в мае.
Путешествие завершено на 1%. Давайте продолжим идти дальше и обучаться.
Фрейминг
- Продукт успешен, потому что решает проблемы за людей. Это звучит очень просто, но это самая важная вещь, которую нужно понимать в создании хороших продуктов.
- Первым шагом в создании чего-то нового является понимание того, какую проблему ты хочешь решить и для кого. Это должно быть предельно ясно до того, как вы начнете думать над решением.
- Третий вопрос, который вы должны себе задать: «Почему именно эту проблему стоит решать?»
- Если аудитория, для которой вы создаете, узко определена (и вы её часть), то вы можете положиться на свою интуицию, чтобы принимать решения по продукту. Если же нет, то стоит полагаться на исследования и данные.
- Если вы — основатель стартапа, будет легче начать с решения проблем узкой аудитории, а затем расширяться к общей аудитории после того, как вы заручитесь изначальной поддержкой.
- Проблема, которую вы пытаетесь решить, должна быть поняла за пару предложений и резонировать с кем-либо из вашей целевой аудитории. Если этого не происходит, то считайте это тревожным признаком.
Перевод выполнен при поддержке компании EDISON Software, которая и в стартапы инвестирует, и портированием и миграцией занимается.
Исполнение
- Хорошая реализация заключается в том, чтобы сделать правдоподобные выводы в кратчайшие сроки.
- Плохая реализация — это когда вы пытаетесь сделать что-то неверное и а) вы не можете вынести уроки из этой неудачи, которые могли бы применить к будущим проектам (потому что не понимаете причины неудачи) или б) прошёл год перед тем как вы выучили определенный урок, хотя более логичный путь выучить тоже самое занял бы 3 месяца.
- Чем обычно успешная команда отличается от неуспешной — это не тем, что команда делает неверные вещи (а это гарантированно), а тем, насколько стабильно они работают.
- При изучении решений для конкретной проблемы, мыслите ширите перед тем, как мыслить глубже. Проведите коллективное обсуждение 10, 20, 50 решений проблемы перед тем, как выбирать «победителя». Первые 5 идей будут очевидны. Творчество начинается с 11, 20 или 50-ой идеи.
- Если вы представляете план продукта, и кто-то спрашивает: «Вы думали о рассмотрении X вместо этого?» и ваш ответ «Нет», то это сигнал о том, что ваш процесс исследования был недостаточно тщательным.
- Используйте эмпирические доказательства, чтобы сократить список лучших идей, к которым вы пришли через мозговой штурм. (Например, выберете топ N любимчиков из команды, дизайна или прототипа, основываясь на точности, и представьте их людям, чтобы понять их реакцию).
- После того, как вы нашли конкретное решение, которого хотите придерживаться при работе, подумайте о нём с точки зрения гипотезы — что, предположительно, случится, если вы реализуете это? (Например: «Проблема, которую мы хотим решить, заключается в том, что каждый горожанин знает о местных событиях на выходных. Наша гипотеза такова: мы можем сообщать об этом X% жителей через рассылку на почту»).
- Вы постоянно должны искать пути, чтобы сократить анализ вашей гипотезы. Вы можете выдать свою идею людям на улице и посмотреть, насколько она ясна? Можете ли вы создать опрос, направленный на вашу аудитории и оценить, достаточно ли людей заинтересованы в идее? Можете ли вы быстро простроить версию, которая приведет вас к четкому выводу, даже если и она не полностью готова, как видение у вас в голове?
- Как только вы получаете положительный фидбек к своей гипотезе, не думайте, что вам нужно сразу устанавливать то, что вы протестировали (потому что вы могли дойти до этого обходными путями). Вместо этого примите отдельное намеренное решение о том, что является преградой для полного запуска, когда дело доходит до редактирования и дополнительных функций. То, что приемлемо для тестирования и что приемлемо для отправки в целом, должно иметь разные критерии.
- Если вы начинаете большой проект, включающий в себя множество различных изменений, посмотрите, можно ли разделить эти изменения на меньшие, независимо тестируемые этапы. Не попадайте в ловушку, когда вы делаете пять изменений, получаете плохой результат и после этого должны понять, какие из этих изменений ответственны за такой результат.
- Проводите анализ каждого проекта внутри команды, независимо от того, был он успешен или же нет. Какие вы вынесли уроки? А командные уроки? Что вы будете делать иначе в будущем? А затем поделитесь своими обсуждениями со всей компанией.
Оценка успеха
- Как вы измеряете успех имеет решающее значение для долгосрочных результатов вашей команды, потому что это именно то, из-за чего народ становится сплоченным. Убедитесь, что вы уделяете этому надлежащее время и внимание (даже больше, чем мысли «как нам это сделать?»)
- Определите, как выглядит успех для вашего продукта перед тем, как запускать его. Иначе, если вы попытаетесь интерпретировать результаты до их возникновения, необъективность подтверждения приведет к необъективному пониманию.
- Для каждой метрики успеха придумайте хорошую метрику счетчика, которая убедит вас, что вы не просто подключаете одно отверстие к другому. (Например, общий счетчик метрик для измерения увеличения производства также измеряет качество каждой произведенной вещи).
- Если важный показатель движется неожиданно, неважно — положительно или отрицательно, вашим первым вопросом должно быть: «Почему?». Не пытайтесь разработать стратегии, чтобы ускорить/помешать тому, что происходит, без полного понимания.
- Используйте технику «Crystal Ball», чтобы выбрать правильные пути для измерения успеха. Спросите себя: «Если бы я мог знать что угодно о том, как люди используют наш продукт, что я бы хотел узнать, чтобы понять, успешен мой продукт или нет?». (Обычно, ответ, который дают люди — это не «число кликов», а что-то нечто более абстрактное, вроде «Как много людей, использовавших мой продукт, получили ценность от него?»). Отталкиваясь от этого ответа, проработайте в обратном направлении, чтобы получить измеряемую метрику, которая наилучшим образом приближает вас к тому, чего вы пытаетесь добиться.
- Ваши цели всегда должны быть снабжены самой лучшей информацией, которой вы владеете на данный момент. Если вы работали над заранее согласованной целью, а затем обнаружили новую информацию, которая изменяет ваше понимание мира, подумайте, следует ли скорректировать свои цели на основе этой новой информации.
- Если вы работаете в команде и не понимайте или не согласны с тем, как команда измеряет успех, сразу же поговорите об этом. Лучше решить все на берегу, при условии, насколько фундаментальным является это выравнивание для продуктивности и хорошей работы.
- Если вы постоянно спорите со своими коллегами о том, куда должен двигаться продукт, корень проблемы, скорее всего, в том, что вы по-разному измеряете успех. Проверьте, можете ли вы сформулировать свои проблемы в форме нового предложения для измерения успеха
- Если вы пытаетесь понять, подходит ли ваш продукт для рынка (по сравнению с попытками оптимизации или масштабирования), то вам лучше перестать сосредотачиваться на удержании (как много людей используют ваш продукт и достаточно его любят, чтобы вернуться за ним?), чем на вовлеченности или числе пользователей.
Динамика команды
- Размышление с точки зрения вашей роли (Что ожидается от дизайнера? Что ожидается от инженера?) ограничит вашу способность оказывать влияние. Вместо этого, думайте с точки зрения «Что я могу сделать, чтобы привести команду к успеху скорее?».
- Команды, влюбленные в проблему, имеют более успешные результаты, чем команды, влюбленные в конкретные решения. Это связано с тем, что знание того, что проблема стоит решения, продолжает мотивировать, даже если команда не приходит к правильному решению с первой, второй или N-й попытки.
- Всегда предполагайте лучшие намерения. Я имею в виду, что в конце концов каждый хочет одного и того же — сделать что-то отличное. Возможно, некоторый процент времени вы и ошибаетесь, но так вы спасете себя от ненужной драмы.
- Поймите свои сильные стороны и сильные стороны ваших коллег. Затем распределите обязанности команды так, чтобы сильные стороны работали на вас.
- Хорошая коммуникация является ключом к здоровой команде. Каждый член команды должен чувствовать, что может смело выражать свои взгляды, даже если эти взгляды противоположны. Разнообразие мнений приведет к лучшим результатам. Поэтому не бойтесь выражать свое мнение, не бойтесь повторять его, если вы не уверены, что люди услышали или полностью поняли вас и стремитесь создать эту безопасность для других.
Автор: Ришат
