{"id":13654,"url":"\/distributions\/13654\/click?bit=1&hash=7a7aa21667aefd656b6233efba962ecbef616dfd5ac100a493b4b5899b23ff1f","title":"\u041c\u044b \u043f\u043e\u043f\u0440\u043e\u0441\u0438\u043b\u0438 \u0440\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u0439 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u0442\u044c, \u043a\u0442\u043e \u0442\u0430\u043a\u0438\u0435 \u00ab\u043a\u0440\u0435\u0430\u0442\u043e\u0440\u00bb \u0438 \u00ab\u043f\u0440\u043e\u0434\u0430\u043a\u0442\u00bb","buttonText":"\u0421\u043c\u043e\u0442\u0440\u0435\u0442\u044c","imageUuid":"32086418-934b-5de5-a4ef-6425a84c490a","isPaidAndBannersEnabled":false}
Alex Sharmanov

Почему не стоит добавлять новые фичи в ваш продукт

Всем привет! Меня зовут Саша и я менеджер по продукту одной большой российской IT-компании. В свободное от работы время я читаю книги и статьи от иностранных гуру продуктового менеджмента и хочу периодически делиться с вами той информацией, которая зацепила и кажется важной. Кроме того, я веду свой канал «Mr Product» по менеджменту продуктов, где делюсь полезной инфой для продактов и тех, кто хочет ими стать. На этом вступительную часть я закончу и перейдём к самому интересному =)

Менеджеры по продукту или основатели, выполняющие эту роль, должны уметь говорить «нет».

Создание отличного продукта — это не создание множества полезных фичей, которые каким-то образом связаны между собой. Для создания отличного продукта у вас должно быть целостное видение о продукте и его работе.

Когда ваш продукт наберёт обороты, вы обнаружите, что вас завалили хорошими идеями новых функций. Они исходят от ваших клиентов, ваших коллег и от вас самих. Поскольку это хорошие идеи, всегда будет много причин, чтобы сказать им «да». Присмотритесь к аргументам, которые используют те, кто их предлагает. Вот 12 аргументов, которые чаще всего используются, чтобы обосновать их появление в продукте.

1. НО ДАННЫЕ ВЫГЛЯДЯТ ХОРОШО

«Мы протестировали эту функцию на небольшой группе и вовлеченность зашкаливала». Часто этот подход страдает от выборочного анализа данных. Продукты представляют собой сложные системы. То, что кажется увеличением вовлеченности, на самом деле просто перебрасывает цифры с места на место. Возможно, вы считаете, что ваша функция ярлыков успешна, основываясь на ее использовании, но заметили ли вы, что ваша функция тегов внезапно перестала быть популярной? Даже когда данные надежны, а рост вовлеченности хороший, вам все равно придется задаться вопросом, соответствует ли это основной задаче продукта. Добавьте тетрис к своему продукту, и вы, вероятно, заметите повышение вовлеченности, но значит ли это, что ваш продукт стал лучше?

2. НО ЭТО ЗАНИМАЕТ ВСЕГО НЕСКОЛЬКО МИНУТ

Основная проблема с этим аргументом заключается в том, что объем работ никогда не должен быть причиной для включения фичи в продукт. Может быть, это причина учесть фичу в роадмапе как быструю победу, но это решение для для роадмапа, а не для продукта.

Многие плохие идеи могут быть реализованы быстро. Не соблазняйтесь. Мелких изменений нет. Даже самые незначительные изменения и дополнения добавляют скрытую сложность.

3. НО ЭТОТ КЛИЕНТ УХОДИТ

Это фич-шантаж. Ни один клиент не может быть важнее, чем хороший продукт. Дорога к заказной разработке обозначена как «только один раз только для этого клиента». Это приводит в лучшем случае к идеальному продукту только для одного клиента, но даже тогда его лояльность зависит от того делаете ли вы то, что он вам говорит. Предоставление дополнительной ценности одному клиенту происходит за счет потери ценности для многих других.

4. НО МЫ МОЖЕМ СДЕЛАТЬ ЭТО НЕОБЯЗАТЕЛЬНЫМ

Ценой этого является беспорядочный интерфейс с большим количеством условного дизайна и кучей настроек. Скрытая стоимость заключается в том, что каждая дополнительная функция ослабляет характеристики вашего продукта. Вы становитесь тайм-трекером, который также может отправлять счета, проводить сверку платежей и еще кучу всего, но причем здесь тайм-трекинг?

5. НО СОСЕД МОЕГО БРАТА СКАЗАЛ...

Экстраполяция информации от крошечной выборки — это простой способ обойти годы опыта, исследований, данных и сделать утверждение, которое звучит разумно. Сказать: «Компания моего брата использует Google Analytics и вообще все они используют расширенные сегменты» — это простой способ обосновать использование расширенных сегментов, игнорируя такие ключевые вопросы, как:

  • что ваш продукт на самом деле делает?
  • является ли компания вашего брата хорошим целевым клиентом?
  • используют ли они его на самом деле или просто говорят, что используют?
  • действительно ли расширенные сегменты являются правильным решением для чего?

