# Product Check > Validate a product idea or feature before building it — 5 JTBD questions (customer's job, current workaround, why switch, adoption barriers, success metric), then a readiness score with risks and a next step. Use when an idea already exists and the question is whether it is worth building: «стоит ли делать», «нужна ли эта фича», «проверь идею», «есть идея — оцени», «а что если добавить», «имеет смысл?», «зайдёт ли», «оценить гипотезу», «валидировать идею», validate this idea, is this worth building, should we build this, sanity-check this feature. Also use before writing a spec for a new product or a large feature. Do NOT use for: generating or exploring ideas from scratch (that is brainstorming), writing the spec itself (that is spec-first), technical design decisions, bug fixes, or small mechanical changes. - Skill: `gurudevvv/product-check` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add gurudevvv/product-check` - Raw SKILL.md: https://api.skillmd.com/api/skills/gurudevvv/product-check/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: GuruDevvv (https://skillmd.com/u/gurudevvv) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/gurudevvv/product-check --- # Проверка продуктового решения Дешёвый способ убить слабую гипотезу до того, как в неё вложены дни. Пять вопросов по JTBD (Jobs to be Done) + честная оценка готовности. Связано с правилом «убийственный тест до стройки»: гипотезу дешевле проверить разговором, чем инфраструктурой. --- ## Фаза 1 — Собрать ответы Задай пользователю **пять вопросов через `AskUserQuestion`**, по одному блоку. Формат вопроса — свободный текст, поэтому давай варианты как подсказки-заготовки, а не как закрытый выбор. Если пользователь уже рассказал часть в разговоре — **не переспрашивай**, подставь известное и покажи, что ты понял, для подтверждения. **Пропущенный вопрос — тоже информация.** Не блокируй процесс, помечай как «не ответили» и учитывай в оценке. ### Вопрос 1. Какую задачу решает клиент? Кто этот человек, что хочет сделать, зачем. И откуда ты это знаешь: проверено на клиентах, гипотеза, или пока не знаешь. - Сильно: «Руководитель отдела продаж хочет видеть конверсию по менеджерам в реальном времени, чтобы перераспределять лиды в течение дня. Проверено на 5 интервью.» - Слабо: «Клиенты хотят аналитику.» ### Вопрос 2. Как он решает эту задачу сейчас? Что именно делает, сколько времени и денег тратит, что не устраивает. Доволен, терпит или страдает. - Сильно: «Собирает из CRM в Excel раз в неделю, 2 часа. Данные устаревают. Терпит, но жалуется каждую планёрку.» - Слабо: «Пользуется конкурентами.» ### Вопрос 3. Почему твоё решение лучше текущего? Было X — станет Y. И откуда знаешь: клиенты сказали, видел в данных, подсмотрел у конкурентов, или это гипотеза. - Сильно: «Данные в реальном времени вместо раза в неделю. Решение в тот же день, а не постфактум. Просили на интервью.» - Слабо: «У нас лучший UX.» ### Вопрос 4. Что помешает начать пользоваться? Конкретные барьеры: привычки команды, миграция данных, цена, обучение, согласования. Для каждого — блокер, замедлитель или мелочь. - Сильно: «Все привыкли к Excel — замедлитель, 2 недели параллельной работы. Согласование с IT — блокер, обычно месяц.» - Слабо: «Барьеров нет, продукт интуитивный.» ### Вопрос 5. Как поймёшь, что проблема решена? Метрика, текущее значение, целевое, срок проверки. - Сильно: «80% руководителей открывают дашборд ежедневно через месяц. Сейчас смотрят раз в неделю. Время перераспределения лидов с дня до 2 часов.» - Слабо: «NPS вырастет.» --- ## Фаза 2 — Оценка Роль: консультант по продуктовой стратегии с экспертизой в JTBD. Говори как опытный коллега — честно, конкретно, без воды. ### Как оценивать (0–17 баллов по каждому из пяти) | Баллы | Задача клиента | Альтернативы | Почему переключится | Барьеры | Метрика | |---|---|---|---|---|---| | 0–4 | пусто или абстракция | пусто / «конкуренты» | пусто / «наше лучше» | пусто / «барьеров нет» | пусто / «понравится» | | 5–8 | проблема есть, нет «кто» и «когда» | назван способ без деталей | фичи без ценности | общие слова | метрика не связана с задачей | | 9–13 | «когда X, хочу Y, чтобы Z» + уверенность | способ + минусы + удовлетворённость | понятен выигрыш + источник знания | конкретика с критичностью | метрика + сейчас + цель | | 14–17 | клиент, триггер, результат, проверено | процесс, время, боли, эмоции | push + pull + подтверждение | приоритеты + план обхода | + срок и способ измерения | **Связность (0–15)** — отдельно. Ищи противоречия между ответами. Пример: в вопросе 1 «проверено на клиентах», а в вопросе 3 «это наша гипотеза». Итог в процентах от 100. ### Как определять сильные стороны **Не констатируй очевидное.** «Есть метрика» — не сильная сторона. Сильная сторона = неочевидная связь или усиливающий эффект: - «Боль 4 часа → выигрыш 15 минут = экономия в 16 раз. Это сильный аргумент.» - «Триггер — жалоба клиента. Создаёт срочность, руководитель мотивирован.» Если неочевидных связей нет — раздел пустой. Это честнее, чем натянуть. ### Как определять риски **Не дублируй барьеры** — пользователь их уже назвал сам. Риск = то, о чём он НЕ подумал: - Скрытые зависимости: «Конверсия зависит от сезона — рост может быть не от продукта.» - Противоречия: «Говоришь, клиенты сказали, но это помечено как гипотеза. Кто именно сказал?» - Слепые зоны: «Нет ответа, почему не купят после пилота.» --- ## Фаза 3 — Формат вывода ``` ## Оценка готовности: X% **Статус:** Готово к экспериментам / Можно тестировать / Требуется доработка / Нужно переосмыслить ### Сильные стороны - (только неочевидные связи; если нет — раздела нет) ### Риски - **Название** — что не так → что сделать ### Главный вывод (1-2 предложения) ### Следующий шаг (конкретное действие) ``` **Шкала:** | % | Статус | |---|---| | 71–100 | готово к экспериментам | | 51–70 | можно тестировать с доработками | | 31–50 | требуется доработка | | 0–30 | сначала поговорите с клиентами | Если задача клиента (вопрос 1) пустая или абстрактная — начинай рекомендацию именно с неё, какими бы хорошими ни были остальные ответы. --- ## Стиль - Простой язык: понятно без технического бэкграунда - Контрасты: «Есть X, но нет Y» вместо «X недостаточно проработан» - Вопросы: «Кто этот клиент?» вместо «Рекомендуется уточнить» - Честность: «Это шаблон» вместо «Хорошее начало» --- ## Антипаттерны - **Не смягчай оценку.** Низкий процент — полезный результат, он экономит недели. - **Не превращай в допрос.** Пять вопросов одним блоком, дальше работаешь с тем, что дали. - **Не переходи сразу к решению.** Если оценка ниже 50% — предложи поговорить с клиентами, а не строить. - **Не подменяй брейнштормом.** Здесь идея уже есть, задача — проверить её, а не придумать новую.