Текст книги "Как создать продукт, который полюбят"

[3] Что мы создаем?

Как определить, что мы должны создать

Проектирование – процесс превращения мечты в реальность.

The Universal Traveler

Давайте сыграем в игру.

Как вы думаете, сколько человек в командах, которые работают над следующими продуктами или функционалами?

• iMovie и iPhoto компании Apple

• Twitter

• Instagram

• Spotify

Подсказка: их меньше, чем вы думаете.

• iMovie и iPhoto компании Apple: 3 и 5 человек соответственно[59]59
  https://www.linkedin.com/in/glennreid


[Закрыть]

• Twitter: 5–7[60]60
  http://www.quora.com/How-are-product-teams-at-Twitter-structured


[Закрыть]

• Instagram: 13 на момент, когда его купил Facebook за 1 миллиард долларов[61]61
  http://www.dailymail.co.uk/news/article-2127343/Facebook-buys-Instagram-13-employees-share-100m-CEO-Kevin-Systrom-set-make-400m.html


[Закрыть]

• Spotify: 8[62]62
  https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf


[Закрыть]

Известно, что команда, которая сделала первые прототипы iPhone, была «шокирующе маленькой»[63]63
  http://on.wsj.com/1SJ4XqK


[Закрыть]. Даже дизайн-студия Джони Айва в компании Apple, воплощавшая промышленный дизайн всех продуктов компании, в том числе iOS 7, насчитывала всего 19 человек[64]64
  http://www.newyorker.com/magazine/2015/02/23/shape-things-come


[Закрыть]. Можно предположить, что эта группа была разбита на более мелкие, каждая из которых работала над отдельным проектом.

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

Джефф Безос, основатель Amazon.com, придумал отличное название для таких команд: «команда на две пиццы»[65]65
  http://www.wsj.com/news/articles/SB10001424052970203914304576627102996831200


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

Ричард Хакман – профессор Гарвардского университета, изучавший психологию организаций, выяснил, что «чем больше группа, тем больше возникает проблем с взаимодействием между ее участниками в процессе коллективной работы… более того, чем больше группа, тем более уязвимой она становится к подобным сложностям»[66]66
  Messick, David and Kramer, Roderick eds. The Psychology of Leadership: New Perspectives and Research. New York: Psychology Press, 2004. P. 131.


[Закрыть].

Хакман определил «проблемы с процессами» как связи – или каналы коммуникации – между членами группы.

С ростом числа членов группы число связей между ними растет экспоненциально. Используя формулу n × (n – 1) / 2, где n – размер группы, Хакман подсчитал, что число связей в группе очень быстро становится труднореализуемым (рис. 3.1).

Рис. 3.1. Чем больше размер группы, тем больше «проблем с процессами» в ней возникает. Это требует дополнительных каналов коммуникации и может замедлить принятие решений[67]67
  Messick, David and Kramer, Roderick eds. The Psychology of Leadership: New Perspectives and Research. New York: Psychology Press, 2004. P. 131.


[Закрыть]

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

• Команда из шести человек имеет всего 15 каналов коммуникации.

• Увеличиваем эту цифру до 10 – и нам придется справляться уже с 45 каналами.

• Если мы возьмем команду вроде той, куда я каждый день хожу на работу, – это Tinder, 70 человек, – число связей возрастет до 2415.

Однако необходимость работать с большим числом связей – не единственная проблема больших команд.

Слишком большие группы слишком уверены в себе. Людям кажется, что они могут сделать все быстрее, они склонны «все больше недооценивать время, необходимое на выполнение задачи». В 2010 году ученые Пенсильванского университета, Университета Северной Каролины в Чапел-Хилл и Калифорнийского университета в Лос-Анджелесе, изучавшие организационное поведение, провели ряд исследований, подтверждающих это мнение[68]68
  http://www.opim.wharton.upenn.edu/~kmilkman/2012_OBHDPb.pdf


