Как запустить новый продукт: от исследования до анализа после запуска (Post-launch Review)

До планирования большой кампании должны существовать хотя бы базовые evidence problem/solution fit: понятно, кто клиент, какая проблема достаточно важна, почему текущие alternatives неудовлетворительны и какой outcome продукт реально способен дать. Если эти ответы отсутствуют, маркетинговый launch лишь ускорит сбор дорогих негативных данных.

Соберите реальные ситуации, triggers, current workflows, alternatives, cost of inaction и decision roles. Интервьюируйте не только enthusiastic early adopters, но и отказавшихся или сомневающихся. Отделяйте stated preference от behavior и фиксируйте повторяющиеся patterns.

Определите primary segment, где problem intensity, urgency, ability to pay и route-to-market сходятся. Для B2B запишите buying committee и каждому участнику — job, risk и evidence need. Слишком широкий ICP делает launch message размытым и повышает acquisition cost.

Свяжите customer jobs, pains и gains с конкретным product mechanism. Value proposition должна объяснять outcome, а не список функций. Укажите proof: pilot result, benchmark, founder expertise, integration, proprietary data, case. Если доказательств пока мало, не маскируйте это маркетинговым языком — превратите gap в research plan.

До разработки всей launch infrastructure проверьте concept: problem framing, promise, package, proof, objections. Используйте interviews, smoke/fake-door tests, demo prototypes или pre-orders — в зависимости от риска и стоимости. Хороший concept test должен давать возможность отказаться от слабой идеи, а не только собирать подтверждение.

Определите value metric, package boundaries, trial/freemium policy, contract length, onboarding fee и discount authority. Тестируйте willingness to pay и choice trade-offs. Цена должна соответствовать GTM: enterprise sales не окупится при слишком низком ACV, а self-service product не выдержит сложный custom pricing.

Сформулируйте target, category, alternatives, unique value и proof. Затем соберите messaging house для 2–4 ключевых decision criteria. Сделайте message variants по buying roles, но сохраняйте единый core, чтобы рынок не получал пять разных объяснений одного продукта.

Не выбирайте motion по моде. Смотрите sales complexity, ACV, implementation effort, buyer risk, expected volume и доступ к customer. Для разных сегментов может потребоваться hybrid model.

Разделите launch на readiness streams: Product, Analytics, Marketing, Sales, CS/Support, Legal, Operations. Назначьте accountable owner, milestones, launch criteria и rollback/escalation. Используйте Launch Brief как source of truth и не полагайтесь на разрозненные чаты.

Для sales-led launch нужны one-pager, pitch deck, demo script, battlecard, case/proof, objection library, ROI/TCO при необходимости и ясные qualification rules. Проведите enablement session на реальных customer scenarios, а не презентацию features.

Разделите target audience на existing demand и market education. Выберите 2–4 канала, где есть fit с ICP и buying journey. Не пытайтесь быть везде в первый день. Лучше собрать learnable system с чистым tracking и понятной ролью каждого канала.

Маркетинговая победа заканчивается не signup. Определите first-value milestone, time-to-value, activation event и owner onboarding. Сравнивайте launch cohorts: если acquisition растёт, а activation и retention ухудшаются, масштабировать трафик рано.

Заранее разделите learning metrics и scale metrics. На раннем launch небольшая выборка может не позволять уверенно считать CAC/LTV, зато отлично показывает repeated objections и activation friction.

Через 2–6 недель проведите review: что подтвердилось, что нет, где biggest surprise, какие segments/use cases сильнее, какие assumptions требуют нового теста. Обновите positioning, onboarding, sales materials и roadmap. Не ждите квартала, если early evidence уже показывает фундаментальную проблему.

• Primary segment демонстрирует повторяемый спрос.
• Activation/time-to-value находится в приемлемом диапазоне.
• Sales/customer objections понятны и не указывают на fundamental mismatch.
• Unit economics или path to acceptable economics реалистичны.
• Tracking и definitions стабильны.
• Delivery/Support выдержит увеличение объёма.
• Есть хотя бы один repeatable acquisition or sales motion.

Назначьте одного launch owner, но не превращайте launch в задачу одного PMM. Product отвечает за readiness и value delivery, Marketing — за market narrative и demand, Sales — за opportunity conversion, CS/Support — за onboarding и feedback, Analytics — за measurement. RACI особенно полезен на зависимых milestones.

• Запускать «для всех».
• Начинать с PR до проверки problem/value.
• Считать launch успехом по impressions.
• Не готовить onboarding и support.
• Путать early adopter enthusiasm с PMF.
• Делать десятки channels одновременно.
• Не фиксировать assumptions и launch criteria.

B2B SaaS запускает модуль forecasting. Первоначальный message — «AI-прогноз продаж». Discovery показывает, что CFO волнует не AI, а позднее обнаружение pipeline risk. Positioning меняется на «видеть риск выполнения плана до конца месяца», demo строится вокруг конкретного forecast workflow, а launch KPI — не количество demo, а доля opportunities, где economic buyer подтверждает этот use case. Это делает launch learnable и коммерчески осмысленным.

• Поиск Product-Market Fit
• Годовая маркетинговая стратегия

• Product Launch Brief
• Positioning Brief
• Demo Script
• Measurement Plan

• JTBD
• Value Proposition Canvas
• STP

• Product Launch
• Go-to-Market
• Pricing Strategy
• Activation

Не каждый релиз требует одинакового GTM. Разделите launches на tiers: крупный стратегический запуск с новым segment/category; средний запуск, меняющий use case или package; малый feature release. Для каждого tier заранее задайте необходимый уровень research, enablement, content, PR, analytics и executive involvement. Это снижает перегрузку команды и помогает вкладывать усилия пропорционально business impact.

Заранее определите kill criteria: например, критично низкая activation после исправления onboarding, отсутствие willingness to pay, невозможность выполнить security requirements ключевого сегмента или economics, которые не сходятся даже в realistic scale scenario. Остановка слабой гипотезы — нормальный outcome launch learning, а не провал команды.