Есть конечное число улучшений, которое вы можете внести в существующий продукт. В какой-то момент вам придётся задуматься над тем, какой функционал подходит вашему продукту и как вы будете его позиционировать. Facebook пришлось столкнуться с сопротивлением со стороны самой ранней и лояльной аудитории, когда они представили новостную ленту. Но смогли бы они так сильно вырости, если бы не отстояли свою позицию и не показали пользователям ценность нового функционала? В этой главе вы научитесь создавать роадмап по формуле, предсказывающей, куда стоит направлять усилия. Но, возможно, гораздо важнее будет то, что вы научитесь говорить «нет» (самое важное слово в словаре менеджера продукта) и поймете, почему вам придётся говорить его очень часто.
Добавление нового функционала
Новый функционал расширяет продукт, часто вызывая большую маркетинговую активность, выход новой версии и как следствие — публикации в прессе. Всё это привлекает новых пользователей и создает новые пути использования вашего продукта. Обычно новый функционал — это единственное улучшение, о котором услышали люди «снаружи» (не ваши пользователи).
Новый функционал — это всегда риск. Вы должны быть достаточно уверенны, что его оценят как будто оценивают ваших детей; вы должны поддерживать его несмотря ни на что.
Спросите ваших пользователей: «Хотите ли вы Календарь/Трекер времени/ Диаграмму Ганта?», и они ответят: «Да». Это одностороннее предложение, в котором они ничего не теряют. Это ведёт к тому, что пользователи говорят о вещах, которые им на самом деле не нужны.
Спросите пользователей: «Хотите ли вы, чтобы мы сделали продукт быстрее или добавили больше функционала для лейблов?», и вы получите другой ответ. Все ценят скорость. Так что, когда вы планируете новый функционал, важно понимать, чем вы можете пожертвовать.
Где вы проседаете? Где это важно?
Если вы собираетесь сделать новую функцию, вам нужно добавить её в дорожную карту. Возможно, ваша выглядит также, как пример сверху. Дорожная карта строится на тяжелых решениях. Баги, которые вы должны исправить, будут соперничать с функционалом, который вы должны доделать. Функции, которые хотят пользователи, соперничают с теми, которые им на самом деле нужны.
Если вы сосредоточитесь только на новом функционале, у вас будет огромный продукт с маленькой глубиной проработки. А если будете заниматься только багами, не сможете привносить инновации, и продукт начнет терять ценность. Непростой выбор.
Когда вы сосредотачиваетесь на улучшении продукта, отличным вопросом будет «Где мы слабее всего, и где это имеет значение?»
Чтобы улучшить продукт, вы фокусируете внимание на том, что одновременно и важно, и разочаровывает ваших пользователей. Важны обе части, потому что иначе, вы будете работать над тем, что никому не интересно или переделывать то, в чем вы и так хороши.
В своей популярной статье Turn Customer Input into Innovation Энтони Ульвик предложил алгоритм возможностей, который предлагает практический путь планирования роадмапа, учитывающего и важность, и удовлетворение.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Где находятся возможности?
Алгоритм Ульвика четко определяет краткосрочные планы в продукте, позволив пользователям оценить свои задачи по важности и удовлетворенности. В таком случае возможность выводится по формуле:
Кроме простоты у формулы есть ещё одно приятное свойство: часто она показывает возможности, которые могли бы быть упущены. Регулярно самые большие возможности находятся в зонах, которые менеджмент считает «готовыми», «не забагованными», «достаточно хорошими» и т. д. Если упростить: небольшое улучшение для важной функции почти всегда важнее, чем большое улучшение для никому не нужной.
Вот куда менеджеров продуктов может завести мышление 80/20. Идея в том, что 20% функционала принесут вам 80% ценности, может быть верна, но это также означает, что вы даете пользователям не самый лучший опыт использования там, где это важнее всего. Вот цитата Марка Цукерберга о ранних днях Facebook:
Нет верного пути приоритезации дорожной карты, но есть множество неправильных. Если есть возможности в существующих зонах, и ваша карта их игнорирует в пользу нового функционала, то очень скоро вы станете продуктом «для всего и не для чего».
Обратите внимание на недостатки вашего продукта, иначе это сделает кто-то другой.
Почему вы не добавляете новый функционал
Менеджеры продуктов или основатели, занимающие эту роль, должны прекрасно уметь говорить нет. Не «может быть» или «позже». Только слово «нет».
Построение отличного продукта — это не создание тонны тактически полезного функционала, который как-то связан. Это поставка отлаженного продукта с хорошо выверенными параметрами.
Когда ваш продукт начнёт набирать вес, вы будете переполнены идеями для новых функций. Они будут приходить от ваших пользователей, коллег и вас самих. Так как эти идеи хорошие, будет множество причин сказать им «да». Вот 12 аргументов, которые чаще всего используют, чтобы протолкнуть функцию в продукт:
- Данные выглядят хорошо
«Мы попробовали эту функцию на небольшой группе и вовлеченность была невероятной». Часто такой подход страдает от выборочного анализа данных. Продукт — это сложная система. То, что выглядит как улучшение вовлеченности на самом деле просто перемещение цифр с места на место. Вы можете посчитать вашу функцию лейблов успехом на основе такого использования, но вы заметили, что функция тегов внезапно больше не популярна? Даже когда выглядят надежно и увеличение вовлеченности хорошее, вы всё равно должны подумать о том, вписывается ли это в продукт. Добавьте в продукт Тетрис и, скорее всего, у вас увеличится вовлеченность, но значит ли это, что ваш продукт стал лучше?
- Это займет всего несколько минут
Главная проблема в этом аргументе — это то, что время, затраченное на создание, никогда не должно быть причиной для добавления в продукт. Возможно, это причина, чтобы добавить функцию в дорожную карту как возможную быструю победу, но это дорожная карта, а не продукт.
Множество плохих идей можно сделать быстро. Не поддавайтесь. Не бывает маленьких изменений. Даже малейшие изменения привносят скрытое усложнение, которое обычно не учитывается в «это всего пять минут».
- Клиент собирается от нас уйти
Это обычный шантаж. Ни один клиент не может быть важнее хорошего продукта. Путь к консалтинговому обеспечению выложен из «один раз, только для этого клиента». Это приводит к идеальному продукту только для одного клиента, и даже их лояльность зависит от того, сделаете ли вы так, как они говорят. Создание дополнительной ценности для одного клиента приводит к потере ценности для всех остальных.
- Это же можно сделать опциональным
Создание опциональных функций скрывает сложность с главного экрана, но она остается в остальных местах. Заметная цена такого решения — неряшливый интерфейс с кучей конфигураций. Скрытая цена такова, что каждая опциональная функция ослабляет четкость вашего продукта. Вы становитесь «трекеров времени, который так же отправляет счета и вроде как работает со счетами. Но не отчета. Пока что… Мне так кажется… Я не знаю.»
- Соседка моей сестры сказала…
Это классическое «как в анекдоте». Очень распространено в продуктах и SaaS компаниях, которые не могут определиться какую конкретно работу они выполняют. Экстраполяция маленькой выборки весьма простой способ пропустить годы опыта, исследований и данных о поведении и высказать идею звучащую разумно. Говоря «компания моего брата использует Google Analytics, они все используют расширенные настройки» простой аргумент в пользу расширенных настроек, который упускает такие вопросы как:
- что делает ваш продукт?
- является ли компания вашего брата целевым клиентом?
- используют ли они это на самом деле или только говорят об этом?
- и являются ли расширенные настройки правильным решением для того, что пытаются сделать ваши пользователи?
- У нас больше ничего не запланировано
Дьявол создает работу для свободных команд и поверьте, он приходит с весьма плохими функциями. Проблема в том, что кто-то видит одного или нескольких свободных инженеров и немедленно бросается к новой функции, чтобы занять их. Поспешные решения принимают, что бы избежать простоя. Это весьма плохой способ «улучшить» продукт.
Вместо того, чтобы наращивать технический долг, лучше использовать эту возможность. Любой кто работал на профессиональной кухне знает: «если есть время готовить, есть время и убирать». Свободное время лучше всего использовать для исправления ошибок, отладки тестовых сценариев или рефакторинга, а не крушить продукт только чтобы занять команду.
- Мы должны были работать над чем захотим
Это аргумент отсылающий к культуре собственного достоинства. Множество больших компаний обещают инженерам, что они смогут делать и выпускать всё что захотят. Обычно такие обещания приводят к двум результатам:
Это ложь чтобы привлечь инженеров. Такое долго не живёт, потому что быстро замечается. You can’t fake culture
Это правда. Конечный результат это огромный-никому-не-подходящий продукт полный полу-законченных идей.
Есть разница между поощрением инженеров за создание чего-то изнутри (это хорошо) и позволением добавлять функции в обход менеджмента продуктов (это плохо)
- 713,000 человек хотят этого
Всегда будьте на чеку когда кто-то обращается к голым цифрам, чтобы что-то оправдать. Любой менеджер продукта может сделать эмоциональное заявление используя цифры, например «Ты можешь наполнить целый парк людьми, который просят интеграцию с Excel.» Подобное заявление заставляет вас выйти из роли менеджера продукта и стать одним из «людей». Вы действительно сможете сказать им всем нет?
Вам придется. Потому что иначе пострадает большая часть ваших пользователей. Вопрос не в том, «сможем ли мы наполнить парк людьми, которые хотят эту функцию?» а «действительно ли это полезная функция, которую будут использовать все наши пользователи?».
- Это есть у наших конкурентов
Это не значит, что это хорошая идея. Это может быть что-то, что они тестируют. Это может быть плохой идеей. Возможно они собираются ее закрыть. Ошибочно думать, что ваши конкуренты сильно умнее чем вы. Одержимость функциональностью конкурентов приведет к тому, что вы будете постоянно поставлять «вчерашние технологии».
- Если мы этого не сделаем, кто-то другой сделает
Это не значит, что это должно быть в вашем продукте. Если это сделает кто-то другой, вы больше не будете нужны вашим пользователям? Они все переметнуться? Просто сказать «кто-то другой сделает» хорошо звучит, но ничего не значит. Мы все ловили себя на этом. Логика подсказывает вам расширить продукт, потому что вы не готовы признать, что где-то он должен остановиться. Вы боитесь провести черту.
Вот пример: Обычное свидание может состоять из похода в кино, ужина и поездки домой. Если хозяева кинотеатра будет постоянно переживать о том, что делают другие бизнесы пытаясь получить больше прибыли они откроет ресторан в кинотеатре и такси. Потом они станут проседать во всех направлениях. Потом ресторан начнёт показывать фильмы…
- Босс очень этого хочет
Если при этом босс менеджер продукта, и у него есть достаточно времени и понимания, чтобы сделать умное и взвешенное решение, пускай. Но, если кто-то пытается выслужиться фокусируясь на пет-прожектах своих руководителей это обязательно приведет к проблемам.
- Это может быть «То Самое»
Классическое «обращение к неизвестности». Изменение продукта требует тяжелых решение о том, что делать. Можно рассуждать о том, что каждая не сделанная функция могла изменить ваш продукт. Но это просто рассуждения, ничего больше. Когда вы не готовы делать тяжелый выбор, вы возвращаетесь к неизвестности, и пытаетесь сделать всё сразу. Вы получите набор функций, не продукт.
Почему «нет» важно?
Суть в том, что никто не держит в дорожной карте плохие идеи. Нахождение и устранение плохих идеи несложная задача. Настоящие продуктовые решения не так просты. Они требуют от вас посмотреть на предложение и сказать «Это действительно классная идея, Я понимаю почему нашим пользователям это понравится. Молодцы. Но мы не будем этого делать. Вместо этого, вот что мы сделаем.»
Не бывает маленьких изменений
Все еще не убеждены в том, что маленьких изменений не бывает? Давайте проверим на простом примере.
«Мы хотим ограничить длину отзывов в продукте 140 символами, потому что мы можем захотеть использовать SMS для их отправки. Небольшое изменение, правда?»
НЕТ
Не бывает маленьких изменений, когда вы пытаетесь создать качественное программное обеспечение. Посмотрим на пример выше. Наивный программист может сделать это за три минуты — в конце концов можно просто добавить аргумент «if».
Но для продуктового менеджмента это не так просто.
Прежде чем вы добавите любое «небольшое изменение» в ваш продукт вам нужно задать несколько вопросов. Придерживаясь нашего примера про длину отзывов начнем с простых.
Что будет, если отзыв длиннее 140 символов? Мы обрезаем строку или выводим пользователю ошибку? Если мы выводим ошибку, где она будет? Что в ней говорится? Кто напишет текст ошибки? Как мы объясним пользователю лимит в 140 символов? Как эти ошибки будут выглядеть? У нас есть примеры? Если нет, кто сделает дизайн?
И это ещё не все…
Даже если по невероятному стечению обстоятельств у нас есть ответы на все эти вопросы, мы все равно не закончили. Просто сделать обработку ошибки на стороне сервера весьма неряшливый путь. Нужно сделать это на стороне клиента. Но если мы сделаем валидацию на клиенте появляется ещё несколько вопросов…
Кто напишет код? Отобразит ли клиентский код ту же ошибку, что и на сервере? Если нет, то какой будет стиль? Как оно будет себя вести без JavaScript-а? Как мы сможем убедиться в том, что все последующие обновления будут учитывать валидацию и на клиенте и на сервере?
Мы все еще не закончили. Посмотрим на это со стороны пользователя. Они итак расстроены внедрение лимита на 140 символов по каким-то непонятным причинам, теперь мы еще и заставляем думать их о том, насколько длинное их сообщение? Должен быть способ получше. Сделаем подсчет символов. Но это поднимает еще несколько вопросов…
Почти у цели…
Кто напишет подсчет символов? Если мы используем уже написанный, кто протестирует его во всех браузерах (не только в Chrome выше 60-й версии)?
А также, где счетчик будет находиться? Как он будет выглядеть? Разумеется, стиль должен изменится когда пользователь достигнет нулевой отметки, и точно своим видом должен говорить об ошибки, когда символов будет больше 140 — или поле должно перестать получать данные после этой отметки? Если так, что произойдёт, когда пользователи вставляют текст? Должны ли мы его изменить или предупредить их?
Когда мы внедрим счетчик символов, задизайним все ошибки, внедрим валидацию на сервере и проверим, что это на всех браузерах останется только написать тесты и зарелизить. Предполагая, что у вас стабильные релизы, тогда все будет в порядке.
Все это радостно игнорирует тот факт, что пользователи зададутся вопросом, почему кто-то до них смог написать отзыв на 80 слов, а они могут использовать лишь 140 символов. Разумеется, нам нужно будет предупредить поддержку, обновить документацию, API, приложения для iPhone и Android. А что мы должны делать со всеми предыдущими отзывами? Должны ли мы их обрезать? Или оставить как есть?
И это все не говоря о том, как мы будем обрабатывать все эмодзи, которые люди используют повсеместно… Скорее всего нам понадобится очищать строку от подобных символов, что означает новые сообщения об ошибках, новый код на сервере… список только растет.
Когда вы пройдете через все это вы получите свою функцию, и это только подсчет символов. Теперь попробуйте что-то посложнее обычного «if». Когда вы делаете всё правильно, не бывает мелких функций. Вот почему, как менеджеру продукта, вам нужно понимание того, что нужно сделать, чтобы внедрить функцию, прежде чем она окажется на вашей дорожной карте.
Картина целиком…
Очень часто работа на пару минут превращается в пару часов, когда мы не смотрим на картину в целом. Функции, которые выглядят неплохо, если сделать их за пару минут, абсолютно точно не стоят пары часов.
Согласится на какую-то функции удивительно просто. Написать для них код уже не очень. Поддерживать их может быть настоящим кошмаром. Когда вы стремитесь к качеству, маленьких изменений быть не может.
Все стоит денег
Часто в описании программ вы слышите о чем-то, что вы получаете бесплатно, например: «фреймворк предоставляет это бесплатно» или «если использовать провайдера X, мы получим Y бесплатно» или ваши разработчики скажут вам «мы все равно этим занимаемся, так что сможем получить вот эту дополнительную часть бесплатно».
В программном обеспечении нет ничего бесплатного.
Любой функционал стоит денег, просто потому, что вы обсуждаете это, рассуждаете о том должны ли вы это делать. Начнем с того, что это стоит вашего времени. Реализация – тоже не бесплатна, или проверка того, что это было сделано правильно, работает и все тесты проходят нормально. Контроль качества никогда не бесплатен.
Не бесплатны даже разговоры о функционале. Если вы добавляете функцию, вы должны рассказать об этом своей команде, команде поддержки, своим пользователям. Вы точно должны рассказать клиентам, иначе в чем смысл. Общение никогда не бесплатно.
Поддержка стоит денег. Когда все сделал релиз, вам нужно начать обрабатывать жалобы пользователей, документы, разделы помощи, видео, все что нужно обновить.
Откатить назад тоже стоит денег.
О новом функционале можно думать как о домашних животных. Craiglist полон бесплатных животных, но вы не берете их всех домой по простой причине. Есть большая разница между тем, чтобы что-то приобрести, и, затем, это содержать.
Редактор статьи: Александрина Бакирова
Интерком о продакт менеджменте:
Глава 1. Узнайте свой продукт.
Глава 2. Когда говорить «нет» новому функционалу — вы прочитали сейчас.
Глава 3. Какой функционал создать следующим.
Глава 4. Помогаем использовать функционал.
