Как построить стартап на боли клиента, а не на «идее мечты»

Почему боль почти всегда выигрывает у «крутой идеи»

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

Идея продаёт вдохновение, боль — освобождение

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

Если проблема болезненная, у вас проще сходятся три вещи:

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

Как понять, что перед вами именно «боль»

Проверяйте проблему по четырём критериям:

1. Срочность — её нельзя откладывать бесконечно (есть дедлайны, штрафы, потери).
2. Частота — она возникает регулярно, а не раз в год.
3. Стоимость ошибки — цена промаха измеряется деньгами, клиентами, безопасностью, репутацией.
4. Эмоциональная цена — стресс, страх, раздражение, чувство контроля потеряно.

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

Как отличить настоящую боль от лёгкого неудобства

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

Что считать «болью»

Настоящая боль почти всегда выражается в одной из потерь:

• Деньги: штрафы, упущенная выручка, перерасход бюджета, возвраты.
• Время: часы на рутину, задержки в процессах, простои.
• Статус/карьера: ошибки «видны», падает доверие, страдает KPI.
• Спокойствие: постоянный стресс, риски, страх проверок или сбоев.

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

Признаки сильной боли

Сильная боль узнаётся по поведению, а не по словам.

1) Обходные пути уже существуют. Таблички, чаты, макросы, цепочки ручных проверок, «костыли» из 5 сервисов.

2) Много ручного труда. Сверки, копипаст, согласования «на всякий случай», дублирование данных.

3) Жалобы повторяются и конкретны. Не «у нас бардак», а «каждую пятницу мы 4 часа закрываем отчёт и всё равно находим ошибки».

Где боль обычно острее

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

• B2B-операции: закупки, логистика, документооборот, поддержка.
• Финансы: платежи, сверки, отчётность, контроль расходов.
• Комплаенс и риски: проверки, регуляторика, безопасность.
• Здоровье: где промедление и ошибки критичны (и эмоционально, и финансово).

Проверочный вопрос на «прочность»

Спросите: «Что произойдёт, если это не решить ещё 3 месяца?»

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

С чего начать: сегмент, контекст и формулировка проблемы

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

1) Выберите 1–2 сегмента и опишите «кто страдает»

Сегмент — это не «отрасль вообще», а конкретная роль в конкретной ситуации. Формулируйте так, чтобы было ясно: кто принимает решение, кто работает руками, и кто платит.

Например: «руководитель отдела продаж в B2B-компании 20–100 человек, где лиды приходят из 3–5 источников и нет единого отчёта по конверсии». Это уже точка входа для customer development.

2) Сформулируйте гипотезу боли: проблема → последствия → альтернативы

Запишите одну гипотезу в 2–3 предложения:

• Проблема: что не получается регулярно и измеримо.
• Последствия: что из-за этого теряют (деньги, время, риски, репутацию, штрафы, упущенная выручка).
• Текущие альтернативы: чем закрывают сейчас.

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

3) Привяжите проблему к контексту через карту процесса

Сделайте простую карту процесса клиента: 6–12 шагов от «входа» до «результата». На каждом шаге отметьте, где возникает трение:

• где данные теряются или дублируются;
• где нужно согласование;
• где ошибка дорого стоит;
• где возникает очередь/задержка.

Так вы находите не абстрактную «боль», а конкретный узел, вокруг которого позже легче построить MVP и проверить problem-solution fit.

4) Соберите первичный список конкурентов и заменителей

За 30–60 минут составьте таблицу: 5–10 прямых решений + 5–10 заменителей (Excel/шаблоны/ручной учёт/аутсорс). Это нужно не для «анализа рынка», а чтобы на интервью спрашивать: почему выбрали именно это, что бесит, за что готовы платить и что мешает сменить подход.

Интервью с пользователями: как добывать факты, а не комплименты

Пользовательские интервью нужны не для того, чтобы услышать «классная идея». Цель — восстановить реальную историю: что человек пытался сделать, где споткнулся, чем это закончилось и сколько это стоило (деньгами, временем, нервами).

Подготовка: вопросы про прошлое, а не про будущее

Соберите 10–12 вопросов, которые заставляют человека вспоминать конкретные случаи. Формулировка простая: «Расскажите про последний раз, когда…».

Примерный набор:

• Когда в последний раз вы столкнулись с этой проблемой? Что было триггером?
• Опишите ситуацию по шагам: что вы сделали сначала, потом?
• Какие варианты решения вы пробовали (инструменты, подрядчики, «сделали сами»)?
• Что в них не сработало? Почему перестали использовать?
• Сколько времени/денег уходит на это в месяц/квартал?
• Что происходит, если проблему не решать? (последствия)
• Кто ещё вовлечён в процесс? Кто страдает больше всего?
• Кто принимает решение о покупке и кто платит?
• Как вы понимаете, что «стало лучше»? Какая метрика для вас важна?
• Был ли момент, когда вы готовы были заплатить, но не нашли решения? Почему?
• Какие требования обязательны, а какие «приятно иметь»?
• Как вы решаете это прямо сейчас (костыли, таблицы, ручная работа)?

Где искать респондентов

Начните там, где люди уже обсуждают боль: профильные сообщества, Telegram-чаты, Slack/Discord, тематические мероприятия. Для B2B хорошо работают LinkedIn и «знакомые знакомых»: попросите 3 интро после каждого разговора.

Какие сигналы фиксировать

Записывайте не мнения, а признаки силы боли:

• Частота: как часто случается проблема.
• Цена ошибки: потери, штрафы, срыв сроков, репутационные риски.
• Роли: кто пользователь, кто влиятельный, кто подписывает чек.

Красные флаги

Осторожно, если слышите:

• общие фразы без примеров («бывает», «в целом актуально»);
• отсутствие реальных попыток решить проблему;
• «нам это было бы интересно» вместо «мы делаем так-то и платим/теряем столько-то».

После 8–12 интервью у вас должны повторяться одни и те же сценарии и цифры. Если повторяемости нет — вы пока ищете не боль, а тему.

Скоринг проблем: как выбрать одну, за которую готовы платить

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

Шаг 1. Сформулируйте 3–5 JTBD для одного сегмента

Не «нужен удобный сервис», а конкретная работа в контексте:

• «Когда ___, я хочу ___, чтобы ___».

Пример для B2B: «Когда менеджер закрывает месяц, он хочет быстро собрать отчёт из трёх систем, чтобы сдать цифры без ошибок и штрафов». Важно: один сегмент (например, только финдиректора в компаниях 50–200 человек), иначе оценки будут “прыгать”.

Шаг 2. Оцените каждую проблему по четырём шкалам

Сделайте таблицу и поставьте баллы (1–5) по критериям:

• Боль (1–5): насколько это критично, есть ли риск потерь/штрафов/срыва KPI.
• Частота: как часто возникает (ежедневно/еженедельно/раз в квартал).
• Платёжеспособность: есть ли у сегмента привычка покупать решения и какой порядок бюджетов.
• Доступ к ЛПР: можете ли вы быстро говорить с тем, кто подписывает договор (или с сильным влияющим).

Полезный приём: попросите респондента сравнить проблему с другими по важности, а не оценивать «в вакууме».

Шаг 3. Проверьте наличие бюджета — «из какой статьи это оплачивается?»

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

Шаг 4. Выберите одну узкую проблему и зафиксируйте “не делаем”

Выберите лидера по сумме баллов, но дополнительно проверьте: можно ли дать измеримый результат за 2–4 недели. И сразу запишите, что не делаете сейчас (смежные сегменты, дополнительные сценарии, «ещё одну интеграцию») — это защитит от расползания в «крутую идею» вместо платной боли.

Валидация спроса без продукта: как проверить готовность платить

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

Сформулируйте ценностное предложение в одну строку

Хорошая формула: «помогаем X сделать Y без Z».

Примеры:

• «Помогаем владельцам интернет-магазинов снизить возвраты без новых сотрудников поддержки».
• «Помогаем HR закрывать вакансии быстрее без выгорания рекрутеров».

Проверьте себя: в фразе должен быть конкретный X, измеримый Y и болезненное Z (то, что люди хотят избежать).

Сделайте 1‑страничный лендинг

Лендинг — это не про дизайн, а про ясность. На одной странице должны быть:

• обещание конкретного результата (в терминах времени/денег/риска);
• кому подходит и кому не подходит;
• как это будет выглядеть (2–4 шага, без фич-листов);
• «кейсовые обещания» без преувеличений: не «в 10 раз», а «сократим время на отчёт с 3 часов до 1–1,5».

Форма на лендинге должна вести к действию: «записаться на пилот», «оставить депозит», «получить расчёт экономии». Если нужен шаблон структуры, заведите внутреннюю страницу /landing-structure и используйте её как чек.

