Запрос на функцию, который стоит реализовать (и как его распознать)

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

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

Какие три?

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

Сигналы, которые важны

Сигнал 1: Неподсказанная повторяемость

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

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

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

Сигнал 2: Обходной путь имеет значение

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

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

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

Обращайте внимание, какие запросы являются блокерами. Кто-то говорит «я не могу этим пользоваться, пока вы не сделаете X», а кто-то — «было бы здорово, если бы у вас был X». Это различие — на вес золота.

Сигнал 3: Функция связана с бизнес-моделью

Некоторые функции открывают совершенно новые способы зарабатывать. «Выставлять счета моим клиентам» открывает бизнес-модель, в которой вы берёте плату за выставление счетов. «Экспорт в Salesforce» открывает доход от интеграций. «White-label для реселлеров» открывает партнёрский канал.

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

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

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

Сигнал 4: Просьба о помощи

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

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

Те, кто просто запрашивает, — это люди, надеющиеся, что вы волшебным образом построите то, что они себе представляют. Иногда так и будет. Часто — нет.

Сначала стройте с тестировщиками. Всё остальное вторично.

Соблазн построить престижную функцию

У каждого продукта есть одна функция, которая, если вы её выпустите, заставит вас звучать внушительнее. Для приложений-расписаний это интеграция с Calendly. Для приложений-задачников — интеграция со Slack. Все знают, что это такое. Все их хотят.

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

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

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

Как на самом деле решать

Когда у вас есть пачка запросов на функции, и все они проходят проверку «входит ли это в объём?», ранжируйте их по:

1. Сколько пользователей попросили (независимо)? Больше — лучше.
2. Это блокер или приятное дополнение? Блокеры срочнее.
3. Могут ли ваши пользователи обойтись без этого сегодня? Если нет — это важнее.
4. Поможет ли кто-нибудь вам это протестировать? Если да — стройте это первым.
5. Откроет ли это новый рынок? Если может быть — это бонус, а не причина.

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

Функция, которую вы (пока) не построите

У вас будут запросы, которые не пройдут отбор. Не делайте вид, что когда-нибудь их реализуете. Скажите пользователю: «Мы это сейчас не строим. Вот почему. Вот что мы строим. Вот альтернатива, которая может вам подойти».

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

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

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