Сначала проверь полноту входных данных, затем выполни задачу строго по структуре ниже. Работай только с переданными данными и незаполненными placeholders, не придумывай факты, не задавай вопросов и не добавляй пояснения о ходе рассуждений. Если исходные правила требуют явно отметить пробелы, предположения, корректировки или ограничения, сделай это в итоговом ответе. Верни только готовый результат в указанном формате.
Вы — продуктовый стратег мирового уровня, специализирующийся на опыте онбординга для SaaS-компаний. [НАЗВАНИЕ КОМПАНИИ] просит разработать всестороннюю продуктовую стратегию онбординга для новой SaaS‑платформы. Тон — инструктивный, практичный, ориентированный на продуктовые команды (PM, UX, growth, engineering). Ответы должны быть прагматичными, с явными выводами и конкретными действиями.
Входные данные (обязательные — заполните перед запуском):
- onboarding_metrics — набор текущих метрик онбординга в следующем формате:
- MAU/DAU, activation_rate (определение активации), time_to_value (в днях/часах), conversion_funnel (показатели по шагам), churn_rate_during_onboarding (с разбивкой по дням/шагам), dropoff_by_step (название шага: % ухода), qualitative_feedback_samples (5–10 цитат/тем).
- personas — массив персон. Для каждой персоны укажите: name, job_title, company_size, primary_goal, technical_skill_level, top_pain_points (3), success_criteria.
- current_onboarding_flow — пошаговое описание текущего онбординга (каждый шаг: id, name, канал/UI, описание, expected_time, conversion_rate_for_step).
- user_feedback — свод ключевых инсайтов из NPS/интервью/чата/тикетов (формат: тема: краткое описание, частота/вес).
- product_capabilities — текущее состояние продукта: core_features, integrations, technical_constraints, support_channels.
- required_company_context — заполните эти поля: COMPANY_STAGE, FUNDING_GOAL, FOUNDING_TEAM_BIOS, MARKET_SIZE_DATA, PRODUCT_ROADMAP.
Обязательные правила обработки входных данных:
- Если каких‑то полей нет — сначала перечислите отсутствующие поля и затем сделайте чётко помеченные предположения (Assumption #1, #2 …). Все рекомендации, основанные на предположениях, помечайте ссылкой на соответствующее предположение.
- Не делайте дополнительных запросов данных.
Задачи (выполните последовательно и по каждой дайте краткие обоснования):
1) Анализ метрик онбординга
- Выделите 3–5 ключевых точек оттока с указанием конкретных метрик (шаг, процент ухода, абсолютное число пользователей, время).
- Для каждой точки укажите вероятную первопричину(ы), какие данные это подтверждают, и какие дополнительные данные стоило бы собрать для валидации гипотезы.
2) Пользовательский путь (по каждой переданной персоне)
- Для каждой персоны представьте пошаговую карту пути (step_id, step_name, user_goal_at_step, user_expectation, friction_points, success_metric_for_step).
- Сформулируйте ключевые потребности и ожидания персоны в контексте онбординга.
3) Приоритизация ключевых функций (3–5)
- Назовите 3–5 функций, которые нужно приоритизировать в онбординге.
- Для каждой функции дайте: краткое описание, почему она решает обнаруженные проблемы (связь с метриками/фидбеком), минимальный набор (MVP) для онбординга, ожидаемый краткосрочный KPI‑эффект (метрика и целевое изменение), пример оценки сложности имплементации (low/medium/high), зависимости.
4) Последовательность шагов онбординга (реализуемый flow)
- Опишите детализированную последовательность шагов (50–150 слов на шаг), где указать: цель шага, ключевой CTA, требуемый UI/UX элемент или поведение, ожидаемое время на исполнение, success_criteria (конкретная метрика), возможные вариации для разных персон.
- Укажите рекомендации по микро‑взаимодействиям (подсказки, ошибки, прогресс‑бар) и по каналам сопровождения (in‑app, email, product tour, support).
5) Риски и тестирование предположений
- Определите одно (1) наиболее слабое предположение в ваших рекомендациях и опишите детальный план тестирования этого предположения: гипотеза, primary_metric, выборка/сегментация, экспериментальный дизайн (A/B или пилот), минимально значимый эффект (MDE), продолжительность и требования к данным.
- Назовите один реалистичный сценарий, в котором предложенная стратегия онбординга может не сработать, и предложите краткие меры смягчения (2–3 шага).
Формат ответа (обязательные требования)
- Верните результат в виде JSON‑объекта с точно такими ключами и вложенными структурами:
{
"summary": "Краткое 2–3 предложенияное резюме ключевых рекомендаций",
"analysis": { ... }, // результат пункта 1: массив проблем/метрик
"user_paths": { ... }, // результат пункта 2: по персоне
"prioritized_features": [ ... ], // пункт 3: массив функций с полями
"onboarding_sequence": [ ... ], // пункт 4: массив шагов с полями
"weakest_assumption_and_test": { ... }, // пункт 5: предположение + план теста
"failure_scenario_and_mitigation": { ... }, // пункт 5: сценарий + mitigations
"inputs_missing_or_assumptions": [ ... ] // перечисление отсутствующих входных данных и сформулированные Assumptions (если были)
}
- Для каждого массива/объекта используйте названия полей, указанные выше; внутри давайте только необходимые поля, избегайте лишней вербosity, но сохраняйте полноту (см. требования задач).
- Минимизируйте свободный текст — где возможны, используйте краткие буллеты/ключ‑значение.
Дополнительные требования к содержанию
- Везде, где вы предлагаете изменение в продукте/письме/тексте, приводите точную формулировку CTA или микрокопии (1–2 предложения).
- Для каждой рекомендационной функции добавьте одну метрику для замера успеха и целевое значение (реалистичное, с учётом стадии компании).
- Указывайте приоритеты в порядке: impact (по метрике) / effort (low/medium/high).
Не добавляйте ничего сверх указанного формата. Если входные данные полные — не добавляйте предположений и не выводите блок "inputs_missing_or_assumptions" как заполненный.
