[9]

Наука и искусство запуска

Изобретение vs. промышленное производство

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

Бен Бёрт, режиссер,
звукорежиссер и монтажер «Звездных войн»

Томас Эдисон в центре общественного внимания.

1882 год. Прошло уже несколько лет с тех пор, как в новогодний вечер 1880 года он распахнул ворота своей лаборатории в Менло-Парк, ослепив гостей электрическим светом. Тогда впервые мир увидел мощь электрического освещения. Для такого случая Эдисон даже сделал праздничные гирлянды.

Примерно 3000 ничего не подозревающих, но скептичных зрителей прибыли вечером на платформу пригородного поезда в сонной Менло-Парк. Картина, которая предстала их взору, превосходила даже то, что они видели на Манхэттене (находящемся всего в 20 милях): деревушка была залита немерцающим светом электрических лампочек.

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

Как будто этого было мало, но у Эдисона вдобавок еще и не имелось ценовой модели. Он собрал несколько команд, которые должны были провести исследование рынка. Сколько люди платят за газ? Какую сумму они готовы платить за электричество и оборудование?

Несмотря на обещание, Эдисон не стремился немедленно его выполнять. Критиков становилось все больше. Неужели его обещание — всего лишь пустые слова?

Между изобретением и выпуском готового продукта на рынок лежит настоящая пропасть… Первая фотография появилась спустя много лет после изобретения технологии; то же самое произошло и с пароходом, и с телеграфом.

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

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

Но как понять, что он уже готов? И как выпустить готовый продукт в реальный мир?

Будет готов, когда придет время

Простой ответ таков: продукт готов… когда он готов.

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

Дело в том, что «запуск продукта» — это просто модные словечки, ничего более.

Пора сжечь корабли.

К черту! Запускаемся.

Концентрируемся и продолжаем запускаться.

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

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

Мне нравится, что по этому поводу говорит Кэт Нуун, успешный предприниматель и продуктовый дизайнер:

Это называется «запуск», а не «запор».

Запуск — самое главное.

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

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

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

И, к сожалению, запуск ради запуска не исправит ситуацию.

Если вы находитесь на этой стадии, сделайте шаг назад. «Нельзя путать скорость и поспешность: людям не нужны неправильные ответы, даже если они получили их в рекордно короткие сроки», — писал Кеннид Боулз, бывший дизайн-менеджер Twitter. Добейтесь правильных от­ветов.

Именно это прекрасно понимали в Facebook. В 2014 году Марк Цукерберг открыто заявил о пересмотре своего знаменитого принципа Move fast and break things («Двигайся быстро, ломая все на пути»), который красовался на стенах офиса компании и в рекламных проспектах IPO.

«Раньше мы пытались выпустить продукт как можно быстрее, а затем смотрели, как на него реагирует рынок, — поясняет Брайан Боланд. — Теперь же мы сначала подтверждаем его качество и надежность».

Говоря о технологических гигантах, можно упомянуть и Apple. Со стороны кажется, будто Тим Кук и Джони Айв выводят продукты на рынок, лишь добившись их «волшебного» совершенства. В конце концов, в их распоряжении больше денег, чем у Министерства финансов США. С такими доходами нужно ли им следить за дед­лайном?

На самом деле все обстоит иначе. «Компания не только устанавливает внутренние дедлайны, но и определяет дедлайны для дедлайнов, у которых есть свои дедлайны, — писал бывший старший дизайнер Apple Марк Кавано (сейчас он возглавляет Storehouse — компанию, предлагающую услуги хранения фотоизображений). — Производ­ственный цикл, от начального этапа до даты поставки, тщательно распланирован».

«Подожди-ка, автор, — можете подумать вы. — Ты же сам только что сказал, что продукт можно запускать, только когда он готов. Что-то не сходится».

Как вам такой поворот? Кавано продолжает свою мысль:

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

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

Цель запуска — создать «минимально привлекательный продукт» (Minimum Loveable Product, MLP). Этот придуманный Кэт Нуун термин отражает стремление подготовить продукт, который будет не только решать проблемы пользователей, но и устанавливать с ними эмоциональную связь.

Нуун пишет:

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

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

Но, как заметил Бен Бёрт, знаменитый звукорежиссер «Звездных войн», описывая съемочный процесс: «Фильмы не выпускают в прокат, они сбегают сами».

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

Быть «директором всего»

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

У каждого из нас свой способ контролировать задачи. Доски в Trello. Стикеры Post-It. Wiki-справочники по проектам. Неважно, каким инструментом пользуетесь вы. Постройте ясные отношения со своей коман­дой. Расскажите им, качество какого уровня вы ждете. Убедитесь, что они понимают, что вы от них ждете. И не забудьте убедиться, что каждый занимается тем, чем должен.

Кэт Нуун рассказала мне, что она и сооснователь компании используют общий доступ к спискам Wunderlist, чтобы отслеживать все, что должен сделать перед запуском небольшой стартап (рис. 9.1).

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

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

Кейтлин Фридсон, дизайнер мобильных продуктов компании , использовала сочетание Jira и общих документов в Google Docs. За задачами в Jira могут следить все участники процесса (рис. 9.2), и для каждой из них есть ссылка на документ, в котором подробно описывается каждая функция (рис. 9.3).

