ИИ в работе продакта: работа с требованиями
В прошлый раз писал про то, как LLM помогают готовиться к интервью: проверять вопросы и смотреть на гипотезу глазами разных участников цепочки принятия решения. Теперь следующий слой- работа с требованиями.
В B2B требования часто приходят не постепенно через метрики, аналитику и поддержку, а приезжают большим массивом в виде клиента, который готов заплатить много денег.
А вместе с деньгами приезжает набор хотелок:
- «нам нужен такой отчет»;
- «добавьте такую кнопку»;
- «сделайте как в Jira / старой системе»;
- «без этой функции мы не сможем внедриться»;
- «это требование от бизнеса / ИБ / архитектуры».
На первый взгляд все звучит убедительно. Особенно если это говорит крупный клиент. Но за одной формулировкой могут стоять разные вещи: реальная боль пользователя, особенность процесса конкретной компании, попытка воспроизвести старую систему, политический компромисс, ограничение ИБ или разовая хотелка, которая не масштабируется на рынок.
Если такое требование сразу положить в backlog или roadmap, можно быстро прийти не к развитию продукта, а к заказной разработке.
Поэтому на этапе discovery важно не только собирать требования, но и прожаривать их:
- что на самом деле стоит за запросом;
- насколько требование продуктово;
- можно ли его обобщить;
- какие риски мы берем;
- не уходим ли мы в кастом.
LLM здесь полезна как предварительный ревьюер требований: инструмент, который помогает задать правильные вопросы до старта разработки.
Я обычно прогоняю спорные требования через 4 проверки.
1. Что здесь проблема, а что уже решение?
Клиент часто формулирует запрос сразу в виде решения.
Например:
«Нам нужна выгрузка в Excel».
Но за этим могут стоять разные проблемы: нет доверия к данным, нужен регулярный отчет, неудобен текущий дашборд, данные нужны для другой системы или пользователи просто привыкли работать в Excel.
LLM можно попросить:
Не принимай формулировку требования как готовое решение. Предложи, какие реальные проблемы могут стоять за этим запросом, и вопросы, которые помогут это проверить.
2. Для кого это требование?
В large enterprise одно требование может по-разному выглядеть для пользователя, руководителя, ИБ, архитектора, эксплуатации, закупки или владельца бюджета.
LLM можно попросить:
Посмотри на это требование глазами разных ролей. Для каждой покажи ценность, вопросы и возможные блокеры.
3. Это продуктовая функция или кастом?
Не каждое важное клиентское требование должно становиться продуктовой функцией.
Иногда это рыночная боль. Иногда - особенность процесса конкретной компании. Иногда - компромисс для сделки. Иногда - кастом, который потом придется годами поддерживать.
LLM можно использовать как оппонента:
Это похоже на продуктовую функцию или кастом под одного заказчика? Дай аргументы за и против. Как можно обобщить требование для рынка?
4. Какие вопросы нужно задать до старта разработки?
Моя любимая ловушка: требование в одну строку, которое кажется понятным и оценивается в 5 дней, а по итогу превращается в 50.
LLM можно попросить:
Сформулируй вопросы, без ответов на которые это требование нельзя брать в работу. Отдельно выдели 5 критичных вопросов.
Главная польза не в том, что ИИ «напишет user story». А в том, что он помогает глубже понять проблему клиента, отделить продуктовую функцию от кастома и не тащить в roadmap лишнее.
Если лучше понять задачу, точнее определить границы решения и заранее увидеть риски, команда за тот же объем времени может создать больше value - не просто закрыть хотелку одного клиента, а усилить продукт в целом.
Общий промпт для такой прожарки требований вынесу в комментарий ниже.
Делитесь, как вы используете LLM на ранних этапах проектирования фичи или продукта. Как лучше делать короткие посты здесь или писать более развернуто на vc.ru?
Читать про продукты в b2b
В этом посте были ссылки, но мы их удалили по правилам Сетки
