19 июля 2013 в 15:28

Стратегия продукта подразумевает ответ — «Нет!» перевод

Перевод оригинальной статьи за авторством Des Traynor

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



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

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


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

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



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


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

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



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


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

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

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



Перевод
Как сделать ужасный софт: 1. Пообещать клиенту встроить его одноразовые фичи в проект 2. Выполнить обещание 3. Повторить


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

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




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

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



Перевод
Команда, неделю назад, я говорил с двоюродной сестрой соседа моей сестры. Она точно наша целевая аудитория (25 лет, женщина, есть ученая степень). Она сказала, что все ее друзья активно используют хеш-теги.
Благодаря ей, я понял, что наш продукт провалится без хеш-тегов.
Я объявляю внеплановое собрание завтра в 8 утра. Канди (это ее имя) присоединится к нашей видеоконференции.
#Спасибо #Команда
Конец связи,
CEO


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

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




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

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

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




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

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


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

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




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

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

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



Перевод
Вы смотрите на конкурентов и думаете: “Нам нужно все скопировать у них!”. Они смотрят на свое приложение и думают: “Половину из этого необходимо убрать”.


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

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




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

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

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



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


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

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




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

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



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

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

Перевод выполнен в рамках летней школы стартапов Tolstoy Summer Camp и MetaBeta.
Автор оригинала: Des Traynor
Михаил Томшинский @tomshinsky
карма
90,0
рейтинг 0,0
Самое читаемое Разное

Комментарии (25)

  • +7
    Подумалось про оперу.
    • +17
      там не просто нет. Там до свидания.
      • 0
        В итоге-то сдались, делают закладки!) Но в целом, кто бы что ни говорил(!!), хороший пример того, так ребята до последнего были верны своему представлению, пониманию, видению продукта. А не поддались на сиюминутные крики. Очень надеюсь, что решение о закладках они приняли не в отрыве от вижена, а как следствие трансформации последнего.
  • +16
    Скажем «Да» таким на редкость полезным статьям
  • +10
    Хорошо написано.

    Под это хорошо подходит gmail.
    Раньше был маленький, без 1001 фич. Всё просто и понятно с одного раза.
    Теперь это классический Nero :-/
    • +16
      Кстати про Nero, давно его не слышно. Но с той скоростью, с которой они добавляли новые фичи, уверен, они уже создали искусственный интеллект и улетели колонизировать Альфу Центавра.
      • 0
        Когда-то хотел поставить Неро. Узнал размер… B пользуюсь прожигалкой размером с мегабайт, умеет всё что мне надо, даже образы делать :)
    • +7
      Не понимаю, почему людей так пугает сложность. На самом деле для многих людей по-прежнему важна функциональность. Я думаю profit от продаж сложного продукта Visual Studio больше какого-нибудь простого почтового клиента.
      Если вам что-то не нужно, это не значит, что оно никому не нужно. Правильно, говорить «нет», для того, чтобы иметь полноценную поддержку заявленных опций и для того, чтобы не тонуть в коде, и быть готовым/свободным, когда действительно важное бизнес-направление появится.

      И в gmail меня совсем не пугает 100 настроек, пока gmail делает так, что мне не приходится туда заглядывать.
    • +1
      Да и Google Chrome тоже подходит, и Google Search в некоторых вопросах тоже.
      Вот Google Reader не подходит, тут уж сказали «нет», так сказали.
  • +3
    Во многом повторяет «Getting Real» и «Rework».
  • +1
    «Как следует из последней рекламы Apple..»

    а какой рекламе Apple идет речь?
    где можно посмотреть?
  • +1
    Есть и другая сторона слова «Нет». Например любой чиновник родом из советской действительности, дольше просидит на своем месте, если будет говорить «нет». Просто приняв любое положительное действие, чиновник ставит себя под удар от вышестоящего начальства если что то пойдет не так. А если всем говорить «нет» то и наказывать не за что.

    Мораль: нужно уметь говорить и «да» и «нет», и учиться обосновывать и взвешивать ответ.
    • +5
      Комментарий из серии КО. Статья все-таки несколько глубже и не о чиновниках. В данном случае сказать «да» в 100 раз проще, чем «нет».
    • –1
      Так думаю недальновидные глупцы. Есть очень важная штука называется оправдание ожиданий. Если чиновник всегда говорит «Да», а после не исполняет обещанного, то он не оправдывает ожидания электората, но как только он скажет «Нет», а после сделает, то такой чиновник будет заслуживать большего доверия, даже если по факту он сделает меньше чем первый.

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

    computer engineer, наверное, лучше переводить как «разработчик». Пишу не в личку потому что в очередной раз встретил такой перевод здесь.
  • 0
    Спасибо за перевод.
    Как по мне, статья довольно обширная и не голословная.
    Много воспринимается интуитивно, облекаясь в конкретную мысленную форму.
  • 0
    Скрины потрясные)
  • 0
    Отчасти пересказ книги Rework! Бизнес без предрассудков, 37Signals
    habrahabr.ru/post/86868/
  • 0
    Хороший посыл у статьи, спасибо за перевод и за ссылку на оригинал.

    На нашем проекте мы «нет» говорим весьма нередко. У нас SaaS и многие спрашивают: «а можно такое же, но с перламутровыми пуговицами в нашей локальной сети?» Конечно нет, ребят, это сервис! Аналогично по некоторым фичам.

    Хотя чаще просят что-то, что уже в планах на реализацию и ответ идёт не строгое «нет», а «ок, это в нашем roadmap». Остается только выставлять приоритеты между присылаемыми хотелками или же паковать их в feature sets, где реализовывать согласно общей канве сервиса.
  • 0
    Ребят, подскажите пожалуйста, с какого сервиса этот скрин: image?
    Спасибо.
    • 0
      Мне кажется сами нарисовали.

      Если хотите ссылку по теме то вот вам basecamp.com/
  • 0
    Думаю, что говорить «Нет» — это касается любого здравомыслящего бизнес-проекта. Так в моем бизнесе, где генерируется много идей, приходится сначала все фиксировать, некоторое время тратить на анализ, а потом говорить нет. Даже если эта идея была крутой. Но она либо несвоевременна, либо не подходит под эту целевую аудиторию. И да, не нужно забывать про человеческий фактор. Люди склонны обижаться, если их гениальная идея не принята. Потому полезны «долгие ящики» — что-то типа стакана в аджайле, — этакая коллекция идея, к которой можно и нужно возвращаться (это и надо делать). Так вы и не обидите разработчиков: «Отличная идея, Данила! Сейчас она не подходит, но позже она нам пригодится, скорее всего на этом этапе.» — Это не обижает людей, но помогает им дальше генерировать идеи, и не важно это сфера услуг или сфера разработки, а, быть может, производства покрышек для автомобилей.
  • 0
    «Вычисленное время разработки маленькой фичи»
    Estimate — это оценка.

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