Jira нужна мне для создания пользовательских историй (к каждой задаче можно добавить описание из нескольких абзацев), там удобно отслеживать их изменение. Но еще больше мне нравится использовать Jira в сочетании с Google Docs. Так я могу вносить изменения в режиме реального времени: если что-то в задаче устаревает, я оставляю комментарий об этом и затем обновляю описание. А команда разработчиков может отслеживать все изменения и не упускать ничего из виду.

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

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

«Думаю, у вас должно быть достаточно энергии, чтобы во всем разобраться и исправить самостоятельно, — говорит Грэм Дженкин, продуктовый дизайнер в AngelList, онлайн-платформе, где стартапы могут привлечь инвестиции или нанять людей в команду. — Это требует времени и сил, но, если вы хотите, чтобы качество продукта было на приемлемом уровне, вам придется этим заниматься. Это тяжелый труд. Но не думаю, что есть способ избежать его».

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

Тимони Уэст и Кайл Бреггер — они создавали продукты для Foursquare, Flickr и Elepath — независимо друг от друга рассказали мне секрет успешного запуска: отслеживать обращения в техподдержку.

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

Да, это совсем малопривлекательно и отнимает массу времени. Но это самый простой и быстрый способ проникнуть в мысли пользователей после запуска. Поставьте себя на их место: разве не круто пообщаться с человеком, который придумал классную функцию или продукт, который вы используете?

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

Тимони Уэст говорит:

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

Кайл Бреггер соглашается:

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

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

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

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

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

Это еще не конец

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

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

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

Интервью: Джош Элман

Джош Элман — опытный лидер продукта, известный своими революционными проектами, которые изменили процесс человеческого общения. Он возглавлял продуктовые команды в Twitter, Facebook, LinkedIn и Zazzle. В настоящее время Джош — один из партнеров в венчурной компании Greylock.

Можете ли вы выявить что-то общее в ваших проектах (Facebook, LinkedIn, Twitter, Zazzle), каждый из которых стал столь успешным?

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

Во-первых, у них есть четкое представление, как изменится мир в случае успеха их продукта. Они не думают, как сделать успешной компанию или продукт. Они действительно верят в то, что в случае их успеха изменится мир. И это действительно мощный инструмент. В случае RealNetworks это была передача аудио и видео через интернет. Представьте мир, в котором вся аудио- и видеоинформация передается по IP. Сейчас мы уже начинаем в нем жить. Задумайтесь, насколько уже изменили вашу жизнь YouTube и Netflix.

Во-вторых, когда я присоединился к команде LinkedIn, Рид [Хоффман] сказал мне: «Если мы сможем соединить профессионалов со всеми людьми, которых они знают, то изменим привычный способ поиска сотрудников и работы, потому что это то, чего никак не добиться, просто общаясь с людьми». Когда я присоединился к Zazzle, история была примерно такой же: «Ты можешь представить мир, где все, что человек хочет купить, он может найти, заказать и получить в течение 24 часов?». И я продолжаю работать над подобными идеями.

Сегодня Facebook и Twitter кажутся более банальными. Но все это крупные проекты, где было четкое представление о том, как изменится мир. И во всех случаях присутствовало не только видение нового мира, но и последовательный план с описанием всех шагов, необходимых для его изменения. Нужно понимать, что выпуск твоего продукта сам по себе не изменит мир. Чтобы достичь цели, нужно сделать что-то еще.

У каждой компании был свой путь, и каждая верила в свое видение будущего. В LinkedIn мы понимали, что все завязано на то, насколько тесными будут профессиональные связи между людьми. В Zazzle мы знали, что единственный способ заставить людей совершать покупки таким образом — это начать с пары крупных брендов и убедить их в том, что теперь можно заказать такие вещи, об изготовлении которых на заказ никто никогда не задумывался, — например, марки. Да, Zazzle предлагал довольно много почтовых марок под заказ. И каждая из них стала маленьким кирпичиком в большом успехе.

В-третьих, все эти продукты были простыми и не идеальными. Люди часто гонятся за идеалом, но у продуктов, которые помогают людям оставаться на связи друг с другом, всегда есть парочка недостатков. Так что все, что нужно — это сделать лучший выбор в сложившихся обстоятельствах, запустить сервис и привлечь первых пользователей. Со временем вы будете улучшать свой продукт, а не говорить: «Он пока не в полной мере соответствует замыслу» или «Нет, это мы точно не будем выпускать».

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

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

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

Где можно распознать возможность?

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

Нужно определить основную цель и дать пользователям то, что у вас есть сейчас. Почему бы не дать им больше? Если больше пользователей решат свою проблему, у продукта будет больше установок, мы больше заработаем, не правда ли? И какое решение этой проблемы предлагает команда в целом? Ни менеджер продукта, ни маркетологи — а вся коман­да? Определение проблемы — это задача всей компании, и к концу дня менеджер продукта, генеральный менеджер и СЕО должны сказать: «Думаю, это именно та важная проблема, которую мы собираемся решить».