[Закрыть]. В одном из экспериментов команды получили задание собрать конструкцию из набора лего. Команды из двух человек справились за 36 минут, тогда как командам из четырех человек потребовалось на 44 процента больше времени.

Тем не менее команды из четырех человек считали, что они справятся с набором лего быстрее, чем команды из двух человек.

Это яркий пример того, почему правило двух пицц отлично работает.

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

Итак, мы выяснили, какого размера должна быть команда. А кого мы туда позовем?

Всем нравятся совещания по продукту. Особенно если это этап принятия решения о том, что именно предстоит создавать.

Даже Стиву Джобсу нравилось принимать участие в этом этапе. «Однажды он сказал мне, – говорит Гленн Рейд, бывший директор по разработке приложений для потребителей в Apple, – что одна из причин, по которым он хотел быть CEO, – то, что никто не мог ему запретить присутствовать при создании продукта»[69]69
  http://inventor-labs.com/blog/2011/10/12/what-its-really-like-working-with-steve-jobs.html


[Закрыть].

Ведите себя так, будто вы работаете вышибалой в известном берлинском клубе «Бергхайн»[70]70
  «Бергхайн» – ночной техноклуб. В апреле 2009 года занял первое место в списке «Ста лучших клубов мира» по версии английского журнала DJmag. Неоднократно признавался лучшим немецким клубом по опросам читателей немецких музыкальных журналов Groove и DeBug. Прим. ред.


[Закрыть], [71]71
  www.telegraph.co.uk/travel/destinations/europe/germany/berlin/10601482/Berghain-how-to-get-into-Berlins-most-exclusive-nightclub.html


[Закрыть]. (Подсказка: вряд ли у вас получится, если вы не говорите по-немецки. К тому же тамошний охранник Свен, «постапокалиптическая версия Вагнера», диктует такой дресс-код, который вряд ли кому-то удастся изменить.)

Итак, кто в вашей команде? Что они знают о том, с какими проблемами вам пришлось столкнуться? И как вы организуете обсуждение?

На этом этапе у вас уже должен быть список всех, кто будет работать в команде над созданием продукта. Например:

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

• Разработчик или разработчики, с которыми вы будете работать над созданием продукта, – обычно это фронтенд и бэкенд.

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

Итен Ша во время работы в KISSMetrics укомплектовывает такие команды…

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

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

ВЕЧЕРИНКА В СТИЛЕ ДЕВЯНОСТЫХ

Реджису Маккенна[72]72
  Реджис Маккенна – один из самых известных маркетологов Кремниевой долины и президент консалтинговой компании McKenna Group, занимающейся проблемами менеджмента и маркетинга. Прим. ред.


[Закрыть] есть что рассказать об этом процессе. В начале девяностых, когда он понял, насколько быстро технологии меняют мир, его – как и Нила Макэлроя из компании Procter & Gamble – осенило, что появилась необходимость в новой роли. Новый человек должен был стать «связующим звеном – как внутри компании, объединяя возможности технологий с потребностями рынка, так и вне ее, позволяя заказчику и компании совместно заниматься разработкой и усовершенствованием товаров и услуг»[73]73
  http://onproductmanagement.net/2010/03/14/the-origins-of-product-management-part-3


[Закрыть].

Если вы проскочили этот абзац, перечитайте его внимательно еще раз. Маккенна отвечал за запуск «визитных карточек» нашей эпохи – первый микропроцессор Intel, первый компьютер Apple и первый розничный магазин компьютеров The Byte Shop. И именно он рассказал историю о «легендарном стартапе в гараже», принесшую популярность компании Apple.

Вы перечитали цитату? Что-нибудь показалось вам знакомым?

Да это же он о вас говорит!

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

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

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

У Джоша Элмана (Greylock Partners, Zazzle, LinkedIn, Facebook, Twitter) есть отличный взгляд на эту часть процесса создания продукта:

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

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

Рис. 3.2. Матрица боли – простой инструмент, который я создал для себя, чтобы значительно облегчить процесс анализа результатов исследования и получения выводов

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

