product-check git:20261002.a76280bA

Immutable. This exact content never changes and is served at /api/v1/blob/4a56ed0f870b6de2.

---
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% — предложи поговорить с
  клиентами, а не строить.
- **Не подменяй брейнштормом.** Здесь идея уже есть, задача — проверить её, а не
  придумать новую.