Intercom — один из самых быстрорастущих стартапов мира. Всего за 6 лет компания превратилась из никому неизвестного проекта с командой из 10 человек в гиганта с оценочной стоимостью в 1.25 миллиарда долларов.
Поэтому книга «Intercom On Starting Up» — настоящий клад для любого стартапа. И для product-менеджеров, которые могут перенять у Intercom искусство общения со своими пользователями.
Мы решили поделиться с вами переводом гайда, который, наверняка, сильно поможет многим. Перевод первой главы ищите в блоге у Lex Mosolov, вашему вниманию — вторая, а на подходе третья — «Какую цену выставить?»
Когда я пришёл в Intercom, здесь не было ни одного product-менеджера или product-дизайнера. Были только я, Дарра (который возглавлял отдел разработки), 6–8 разработчиков и наши основатели. В первые 6 месяцев все мы занимались абсолютно всем. Я был product-дизайнером, product-менеджером и исследователем.
Мы постоянно что-то меняли. Мы записывали roadmap всего продукта на доске. У нас всё было просто: мы вели список проектов, которые хотели реализовать; список проблем, которые каждый из них должен был решить; и пытались рассчитать, сколько на это понадобится времени. Каждый проект длился меньше 4-х недель. Нам хотелось передать продукт в руки пользователей как можно быстрее, чтобы понимать, решаем ли мы вообще их проблемы.
Мы переросли этот процесс, когда в нашей команде продактов и разработчиков оказалось уже около 20 человек. Но мы до сих пор соблюдаем основные принципы по созданию продукта:
· Мы чётко сосредотачиваемся на той проблеме, которую решаем прямо сейчас. Мы одержимые — постоянно общаемся с клиентами, исследуем их проблемы, спрашиваем об их восприятии, «хотелках» и нуждах. Мы общаемся с ними прямо в личных сообщениях в соцсетях и месcенджерах.
Когда я вспоминаю те компании, в которых работал на старте карьеры, я понимаю, что люди не сосредотачивались на проблемах так, как мы в Intercom. Многие идеи, которые люди придумывали для своих продуктов, вообще не решила никаких задач и были оторваны от реального мира. Часто какой-нибудь высокостоящий человек кидал идею, с которой столкнулся в жизни. Очень редко они действительно срабатывали, но чаще — проваливались. В Intercom мы так не работаем. Нам нужно чётко понимать, что мы тратим драгоценные ресурсы на реальные проблемы, которые есть у большинства наших пользователей. У нас нет такой драгоценности, как возможность строить гипотезы.
· Мы цепляемся к самым мелким, как иногда кажется, деталям, которые могут решить проблему. Мы думаем широко. Но иногда готовы опускаться до мельчайших улучшений. Это больно, но так мы точно знаем, что сосредоточены.
· Мы продаём продукт, в том числе, чтобы учиться. Продажа — это только верхушка айсберга под названием «разработка продукта». Мы даём доступ к новым версиям как можно быстрее. Многие стартапы не совсем понимают, как надо с этим работать. Мы не любители многовариантного тестирования. Мы — противники экспериментов. Стартапы, которые постоянно возвращаются к экспериментам, чтобы принять решение о новых фичах, недостаточно фокусируются на проблемах, которые решают их продукты.
Продажа ради обучения — это уверенность, что вы осознали и решили проблему. Но и нужно быть поскромнее и понимать, что вы по-настоящему учитесь только когда продукт в руках у клиентов. Все лучшие продакты, с которыми я работал, становились до навязчивости любопытными, когда отдавали сервис потребителю. Им нужно было обязательно убедиться — то, что они придумали и разработали, помогло их клиентам.
И вот эта комбинация во многом была нашим секретом. Мы преследовали проблему, которую нужно было решить; фокусировались на ней, как лазер; потом мы находили решение, которое, как нам казалось, должно было её решить; и отдавали клиентам сервис и знание, что нам ещё много чему есть поучиться.
Очень многие в интернете пишут о том, как вы должны создавать продукт, но очень мало IT-стартапов, которые реально показали, как это происходит. Довольно часто это неприятная реальность, которой никто не хочет делиться.
С тех пор как мы основали Intercom, мы многое узнали о масштабировании команды и о том, как создать ценный продукт как можно быстрее.
Только сразу оговорюсь:
· Этот процесс происходил тогда, когда у нас было 4 product-менеджера, 4 product-дизайнера и 25 разработчиков. С тех пор команда значительно выросла, так что прямо сейчас мы живём уже по несколько другой системе.
· Процесс создания продукта очень сильно зависит от культуры общества. Если вы живете в другой реальности, то и действия должны быть другими. Тем не менее, мы выделили ключевые принципы, которые всё равно будут эффективны. И помогут понять, как начать постройку продукта.
1. Создайте набор гайдлайнов для принятия решений
Для того, чтобы увеличивать и масштабировать команду, вам нужно составить список ценностей. То, во что вы все вместе верите. Вот зачем нам нужны наши гайдлайны.
Много мелких шагов лучше больших запусков
Величие достигается в 1000 маленьких шажочков. Когда вы отдаёте продукт клиенту — это самая простая вещь, которая движет вас ближе к цели быстрее всего. А ещё помогает понять, что именно работает, а что нет.
Думайте о каждодневных и еженедельных целях
Каждый отдельный день работы имеет значение. Любой член команды должен понимать, какие у него цели на день, как они соотносятся с командными еженедельными задачами и какой вклад они вносят в каждый релиз продукта.
Переориентируйтесь под работу лицом к лицу
Работа спорится, когда вы с коллегами находитесь рядом. Два человека у маркерной доски — самая продуктивная форма деятельности, которую мы вообще видели. Генерится больше идей, быстрее достигается консенсус. Удалёнка здорово работает во многих случаях, но не тогда, когда нужна скорость и эффективность в принятии решений.
Чем проще, тем лучше
Иногда использование софта при разработке софта тормозит работу, а вот доска и стикеры работают лучше. Не усложняйте рабочие процессы, используйте как можно меньше различных программ.
Результат важнее плана
Планы составляются в контексте той информации и положения дел, которые есть прямо сейчас. Но всегда появляется что-то ещё, в ходе работы вы узнаёте новые вещи. Лучшие команды всегда подстраиваются под меняющиеся обстоятельства.
«Философия MVP иногда понимается совсем неправильно. Не надо отправлять дерьмовый продукт как можно быстрее. Не фокусируйтесь только на минимуме, забыв о жизнеспособности. Протестируйте прототип на вашей целевой аудитории до запуска, чтобы убедиться — продукт, который вы отправляется, достоин называться как минимум MVP».
Sian Townsend, директор по исследованиям Intercom
2. Чётко распределите зоны ответственности
При разработке продукта должно быть кристально ясно, кто и за что отвечает. Если проблема в дизайне, её и решает дизайнер (в следующий раз убедитесь, что он «в теме» — понимает, что вы попросили исправить). Если в продукте слишком много багов, то вопросы к product-менеджеру (в следующий раз убедитесь, что он тестирует реальное использование продукта).
Безусловно, если зоны общей ответственности, и члены команды помогают друг другу в смежных областях. Так конечный результат будет намного лучше. Но когда вы садитесь и анализируете, на что команда тратит своё драгоценное время, нужно чётко разделять, чем занимается каждый.
3. Создайте лёгкую, прозрачную roadmap
Хорошая roadmap основывается на нескольких основных источниках. Подробнее об этом — чуть ниже. Наша карта строится на вещах, в которые мы верим, на наших идеях, которые помогают нам масштабироваться, на качественной обратной связи от пользователей и количественных данных, основанных на измерении производительности нашего продукта.
Сложность здесь в том, чтобы умело сочетать эти ингредиенты и вычленить из них чёткий план на следующие несколько месяцев.
Когда Intercom был совсем маленькой командой, по-настоящему эффективным было прописывать roadmap в трёх измерениях: следующие 6 лет, 6 месяцев и 6 недель.
Следующие 6 лет
Это должна быть картина вашего мира через 6 лет. Здесь нужно принять во внимание и все возможные изменения, которые вы будете вносить в проект.
Следующие 6 месяцев
Это план тех вещей, которые окажут огромное влияние на ваше приключение — создание продукта, который изменит мир. Когда вы смотрите на то, что вам предстоит сделать за следующие 6 месяцев, вы должны думать: «Да мы очень круто идём!»
Ваш шестимесячный план — штука ветреная, непостоянная, учтите это. Если взглянете на то, что сделали за предыдущие полгода, около 50–75% будет тем, что вы планировали заранее, а как минимум 25% тем, о чём вы вообще до этого не думали. Это постоянно обновляющаяся временная шкала, которая обновляется каждые несколько месяцев.
Следующие 6 недель
План на следующие 6 недель максимально конкретен. Это ваш непосредственный план и то, в чём команда широко разбирается. Вы точно знаете, что сейчас происходит и разрабатывается. Эта «измерение» обновляется каждую неделю-две.
4. Воспитайте культуру постановки целей
Чтобы быть уверенным, что вы сосредоточены и не сходите с пути, ставьте для команды еженедельные цели. А постоянно добавляющиеся задачи, которые отвлекают внимание, делают постановку таких целей просто необходимой!
Вспомните, что каждый отдельный день работы имеет значение. Разбивайте еженедельные цели по ежедневным задачам.
Наш процесс создания продукта совсем не идеален. Более того, мы постоянно меняем его, так что даже пока вы прочитаете этот текст, мы опять внесём какие-то изменения. Однако эти 4 основных принципа — отличная отправная точка, чтобы проанализировать вашу разработку и помочь вам делать её лучше.
Анатомия roadmap
Чтобы определить, что будет в вашей roadmap, придётся принимать сложные решения и идти на мучительные компромиссы. Должны ли вы создавать новые интересные продукты или дорабатывать свой существующий? Стоит разрабатывать новые фичи для потенциальных клиентов или лучше сосредоточиться на решении проблем лояльных пользователей?
Мы много работали, чтобы убедиться — у нас полностью сбалансированный список приоритетов. А чтобы составить его, мы делим все наши идеи на 5 категорий:
1. Новые идеи
Они основаны на мнениях, а не на исследованиях. Включают в себя тренды, которые мы подмечаем, и наши идеи. Происходят не из цифр, а скорее из ощущений. Мы просто смотрим, что происходит вокруг и берём какие-то вещи, которые зацепили нас больше всего.
Например, мы знали, что хотим эмодзи и стикеры в Intercom. Понимали, что сейчас это неотъемлемая часть общения в интернете. Пользователи даже не просили их, но мы добавили эту возможность, потому что знали, что люди их полюбят.
2. Работа над ошибками
Распространённая ошибка большинства разработчиков — они выпускают что-то и сразу же переходят к разработке чего-то нового. Но правда такова, что с первого раза у вас никогда не получится выпустить идеальный софт. Это аксиома, как бы вы сильно ни старались и как много тестов ни проводили. Так что для нас выпуск продукта — это только начало. После этого мы постоянно работаем над ним и делаем лучше. Да, для этого нужно уметь планировать и проявить некоторую настойчивость.
Всё это гораздо проще сделать, когда у вас есть критерии успешности. Мы всегда ставим себе такие критерии, обычно это определённые показатели. Замеряем их после запуска, а потом «ведём» клиентов, если это нужно, чтобы собирать от них фидбек.
3. Самые распространённые проблемы пользователей
Каждую неделю наши product-менеджеры читают сотни переписок наших пользователей. Когда служба поддержки Intercom общается с ними, сотрудники помечают все переписки тегами-категориями (например, проблемы с юзабилити, баг, помощь с использованием). Помечают и команду (разработчиков, дизайнеров и т.д.), кто ответственен за ту или иную проблему.
Один раз в неделю продакты собирают эти переписки и напрямую связываются с пользователями, чтобы узнать о ситуации подробнее. И, в конце концов, каждые несколько месяцев мы составляем список самых главных проблем, которые тут же отсылаем на разработку.
4. Улучшение качества
В любом софте есть баги. Рассчитывать на их отсутствие — ну слишком уж самоуверенно и непрактично. Так что любым недоработкам нужно адекватно расставить приоритеты. У нас для этого есть два критерия:
· Насколько проблема серьёзна?
· Скольких пользователей она касается?
«Лечите» продукт от наибольшей проблемы к меньшей и не прекращайте собирать фидбек.
5. Фичи, которые помогут вырасти
Наконец, если у вас быстрорастущая компания, вместе с ростом вы будете замечать и новые проблемы, которые есть у вашего продукта. Вы столкнётесь настолько крупными клиентами, с какими никогда раньше не работали. Клиенты будут приходить из таких индустрий, с которыми вы раньше вообще не имели дела.
Поэтому постоянно будьте в контакте со своими продажниками. Потому что это отличная возможность изучить потенциальных клиентов и узнать о фичах, которые они ищут.
Найти правильный баланс
Настоящее искусство — это сохранение постоянного баланса между этими пятью приоритетами. Как можно разрабатывать новые продукты, обновлять существующие, добавлять трендовые фичи для новых и лояльных клиентов да так, чтобы сохранять высокое качество, отлавливать баги, быть быстрыми и производительными.
Добро пожаловать в мир непростых противоречий. Если вы работаете только над новыми идеями, у вас будет полурабочее, медленное и забагованное приложение. Но в то же время, если вы работаете только над самыми распространёнными проблемами клиентов, которые есть у них сегодня, вы упустите те, которые могут быть у них завтра.
Запуск — это только начало
Очень часто запуск считают счастливым концом, рубежом, после которого можно переходить к разработке нового проекта или просто уйти в другую команду. Но вообще-то всё наоборот, запуск — это только начало.
«Софт становится ценным только тогда, когда попадает в руки пользователей. А до того момента это просто дорогостоящее накопление тяжёлой работы и предположений»
Darragh Curran (руководитель команды разработки)
Чтобы поощрять подобное мышление в команде, мы следуем трём принципам:
1. Спокойно относитесь к тому, что новые фичи не всегда идеальны
Вы не будете в чём-то хороши, если у вас поначалу не будет свободы совершать ошибки. Если вы верите, что каждая идея должна выглядеть и звучать великолепно, не удивляйтесь, если сначала их не будет совсем… А если их будет всего несколько, не удивляйтесь, если выберите не ту. Когда вы берётесь за плохую идею, её не спасут уже никаких обновления.
Мы часто выпускали штуки, которые не назовёшь «идеальными». Всегда могло быть что-то лучше, что-то можно было добавить. Но мы сознательно не добавляли их, чтобы ускорить выпуск. Для нас запуск продукта или выпуск новой версии — это его сердцебиение. И скорее всего вы услышите от клиентов, как они довольны текущими фичами, хотя вы и переживали за их состоятельность.
2. Следите за автономностью, чёткими границами
Автономность означает, что разработчикам не придётся знать весь код, разные его несвязанные части, чтобы продолжать работу. Это особенно здорово, когда в команду приходят новые люди, потому что они могут сразу включиться в процесс. А чёткие границы значат, что вы сможете выкатывать новые версии в течение недели.
Всегда есть искушение потянуться к чему-то большему, чему-то более амбициозному, новаторскому. Но противоположный подход обычно срабатывает лучше. Если вы разобьёте большую картинку-паззл на много мелких частей, а потом будете их постепенно собирать, они не всегда будут подходить. Но зато вы будете учиться с каждым новым фрагментом и неудачей.
3. Продажа — это обучение
Вы никогда не предскажете на 100% реакцию пользователей. Вам нужно дать им базовый набор функций, собрать фидбек и после этого уже работать над фичами. Мы продаём, чтобы учиться. Мы знаем, что ошибаться будем чаще, чем будем правы. Поскольку мы больше всего заботимся именно об обучении, для нас скорость в приоритете над исполнением.
Мы все мечтаем о том, каким великолепным будет наш продукт. Дизайнер уже представляет какую-нибудь красивую штуку. Разработчик продукмывает, как её воплотить в жизнь. Совсем небольшая польза, которую вы смогли принести клиенту, научит вас очень многому.
Пол Адамс, руководитель по продукту
