Skip to content
Back to skills

Product Check

ASecurity

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 bu...

  • 5 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 12, 2026
ai-agents

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned October 12, 2026

npx -y skills add GuruDevvv/my-claude-skills --skill product-check --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Product Check?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Product Check
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/gurudevvv-product-check/badge)](https://www.skillsdirectory.com/skills/gurudevvv-product-check)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.md1.1 KB
  • SKILL.md10.5 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.