Когда я пришёл в Intercom, здесь не было ни одного продакт-менеджера и продуктового-дизайнера. Т.е были только я, Дарра (возглавлявший команду инженеров), 6-8 инженеров и наши основатели. В первые шесть месяцев мы работали как умели, каждый брался за то, что умел лучше всего. Например, я был продуктовым дизайнером, а также продакт-менеджером и исследователем.
У нас был определенный процесс развития продукта. Роадмап (roadmap, план развития) мы построили на доске и он был очень простой: просто список проектов, которые мы хотели воплотить, при этом каждый проект устранял одну четкую проблему и была оценка, сколько времени может потребоваться на реализацию. Проекты длились до четырех недель. Мы были одержимы поставкой продукта клиентам и неистово желали, чтобы продукт попадал в руки клиентов как можно скорее, а мы бы тогда смогли узнать, удалось ли устранить проблему.
Мы переросли этот процесс, когда у нас появилось около 20 человек по развитию продуктов и инженеров. Но мы до сих пор соблюдаем основные принципы создания высококлассного программного обеспечения:
- Мы жестко фокусируемся на конкретной задаче/проблеме, которую стоит решить. Мы как одержимые: непрерывно общаемся с клиентами, исследуем их ситуацию/задачи/проблемы, представления и ментальные модели, желания и потребности. Наши продакты держат прямой контакт с клиентами в личных сообщениях в соцсетях и мессенджерах.
Когда я вспоминаю компании, в которых работал на старте карьеры, то понимаю, что там настолько не забуривались в специфику проблем так, как мы в Intercom. Мы делали софт на заказ и многие идеи, которые люди придумывали для своих продуктов, вообще не решали никаких полезных задач и были оторваны от реального мира.
Идеи были очень похожи на надуманные и, возможно, поэтому срабатывали редко. В Intercom мы уже так не работаем. Нам нужно знать, что мы вкладываем наши драгоценные ресурсы на решение реальных проблем (настояющих задач), с которыми сталкиваются многие наши клиенты. Мы не можем позволить себе роскошь гадать. - Мы знаем, что каждая мелочь влияет на итоговое решение. Поэтому мы мыслим глобально, но готовы погрузиться так глубоко как требуется и выточить мельчайшие детали. Конечно, это непросто, но только при таком подходе мы мы ощущаем, что действительно сфокусировались.
- Мы поставляем продукт, в том числе, чтобы учиться. Поставка продукта — это только начало создания продукта. Поэтому мы предоставляем доступ к новым версиям так быстро как только можем. Многие стартапы неверно понимают такой подход, им кажется, что это про вывод поделок на рынок с целью найти то, что приживется.Мы не любители многовариантного тестирования. Мы — противники экспериментов. Стартапы, которые прибегают к экспериментам для принятия решений о развитии продукта, недостаточно фокусируются на проблемах, которые призваны решать их продукты.
- Поставка продукта с целью обучения подразумевает уверенность в том, что понимаешь и решаешь важную проблему. Также она подразумевает скромность, чтобы признать, что вы по-настоящему учитесь только когда продукт оказывается в руках у клиентов. Все лучшие продакты, с которыми я работал, проявляют неудержимое любопытство после того, как что-то выпускают. Им важно знать, помогло ли то, что они спроектировали и построили, их клиентам.
Вот эта комбинация во многом и была нашим секретом: мы становимся одержимыми проблемой, которую важно решить; мы остаемся сфокусированными на этой проблеме; активно ищем решения, которые, как мы верим, решат эту очень конкретную проблему; и мы поставляем продукт, подразумевая, что нам еще есть чему поучиться.
В интернете уже достаточно советов и схем правильного создания программного обеспечения. но очень мало Tech-стартапов, реально показывают, как это происходит. Зачастую это такой клубок непоследовательных событий, что делиться этим как системой, ну просто не выходит.
С момента запуска Intercom, мы сами тоже прилично открыли для себя нюансов о масштабировании команды создания продуктов и о том, как создать ценный продукт как можно быстрее.
Что здесь хотелось бы подчеркнуть:
- Этот процесс отражает то, как мы создавали продукт на старте Intercom, когда у нас было 4 продакт-менеджера, четыре продуктовых дизайнера и 25 разработчиков. С тех пор команда значительно выросла, так что прямо сейчас мы живём уже по несколько другой реальности;
- То, как мы создаем продукт, сильно зависит от культуры. Если вы живете в другой реальности (и создаете продукт под другой культурный контекст), то и действия должны быть другими. Тем не менее, мы выделили ключевые принципы, которые могут пригодиться. И помогут понять, как начать создание продукта.
1. Создайте руководство (гайдлайны) по принятию решений
Чтобы развивать и масштабировать продуктовую команду, вам нужен список ценностей, которые помогут вам принимать правильные решения — это то, во что вы все вместе верите, и что соответствует вашим коллективным убеждениям. Наши гайдлайны служат именно этой цели.
Много маленьких шагов лучше больших запусков
Величие достигается за 1000 маленьких шагов. Вручите клиету самую маленькую и простую вещь, которая будет как можно быстрее приближать вас к цели. А ещё помогает понять, что именно работает, а что нет.
Прорабатывайте ежедневные и еженедельные цели
Каждый конкретный рабочий день имеет значение. Каждый участник команды должен понимать, какие у него цели на день, как они соотносятся с недельной целью команды и как они связаны с тем, что создает компания.
Оптимизация для работы в парах
Работа выполняется быстрее при личном общении. Два человека у доски генерируют больше идей и достигают консенсуса быстрее, чем любая другая схема, которую мы видели. Также нужно быть готовым, что в удаленном формате процессы принятия решений могут протекать медленнее.
Стремитесь к простоте
Зачастую проработать ключевые моменты в разы быстрее с помощью доски и стикеров, а не в каком-нибудь редакторе. Боритесь со всем, что выходит за рамки легкого процесса. Упрощайте и систематизируйте рабочие процессы, используйте как можно меньше различных программ.
Реальный эффект (outcome) важнее плана
Планы составляются в контексте той информации и положения дел, которые есть прямо сейчас. Но зачастую в уже в процессе работы возникают новые нюансы, которые уточняют как постановку задачи, так и сам план по достижению цели. Сильные продуктовые команды быстрее схватывают, шустрее реагируют на обновляющую обстановку.
Чтобы лучше понять истинную ценность реального эффекта (outcome) по сравнению с формальными результатами (output), давайте рассмотрим вопрос через призму крупной компании и ее клиентов. Формальные результаты работы (output) — это характеристики и преимущества услуги/продукта. Реальный эффект (outcome) — это значимый опыт, который получают клиенты, когда внедряют эти услуги или продукты в работу и начинают получать пользу.
Теперь возьмем завод, который производит семейные автомобили. Их результат работы (output) — штампованный металл и пластик. Однако клиенты видят не только это. Клиенты видят способ безопасно доставить свои семьи из одного места в другое. Они ищут душевного спокойствия, а для этого им важно чувствовать себя защитниками своих семей. Таков реальный эффект (outcome): в нем заключается смысл и ценность отношений, в нем отражаются обещания бренда.
«Философия MVP порой трактуется совсем неверно. Она не о том, что нужно отправлять плохой продукт как можно быстрее. MVP — это не про фокусировку на минимуме, без отчета о жизнеспособности. Протестируйте прототип с группой целевых пользователей перед масштабной поставкой, и вы сможете оценить, MVP ли вы собрали и требуется внести правки».
2. Четко распределите зоны ответственности
При создании продукта должно быть предельно ясно, кто за что отвечает. Если проблема в дизайне, её решает дизайнер (в следующий раз убедитесь, что он погрузился и изучил исследования (research) и разобрался в проблеме, которую вы решаете). Если в продукте слишком много багов, то вопросы к продакт-менеджеру (в следующий раз убедитесь, что он обеспечил тестирование реального использования продукта).
В зонах общей ответственности требуется сотрудничество. Обычно здесь все решается через договоренности. Главное на ретроспективе затрат/результатов помимо работ в прямой зоне ответственности, не забыть учесть и эти моменты.
3. Создайте простой и ясный роадмап (roadmap, карта развития продукта)
Хороший роадмап опирается на несколько первоисточников (мы их еще разберем). В основе нашего роадмапа следующие моменты: вещи, в которое мы верим; новые идеи, которые у нас есть; функции, которые помогают нам масштабироваться; обратная связь (qualitative feedback) от клиентов и количественные данные (qualitative feedback), собранный путем замеров результативности нашего продукта.
Самый драйв здесь в том, чтобы умело балансировать эти ингредиенты и объединить их в четкий план того, что нужно построить в течение следующих нескольких месяцев.
Когда Intercom был небольшой командой разработчиков, нам помогал формат подачи роадмапа в трех временных срезах: следующие шесть лет, шесть месяцев и шесть недель.
Следующие шесть лет
Это картина мира через шесть лет, с учетом того, как продукт будет развиваться.
Следующие шесть месяцев
Это ваш план создания таких штук, которые окажут существенное влияние на ваш путь развития и которые вы хотите привнести в мир. Когда вы смотрите на то, что вам предстоит сделать за следующие 6 месяцев, вы должны думать: «Да, клевая динамика!»
Ваш шестимесячный план может меняться. Если взглянете на то, что сделали за прошлые полгода, то найдете около 50–75% того, что удалось запланировать, и минимум 25% того, о чём вы вообще до этого не думали. Обновляйте этот план каждые несколько месяцев.
Следующие шесть недель
План на следующие 6 недель максимально проработан. Это ваши ближайшие задачи и цели и то, что уже хорошо понимает ваша команда. Помогает быть в курсе того, что строится. Работы по проектированию уже идут полным ходом. Обновляется каждую неделю-две.
4. Развивайте культуру постановки целей
Чтобы быть уверенным, что вы сосредоточены и не сходите с пути, ставьте для команды еженедельные цели. Ежедневные и еженедельные цели — отличный способ помочь вам расставить приоритеты. Кстати, постоянно появляющиеся задачи, отвлекают же внимание и делают постановку таких целей просто необходимой!
Чтобы достигать еженедельных целей, разбивайте их на ежедневные и промежуточные цели. Каждый отдельный день имеет значение и также важен темп.
Наш процесс создания продукта ни в коем случае не идеален. Более того, мы активно развиваем его, так что даже пока вы прочитаете этот текст, мы опять внесем какие-нибудь изменения. Однако эти 4 основных принципа — хорошая отправная точка, чтобы проанализировать вашу систему создания продуктов и помочь ее усовершенствовать.
Как устроен план развития продукта (roadmap или карта развития продукта)
Роадмап соткан из сложных решений и мучительных компромиссов. Должны ли вы создавать новые интересные продукты или дорабатывать свой существующий? Стоит разрабатывать новые фичи для потенциальных клиентов или лучше сосредоточиться на решении проблем клиентов?
Проработка приоритетов — это большая работа. В ней нам помогает подход пяти категорий:
1. Новые идеи, которые у нас есть
Они основаны на мнениях, а не на исследованиях. Включают в себя тренды, которые мы подмечаем, и любые наши идеи. Они не обоснованы данными (not data driven). Они приходит в моменты наблюдений за тем, что происходит и отражают наши волнения.
Например, мы знали, что нам нужны эмодзи и стикеры в Intercom. Мы знали, что это важная часть современного обмена сообщениями. Клиенты их не просили. Но мы создали их, потому что верили в них, и люди их любили.
2. Работа над ошибками
Популярная ошибка у разработчиков — выпускать что-то и сразу же переходить к разработке чего-то нового. Но правда такова, что с первого раза у вас никогда не получится выпустить идеальный софт. Это аксиома, как бы вы сильно ни старались и как много тестов ни проводили. Так что для нас запуск продукта — это только начало пути развития. А еще такой подход требует тщательного планирования и настойчивости.
Работа над ошибками — это простая задача, особенно когда у вас есть критерии успешности. Поэтому мы задаем себе критерии успеха, часто в виде метрик, измеряем их после запуска, а затем при необходимости связываемся с клиентами для получения обратной связи (qualitative feedback).
3. Самые распространенные проблемы пользователей
Каждую неделю наша команда продакт-менеджеров вычитывает сотни диалогов с клиентами. Когда служба поддержки Intercom общается с ними, сотрудники помечают все переписки тегами-категориями (например, проблемы с юзабилити, запрос, баг / usability issue, feature request, bug), а также отмечает команду (разработчиков, дизайнеров и т.д.), которая ответствечает за ту или иную проблему и команду, которая владеет этой областью продукта. Раз в неделю продакт-менеджеры разбирают эти переписки и напрямую связываются с пользователями, чтобы узнать о ситуации подробнее. Кроме того, каждые несколько месяцев наша исследовательская группа (research team) собирает все разговоры, анализирует их и составляет hot-лист самых популярных проблем клиентов. Так благодаря еженедельному ритму работы продактов и системному анализу исследователей мы можем легко определить, какие проблемы решать в первую очередь.
4. Улучшение качества
Во всех программах есть ошибки. Стремление к нулевому количеству ошибок (zero bugs) нереалистично, непрактично и, безусловно, чрезмерно оптимистично и дает слабую отдачу. Таким образом, все проблемы должны быть оценены по важности для целевых сегментов. Для оценки мы используем два основных показателя:
- Насколько серьезна проблема?
- На скольких клиентов это влияет?
Держите высокую планку скорости работы, релизов и результативности в том, что вы создаете. Большая часть релизов в нашем случае — это доработки.
5. Функции, помогающие масштабироваться
Если у вас быстрорастущая компания, вместе с ростом вы будете замечать и новые проблемы в вашем продукте. Например, однажды вы начнете привлекать очень крупных клиентов, которые будут сильно больше, чем вы видели раньше. А еще клиенты будут приходить из таких индустрий, с которыми вы раньше вообще не имели дела.
Также возьмите на заметку, что никогда не создавайте функцию просто для закрытия сделки — вникайте в ситуацию в процессе продаж — это отличная возможность изучить потенциальных клиентов и узнать о фичах, которые они ищут.
Ищите подходящий баланс
Благодаря этим пяти входам искусство уравновешивает конкурирующие требования. Как мы можем создавать интересные новые продукты, улучшать существующий продукт, предоставлять часто запрашиваемые функции от существующих клиентов и добавлять новые функции, необходимые потенциальным клиентам, сохраняя при этом все высокое качество, отсутствие ошибок, быстроту и производительность?
Настоящее искусство — это сохранение баланса между приоритетами в контексте вот такого вопроса: Как мы можем создавать новые продукты, улучшать существующие, пилить часто запрашиваемые функции для существующих клиентов, добавлять новые функции для потенциальных клиентов да так, чтобы сохранять высокое качество, отсутствие ошибок, скорость и производительность?
Добро пожаловать в мир жестких компромиссов. Если вы будете работать только над новшествами, у вас получится приложение наполовину бесполезное, наполовину законченное, глючное и медленное. Точно так же, если вы просто будете решать «наиболее распространенные проблемы клиентов», вы решите проблемы клиентов сегодня, но проигнорируете те, которые у них могут возникнуть завтра.
Запуск — это только начало
Слишком часто выпуск продукта рассматривается как некая высота или рубеж, после которого можно переходить к разработке нового проекта или просто уйти в другую команду. Но вообще-то всё наоборот, запуск — это только начало.
«Софт становится ценным только тогда, когда попадает в руки пользователей. А до того момента это просто дорогостоящая большая работа и множество допущений.»
Культивировать такое мышление в команде нам помогают три принципа:
1. Спокойно относитесь к тому, что новые фичи не всегда идеальны
Вы не будете в чём-то хороши, если у вас на старте не будет свободы делать ошибки. ошибки. Если вы верите, что каждая идея должна выглядеть и звучать великолепно, не удивляйтесь, если их будет очень мало… Если у вас их очень мало, не удивляйтесь, если вы выберете плохую. А когда вы беретесь за плохую идею, никакие итерации не сделают ее отличной.
Мы часто выпускали штуки, которые не назовешь «идеальными». Всегда есть список штук, которые можно было бы улучшить, и дополнительные функции, которые можно было бы добавить. Но мы сознательно не добавляли их, чтобы ускорить запуск. Мы считаем, что запуск и релизы — это сердцебиение компании, а также способ быстро узнать от наших клиентов, что стоит развить в первую очередь.
2. Следите за автономностью и четкостью границ
Автономность означает, что разработчикам не придётся изучать весь код, разные его несвязанные части, чтобы продолжать работу. Это особенно здорово, когда в команду приходят новые люди, потому что они могут сразу включиться в работу. Хорошая масштабируемость определяется просто — новые проекты можно выпускать в течение недели.
Всегда есть искушение взяться за что-то большее, что-то более амбициозное, новаторское. Но противоположный подход на практике срабатывает лучше. Если разбить большую картинку-паззл на много мелких частей, а потом начать их постепенно собирать, они, конечно, не всегда будут подходить. Но зато вы сможете учиться с каждым новым фрагментом и неудачей.
3. Продажа — это обучение
Вы никогда не предскажете на 100% реакцию пользователей. Вам лучше дать людям базовый набор функций, посмотреть, как они себя ведут, и быстро начать дорабатывать итерациями. Мы продаём, чтобы учиться. Мы знаем, что ошибаться будем чаще, чем будем правы. Поскольку мы больше всего заботимся об обучении, мы отдаем предпочтение скорости выполнения.
«Чем быстрее вы сможете получить обратную связь о том, что вы думаете, тем лучше будет ваша идея. Продукт в руках клиентов — это кислород для идей».
Мы все мечтаем о том, каким великолепным будет наш продукт. Как дизайнер вы представляете себе нечто прекрасное. Как разработчик вы реализуете это с помощью: методов, классов и граничных значений. Но небольшая ценность, которую вы могли бы поставить несколько месяцев назад и которая понравилась бы вашим клиентам, может научить вас гораздо большему.