6. НО МЫ НИЧЕГО БОЛЬШЕ НЕ ПЛАНИРУЕМ

Проблема здесь в том, что кто-то видит, что один или несколько инженеров сидят без дела, и сразу же бросается реализовывать новую функцию, чтобы «занять их». Решения принимаются в спешке. Это плохой способ «улучшить» продукт.

Вместо того, чтобы увеличивать технический долг, есть возможность погасить его. Время простоя лучше всего использовать на исправление ошибок, очистку наборов тестов, рефакторинг и т. д., а не на изменение концепции продукта только для того, чтобы «поддерживать продуктивность команды».

7. НО НАМ ДОЛЖНО БЫТЬ РАЗРЕШЕНО РАБОТАТЬ НАД ЧЕМ ЗАХОТИМ

Есть много известных компаний, которые обещают разработчкиам, что они могут построить все, что захотят. Обычно это обещание имеет один из двух результатов:

  • Это ложь, рассказанная для привлечения разработчиков. Это быстро замечается и разваливается.
  • Это так. Конечным результатом является универсальный продукт, полный недоработанных идей.

Есть разница между мотивацией разработчиков создавать что-то внутри компании (хорошо) и предоставлением людям возможности добавлять функции в продукт, минуя управление продуктом (плохо).

8. НО 713 000 ЧЕЛОВЕК ХОТЯТ ЭТОГО

Всегда остерегайтесь, когда кто-то прибегает к необработанным цифрам, чтобы что-то доказать. Можно сделать эмоциональное заявление, используя цифры. Например «Вы могли бы заполнить Долорес Парк людьми, которые просили интеграцию с Excel». Такое заявление заставляет вас встать лицом к лицу с этими людьми. Вы действительно сможете сказать нет всем этим людям в лицо?

Вы должны. Потому что в противном случае пострадает большинство ваших пользователей. Вопрос не в том, «можем ли мы наполнить Долорес Парк людьми, которым нужна эта функция?», а в том, «является ли это ценной функцией, которую будут использовать все наши клиенты?».

9. НО ЭТО У НАШИХ КОНКУРЕНТОВ УЖЕ ЕСТЬ

Это не значит, что это хорошая идея. Это может быть что-то, что они пробуют. Это может быть плохая идея. Это может быть что-то, что они планируют убить. Было бы ошибкой полагать, что ваши конкуренты умнее вас. Зацикленность на возможностях вашего конкурента заставляет вас постоянно поставлять «вчерашние технологии завтра».

10. ЕСЛИ МЫ ЭТО НЕ ПОСТРОИМ, ТО ЭТО СДЕЛАЕТ КТО-ТО ДРУГОЙ

Если это сделает кто-то другой, разве клиенты больше не будут нуждаться в вашем продукте? Они все перейдут на другой продукт? Мы все ловили себя на том, что говорим это. Чаще всего это из-за того что мы не хотим признать, что наш продукт где-то заканчивается. Мы боимся провести черту.

Вот пример: типичное свидание может включать в себя просмотр фильма, ужин и поездку домой. Если владелец кинотеатра постоянно беспокоится о том, что построят другие заведения и жаждет получить больше прибыли, то он построит ресторан в своем кинотеатре и создаст компанию такси. Но скорее всего все три его компании будут неочень высокого качества.

11. НО БОСС ДЕЙСТВИТЕЛЬНО ХОЧЕТ ЭТОГО

Если босс также является менеджером по продукту и имеет необходимое время и понимание для принятия разумных целостных решений, то это нормально. Однако, если кто-то пытается заработать очки, сосредоточившись на любимых проектах его руководителя, то это неизбежно приводит к проблемам.

12. НО ЭТО МОЖЕТ БЫТЬ «ТОТ ОДИН»

Изменение продукта требует трудных решений. Вы можете предположить, что любая функция может изменить ваш продукт. Но это всё домыслы, не более того. Когда вы боитесь принимать трудные решения, вы продолжаете добавлять новые фичи. В итоге вы получаете хранилище функций, а не продукт.

Почему «нет» так важно?

Дело в том, что никто не держит плохие идеи в своём роадмапе. Выявление и устранение плохих идей — это очень просто. Реальные решения о продукте даются нелегко. Они требуют, чтобы вы посмотрели на идею и сказали: «Это действительно отличная идея, я понимаю, почему она понравится нашим клиентам. Отличная работа. Но мы не собираемся тратить на это время. Вместо этого, вот что мы делаем».

Это был вольный перевод одной из глав книги «Intercom on Product Management». Вопросы и набросы пишите в комментах.

Еще больше полезных материалов в моём канале в телеграме =) Подписывайтесь!

0
1 комментарий
Виктория Рожкова

Мне кажется, что продукт становится не благодаря внедрению фич, а удалению ненужных атрибутов

Ответить
Развернуть ветку
Читать все 1 комментарий
null