Когда дело доходит до продуктовой стратегии, мы в Интерком предпочитаем фреймворк Jobs-to-be-Done, который помогает нам в принятии решения о том, что сделать следующим. Популяризированный профессором Клэем Кристенсеном из Бизнес школы Гарварда, это взгляд на то, как используют ваш продукт, вместо традиционного маркетингового разделения на демографические группы.
Люди не покупают продукт, потому что они попадают в какую-то категорию, например: женщина, среднего возраста, живет в пригороде, работает на пол-ставки. Они покупают продукт, чтобы решить проблему. Если вы понимаете, для какой «работы» пользователи нанимают ваш продукт, тогда вы можете полностью сфокусироваться на том, чтобы они могли достигнуть желаемого результата. Функционал, который вы решите сделать, должен помогать им решать их задачи.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Создаем то, что люди хотят
Проблемы, с которыми сталкиваются люди, почти не изменились за много поколений. Продукты, которые они используют для решения этих проблем меняются постоянно.
Когда вы создаете или управляете новым продуктом, вы должны верить в то, что сможете создать лучшее решение, которое люди захотят использовать, потому что оно даст им больше пользы. Четкое понимание того, что пользователи хотят получить, и как они получают это сейчас, невероятно важно для вас, чтобы создать успешный продукт.
Может быть, ваши пользователи хотят развлечений, или провести время с друзьями, или понять, над каким проектом работает их коллега, или, возможно, они хотят, чтобы их бизнес рос. Если желаемый результат реален, они уже достигают его при помощи каких-то продуктов. Ваша задача улучшить процесс.
Заметки на полях: Если вы не можете найти, какой продукт они сейчас используют, существует шанс, что это «ненастоящая» потребность («Было бы круто, если бы все мои социальные сети были в одном месте?») или «желаемая» («Конечно я хочу похудеть.»). Желаемое поведение никогда не отражает реальность.
Фокусируясь на результате, а не на категории, индустрии или типе продукта вы может узнать настоящих конкурентов. В ту секунду, когда компания начинает фокусироваться на «индустрии, в которой мы работаем», а не на «какой результат мы даем» она теряет хватку и, как следствие, — пользователей.
Например, газеты верили, что они были «Газетной индустрией», и из-за этого не могли понять, почему скучающие пользователи не покупали их продукт. Они смотрели по сторонам, пытаясь понять, какая газета увела их покупателей. Если бы они сфокусировали на результате, который они выдают (скучающие путники хотят быстро развлечься небольшими статьями), тогда их конкуренты (Twitter, Facebook, новостные приложения) были бы более очевидны.
Посмотрим на «работы», которые, как и скука в поездке, существуют во все времена, несмотря на развитие технологий.
Старые запросы, новые решения
Люди, особенно студенты и подростки, хотят обмениваться заметками и сообщениями, не боясь того, что другие люди их увидели… Люди все еще этого хотят, поэтому сегодня они используют Snapchat.
Люди хотят хранить фотографии в надежном месте, например, в коробке из под обуви под кроватью… сегодня они используют для этого Dropbox.
Люди хотят выставлять свои любимые фотографии на видное место, например, полку над камином, чтобы все могли их увидеть…сегодня они используют для этого Facebook.
Люди хотят собирать альбомы с идеями для ремонта или других проектов…сегодня они используют для этого Pinterest.
Люди хотят оставлять хорошие отзывы и советы для других путешественников в книге отзывов…сегодня они используют для этого Foursquare.
Делая работу лучше
Есть сотни примеров похожих на те, что мы разобрали, и всех их объединяет один тренд. Чтобы создать то, что хотят люди, нужно понимать долгосрочные потребности человека или бизнеса и использовать технологии, чтобы:
- упростить
- сделать доступным для большего количества людей
- сделать более вариативным
Первый подход, упрощение, чаще используется в стартапах. Выбрать нишу, в которой существующее устаревшее, сложное и раздутое решение, и найти наиболее простой способ предоставить ту же ценность. Вызов такси требовал звонков в разные фирмы до тех пор, пока вы не найдете свободную, затем долгий диалог о вашем местоположении, точке назначения и времени, которое займет поездка.
Сегодня мы нажимаем одну кнопку, и приезжает машина.
Второй подход в основном задействует удешевление (во времени или деньгах) или устраняет барьеры, чтобы больше людей могли использовать продукт, расширяя тем самым рынок. Четырнадцать лет назад, если кто-то хотел писать в интернете, он должен был арендовать сервер на Linux, скачать архив с исходным кодом блог платформы, загрузить его, выполнить серию странных команд, чтобы распаковать и настроить его.
Сегодня это занимает пару кликов в Medium.
Третий подход исключает различные ограничения при использовании. Прием платежей когда-то включал в себя массивную машину с роликом термальной бумаги, пересылку факса в банк, линии ISDN и партии транзакций, отправляемые по ночам.
Сегодня вы проводите картой через телефон, и все готово.
Джефф Безос знаменит своей фразой «сосредоточьтесь на том, что не меняется». Проблемы, с которыми сталкиваются люди и бизнесы, практически не меняются. То, как они могут быть решены, меняется постоянно. Так что начинать делать то, что люди захотят, нужно с мысли «чего хотят люди», а не более привлекательной «что мы можем создать».
Помните: Гораздо проще создать то, что люди хотят, чем заставить их хотеть чего-то
Быстрый тест для нового фунционала
Вот простой набор вопросов, на которые нужно ответить Да или Нет, прежде чем добавлять очередную функцию в дорожную карту.
В предыдущей главе мы разобрали, как слово «нет» влияет на продуктовую стратегию, но список причин, по которым вы можете отказать фунционалу, не так полезен, как тест, который должна пройти каждая новая функция. Вот список вопросов, на которые точно нужно ответить «Да».
Это соответствует вашему видению?
Во что верите только вы и больше никто? Что вы знаете об этой проблеме, чего никто больше не знает? Как по вашему она должна быть решена? Кто угодно может достать данные, поговорить с фокус группой, прочитать отчет, но только у вас есть видение.
Продуктовые решения, основанные только на видении, могут показаться нерациональными, потому что их тяжело принимать. Большинство людей осознает, что их баг трекер не следит за временем работы серверов. Никто об этом говорит, это не имеет реальной ценности. Но должен ли сервис для менеджмента проектов иметь функционал репортов? Не так очевидно.
Наиболее неординарные решения встретят самое большое сопротивление. Коллеги, пользователи или даже другие менеджеры продуктов и основатели могу начать давить на вас. Вот несколько примеров:
- Apple отказалась делать нетбуки во времена, когда это был самый популярный тип компьютеров. Каждый аналитик требовал этого.
- Basecamp отказались добавлять диаграмму Ганта в свой продукт. За это их заклеймили слепыми идеологистами.
- Разработчик Гаррет Димон отказался добавлять статус «в ожидании» в свой трекер задач Sifter, просто потому что он считал это неправильным способ управления задачами
Помимо того, что это сложное решение, вы никогда не будете уверены, что поступили правильно. Но не бывает правильных или неправильных решений. Это искусство, а не наука. Есть только вы и ваше видение.
Будет ли это иметь значение через пять лет?
Это сложный и крайне скучный вопрос, но будет ли функция давать результат через пять лет? Вы будете выглядеть ворчуном при каждом планировании. Но вот приложение, которое было так популярно в 2013, полностью забыто в 2014. Все эти эффекты, которые были популярны в прошлом году, смотрятся жутко устаревшими в этом. Если вы собираетесь потратить лучшие годы своей жизни на продукт, избегайте трендов, сосредоточьтесь на том, что действительно важно.
Все ли получат от этого пользу?
Опасайтесь «недавно-частотного» искажения. Вы никогда не сомневаетесь в том, что вещи, о которых вы слышали часто или недавно, должны быть добавлены на дорожную карту. Это обычная реакция, направленная на увеличение эмпатии у пользователей. Довольно сложно всегда говорить людям «нет» и слышать одни и те же ответы, поэтому, когда это возможно, мы используем это искажение, чтобы оправдать себя. «Конечно, мы это сделаем, я слышал об этом уже дважды сегодня», говорит основатель с 4800 ежедневно активных пользователей, чтобы порадовать 0,0625% аудитории.Такое искажение опасно тем, что оно дает вам иллюзию анализа, ощущение, что вы подготовились, и это вполне рациональное решение. На самом деле вы приняли ленивое решение, чтобы удовлетворить небольшую часть активных пользователей, не проверив, сколько пользователей действительно хотят эту функцию.
Это улучшит, дополнит или изменит существующий процесс?
Добавление полностью новых процессов в ваш продукт должно быть редким явлением. Большая часть вашего времени должна быть направлена на улучшение, дополнять или изменять существующие, и вы должны понимать за что отвечает каждая функция.
Если вы улучшаете существующее решение, вашими метриками будет удовлетворение пользователе и/или, возможно, уменьшение времени, потраченного на достижение цели или уменьшение обращений в поддержку.
Если вы его дополняете, ваши метрики — это увеличенная частота использования, так как теперь функцию можно использовать для большего количества задач и ситуаций.
С изменением сложнее всего. Вы стремитесь к чему-то «совсем новому», что несет за собой огромный риск, но и огромную награду. Мерилом будут новые пользователи, пришедшие пользователи, которые попали к вам не напрямую, а через PR или маркетинг.Редизайны — это весело, но вы можете легко все проиграть. Хороший способ пробиться к истине — это задавать вопросы «Будет ли больше людей это использовать? Будут ли они использовать это чаще? Если ни то и ни другое, тогда улучшится ли оно для тех, кто использует это сейчас?»
Поможет ли это бизнесу вырасти?
Можете ли вы сопоставить эффект, который произведет новый функционал на пользовательские процессы с тем, сколько денег он может принести? Например, компания, которая создает софт для менеджмента проектов, может сделать шаблоны проектов. Аргументом будет то, что шаблоны можно использовать чаще, это увеличит количество проектов у пользователей, что увеличит количество апгрейдов, и в конечном итоге увеличится прибыль.Нельзя забывать, что уменьшение оттока также помогает бизнесу; деньгам все равно, откуда они приходят. Часто функции добавляют, чтобы удержать пользователей или сильнее привязать их к продукту. Ключевая цель, во всех случаях — понять, как работа влияет на рост, в конце концов, все работают для роста.
Увеличится ли значимая вовлеченность?
Большинство метрик игнорируют общую картинку и фокусируются только на новом функционале. Добавьте в продукт кнопку, и люди будут на нее кликать, наберите достаточное количество кликов, и вы сможете назвать это увеличением вовлеченности. Но это же нонсенс! Контр-метрикой будет «перестали ли люди делать что-то еще?». Если вы добавили метрику, которая следит за определенной частью продукта, вы должны анализировать и другие части, которые может задеть.
Мы видим, как запуск полностью нового процесса влияет на продажи. Если вы PM диетической колы с лаймом, вы уверены в том, что ваш запуск это успех, но если вы CEO, вы понимаете, что усложнили продуктовую линейку, закупили лаймов, соков и кучу рекламы, и у вас нет достаточно новой прибыли, чтобы это покрыть. Это не похоже на успех,и не важно, какие метрики вам покажет PM.
Если это все же успех, можем ли мы его себе позволить и поддерживать в дальнейшем?
Распространенное заблуждение о «быстрых победах» и «легких хаках» в том, что они учитывают только усилия, требуемые, чтобы их запустить. Например, кто-то удивил вас небольшим JavaScript приложением для вашей программы, или агентство сделало приложение для Windows Phone за рекордно низкие цену и время, и в целом идея была неплохой, вы это зарелизили. Успех!
Затем пришел запрос в тех. поддержку, и выяснилось, что никто в вашей команде не знает XAML, так что вы остались со сломанным билдом в бою и парой сотен пользователей, пишущих об этом в поддержку. Конечно же, в реально жизни бывает не так. Хорошие инженеры редко говорят, что они чего-то не знают. В один из вечером они разберут проблему, используют свои компетенции и посчитают, за сколько они решат проблемы. Все это отнимет время, которое вы не планировали тратить, когда запускали приложение. А еще их оценка оказалось неправильной. И так далее.
Еще одно действие, которое может вам аукнуться в будущем, это предлагать инициативы, которые вы не можете оправдать. Если ваш продукт — это CMS, и вы предлагаете бесплатный дизайн для домашней страницы, вы получите больше регистраций. На данный момент это имеет смысл, когда вам нужно заманить клиентов на ранней стадии, чтобы они попробовали новый продукт, но в долгосрочной перспективе это не сработает. Делать вещи, которые не растут — это круто, пока вам не нужно их растить.
Можем ли мы сделать дизайн так, чтобы награда была больше приложенного усилия?
Как говорил мой коллега Пол Адамс , для любой функции полученная награда должна быть больше, чем затраченные усилия. Пользователи понимали плюсы, которые даст Google Plus, но усложненный процесс перетаскивания различных копий ваших контактов в разные окошки на регулярной основе просто того не стоил. Мне кажется, что приложения для разделения чеков попадают в ту же категорию. Разделение чека по людям может быть проблемой, но на данный момент, любое решение стоило слишком много, и мы даже не касаемся цены. Мы говорим о времени, сложности, социальном капитале и тд
Продуктовый дизайн построен на анализе затраты-пользы. Насколько что-то полезно против того насколько это сложно сделать. Вот как я это вижу…
Можем ли мы сделать это хорошо?
Каждый продукт имеет свои слабости, обычно это те места, где PM честно пытался, но признал поражение. Признание поражения редко заканчивается удалением функции, обычно это значит, что ее просто игнорируют.
Проблема здесь возникает тогда, когда команда исследует области, которые она не совсем понимает. Обычно это происходит, когда команда уходит от дизайна для себя, проходит тот этап, когда сама является своим пользователем. В этот момент их дизайн-процесс ломается, и возникает потребность в новом.
Примеры:
команды, которые не считают свое время, добавляют функционал подсчета времени;
люди, которые не работают с календарем, делают дизайн для менеджмента календаря;
дизайнеры, которые не закрывают задачи, создают систему трекинга задач.
Важно помнить, что примеры выше ни в коем случае не ошибка, ошибочен только дизайн-процесс. Нужно двигаться дальше, чем «для меня работает нормально», к чему-то более сфокусированному. Чтобы хорошо сделать функционал, вы должны прекрасно понимать задачу, которую он решает. Не зря говорят: «если не можешь сделать что-то хорошо, то оно не стоит усилий».
Можем ли четко выделить полезную область?
Начинать с простых MVP невероятно важно. Ранние рабочие прототипы дают обратную связь, необходимую, чтобы идея расцвела. Хороший признак того, что функция не может найти полезную область, это отсутствие деталей(«Адаптируйте ее для больших компаний»), или когда она ориентирована на функционал(«отчеты», вместо того, чтобы быть ориентированной на работу — «Давайте позволим менеджерам продаж наблюдать за успехами команды»).
Всегда достаточно просто согласится на очевидно правдивые заявления на продуктовых встречах. Кто-то может сказать: «Это должно стать проще для больших команд», все кивнут, и стикер с идеей останется висеть на доске. Только в деталях вы сможете понять полезную область, «мы должны позволить людям группировать коллег по департаментам», против «нам нужен бизнес режим».
Фичи без полезной области никому не нужны, долго делаются, если делаются вообще, и не добавляют в продукт ничего, кроме путаницы.
Скользкие пути и крайние случаи
Велик соблазн время от времени пренебрегать этим списком, предполагая что «пока мы правы в большинстве случаев», и все будет в порядке. Возможно, это работает в теории, но мы говорим о программном обеспечении. Реальность тут совсем иная. Именно поэтому мы говорим о том, что продуктовая стратегия заключается в слове «нет». Дорожные карты невероятно сложны и требуют мучительных решений, но несмотря на это, каждый менеджер продукта нуждается в твердом чек листе, чтобы понимать, когда говорить «да», а когда «нет». Не делая никаких исключений.
Продукты раздуваются одним ленивым решением за другим. Не будет никакого индикатора, который подскажет «Ваш Продукт Теперь Слишком Сложен», и вы никогда не получите письма с текстом «В прошлый четверг в 14:30 ваш продукт был разрушен». Переполнение, усложнение и разрушение можно заметить только в зеркале заднего вида, так что всегда помните о риске, говоря «да».
Функционал и физические ограничения
Непонимание ограничений отлично описывает желание дизайнеров, разработчиков и менеджеров продуктов нарушить правила системы, которые им просто не подчиняются. Было бы замечательно, если бы возврат инвестиций был идеально пропорционален времени, затраченному на разработку. Продуктовое планирование стало бы сильно проще. Проблема в том, что вы можете потратить пять недель работая над супер функцией, чтобы потом наблюдать за тем, как ее игнорируют все пользователи. С другой стороны, вы можете добавить один звуковой эффект, заставить ваш милый логотип говорить «Привет» или сделать так, чтобы фавиконка подмигивала, и внезапно о вас все говорят. Это нелогично, но так это работает.
Вместо того, чтобы завидовать тем, кто не сталкивается с такой иррациональностью, давайте подумаем, как мы можем использовать это себе на пользу. Когда будете планировать работу на следующие несколько месяцев, расположите функции на этом графике…
Все, что попало в правый нижний угол, получает особый статус. Это функции, возврат от которых не пропорционален усилиям. Несколько примеров:
- перепишите функцию копирования, сделав ее более личной, забавной, аккуратной или полезной;
- добавьте несколько сочетаний клавиш, чтобы пользователи могли работать более продуктивно;
- запоминайте последний активный проект и возвращайте пользователя к нему, когда он вернется;
- добавьте больше информации и ссылок в почтовых уведомлениях.
Когда использовать быстрые победы
Пользователи не будут ценить все разработки в вашем продукте. Некоторые необходимые задачи, такие как бек-апы, рефакторинг, оптимизация, улучшение инфраструктуру, редко приносят пользу сразу. Но это не значит, что вы можете игнорировать эти проблемы. Трюк в том, чтобы планировать дорожную карту таким образом, чтобы пользователи никогда не ощущали, что приложение забросили.
В такие моменты быстрые победы наиболее полезны. Вы можете закрыть ими те периоды, когда без них будет казаться, что в приложении ничего не меняется. Таким образом вы будете постоянно приносить пользу вашим пользователям, пока занимаетесь большими задачами или серверными проблемами. Помните, хуже приложения которое обновляется постоянно, только то, с которого пользователи начинают смахивать пыль.
Выкатка нового функционала
Выкатка — это судьбоносный момент, поэтому так тяжело сделать все правильно. Особенно если вы меняете пользовательские процессы. Многие b2b клиенты строят на них свои ежедневные процессы. Есть тысячи человек, у которых вся работа — использование Intercom. Поэтому, когда мы планируем изменять поведение или вводить новое, мы подходим к этому серьезно.
Мы используем пошаговую систему, которая помогает нам постепенно выкатывать функционал, используя сигналы на каждом этапе. Ваш подход может отличаться, но мы достигли большого успеха, используя наш.
Тестирование командой
Первый шаг — это выкатка в бой с реальными данными, но только для команды, которая это делала. Это очень важно, потому что позволяет избежать множества одинаковых ошибок от разных людей, но при этом позволяет выкатиться до того, как все отточено до идеала. Только команда знает, насколько все готово, поэтому только они могут сказать, что баг, а где функционал просто не закончен.
Тестирование компанией
Когда команда понимает, что функционал готов, его открывают для всех сотрудников, которые начинают использовать его в своих процессах. В этот момент нет никаких объяснений, туториалов или отговорок. Его просто выкатывают, так, как бы мы выкатили его для пользователей. Это позволяет заметить любые недопонимания, которые мы могли создать. Если даже сотрудники компании не смогли чего-то понять, чего ожидать от пользователей?
Ограниченная бета
Первый публичный релиз — для одного процента пользователей. У нас есть группа «Доверенных Тестировщиков» для таких целей. Мы рассказываем об этом, как о бете, и просим обратную связь после того, как они воспользовались функционалом. Последний пункт может показаться незначительным, но о нем нельзя забывать. Ведь обратная связь может поступать только от людей, которые воспользовались функционалом. Не людей, которые тестировали или просто поигрались. Джейк Кнапп написал “Reactions > Feedback”, говоря о том, что когда люди пытаются быть полезными, они могут выдумывать проблемы, чтобы предложить вам улучшения. Спекуляциям и выдумкам не место в продуктовом дизайне.
На что смотреть:
- Находимость — находят ли пользователи этот функционал
- Вовлечение — пользуются ли они им
- Примеры использования — как они его используют? Какие варианты популярнее всего?
- Барьеры — кто его не использует? Почему? Что им мешает?
Во время закрытой беты вы можете быть уверены, что функция доступна всем пользователям, сфокусировать ваш маркетинг на объяснении пользы, как её видят ваши пользователи, а также устраните барьеры для использования и вовлечения.
Полная выкатка
Момент, когда функционал появляется у всех, кому он должен быть доступен. И вы должны подумать о том, как вы им об этом сообщите. Зачастую не все функции доступны всем пользователям — есть ценовые категории, то есть вам, как минимум, нужно будет разделить сообщения для тех, у кого она есть, и для тех, у кого ее нет.
Те, кому она доступна, должны быть очень рады. Анонсы функционала обычно сфокусированы на том, «что мы сделали», а не на «что вы теперь сможете сделать», как будто они направлены вовнутрь компании. Если вы хотите, чтобы пользователи использовали ваш продукт, поощряйте их, рассказывая, что они могут использовать для достижения целей.
Те, у кого функционала нет, должны захотеть улучшить свой тариф. Зачастую вы можете достигнуть этого, предложив бесплатный период (попробуйте премиумный план в течение месяца бесплатно).
Не забывайте рассказывать о функционале
Когда функция в бою, довольно легко забыть о ней и отправится создавать новую. Но функции без вовлечения просто раздувают продукт. Для каждой важной функции должен быть план для тех, кто ее использует и для тех, кто нет.
Когда люди хорошо ее используют, вы можете захотеть собрать все пользовательские сценарии и использовать их в дальнейшем маркетинге. В зависимости от планов вы также можете собрать обратную связь.
Когда люди не используют функционал, вы должны поощрить их, обучить и вовлечь, они должны либо использовать его, либо объяснить, почему они этого не делают.
Нельзя гордится тем, что у вас «большой» продукт с кучей функционала и только одной функцией, которой реально пользуются. Чем больше ваш продукт, тем более важным становится вовлечение и обучение на своих ошибках. Это особенно важно, когда вы молоды и не сфокусированы. Вы можете добавлять новые функции каждую неделю, но вы должны фокусироваться на улучшении использования вашего продукта, а не его расширении.
Интерком о продакт менеджменте:
Глава 1. Узнайте свой продукт.
Глава 2. Когда говорить «нет» новому функционалу.
Глава 3. Какой функционал создать следующим — вы прочитали сейчас.
Глава 4. Помогаем использовать функционал.
