💡 Как понять, какую функцию делать следующей?

У стартапа пять клиентов, и у каждого свой список пожеланий. Одному нужна интеграция с CRM. Второму — гибкие отчёты. Третий говорит, что купит продукт, если появится мобильное приложение.

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

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

Задача команды — понять, какая проблема стоит за запросом, насколько она типична для целевого сегмента и какой эффект даст её решение относительно стоимости разработки.

Для этого полезно пройти несколько шагов.

1⃣ Отделите запрос на функцию от самой проблемы
Клиенты часто формулируют не потребность, а уже готовое решение. «Нужна выгрузка в Excel» ещё не объясняет, зачем она нужна. Возможно, сотрудник каждую пятницу вручную собирает данные для отчёта руководителю. Тогда проблему может решить не полноценный конструктор выгрузок, а автоматическая отправка готовой сводки.

Поэтому сначала стоит выяснить:
🌟 когда проблема возникала в последний раз;
🌟 как клиент решает её сейчас;
🌟 сколько времени, денег или ресурсов на это уходит;
🌟 что произойдёт, если ничего не менять.

Так команда оценивает не привлекательность функции, а масштаб проблемы.

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

Вопрос «Нужен ли вам более удобный отчёт?» почти наверняка получит положительный ответ. Гораздо полезнее спросить: «Как вы сейчас готовите отчёт?», «Кто участвует в процессе?», «Сколько времени это занимает?», «Где возникают основные сложности?».

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

3⃣ Свяжите функцию с бизнес-результатом
У каждой заметной доработки должен быть ожидаемый эффект.
Например, функция может:
🌟 снять блокер для внедрения;
🌟 повысить регулярность использования продукта;
🌟 сократить time-to-value;
🌟 создать возможность для допродажи;
🌟 снизить стоимость внедрения или поддержки.

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

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

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

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

5⃣ Сначала проверьте гипотезу, потом масштабируйте решение
Не каждую идею нужно сразу превращать в полноценную функцию.
Часть гипотез можно проверить дешевле:
🌟 отчёт временно собирать вручную;
🌟 интеграцию протестировать через разовый обмен данными;
🌟 новый сценарий показать на прототипе.

Важно проверить меняет ли решение поведение клиента.

На первый взгляд приоритетнее выглядит разделение прав доступа. У запроса есть понятный сегмент, подтверждённая проблема и прямое влияние на внедрение.

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

Перед добавлением функции в roadmap попробуйте закончить фразу:
«Мы решаем ___ для ___, потому что сейчас они не могут ___. Это влияет на ___. Гипотезу считаем подтверждённой, если ___».

Если какие-то поля остаются пустыми, скорее всего, команде пока не хватает данных для принятия решения.