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

Как следует из последней рекламы Apple, могут существовать десятки тысяч версий вашего продукта, которые могут появляться из-за разных фич, важных и неважных. Большинство из этих версий с треском провалятся и только лучшие смогут обслужить рынок.

Так много причин сказать да

Когда вы находитесь в процессе создания продукта, вы будете завалены хорошими идеями. Они будут приходить от ваших клиентов, коллег и вас самих. У вас будет очень много причин сказать им да, ведь они хорошие. Вот 12 аргументов в стиле Дона Линдси, которые часто помогают ненужным фичам попасть в продукт.

Но статистика выглядит замечательно

Улучшение интерфейса с течением времени

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

Но это займет всего несколько минут

Вычисленное время разработки маленькой фичи
Реальное время разработки маленькой фичи

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

Очень много плохих идей могут быть воплощены в продукте очень быстро. Не соблазняйтесь. Не бывает маленьких изменений. Кстати, даже небольшое изменение может усложнить продукт, а его упрощение не вкладывается в эти “всего лишь 5 минут”.

Но этот клиент может уйти

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

Но мы можем сделать это опциональным

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

Но сосед моего двоюродного брата сказал…

Похоже на анекдот. Это распространено в SaaS компаниях, которые не могут понять, что за работу они делают. Экстраполирование крошечного образца – верный путь к годам тестирования, исследования, выработки статистики и поведения. Высказывание “компания моего брата использует Google Analytics, и в ней используют расширенные сегменты” может привести к использованию расширенных сегментов, обойдя стороной вопросы: что это такое? что ваш продукт делает? действительно ли компания этого брата хороша в выборе клиентов? действительно ли они это используют или просто говорят так? подходит ли этот прием вам?

Но у нас ничего больше не запланировано

Незанятые руки ищут работы. Многие, видя праздношатающихся разработчиков придумывают новые фичи, лишь бы они работали. Принятие идей ускоряется – все, лишь бы избежать безделья. Это не лучший путь улучшения своего продукта.

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

Но я думал, что мы будем работать над тем, над чем захотим

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

1. Это ложь, сказанная для привлечения инженеров. Она очень быстро становится явной и проваливается.
2. Это – правда, и конечный ее результат – полностью реализованный никому не нужный продукт и наполовину выполненные идеи.

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

Но 713 тысяч человек хотят этого

Старайтесь избегать ситуаций, когда кто-то пытается оправдаться сырыми числами. Любой, хоть мало-мальски разрабатываемый продукт найдет свое число потребителей. Например: “Мы можем заполнить Долоресский Парк людьми, которые попросили интеграции с Excel”. Это заставляет вас свернуть с первоначального курса и поддаться влиянию толпы, стать “одним из них”. Неужели вы можете так жестоко сказать нет?

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

Но у наших конкурентов это есть

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

Но если мы этого не сделаем, это сделает кто-то другой

Это не значит, что это должно быть в вашем продукте. Если кто-то еще сделает это, бросят ли клиенты ваш продукт? Перейдут ли на другую сторону? Просто сказать “кто-то другой сделает” – это хорошо, но ничего не значит. Я заметил, что говорю это очень часто. Эту логику используют для расширения продукта, ведь вы не хотите останавливаться на достигнутом ни на секунду. Вы боитесь достичь финиша своего проекта.

Вот пример: типовое свидание включает в себя кино, ужин и поездку домой. Если бы хозяин кинотеатра постоянно волновался о том, что сделают другие бизнесмены и хотел бы получить больше выгоды, он бы поместил ресторан в свой кинотеатр и создал бы компанию развозов людей по домам a la такси. И все эти три сервиса были бы отвратительны. А потом еще рестораны начали бы показывать фильмы…

Но босс этого хочет

Так точно, быстро делаем круговые диаграммы. Тонны их.

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

Но это будет тем, что изменит наш продукт

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

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

Дело в том, что никто не планирует неудачи. Определение и отсечение оных – это достаточно просто. Но решения, принимаемые при работе над серьезным продуктом не так просты. Они заставляют вас прочитать целиком описание фичи и ее реализации и сказать: “Это действительно хорошая идея, я понимаю, почему она понравится нашим клиентам. Отличная работа. Но мы не будем добавлять ее в продукт… Вот, что мы сделаем вместо этого.”

От переводчика: в статье приводится ряд причин, почему нужно уметь говорить «нет», с наглядными примерами и разоблачением факапов. По сути — как избежать провокации с той или иной стороны. В то же время автор не сказал главного — что позволяет нам говорить заветное «да». Два момента: во-первых, рекомендую прочитать эту статью; во-вторых, моя позиция такова: нужно уметь соотносить предлагаемую фичу со стратегией продукта в целом. Если фича никак не помогает в достижении стратегической цели — на мороз. Иначе это чистой воды «фичиризм». Мы не знаем кто наши пользователи и что им нужно, поэтому мы на всякий случай сделаем все — универсальный комбайн на все случаи жизни. Это тупиковый путь. Надеюсь, что в ближайшем будущем найду время обобщить свой опыт продакт-менеджера Яндекса и написать подробную статью на эту тему.

Перевод выполнен в рамках летней школы стартапов Tolstoy Summer Camp и MetaBeta.

Автор: tomshinsky

Источник