Теперь время поработать продуктовой команде. «Каким может быть наилучшее решение создавшейся проблемы?» И все вместе они должны придумать решение. Когда я говорю об управлении продуктом, то часто использую одну фразу (у меня есть даже соответствующая запись в блоге). Это фраза — «Менеджер продукта должен помочь своей коман­де разработать лучший продукт для пользователей». Помочь коман­де, а не заставить ее.

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

Как вам удается сфокусировать внимание команды на нужных вещах?

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

Итак, что я делаю: мы знаем, что есть проблема, но мы не знаем точно, какова она и как ее решить. Я собираю команду на общий мозговой штурм с вопросом «Что нам делать?». На чем сконцентрироваться в первую очередь, чтобы увеличить активность пользователей? Как привлечь новых пользователей в нашу систему? У меня есть идеи, основанные на моем опыте, у других людей есть идеи, основанные на их мыслях. Мы всё обсуждаем и потом голосуем. Да, я доверяю команде проголосовать. И если команда проголосовала за какой-то вариант как наиболее подходящий для решения проблемы, я доверяю ее решению. В любом случае, этим людям придется воплощать его в жизнь. И мы будем делать это вместе.

Заметьте, не все могут быть согласны, но если каждый видит прозрачную процедуру голосования и обсуждения и если вы открыты и честны, то всегда можете сказать: «Окей, мы выбрали этот вариант все вместе. Мы же команда? Так давайте его придерживаться». Ваша работа — помогать команде делать именно те вещи, которые вы все вместе решили делать, и это уже своего рода соглашение. Так что я действительно думаю, что обсуждение и голосование очень важны.

Как вы управляете процессом создания продукта? Как определяете, что все идет по плану?

На самом деле мне кажется, что хорошие дизайнеры и хорошие инженеры должны чувствовать процесс, как это делаю я. Моя роль — быть лидером. В первую очередь, я фокусируюсь на истории. У продукта всегда должно быть название — даже у самой маленькой из разрабатываемых нами вещей всегда есть название. Каким бы оно ни было — «Электронное страховое письмо», «Поздравительное письмо» или «Новый пользовательский сценарий — 3». Иногда названия могут быть дурацкими, иногда — действительно цепляющими, вроде использованного нами в Twitter «Кого читать?» (в оригинале WTF — Who To Follow). Кстати, эта идея была предложена одним из наших пользователей. Мы всегда стараемся придумать название и вслед за ним — историю.

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

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

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

Я думаю, в первую очередь, если я не могу точно описать свой продукт. Или если я рассказываю о нем людям, а они не до конца могут понять мои идеи и начинают их искажать. Я думаю, эти два момента напрямую касаются меня. Мне кажется, это самое главное. Или ты не можешь описать свой продукт, или ты описываешь его, а люди высказывают свое «фи». Впрочем, даже в этом случае, если вы полностью уверены в своей правоте, все нормально, пока люди хоть как-то понимают ваши идеи. Потому что это означает, что вам всего лишь нужно научиться доносить их лучше. Еще один момент. Если вы начинаете разработку и вся команда говорит, что «это отстой», — это плохой знак. Вы доверяете мнению команды. Но иногда вам приходится противостоять ему, потому что люди зашли в тупик, или потому что задача труднее, чем они думали, или по другим причинам. Но если вы считаете, что что-то правильно (и это расходится с мнением команды), то иногда надо настоять на своем.

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

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

Интервью: Кэт Нуун

Кэт Нуун — опытный продуктовый дизайнер. В настоящее время она работает над Iris, приложением, которое уведомляет близких человека о том, что с ним произошел несчастный случай.

Как вы решаете, что будете делать? Кто участвует в этом про­цессе?

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

Как вы выявляете и решаете проблемы?

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

На что похоже это общение?

Обычно мы просто обсуждаем все, что приходит в голову. У нас есть список «Будущие идеи» на Wunderlist, куда мы записываем свои мысли, а затем обсуждаем их. Мы разбираем все за и против, как идея может отразиться на наших пользователях, платформе и компании. Иногда один из нас загорается какой-то идеей, но в процессе обсуждения выясняются новые подробности и становится очевидным, что воплощать ее мы не будем — потому что это будет пустой тратой времени и/или средств.

Каков результат такой встречи? Документ? План? Календарь? Как вы фиксируете результаты?

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

Мы никогда четко не формируем календарь. Единственное, что привязано к конкретным датам, — это GitHub, потому что нужно как-то отмечать основные вехи, а Wunderlist просто напоминает нам о дедлайнах.

Подобные встречи помогают поддерживать процесс, избегать глобальных ошибок в оформлении продукта?

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

Какие виды сравнительного анализа вы используете? Изучая продукты конкурентов, на что вы обращаете внимание? Сами продукты? Интерфейсные решения? Что им удалось, а что пошло не так?

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

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

Изучаете ли вы отзывы на форумах, обзоры приложений для определения слабых мест и/или потенциальных возможностей? Если так, на что похожи такие исследования?

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

Какие инструменты вы активно используете или изучаете в процессе создания продуктов?

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

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

Как вам удается поддерживать творческую искру?

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

Отправить