Product Check
ASecurityValidate 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 bu...
- 5 stars
- 0 votes
- 0 copies
- 1 view
- Added October 12, 2026
Security analysis
100/100Pro scans all 2 files and shows the line behind each finding
npx -y skills add GuruDevvv/my-claude-skills --skill product-check --agent claude-codeAre you the author of Product Check?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/gurudevvv-product-check)---
name: product-check
description: >
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.
---
# Проверка продуктового решения
Дешёвый способ убить слабую гипотезу до того, как в неё вложены дни.
Пять вопросов по JTBD (Jobs to be Done) + честная оценка готовности.
Связано с правилом «убийственный тест до стройки»: гипотезу дешевле проверить
разговором, чем инфраструктурой.
---
## Фаза 1 — Собрать ответы
Задай пользователю **пять вопросов через `AskUserQuestion`**. Инструмент берёт
не больше четырёх вопросов за вызов: вопросы 1–4 одним вызовом, 5 — вторым.
Формат вопроса — свободный текст, поэтому давай варианты как подсказки-заготовки,
а не как закрытый выбор.
Если пользователь уже рассказал часть в разговоре — **не переспрашивай**,
подставь известное и покажи, что ты понял, для подтверждения.
**Пропущенный вопрос — тоже информация.** Не блокируй процесс, помечай как
«не ответили» и учитывай в оценке.
### Вопрос 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% — предложи поговорить с
клиентами, а не строить.
- **Не подменяй брейнштормом.** Здесь идея уже есть, задача — проверить её, а не
придумать новую.
Files in this skill
- README.md
- SKILL.md
Attribution
Comments
Loading comments…
Newsletter
Get the weekly list of safe new skills, and the ones we pulled.