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

Почему «нет» — ключевое слово при создании продукта?

Продукт определяет то, что он делает. С этим сложно поспорить.

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

У вашего продукта есть граница, он не может быть всем для всех. Чтобы определить границу, надо ответить на следующий вопрос:

Кто и на какую работу нанимает мой продукт?

Например, Яндекс Навигатор нанимают автомобилисты, чтобы он вел их по оптимальному маршруту туда, куда им надо добраться. Качественное выполнение этой работы потребует от Навигатора определенный набор скилов (фичей), которым команда его должна обучить (порядок принципиален: вначале какую работу и для кого продукт должен делать, и только потом — какая функциональность нужна, чтобы выполнять эту работу).

Ответ в случае Навигатора может быть и другим — во многом его определяет то, как команда видит свой продукт. Например, команда могла бы сказать, что Навигатор должен делать поездку автомобилиста максимально веселой, так как водителям в машине очень скучно. Но тогда и набор скилов, которым надо было бы обучить Навигатор (скорее всего, продукт уже назывался бы иначе), был бы совсем другим.

Ответ на вопрос, обозначенный выше, станет стержнем вашего продукта, вокруг которого будет строиться все остальное. Именно он позволит вам создать единый стройный продукт, а не набор локальных фичей, объединенных общей тематикой (молоток, который вкручивает шурупы, а еще и сверлит стены — на первый взгляд, идеальное решение для строителя).

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

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

Что не может быть причиной для добавления фичи в продукт?

Данные говорят, что клиенты используют эту фичу

Мы провели тест и люди используют новую функциональность!

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

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

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

Продублируйте определенный функционал в продукте, и часть людей начнет решать свои задачи новым способом, но при этом перестанет использовать старый.

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

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

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

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

Вот очень крутой разбор кейса добавления «маленькой» фичи про ограничение длины отзыва до 140 символов в блоге Intercom. В следующий раз, говоря про маленькую фичу, вспомните этот пример.

Но без этой фичи уйдет этот клиент (обычно важный) или эти пользователи (обычно тоже важные)

Ни один клиент не важнее продукта. Вы не можете построить продукт для всех (вновь возвращаемся к ответу на вопрос в начале статьи). В определенный момент некоторые ваши клиенты перерастут ваш продукт. Это не значит, что продукт стал плохим — это значит, что он больше им не подходит.

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

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

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

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

Если вы можете сделать эту фичу опциональной, то вы вполне можете ее не делать.

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

Вы, как создатель продукта, должны принять все продуктовые решения за пользователя — это ваша работа, а не их.

"Я вчера обсуждал продукт со своим знакомым и он сказал..."

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

Самое страшное, что стоит вам услышать подобные просьбы/предложения 2-3 раза из разных источников, как вы и впрямь начинаете верить в важность и повсеместность этой проблемы. И вот эта проблема уже решается как наиболее приоритетная. Хотя чаще всего есть один единственный человек, который обсудил эту проблему с несколькими коллегами, и теперь она оказалась в центре всеобщего внимания. Самое смешное, что теперь те редкие отзывы, в которых говорится об этой проблеме, будут цеплять ваш взгляд.

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

«У меня есть идея, а давайте сделаем Х!»

Любая фича, которая начинается с фичи, а не с задачи/проблемы, которую она решает — повод вернуться на шаг назад. Начинать надо с проблемы, а не с решения. Выясните у человека, что он пытается добиться этими фичами, какую задачу или проблему решить?

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

Но у нас больше ничего не запланировано, команда простаивает

Наличие свободного времени у команды — опять не причина для того, чтобы что-то делать или не делать. На решение делать или не делать должна влиять только сама функциональность.

Свободное время у команды — идеальная возможность, чтобы разобраться с техническим долгом, а он есть всегда.

Но наши конкуренты сделали это!

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

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

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

Но мой руководитель считает, что это надо сделать

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

Но если это просто идея, то у нее нет никакого специального статуса — все идеи приоритизируются и прорабатываются вместе, вне зависимости от того, кто их придумал (клиенты, вы с командой или же руководство компании).

Это надо сделать потому что причина1 и причина2, а еще причина3

Если для обоснования фичи используется несколько причин, то, скорее всего, ее не стоит делать.

В качестве комментария — цитата из книги «Антихрупкость» Нассима Талеба.

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

Вопросы, требующие ответа, перед добавлением фичи в продукт

Соответствует ли эта фича нашему продукту?

Через свой продукт вы делитесь своим понимаем, как надо делать определенные вещи. Ваш взгляд на мир, что-то что вы поняли, а другие еще нет — вот что определяет ваш продукт, и отличает его от других.

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

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

Будет ли это важно и актуально спустя 5 лет?

Не навеяно ли модой или чьим-то сиюминутным успехом, или громким пиаром то, что вы хотите сделать?

Если да, то, скорее всего, это решение будет уже неактуально спустя год. Стоит ли в таком случае тратить на это ваши ограниченные ресурсы?

Какой части пользователей нужно то, что мы хотим сделать?

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

Сделав что-то, что нужно лишь 1% ваших пользователей, вы испортите продукт для оставшихся 99%.

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

Это улучшит, дополнит или инновационно изменит то, как люди сейчас решают свои задачи с помощью продукта?

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

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

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

Поможет ли эта новая функциональность вырастить бизнес?

Как то, что вы хотите сделать повлияет на бизнес показатели?

• Поможет ли это привлечь новых пользователей?

• Поможет ли снизить churn rate? Или повысить retention?

• Создаст ли новые источники дохода?

• Поможет ли повысить активность использования продукта существующими клиентами? Повлияет ли, и если да, то как, эта активность на бизнес показатели?

Теперь сравните то, сколько вам будет стоить разработать определенную функциональность с тем, сколько она вам может принести денег.

Если эта фича окажется успешной — хватит ли у нас ресурсов на ее поддержку и развитие?

Стоимость фичи не ограничивается временем, потраченным на ее разработку. Любая функциональность требует поддержки и развития, а значит и времени команды в будущем.

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

Если вы сделали фичу, которой пользуется 5% пользователей, то в будущем ее поддержка будет отъедать у вас столько же времени, как и фича, которой пользуются 95% пользователей. Вам надо будет править баги, учитывать и часто модифицировать эту фунциональность при будущих изменениях продукта.

С учетом всех дополнительных ресурсов и времени, требуемых для будущей поддержи — нужна ли вам все еще эта новая функциональность? Имеет ли она финансовый смысл?

Насколько сложно воспользоваться фичей VS сколько пользы приносит ее использование?

Сможете ли вы реализовать фичу так, что трудозатраты пользователя на ее использование будут меньше, чем профит от нее?

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

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

Можем ли мы сделать эту функциональность хорошо?

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

Подобные проблемы нередко начинаются тогда, когда продуктовая команда выходит за рамки своих собственных потребностей. Когда команда начинает разрабатывать функциональность, которую не понимает и не чувствует. Например, команда, в которой никто не ездит на автомобиле, начинает делать автомобильную навигацию.

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

Можем ли мы детализировать фичу?

Самый яркий сигнал того, что фича плохо продумана и проработана — когда ее описанию не хватает детализации и контекста. Любые обобщения в описании вместо конкретики — плохой знак.

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

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

Меньше лучше

Закончить эту статью я хочу двумя цитатами, которые очень хорошо передают ее суть.

«Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать»

— Антуан де Сент-Экзюпери

«Друг, прости меня, нет времени написать короткое письмо, поэтому пишу тебе длинное...»

— Блез Паскаль

Оригинал: http://gopractice.ru/no/