Для примера разберем Fb, который однажды столкнулся с жесткой реакцией от самых ранних и лояльных клиентов, когда зарелизил новую новостную ленту. Но если поразмыслить на следующим: получили ли бы ребята в Fb глобальный рост, если бы не доносили свою позицию и не раскрывали пользователям ценность новинок? Вопросы не простые, поэтому давайте дальше разбирать основы. В этой главе мы разберем как создавать роадмап и вычислять по формуле точку для приложения силы. А еще вы узнаете почему навык говорить «нет и вот почему» (самый важный в арсенале продакт-менеджера) и поймете, почему его говорят так часто.
Добавление новой функциональности
Новая функциональность расширяет возможности продукта, создает всплеск интереса, в связи с выходом новой версии и как следствие — появляются и заголовки в СМИ. Всё это привлекает новых клиентов и создает новые сценарии использования (use-cases) вашего продукта. Обычно, новые функции — это единственное, что слышат потенциальные клиенты.
Новые фичи — это всегда риск. Здесь, как с ребенком, вам придется поддерживать их, что бы ни случилось.
Спросите ваших пользователей: «Хотите ли вы Календарь/Трекер времени/ Диаграмму Ганта?», и они ответят: «Да». Но нюанс в том, что клиенты не делали выбор между конкурирующими вариантами и не определялись с приоритетами. Т.е клиенты говорят «хочу» для функций, которые на самом деле им не нужны.
Спросите клиентов «Хотели бы вы, чтобы продукт стал быстрее или, чтобы мы добавили функциональность с метками?» и вы услышите еще один ответ. Каждый ценит скорость работы. Поэтому при планировании новых функций важно понимать компромиссы.
Где слабые места вашего продукта и где это имеет значение?
Если вы собираетесь разработать новую функцию, вам стоит добавить её в план развития продукта (роадмап, product roadmap). Пример роадмапа выше. Весь роадмап соткан из непростых решений. Баги, которые вы должны исправить, здесь повсюду соперничают с функциональностью, которую важно доделать. А фичи, которые хотят пользователи, соперничают с теми, которые им на самом деле нужны.
Если вы сфокусируетесь только на новой функциональности, у вас получится большой продукт с поверхностной проработкой функций. А если вы фокусируетесь только на фиксах и доработках, у вас не будет инноваций, и продукт устареет. В этом деле важен баланс.
Когда вы решили улучшить продукт, полезным бывает вопрос, «Где наши слабые места, и где это имеет значение?»
Чтобы улучшить продукт, вы фокусируетесь на том, что одновременно и важно и разочаровывает ваших пользователей. Обе грани важны, потому что иначе, вы будете работать над тем, что никого не волнует или переделывать то, в чем вы уже хороши.
В статье Turn Customer Input into Innovation Энтони Ульвик (Anthony Ullwick) предлагает алгоритм поиска возможностей, который описывает практические шаги планирования роадмапа, учитывающего и важность (importance), и удовлетворение (satisfaction).
Где находятся возможности?
В основе алгоритма Ульвика система, которая наглядно подсвечивает недостатки продукта, так как сами пользователи оценивают работы (jobs) по важности и удовлетворенности. Формула выходит следующая:
Opportunity (Возможность) = importance + (importance – satisfaction)
Возможность = Важность работы + (*важность* работы - *удовлетворенность* тем, как работа сделана)
Заметка: Параметр в скобках не может быть меньше нуля; то есть даже если вы с лихвой «закрываете» потребность клиента, это не уменьшает вес возможности.
Кроме простоты у формулы есть ещё одно приятное свойство: часто она показывает возможности, которые могли бы быть упущены. Зачастую самые большие возможности находятся в зонах, которые продакт-менеджмент видит «готовыми», «не забагованными», «достаточно хорошими» и т. д. Если проще: небольшое (minor) улучшение для востребованной функции почти всегда важнее, чем большое улучшение для никому не нужной.
Это как раз тот случай, когда правило 80/20 может не сработать. Идея в том, что 20% функций составляют 80% ценности продукта может и верная. Но это также значит, что вы можете предлагать клиентам не самый лучший опыт (B-grade experience) в наиболее важных для них задачах. Это наблюдение сделал Марк Цукерберг, когда рассказывал об истории Fb.
Не существует единственного правильного способа приоритизировать функции в роадмапе (плане развития продукта). Если у продукта есть возможности для развития в существующих зонах, и ваш план их игнорирует в пользу новых фичей, то очень скоро вы станете продуктом «для всего и ничего» — универсалом (jack-of-all-jobs product).
Обратите внимание на недостатки вашего продукта, иначе это сделает кто-то другой.
Почему вы не добавляете новые функции?
Продакт-менеджеры и основатели в этой роли, должны уметь смело говорить нет. Не слова «может быть» или «позже». Только слово «нет».
Разработка продукта — это не добавление бесконечного количества полезных функций важных в этой теме. Это поставка клиенту цельного продукта с выверенными параметрами.
Когда продукт начнёт набирать обороты, вы будете переполнены идеями для новых фич. Они будут приходить от ваших пользователей, коллег и вас самих. Так как все эти идеи будут хорошими (они же про развитие), вы найдете множество причин сказать им «да». Вот 12 аргументов, которые чаще всего используют, чтобы добавить функцию в продукт:
1. Данные говорят, что штука полезная
«Мы попробовали эту фичу на небольшой группе и вовлеченность зашкаливала». При такой формулировке стоит внимательно изучить данные соответствующими методами, возможно вы попали в ловушку выборочного анализа данных. Продукт — это сложная система. То, что выглядит как улучшение вовлеченности на самом деле просто смещения цифр с места на место. Например, вы можете заметить, что ваша функция ярлыков успешна, основываясь на метриках ее использования, но вы также заметили, что ваша функция тегов вдруг стала непопулярной? Даже если данные выглядят хорошо и увеличение вовлеченности тоже хорошее, вам все равно стоит подумать о том, должна ли эта функциональность быть частью продукта. Попробуйте добавить Тетрис в ваш продукт и вы скорее всего увидите всплеск использования этой функции. Но стал ли продукт лучше?
2. Это займет всего пару минут
Главная проблема в этом аргументе — это то, что объем работ никогда не должен быть причиной для включения новой функции в продукт. Возможно, это и причина добавить в план по развитию (roadman) эту функцию, но это решение о включении в план по развитию, а не о разработке продукта.
Множество плохих идей можно сделать быстро. Не поддавайтесь. Не бывает маленьких изменений. Даже мелкие изменения добавляют скрытую сложность, которую не учли в оценке в стиле «но это всего 5 минут».
3. Клиент собирается от нас уйти
Это обычный шантаж. Если это все аргументы, то знайте, что ни один клиент не может быть важнее хорошего продукта. Путь к продукту покрытый табличками «сделано только для этого клиента» приводит к идеальному продукту только для одного клиента, и даже их лояльность зависит от того, сделаете ли вы так, как они говорят или нет. Создание дополнительной ценности для одного клиента приводит к потере ценности для всех остальных.
4. Это мы тоже можем сделать опциональным
Это ведет к смерти от обилия настроек. Делая функцию опциональной, конечно, вы снижаете сложность главных экранов интерфейса, но эта сложность продолжает сквозить во всех остальных местах. Видимая цена в таком подходе — сложный интерфейс со множеством условных элементов и тоннами настроек. Скрытая цена — каждая опциональная функция ослабляет ключевую концепцию вашего продукта. В итоге из вас получится «трекер времени, который может рассылать инвойсы и сводить баланс платежей, но без отчетов».
5. Сосед моего двоюродного брата сказал…
Это «как в анекдоте». Очень распространено в продуктах и SaaS компаниях, которые не могут определиться какую конкретно работу (job) они выполняют.
Экстраполяция маленькой выборки весьма простой способ пропустить годы опыта, исследований и данных о поведении и высказать идею звучащую разумно. Говоря «в компании моего брата используют Google Analytics и расширенные сегменты» очень просто убедить использовать расширенные сегменты и пропустить следующие моменты:
- что делает ваш продукт?
- является ли компания вашего брата целевым клиентом (target customer)?
- используют ли они это на самом деле или только говорят об этом?
- действительно ли расширенные сегменты — это хорошее решение для ваших клиентов?
6. У нас пока больше ничего не запланировано
Как будто сам дьявол подкидывает работу свободным продуктовым командам, и они начинают второпях создавать действительно ужасные штуки. Ситуация такая: если кто-то видит инженера, сидящего без дела, он тут же дает ему задачу на создание новой функции, чтобы не бездельничал. Принимаются поспешные решения, клепаются дизайны — что угодно, лишь бы не простаивать.
Так продукт не улучшить.
Вместо того, чтобы наращивать технический долг, лучше использовать эту возможность и уменьшить существующий долг. Любой кто работал на профессиональной кухне знает: «если у вас есть время отдохнуть, у вас есть время и прибраться». Свободное время лучше всего использовать для исправления ошибок, отладки тестовых сценариев или рефакторинга, а не разваливать продукт только чтобы занять команду.
7. Мы думали, что можем работать над чем захотим
Этот аргумент исходит из корпоративной культуры. Все еще много больших компаний обещают инженерам, что они смогут делать и выпускать всё, что захотят. Обычно такие обещания приводят к двум результатам:
- Это ложь, чтобы привлечь больше инженеров. Но люди быстро замечают это и бросают попытки добавить свое в продукт и вы проседаете по инициативам. Т.е у вас не выйдет имитировать культуру компании.
- Это правда. В результате получается продукт, полный незавершенных идей.
Есть разница между тем, чтобы вдохновлять инженеров на инициативные разработки (это хорошо) и поощрять их добавлять функции в обход продакт-менеджеров (это плохо).
8. 713 000 человек хотят этого
Всегда найдется кто-то, кто будет использовать голые числа, чтобы убедить вас. Продакт-менеджер и сам может сделать эмоциональное заявление используя цифры, например «Вы сможете заполнить целый Dolores Park людьми, которым нужна интеграция с Excel.» Подобное заявление побуждает вас выйти из роли продакт-менеджера и стать одним из «людей». Вы действительно собираетесь сказать нет им всем?
Вам придется. Потому что иначе пострадает большая часть ваших пользователей. Вопрос не в том, «сможем ли мы наполнить парк людьми, которые хотят эту функцию?», а «действительно ли это полезная функция, которую будут использовать все наши пользователи?».
9. А это есть у наших конкурентов
И это вовсе не значит, что это хорошая идея. Возможно они просто тестируют эту функциональность. Т.е это может быть и плохой идеей. Возможно они собираются вовсе пристрелить эту функцию. Не вздумайте считать, что ваши конкуренты сильно умнее чем вы. Одержимость функциональностью конкурентов приведет к тому, что вы будете постоянно поставлять «вчерашние технологии».
10. Если мы этого не сделаем, кто-то другой сделает
И это тоже вовсе не значит, что фича должна быть в вашем продукте. Если это сделает кто-то другой, вы больше не будете нужны вашим пользователям? Они все убегут к ним? Просто сказать «кто-то другой сделает» хорошо звучит, но пока ничего не значит. Да, мы все так иногда говорим. Просто на автопилоте, что-то подсказывает вам, что нужно расширить продукт и вы не готовы признать, что где-то он все же должен остановиться. Вы просто боитесь провести черту.
Например: Обычное свидание включает кино, ужин и поездку домой. Если хозяева кинотеатра будет постоянно переживать о том, что делают другие бизнесы пытаясь получить больше прибыли они откроют ресторан в кинотеатре и такси. Потом они станут проседать во всех направлениях. Потом ресторан начнет показывать фильмы…
11. Начальник очень хочет добавить эту функцию
Если при этом начальник — менеджер продукта, и у него есть достаточно времени и понимания, чтобы сделать умное и взвешенное решение, то предположим. Но, если кто-то просто пытается выслужиться, втаскивая пет-прожекты руководителей, то проблем в продукте не избежать.
12. Это может быть «То самое»
Это классический способ ссылаться на неизвестное. Развитие продукта требует череды сложных решений о том, что делать. Конечно, можно рассуждать о том, что каждая не сделанная функция могла в корне изменить ваш продукт. Но это все еще просто рассуждения и ничего больше. Когда вы боитесь принимать трудные решения, вы откатываетесь к таким домыслам, и, в результате, добавляете в продукт все подряд. В конечном итоге у вас получается набор функций, а не продукт.
Почему уметь говорить «нет» важно?
Дело в том, что никто не хочет держать плохие идеи в роадмапе. Найти и устранить плохие идеи простая задача. Но настоящие продуктовые решения — непростые. Зачастую они требуют от вас посмотреть на инциативу и сказать «Это действительно классная идея. И я понимаю почему нашим пользователям это понравится. Молодцы. Но мы не будем этого делать. Вместо этого, вот что мы сделаем и вот почему.»
Не бывает мелких изменений
Все еще не верите, что мелких изменений не бывает? Давайте разберем на простом примере.
«Мы хотим ограничить длину отзывов в продукте 140 символами, так как мы хотим использовать SMS для их отправки. Небольшое изменение, добавим?»
НЕТ
Не бывает мелких изменений, когда вы пытаетесь разработать качественное программное обеспечение. Посмотрим на пример выше. Наивный программист может сделать это за три минуты — в конце концов, это всего лишь одно условие в коде.
Но для продакт-менеджера это не так просто.
Прежде чем вы добавите даже «мелкое изменение» в ваш продукт, вам стоит задать несколько вопросов. Вернемся к нашему примеру с длиной комментариев и зададим серию вопросов:
- Что будет, если отзыв длиннее 140 символов?
- Мы обрезаем строку или выводим пользователю ошибку? Если мы выводим ошибку, где она будет?
- Что в ней говорится? Кто напишет текст ошибки?
- Как мы объясним пользователю лимит в 140 символов?
- Как эти ошибки будут выглядеть? У нас есть примеры?
- Если нет, кто сделает дизайн?
И это ещё не все…
И если даже у нас есть ответы на все эти вопросы, осталось еще кое-что. Просто сделать обработку ошибки на стороне сервера весьма неряшливый путь. Нужно сделать это на стороне клиента. Но если мы сделаем валидацию на клиенте появляется ещё несколько вопросов…
- Кто напишет код?
- Отобразит ли клиентский код ту же ошибку, что и на сервере? Если нет, то какой будет стиль?
- Как оно ведет себя с отключенным JavaScript в браузере?
- Что сделать, чтобы в будущем при любых изменениях правила 140 символов не забывать менять и на серверной, и на клиентской стороне?
Мы все еще не закончили. Посмотрим на это со стороны пользователя. Они итак расстроены внедрение лимита на 140 символов по каким-то непонятным причинам, теперь мы еще и заставляем думать их о том, насколько длинное их сообщение? Должен быть способ получше. Сделаем подсчет символов. Но это поднимает еще несколько вопросов…
Почти готово…
Кто сделает счетчик символов? Если будем использовать готовый, найденный в интернете, кто протестирует во всех браузерах, которые мы поддерживаем (не только в Chrome выше 60-й версии)?
А nакже, где будут отображаться цифры счетчика? Как будет выглядеть счетчик? Конечно, нужно изменить стиль цифр, когда пользователь приближается к нулю, а еще, цифры должны выглядеть по другому, когда пользователь написал больше 140 символов. А может нужно не давать вводить больше? Если так, что будет, если они вставят текст из буффера обмена? Должны ли мы позволить редактировать их, или лучше предупредить?
Мы реализовали счетчик, отображение ошибок, добавили проверку на стороне сервера, и протестировали во всех поддерживаемых браузерах. Теперь осталось написать автоматические тесты и выпустить новую функциональность. Предположим, что механизм выпуска новой версии у вас отлажен, тогда все будет в порядке.
И еще один нюанс остался. Мы проигнорировали факт, что пользователи будут недоумевать, почему, кто-то написал большой комментарий некоторое время назад, а они теперь могут писать лишь 140 символов. Получается что, нам нужно еще предупредить техподдержку, обновить документацию, API для приложений iPhone/Android. Также, нужно решить, что делать со старыми комментариями, урезать их или оставить как есть?
Не говоря уже о том, что делать со всеми этими эмодзи, которые так популярны сегодня… удачи в отправке их через SMS. Скорее всего нам также потребуется не разрешать вводить недопустимые символы, а это значит новые сообщения об ошибках, дополнительный код… список задач продолжается.
Когда вы пройдете через все это вы получите функцию, и это только подсчет символов. Теперь попробуйте что-то посложнее обычного «if». Когда вы делаете всё правильно, не бывает мелких функций. Вот почему, как продакт-менеджеру, вам нужно понимание того, что нужно сделать, чтобы внедрить функцию, прежде чем она окажется в вашем роадмапе.
Картина целиком (Big Picture)…
Зачастую работа на пару минут превращается в пару часов, если не посмотреть на картину в целом. Функции, которые выглядят полезными и их можно сделать за пару минут, можно смело оценивать как больше двух часов.
Ключевое: Объем работы скрывается в минутах, а не в месяцах. Следите за минутами, и будет порядок с месяцами. Согласиться на добавление новой функции легко. А вот программирование этих функций уже вряд ли будет легким делом. Поддержка будет кошмаром. Когда вы стремитесь к качеству не бывает маленьких изменений.
У всего в разработке продукта есть цена
Зачастую в описании программ вы видите что-то, что вы получаете бесплатно, например: «фреймворк предоставляет это бесплатно» или «если использовать провайдера X, мы получим Y бесплатно» или ваши разработчики скажут вам «мы все равно этим занимаемся, так что сможем получить вот эту дополнительную часть бесплатно».
В программном обеспечении нет ничего бесплатного.
Любая функциональность стоит денег, просто потому, что вы обсуждаете это, рассуждаете о том должны ли вы это делать. Начнем с того, что это стоит вашего времени. Реализация – тоже не бесплатна, или проверка того, что это было сделано правильно, работает и все тесты проходят нормально. Контроль качества никогда не бесплатен.
Не бесплатны и разговоры о новых функциях. Если вы добавляете функцию, вы должны рассказать об этом продуктовой команде команде и команде дизайнеров, команде техподдержки, своим пользователям. Вы также должны рассказать клиентам, иначе в чем смысл. Коммуникация всегда стоит денег и никогда не бесплатна.
Поддержка стоит денег. Когда вы запустили фичу в мир, вам предстоит разгребать жалобы и запросы пользователей, документы, разделы помощи, видео, все что нужно обновить.
Даже откатиться назад тоже стоит денег.
Кстати интересный взгляд на новую функциональность (фичи, features) можно получить, если взглянуть через призму ситуации с домашними животными. Craiglist полон бесплатных предложений о питомцах, но вы не берете их всех домой по простой причине. Есть большая разница между тем, чтобы что-то приобрести, а затем содержать и нести ответственность.
← Назад | Продолжение (Глава 3) →