Идея нравится всем, но кто за нее заплатит? Мой первый вопрос к новому продукту

Идею нового продукта редко встречают молчанием. Коллеги кивают, знакомые говорят: «Было бы удобно», потенциальный клиент просит показать, когда будет готово. В такой момент очень хочется открыть backlog, собрать команду и начать считать экраны.

Я бы начал с другого вопроса: кто и за решение какой конкретной задачи будет платить? Не «кому в целом понравится», не «кто будет пользоваться когда-нибудь», а кто достанет деньги из своего бюджета и почему не захочет оставить всё как есть.

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

Симпатия — не спрос

Фраза «мне бы пригодилось» часто означает совсем не то, что слышит команда. Человек может представить идеальный день, в котором новая система уже работает, а заодно исчезли привычки, ограничения и ручные обходы. Но покупать ему придётся не картинку будущего. Ему придётся менять процесс, объяснять решение коллегам, переносить данные и выделять время.

Поэтому полезно спросить не «нужен ли вам такой сервис?», а «в какой момент на прошлой неделе вы столкнулись с этой проблемой? Что сделали вместо решения? Что это вам стоило?» После такого вопроса разговор либо становится конкретным, либо быстро обнаруживает, что боль пока живёт только в нашей голове.

Конкретика обычно звучит не как описание функции. Руководитель отдела не говорит: «Нам нужен модуль согласования». Он говорит: «Мы третий раз переделываем расчёт, потому что версия в письме не совпала с таблицей». Основатель не просит «дашборд». Он говорит: «В пятницу я опять не понял, какие заказы реально успеем отгрузить». Вот здесь уже есть работа, риск и человек, который отвечает за результат.

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

Кто платит и кто живёт с результатом

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

Я бы разделил роли на четыре простых вопроса:

• кто сталкивается с проблемой руками;
• кто теряет время, деньги или контроль, если ничего не менять;
• кто может принять решение о покупке;
• кому придётся объяснять, почему новый способ работы лучше старого.

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

Разговор, который не похож на продажу

Проверка спроса ломается, когда команда приходит за подтверждением. Если показать красивый макет и спросить, нравится ли он, большинство людей будет вежливо поддерживать разговор. Гораздо полезнее попросить рассказать о последнем реальном случае. Не предлагать ответ заранее, не спорить с обходным путём, не обещать, что «у нас всё будет проще».

Я бы держал перед собой пять вопросов:

• Что именно вы пытаетесь сделать?
• Где этот путь обычно тормозит или ломается?
• Как вы решаете это сейчас?
• Что будет, если ничего не менять ближайшие полгода?
• За что вы уже платите деньгами, временем или ошибками?

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

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

Что считать ранним подтверждением

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

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

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

Что делать, если ответ пока неясен

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

Такой сдвиг меняет всё: легче найти собеседника, показать первый результат и понять, что считать полезным. Именно из узкого сценария обычно и вырастает первая версия. О том, что в неё действительно стоит включать, есть отдельный разбор: «Что обязательно должно быть в первой версии продукта?».

Если после нескольких честных разговоров не видно ни повторяющейся ситуации, ни готовности сделать следующий шаг, я бы не называл это «рынок ещё не понял ценность». Гораздо полезнее признать: гипотеза пока не нашла своего покупателя. Это недорогая новость до разработки и очень дорогая — после неё.

Первый вопрос не отменяет продуктовую работу

Проверка спроса не заменяет архитектуру, расчёт экономики и нормальную разработку. Она помогает не строить дом вокруг двери, которой никто не собирался пользоваться. Когда ясно, кто платит и за какую работу, можно обсуждать формат продукта, интеграции, поддержку и путь к запуску. Для таких задач на сайте есть направление разработки IT-продуктов.

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

Кому нельзя отдавать ответ за весь рынок

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

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

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

Цена вопроса не всегда выражается в рублях

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

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

Не путать готовность платить с просьбой о скидке

Когда разговор доходит до цены, у собеседника почти всегда появляются вопросы. Это нормально. Он сравнивает риск нового решения с привычным способом работы, просит понятный объём пилота, хочет увидеть, что будет при ошибке. Такие вопросы не ослабляют гипотезу. Наоборот, они означают, что человек примеряет решение к своей реальности.

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

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