Тесты спроса, которые заменяют продукт

Лучшие тесты — те, где у человека появляется ставка:

• лист ожидания (минимум) — с квалифицирующим вопросом про проблему;
• предзаказ — даже если срок поставки «через N недель»;
• пилот — ограниченный по времени и объёму;
• платная консультация/аудит — быстрый способ проверить готовность платить;
• депозит — сильный сигнал, если возвращаемый.

Метрики ранней проверки

Смотрите на поведение, а не на комплименты:

• конверсия в заявку с лендинга;
• доля согласившихся на пилот/предзаказ среди целевых разговоров;
• скорость ответа (как быстро возвращаются с вопросами и документами).

Если заявки есть, но платить не готовы, чаще всего проблема в формулировке результата, выборе сегмента или отсутствии доверия — а не в «недостатке функций».

MVP вокруг боли: минимальный результат вместо набора фич

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

На практике здесь часто ломается скорость: команда может неделями спорить о фичах и архитектуре. Если вам нужно быстро собрать работающий прототип веб‑сервиса, админки или внутреннего инструмента, полезно использовать подход «собрал — проверил — откатил». Например, в TakProsto.AI (vibe‑coding платформа для российского рынка) можно быстро накидать MVP через чат, сделать деплой, а при неудачной итерации откатиться с помощью снапшотов и rollback — без долгой сборки пайплайна.

1) Найдите минимальный сценарий снятия боли

Сформулируйте MVP как обещание результата: «за 10 минут получить X без Y». Затем вырежьте всё, что не влияет на этот результат.

Пример логики: если боль — «согласование договоров занимает 5 дней», то MVP — не «платформа с ролями и комментариями», а «получить правки юриста за 2 часа по понятному процессу».

2) Решите, что сделать вручную (concierge), а что автоматизировать позже

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

Правило: автоматизируйте только то, что повторяется часто и тормозит скорость доставки результата.

3) Ограничьте MVP одним сегментом и одним use case

Один сегмент = одинаковый контекст и критерии успеха. Один кейс = понятная ценность.

Формула ограничения: «Для кого?» + «В какой ситуации?» + «Какой результат за какое время?». Всё, что не укладывается — в бэклог.

4) Запланируйте сбор обратной связи заранее

Не ждите «когда накопятся пользователи». Задайте ритм:

• Что измеряем: время до результата, долю пользователей, дошедших до конца сценария, частоту повторного использования, готовность рекомендовать.
• Когда созваниваемся: после первого результата (в течение 24–48 часов) и после 3–5 повторов.
• Какие вопросы: «Что было самым болезненным до?», «На каком шаге хотелось бросить?», «Что бы вы делали вместо нас?», «За что вы готовы платить регулярно?».

Если хотите, в следующем шаге можно связать метрики MVP с проверкой оплаты в разделе про /blog/validaciya-sprosa-bez-produkta.

Ценообразование и unit-экономика: монетизируем реальную стоимость боли

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

Как боль превращается в цену

Начните с простого: во что клиенту обходится текущая ситуация за месяц.

• Простой и задержки: часы простоя × стоимость часа команды/оборудования/упущенной выручки.
• Ошибки и переделки: количество инцидентов × средняя цена исправления (время, материалы, возвраты).
• Штрафы и риски: ожидаемая стоимость = вероятность × размер штрафа/убытка.
• Текучка и выгорание: стоимость замены сотрудника (поиск, адаптация, падение продуктивности).

Дальше формула должна быть честной: если ваша ценность — экономить клиенту 300 000 ₽ в месяц, цена в 15–60 000 ₽ выглядит понятной. Если экономия «где-то там», клиент будет требовать скидку.

Выбор модели монетизации

Модель должна совпадать с тем, как проявляется боль:

• Подписка — когда ценность регулярная (снижение рутины, контроль, предотвращение ошибок).
• Оплата за использование — когда боль растёт с объёмом (документы, транзакции, проверки).
• Оплата за результат — когда можно измерить эффект (сокращение времени, снижение брака, рост конверсии).
• За место/пользователя — когда ценность связана с командной работой и доступами.

Черновик unit-экономики до масштабирования

Ещё до полноценного продукта прикиньте «скелет»:

