Персоны SaaS-пользователей по отзывам, болям и сценариям

Разработай детальные пользовательские персоны для SaaS-продукта [НАЗВАНИЕ_КОМПАНИИ].

Используй только входные данные:
- YOUR_COMPANY_NAME
- CUSTOMER_FEEDBACK
- при наличии: COMPETITOR_PERSONAS
- при наличии: PRODUCT_FEATURES

Правила:
- Отвечай только на русском.
- Не придумывай данные.
- Если исходных данных недостаточно для какого-либо вывода, явно помечай предположение и уровень уверенности.
- Не включай личные данные реальных клиентов.

Структура ответа строго по заголовкам:
1. Входные данные
2. [DEMOGRAPHIC_DETAILS]
3. [USER_PAIN_POINTS]
4. [USER_PERSONA_PROFILE]
5. [VISUAL_PERSONA]
6. [USER_SCENARIOS]
7. [COMPETITOR_PERSONAS]
8. [PRODUCT_FEATURES]
9. Рекомендуемые приоритеты и KPI
10. Слабейшая гипотеза и план тестирования
11. Ситуация, в которой персона может ввести в заблуждение

Содержательные требования:
- [DEMOGRAPHIC_DETAILS]:
  - 3-5 демографических сведений;
  - для каждого источник и уровень уверенности.
- [USER_PAIN_POINTS]:
  - 2-4 боли;
  - 1-2 прямые цитаты, если они есть;
  - метрика или индикатор.
- [USER_PERSONA_PROFILE]:
  - 1-2 персоны;
  - имя, ролевая метка, описание, цели, барьеры, поведение, стек, критерии решений и доказательства.
- [VISUAL_PERSONA]:
  - компактная ASCII-визитка;
  - при желании простая ASCII-диаграмма, не более 100 строк.
- [USER_SCENARIOS]:
  - для каждой персоны 2-3 сценария по цепочке триггер -> цель -> действия -> ожидаемый результат -> метрика.
- Раздел 9:
  - 3 конкретных продуктовых или маркетинговых приоритета;
  - для каждого ожидаемый эффект и KPI.
- Раздел 10:
  - одна слабейшая гипотеза;
  - один конкретный тест.
- Раздел 11:
  - один сценарий ошибочного использования персоны;
  - как это минимизировать.

Если COMPETITOR_PERSONAS отсутствуют, в разделе 7 напиши "нет данных".