Диогенис Брито, занимающий пост продуктового дизайнера в стартапе Slack, напоминает:

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

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

Вы можете больше.

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

КОНЦЕНТРАЦИЯ ВНИМАНИЯ!

Огромную проблему на совещаниях по продукту представляет «клубная» эйфория, когда сфокусированность уступает место всеобщему хаосу. Как управлять вниманием команды и вести здоровую дискуссию?

Заведите доску для записи идей. Она послужит сразу трем практическим целям.

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

• Мысли визуализируются. Не все идеи можно объяснить словами; доска для записей позволяет каждому примерно описать свою основную идею без излишней детализации. Таким образом, команда получает возможность перенести идеи из своей головы на общее игровое поле.

• Лучшие идеи остаются, а те, что похуже, сами собой тонут. Это преимущество проистекает из естественной склонности группы забывать, кому принадлежит идея. Поэтому доска очень полезна, особенно если у группы много идей. Главное, не подписывать идеи: так вы не заденете ничьего самолюбия и не запустите механизм неприятия чужой разработки или механизм «придумано не нами». Технику «общего котла» (The Cauldron) использовали в Apple, где на совещании иногда присутствовал и Стив Джобс. Гленн Рейд, бывший директор по разработке приложений для потребителей в Apple, говорил: «Общий котел позволял нам сделать замечательный суп, сварить зелье – и неважно, где была чья идея. Ретроспектива показала, что очень важно было отделить идеи от их авторов. Если идея была хорошей – мы соглашались, если идея была плохой – она оседала на дно котла. Мы не помнили, кто что придумал, – это не имело никакого значения»[74]74
  http://inventor-labs.com/blog/2011/10/12/what-its-really-like-working-with-steve-jobs.html


[Закрыть].

Преимущество есть и у техник ограничения времени, как, например, та, которой воспользовались в онлайн-стартапе Medium. Берете группу нужных людей, формулируете проблему, которую необходимо решить, и – «у вас есть две минуты, чтобы записать все идеи, которые придут им в голову [насчет решения этой проблемы], – сказал мне директор по разработке и запуску продуктов Джейсон Стирман. – После этого у вас будет пять минут, чтобы записать идеи на доску и объяснить их. После этого – еще две минуты, чтобы дописать недостающие идеи… конечный результат – вы получаете максимально возможное количество идей. Мы так часто устраиваем мозговой штурм».

«ЗАДОМ НАПЕРЕД»

Есть еще одна мощная техника, которую используют в Amazon. Она известна как «задом наперед» (working backwards). Сначала владелец продукта должен написать предполагаемый пресс-релиз для будущего продукта, а также собрать придуманные цитаты из отзывов пользователей, часто задаваемые вопросы и рассказы покупателей о том, как они использовали продукт.

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

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

Вернер Фогелс, главный технический директор в Amazon, так объясняет этот процесс:

Формирование технических требований к продукту происходит «задом наперед»: мы начинаем с написания документов, которые понадобятся при запуске продукта (пресс-релиз, часто задаваемые вопросы), а на их основе разрабатываем документы, которые необходимы для практической реализации.

Формирование технических требований к продукту «задом наперед» позволяет увидеть концепцию целиком и четко понять, что именно мы собираемся «взять и сделать»[75]75
  http://www.allthingsdistributed.com/2006/11/working_backwards.html


[Закрыть].

По Фогелсу, в технике «задом наперед» задействованы четыре документа.

Пресс-релиз

Для чего предназначен продукт и почему он создан.

Часто задаваемые вопросы

Вопросы, которые могут возникнуть после прочтения пресс-релиза.

Описание потребительского опыта

Описание того, что увидит и почувствует потребитель при использовании продукта, и соответствующие иллюстрации к этому описанию.

Руководство пользователя

К нему пользователь будет обращаться, чтобы разобраться, как применять продукт.

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

