Лекция 17 — Как проектировать аппаратные продукты (Хосейн Рахман)

Аппаратный путь создания продуктов

Спасибо, Сэм, что пригласил меня. Мы с Сэмом давно знаем друг друга, потому что мы были компаниями из портфеля Sequoia, и мы встретились в самом начале, когда он был в начале пути своей компании. Он попросил меня сегодня рассказать об аппаратном пути создания продуктов. Я хочу дать вам небольшой обзор Jawbone: чем мы занимаемся, как мы думаем о мире, как мы создаем продукты, а затем перейти к процессу проектирования, разработки и сборки.

Наше видение мира

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

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

Наш путь

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

• Нашим первым потребительским продуктом была гарнитура — по сути, носимый компьютер. Это была первая гарнитура с функцией.
• Затем мы изобрели пространство беспроводных колонок в области Bluetooth-аудио.
• Недавно мы сосредоточились на носимой революции в области здоровья, используя датчики из гарнитур первого поколения и применяя их к другим частям тела.

Проблема Интернета вещей

В Интернете вещей всё умное и подключенное. Ко всему есть приложение, но это не значит, что это легко для пользователей. Ваша микроволновка, холодильник, машина, Xbox, Xfinity, Comcast — у всего есть приложение. Они не общаются друг с другом. Это сбивает пользователя с толку.

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

Носимые устройства как центр

Когда у вас есть устройство на теле 24/7, оно становится идеальным контекстным движком для всего окружающего мира. Мой телефон не всегда при мне — он в куртке или на зарядке. Но моё приложение на мне и понимает всё, что происходит: измеряет пульс, дыхание, отслеживает разные вещи.

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

Мир движется к тому, что носимые устройства станут центром этой революции, где всё будет подключено и умно.

Полный стек

Чтобы видение осуществилось, нужно быть отличными почти во всём. Мы называем это полным стеком:

• Аппаратное обеспечение — люди должны носить устройства 24/7, иначе всё остальное — замок на воздухе.
• Программное обеспечение — мы разработали опыт мирового класса в области приложений. Мы должны быть так же хороши в вовлеченности, как Instagram или WhatsApp.
• Данные — мы должны знать, что делать с огромным количеством информации: обрабатывать, передавать и заставлять работать на пользователя.

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

Трение между дисциплинами

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

Когда мы собрали эти части вместе, это создало интересное трение:

• Команда разработчиков привыкла двигаться очень быстро и итерировать.
• В мире аппаратного обеспечения нужно не торопиться — циклы итераций гораздо более обдуманные. Инструментальная оснастка занимает 16 недель, нельзя просто подправить что-то.

Команда аппаратного обеспечения училась двигаться быстрее, а разработчики — больше думать о том, как разрешить опыт до отгрузки, а не просто выбрасывать что-то и проводить A/B-тестирование. Наука о данных информирует всё это, предоставляя больше информации для принятия решений.

Как мы создаем продукты

Системный подход

Всё для нас — система. Мы не думаем дискретно об аппаратном обеспечении, приложении или платформе. Мы думаем обо всём в целом.

Пример с Up:

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

Процесс создания

Мы держим это в секрете, но процесс выглядит так:

1. Исследование — необузданное воображение, видение, стратегия, бренд.
2. Ранняя валидация — доказать концепции, как диссертацию PhD.
3. Концептуализация — каким будет опыт, что возможно.
4. Тщательное планирование — компромиссы между творчеством и физикой, мощностью батареи, ограничениями.
5. Разработка — передача между функциональными командами, решение проблем.
6. Запуск — учимся, видим, что думают пользователи.
7. Итерация — начинаем заново.

Фаза исследования

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

Возглавляется командой стратегического развития (R&D). Участвуют отделы продуктов и инженерии — аппаратной и программной. Руководители выступают в роли резонаторов: тыкают и подталкивают людей.

Чтобы перейти к следующему порогу, мы думаем: «Дал бы я этому парню 50 тысяч?» — как ангельская инвестиция. Наш CTO — окончательное лицо, принимающее решения.

Фаза валидации

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

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

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

Фаза концепции

Ответственность переходит от R&D к команде по опыту продукта. В Jawbone это включает промышленный дизайн, дизайн программного обеспечения, аудиодизайн, писателей, рассказчиков, специалистов по ID, дизайнеров приложений, графических дизайнеров. Всё в одной команде.

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

У нас есть ускоренные программы. Например, Jambox — мы сказали: «Мы не будем проходить через другие этапы. Перейдём прямо в разработку, потому что хотим выпустить эту штуку и двигаться очень быстро».

Переход к разработке

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

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

Продакт-менеджеры ведут это. Мы синтезируем всё и спрашиваем: «Пересекает ли это достаточно пунктов из нашего списка? Соответствует ли минимальной жизнеспособности?» Мы начинаем с большого списка пожеланий, затем урезаем его.

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

Магические детали

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

• Jambox — звуковой дизайн «воу-воу» при включении. На то, чтобы придумать правильную аудионастройку, ушли месяцы. Мы работали с разными хореографами.
• Ощущение резины — в мире был только один производитель, который смог сделать резину такого качества, твёрдости и цветов, которые мы хотели.
• Up — анимации появления столбцов, влёта и вылёта карточек. Деталь, над которой мы думали: как это будет взаимодействовать, как пользователь будет воспринимать и чувствовать.

Framework героических впечатлений

Мы начинаем с «почему» — формулировки проблемы, которую решаем. Затем темы становятся действенными концепциями.

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

Вопрос «почему»

Это простой вопрос: какую проблему пользователя мы решаем? Будь то в аппаратном обеспечении, программном обеспечении, данных, платформе. Как только мы её решим, люди не смогут без этого жить.

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

Jambox — отличный пример. Когда мы запустили его осенью 2010 года, рынок беспроводных колонок составлял 0% от общего рынка колонок. Рождество 2013 года — 78%. За несколько лет мы трансформировали индустрию, которая существовала с 50-х и 60-х годов.

Если бы я спросил людей: «Кто хочет колонку за 199 долларов для мобильного телефона?» — 0% сказали бы, что хотят или готовы заплатить. Но когда мы это сделали, это трансформировало индустрию.

Стратегия категории

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

Для Jawbone это был вход в ваш дом. Пока все говорят об умных вещах в доме — лампочках, термостатах, холодильниках — медиа остаётся убийственным приложением. Колонки могут быть нашим входом в этот мир и хабом для вещей, которые мы хотим делать с точки зрения программного обеспечения и сервисов.

Континуум опыта

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

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

Система как флагман

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

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

Героические впечатления

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

Эти принципы управляют всем. Мы должны продолжать задавать себе вопросы: «Делает ли это это?»

Framework опыта

Всё собирается в framework опыта, который становится брифом для инженерной команды, команды дизайнеров и всех, кто работает над продуктом. К нему можно вернуться и спросить: «Что мы делаем? Почему мы это делаем? Как это работает? Как мы создаём в соответствии с этим?»

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