• CAC: сколько стоит привлечь одного платящего (каналы + время продаж).
• Маржа: цена минус переменные издержки (поддержка, интеграции, инфраструктура).
• LTV: сколько приносит клиент за срок жизни.
• Срок окупаемости: за сколько месяцев LTV покрывает CAC.

Если окупаемость выходит «когда-нибудь потом», проблема часто не в маркетинге, а в цене или сегменте.

Ловушка «сделаем дешево, чтобы проще продать»

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

Позиционирование и первые продажи: говорить языком боли

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

Формула позиционирования без маркетингового тумана

Соберите одну фразу, которую можно сказать в первом сообщении или на созвоне:

«Мы помогаем [сегменту] в ситуации [контекст] уменьшить/убрать [боль, измеримая последствиями], чтобы [ценный результат], без [типичный риск/страх]».

Пример (шаблон): «Помогаем руководителям отделов продаж в B2B сократить потери сделок из‑за неразобранных лидов, чтобы увеличить выручку в текущем штате, без внедрения на 3 месяца».

«Доказательства» вместо громких обещаний

Вам не нужны большие кейсы — нужны наблюдаемые сигналы, что боль реально уменьшается:

• пилот на 2–4 недели с чётким критерием успеха;
• цифры до/после (время, ошибки, потери, деньги, скорость);
• короткий отзыв в формате: «было → стало» (без восторгов и общих слов);
• артефакты доверия: список клиентов (с разрешения), письмо‑рекомендация, скрин метрик.

Если доказательств пока нет — продавайте не «продукт», а следующий шаг: диагностику, аудит, пилот.

Скрипт первого контакта: вопросы, боль, следующий шаг

Цель разговора — не презентация, а выяснение фактов.

1. «Как вы сейчас решаете [задачу]?»

2. «Что чаще всего идёт не так? Как это проявляется в цифрах/времени/деньгах?»

3. «Что уже пробовали? Почему не сработало?»

4. «Если ничего не менять 3 месяца, что будет?»

5. «Ок, вижу, что цена проблемы примерно X. Предлагаю пилот: [условия]. Если получаем [метрика], обсуждаем оплату/контракт».

Каналы на раннем этапе

Лучше всего работают каналы, где можно быстро получить диалог:

• личные продажи и тёплые интро;
• партнёры (агентства, интеграторы, консультанты), у которых эта боль всплывает регулярно;
• сообщества по роли/отрасли;
• контент «по проблеме» (разборы причин, чек‑листы, калькуляторы потерь), который ведёт на /pricing или запись на пилот.

Когда вы говорите языком боли, клиент слышит: «эти люди понимают мою цену бездействия». Это и запускает первые сделки.

Удержание и рост: как измерять, что боль реально ушла

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

Метрики, которые показывают силу снятой боли

Смотрите не на абстрактный retention, а на метрики, напрямую связанные с проблемой:

• Время до ценности (time-to-value): сколько минут/дней проходит до момента, когда пользователь впервые говорит себе «о, стало легче». Чем острее боль, тем сильнее стремление получить результат быстро.
• Частота использования: как часто продукт реально нужен для снятия боли (ежедневно, еженедельно, «по событию»). Важно сравнивать с естественным ритмом проблемы.
• Повторные покупки/продления: лучший маркер того, что ценность не разовая. Если продления нет — боль либо решается альтернативой, либо вы лечите симптом, а не причину.

Онбординг как диагностика, а не экскурсия

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

План итераций: коротко и измеримо

Заведите ритм: каждые 1–2 недели — одна гипотеза, один измеримый результат. Пример: «Если упростим первый сценарий до 3 шагов, time-to-value снизится с 2 дней до 30 минут».

Если вы строите MVP на TakProsto.AI, это удобно поддерживать «вживую»: планирование (planning mode) помогает зафиксировать гипотезу и критерии успеха до изменений, а экспорт исходников — не бояться, что быстрый старт «закроет» путь к дальнейшей разработке.

Когда расширяться

Расширение (новые сегменты, каналы, фичи) имеет смысл, когда:

• проблема решается стабильно, без ручного «дотягивания» каждого клиента;
• метрики (time-to-value, частота, продления) держатся на целевом уровне;
• продажи становятся повторяемыми: понятный оффер, прогнозируемая конверсия, понятные причины отказов.

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

Типичные ошибки и как не скатиться обратно в «крутую идею»