Центральным элементом метода «задом наперед» выступает пресс-релиз. Этот документ объемом не более полутора страниц – путеводная звезда и краеугольный камень продукта, и иногда именно он может определять ход развития событий.

«У меня есть проверенное правило: если сложно написать пресс-релиз, скорее всего, и продукт выйдет отвратительный, – говорит Иан Макаллистер из Amazon. – Работайте над ним до тех пор, пока вы ясно не увидите идею каждого абзаца»[76]76
  http://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management


[Закрыть].

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

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

Итак, как должен выглядеть пресс-релиз? Благодаря Макаллистеру у нас есть очень точное описание документа, который используют в Amazon на совещаниях по продукту:

1. Заголовок: название продукта. Поймет ли целевая аудитория значение названия? Захотят ли они узнать больше?

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

3. Описание: кратко опишите суть продукта и его преимущества. Макаллистер предостерегает: велика вероятность, что ваши покупатели дочитают только до этого места, так что «убедитесь, что этот абзац хорош».

4. Проблема: именно это вы и исследовали. Какую проблему решает ваш продукт? Какие нужды ваших покупателей удовлетворяет этот продукт?

5. Решение: как продукт решает проблемы покупателей наиболее безболезненным из возможных способов?

6. Цитата представителя компании.

7. Как начать: как покупатель может сделать первый шаг в новый мир – к вашему продукту? Опишите идеальный «первый шаг», который сразу же принесет выгоду покупателю.

8. Цитата покупателя: что скажет идеальный покупатель после того, как ваш продукт удовлетворит его потребности?

9. Подведение итогов, призыв к действию.

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

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

СОЗДАНИЕ ИНСТРУКЦИИ ПО ПРОДУКТУ

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

Мне нравится подход Кэпа Уоткинса, вице-президента в Buzzfeed и бывшего старшего менеджера по дизайну продуктов в Etsy. По итогам совещания он предлагает создать «инструкцию по продукту»[77]77
  http://blog.capwatkins.com/my-design-process-part-1


[Закрыть]:

После совещания по продукту запишите:

Что вы делаете.

Почему вы это делаете (какие проблемы пытаетесь решить).

Как вы поймете, что делаете это успешно (количественные и качественные показатели).

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

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

Еще до второго пришествия Стива Джобса в Apple появилось правило для любого проекта компании: «Назначить ответственного». Очень просто и очень эффективно. Впишите имя ответственного лица напротив задания на виду у всей компании и будьте уверены – он почувствует личную ответственность за проект[78]78
  http://allvirtual.me/2012/09/04/what-inside-apple-teaches-you-about-product-marketing-and-product-management


[Закрыть].

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

Как выстроить контроль и управление? Как выиграть гонку со временем и сделать для клиентов по-настоящему ценный продукт?

Intercom – компания, специализирующаяся на удержании клиентов, определяет для своих продуктов еженедельные цели. «Совершенства можно достичь за 1000 маленьких шагов.

Мы всегда стараемся сделать то, что быстрее и легче приближает нас к цели. Все наши проекты разделены на множество маленьких независимых релизов, и каждый из них предлагает что-то ценное нашим клиентам»[79]79
  https://blog.intercom.io/how-we-build-software


[Закрыть].

В AngelList Грэм Дженкинс одинаково требователен и к себе, и к своей команде – новый продукт нужно выпустить в кратчайшие сроки. «Мы всегда думаем о том, как закончить задание к вечеру – или к концу недели. Успеем ли мы до конца недели? Если нет, может, мы решаем не ту проблему?» Этот подход представляет собой скорее паутину из необходимостей, появляющихся в конкретный момент, чем жесткий набор дедлайнов.

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

Как бы ни обстояли дела в вашей команде, помните: вы – связующее звено. Будьте лидером. Становитесь на защиту потребителя. Не размахивайте руками впустую, не нужно лишней бравады.

Вы способны на большее. Вы талантливы. И наверняка выглядите лучше.