Даже если вы начали с реальной боли, команда легко «съезжает» в режим идей и хотелок. Обычно это происходит незаметно: метрики не растут, и появляется соблазн лечить это новыми фичами, ребрендингом или «платформой для всех».

Ловушка «влюбился в идею» — как распознать

Сигнал не в эмоциях, а в решениях команды. Если обсуждения звучат как «давайте добавим…», «будет круто, если…», а не «пользователь тратит X часов/денег из‑за Y, и вот доказательства», вы уже строите мечту.

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

Ранняя «платформа» и распыление по сегментам

«Сделаем платформу, чтобы потом подключать модули» — часто способ избежать выбора. Платформа почти всегда означает сложность, долгую разработку и размытый месседж.

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

Подмена боли желаемостью

Опросы в стиле «вам нужно?» измеряют вежливость, а не готовность менять поведение. Корректнее смотреть на факты:

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

Если «да, было бы полезно» не подкрепляется текущими затратами — это, скорее всего, лёгкое неудобство.

Как делать пивот без паники

Хороший пивот — не «меняем всё», а «пересобираем то, что не сошлось с фактами».

Сохраняем: доказанный сегмент или контекст, где боль подтверждена; инсайты из интервью; каналы, где есть отклик.

Меняем: формулировку проблемы, ключевое обещание, способ доставки результата (иногда — аудиторию), если данные показали другое.

Фиксируйте причину пивота в одном абзаце: какие наблюдения/цифры заставили признать, что текущая гипотеза не работает. Это дисциплинирует и не даёт «скатиться» обратно в очередную «крутую идею».

Практический чек-лист: от гипотезы боли до первых денег

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

Чек-лист из 10 пунктов (печать на одну страницу)

1. Сегмент: кто именно? (роль, индустрия, размер компании, география)

2. Боль: что происходит сейчас, когда боль «случается»? (событие-триггер)

3. Контекст: где и когда это возникает? (процесс, частота, сезонность)

4. Цена бездействия: что теряют в деньгах/времени/рисках/репутации?

5. Альтернативы: чем закрывают боль сегодня? (Excel, агентство, ручной труд, конкурент)

6. Бюджет: есть ли строка бюджета или понятная статья расходов?

7. ЛПР и пользователь: кто принимает решение и кто страдает? совпадают?

8. Пилот: что должно случиться за 2–4 недели, чтобы они сказали «работает»?

9. Цена: за что платят — за результат, объём, риск, скорость? первая «вилка».

10. Метрики: чем измеряем исчезновение боли? (время цикла, ошибки, возвраты, SLA, выручка)

Шаблоны, чтобы действовать быстрее

1) Структура интервью (30–40 минут)

• Разогрев: роль, задачи, KPI.
• Последний раз: «Вспомните последний кейс, когда проблема проявилась».
• Разбор: шаги, участники, инструменты, где ломается.
• Последствия: потери, риски, эскалации.
• Альтернативы: что пробовали, почему не подошло.
• Готовность: как выглядит хороший результат, кто утверждает, сроки.
• Деньги: как покупают подобное, диапазон, условия пилота.

2) Таблица скоринга проблем (заполняйте после 5–10 разговоров)

Критерий                | 1–5 | Примечание
Частота                 |     |
Сила боли (потери)       |     |
Срочность               |     |
Платёжеспособность       |     |
Доступ к ЛПР            |     |
Сила альтернатив         |     |
Итог (сумма)            |     |

3) План MVP на 4 недели (вокруг результата, не фич)

• Неделя 1: обещание результата + лендинг + 10–15 интервью.
• Неделя 2: «ручной» пилот (сервис/консьерж) на 2–3 клиента.
• Неделя 3: автоматизация самого узкого места + повторный пилот.
• Неделя 4: коммерческое предложение, счёт, первые оплаты/предзаказы.

Если нужно углубиться в выбор сегмента и вопросы интервью — посмотрите материалы в /blog. А когда дойдёте до упаковки тарифов и условий пилота, удобно сверяться с /pricing.

P.S. Если ваша цель — максимально быстро проверить гипотезу «за это готовы платить», держите фокус на результате и времени цикла. Инструменты наподобие TakProsto.AI помогают ускорить путь от разговоров к работающему MVP (веб/сервер/мобильное), особенно когда важно итеративно тестировать сценарии, а не месяцами «допиливать идею». При этом можно начать с бесплатного тарифа, а при росте перейти на pro/business/enterprise — под объём и процессы команды.