Ручной анализ 200 ревью занимает 2-3 недели, и к моменту завершения приоритеты уже сменились. Поэтому большая часть пользовательских отзывов никогда не становятся product decisions.
Есть способ пройти путь от сырых отзывов до конкретных Jobs-to-be-Done за 2 часа. Четыре шага, на каждом работает LLM.
Шаг 1 - извлечение сигналов. Не sentiment analysis и не классификация. Из каждого отзыва извлекается структура: что человек пытался сделать, что пошло не так, какой результат ожидал. Формат - JSON с полями situation, intent, outcome_expected, outcome_actual, emotion, signal_strength. 200 отзывов разбиваются на батчи по 20, обрабатываются за 5-7 минут.
Шаг 2 - кластеризация. Два подхода. Для датасетов до 200 записей достаточно LLM-кластеризации: передать все сигналы и попросить сгруппировать по смыслу intent + situation. Для больших объёмов - embeddings через sentence-transformers и HDBSCAN. Алгоритм сам определяет количество кластеров и выделяет шум. Типичный результат для 200 записей: 8-15 кластеров, 10-20% шума.
Шаг 3 - формулировка JTBD. Каждый кластер содержит повторяющийся паттерн. LLM преобразует его в формулу: "Когда [ситуация], я хочу [действие], чтобы [результат]." Принципиальный момент - JTBD описывает job, не фичу. "Хочу оффлайн-режим" - это фича. "Хочу не зависеть от связи и следовать плану в поездке" - это job. Второе открывает пространство решений: оффлайн-карты, предзагрузка, SMS-fallback, печатная версия.
Шаг 4 - валидация. Три проверки. Обратная трассировка: каждый JTBD должен прослеживаться минимум до 5 конкретных отзывов, иначе это может быть галлюцинация модели. Тест на overlap: два JTBD не должны описывать один job разными словами (порог - 0.6). Тест на actionability: можно ли за 2 недели сделать минимальное решение для этого job.
Ключевое отличие от ручного процесса - воспроизводимость. Три прогона одного датасета с temperature 0.3 дают 85-90% совпадения JTBD. Два аналитика, работающие вручную - 40-60%.
Несколько ловушек. Анализ без контекста продукта - модель генерирует JTBD для фич, которые уже существуют. Игнорирование позитивных отзывов - пятизвёздочные ревью содержат JTBD, которые продукт уже закрывает, это валидация стратегии. Кластеризация по словам вместо смысла - "карта тормозит" и "маршрут не загружается оффлайн" выглядят по-разному, но это один кластер (доступ к маршруту).
Стоимость полного цикла: $3-6 за 200 отзывов. День работы product-аналитика - $300-500.
Минимальный стек: один LLM API, Python-скрипт для батчинга, Google Sheets для результата.
Подробный гайд с промптами и примерами в блоге: https://futurecraft.pro/ru/blog/jtbd-ai-research/
Есть способ пройти путь от сырых отзывов до конкретных Jobs-to-be-Done за 2 часа. Четыре шага, на каждом работает LLM.
Шаг 1 - извлечение сигналов. Не sentiment analysis и не классификация. Из каждого отзыва извлекается структура: что человек пытался сделать, что пошло не так, какой результат ожидал. Формат - JSON с полями situation, intent, outcome_expected, outcome_actual, emotion, signal_strength. 200 отзывов разбиваются на батчи по 20, обрабатываются за 5-7 минут.
Шаг 2 - кластеризация. Два подхода. Для датасетов до 200 записей достаточно LLM-кластеризации: передать все сигналы и попросить сгруппировать по смыслу intent + situation. Для больших объёмов - embeddings через sentence-transformers и HDBSCAN. Алгоритм сам определяет количество кластеров и выделяет шум. Типичный результат для 200 записей: 8-15 кластеров, 10-20% шума.
Шаг 3 - формулировка JTBD. Каждый кластер содержит повторяющийся паттерн. LLM преобразует его в формулу: "Когда [ситуация], я хочу [действие], чтобы [результат]." Принципиальный момент - JTBD описывает job, не фичу. "Хочу оффлайн-режим" - это фича. "Хочу не зависеть от связи и следовать плану в поездке" - это job. Второе открывает пространство решений: оффлайн-карты, предзагрузка, SMS-fallback, печатная версия.
Шаг 4 - валидация. Три проверки. Обратная трассировка: каждый JTBD должен прослеживаться минимум до 5 конкретных отзывов, иначе это может быть галлюцинация модели. Тест на overlap: два JTBD не должны описывать один job разными словами (порог - 0.6). Тест на actionability: можно ли за 2 недели сделать минимальное решение для этого job.
Ключевое отличие от ручного процесса - воспроизводимость. Три прогона одного датасета с temperature 0.3 дают 85-90% совпадения JTBD. Два аналитика, работающие вручную - 40-60%.
Несколько ловушек. Анализ без контекста продукта - модель генерирует JTBD для фич, которые уже существуют. Игнорирование позитивных отзывов - пятизвёздочные ревью содержат JTBD, которые продукт уже закрывает, это валидация стратегии. Кластеризация по словам вместо смысла - "карта тормозит" и "маршрут не загружается оффлайн" выглядят по-разному, но это один кластер (доступ к маршруту).
Стоимость полного цикла: $3-6 за 200 отзывов. День работы product-аналитика - $300-500.
Минимальный стек: один LLM API, Python-скрипт для батчинга, Google Sheets для результата.
Подробный гайд с промптами и примерами в блоге: https://futurecraft.pro/ru/blog/jtbd-ai-research/
futurecraft.pro
200 отзывов → 5 JTBD за 2 часа: AI-синтез user research — futurecraft.pro
Пошаговый процесс извлечения Jobs-to-be-Done из пользовательских отзывов с помощью LLM. Промпты для анализа, кластеризация, примеры output и готовый workflow.
Pitch deck - не набор слайдов, а инструмент продажи с драматической аркой. Большинство фаундеров этого не понимают и теряют инвестора на второй минуте.
DocSend проанализировал 200 000+ сессий: среднее время на один pitch deck - 3 минуты 44 секунды. 72% этого времени уходит на три слайда: финансы, команда, продукт. Остальные семь слайдов делят между собой меньше минуты. Задача нарратива - протащить инвестора через эти семь слайдов до финансов, не потеряв его внимание.
Каталог vs. история. Типичный подход: шаблон на 10 слайдов, каждый забит фактами. Результат - каталог. Инвестор видит 20-30 таких в неделю. Нарратив работает иначе: каждый слайд создаёт эмоциональный переход. Problem строит напряжение. Solution снимает его. Traction доказывает, что снятие уже происходит. Ask превращает историю в конкретное предложение.
Три правила, которые держат нарратив.
Первое - один тезис на слайд. Два аргумента на одном слайде означают, что один из них теряется. Инвестор тратит 20-25 секунд на слайд. За это время он усвоит одну мысль, не две.
Второе - каузальная связь между слайдами. Каждый следующий слайд отвечает на вопрос, который возник на предыдущем. Problem вызывает "Как это решить?". Solution вызывает "Это работает?". Product вызывает "Какой рынок?". Если связь рвётся, инвестор начинает листать вперёд.
Третье - эскалация ставок. От "проблема существует" к "проблема стоит $ X млрд" к "мы решаем её прямо сейчас с трекшеном Y". Каждый слайд повышает ставки, не повторяет предыдущий.
Структура следует драматической арке. Экспозиция (Cover + Problem), кульминация (Solution + Product + Market), доказательная база (Business Model + Traction + Competition), развязка (Team + Ask). Порядок не случаен - Problem до Solution всегда, без исключений. Если инвестор не почувствовал боль, решение ему безразлично.
Где чаще всего ломается нарратив. Пять точек разрыва. Market без связи с Problem - описали боль SMB, а TAM считают по enterprise. Traction без контекста - "10 000 пользователей" ничего не значит, "10 000 за 3 месяца без платного маркетинга" значит многое. Ask без обоснования - "$5M на рост" не объясняет ничего, разбивка по направлениям с привязкой к метрикам объясняет всё. Competition через принижение - инвестор знает конкурентов лично, признайте их силу. Начало с решения - инвестор ещё не понимает, зачем ему это.
Адаптация под стадию. Angel-инвестору усиливайте Team и Problem, минимизируйте Market. Seed-фонду - Traction и Market. Series A - Business Model и unit economics. Ядро нарратива одно, акценты разные.
Практический подход. Не пытайтесь собрать весь deck за раз. Начните с Problem-слайда. Если описание проблемы заставляет кивать, продолжайте. Если нет - уточняйте входные данные. Problem - фундамент, на котором стоят остальные девять слайдов.
Подробный гайд с промптами для каждого слайда в блоге: https://futurecraft.pro/ru/blog/pitch-deck-narrative-ai/
DocSend проанализировал 200 000+ сессий: среднее время на один pitch deck - 3 минуты 44 секунды. 72% этого времени уходит на три слайда: финансы, команда, продукт. Остальные семь слайдов делят между собой меньше минуты. Задача нарратива - протащить инвестора через эти семь слайдов до финансов, не потеряв его внимание.
Каталог vs. история. Типичный подход: шаблон на 10 слайдов, каждый забит фактами. Результат - каталог. Инвестор видит 20-30 таких в неделю. Нарратив работает иначе: каждый слайд создаёт эмоциональный переход. Problem строит напряжение. Solution снимает его. Traction доказывает, что снятие уже происходит. Ask превращает историю в конкретное предложение.
Три правила, которые держат нарратив.
Первое - один тезис на слайд. Два аргумента на одном слайде означают, что один из них теряется. Инвестор тратит 20-25 секунд на слайд. За это время он усвоит одну мысль, не две.
Второе - каузальная связь между слайдами. Каждый следующий слайд отвечает на вопрос, который возник на предыдущем. Problem вызывает "Как это решить?". Solution вызывает "Это работает?". Product вызывает "Какой рынок?". Если связь рвётся, инвестор начинает листать вперёд.
Третье - эскалация ставок. От "проблема существует" к "проблема стоит $ X млрд" к "мы решаем её прямо сейчас с трекшеном Y". Каждый слайд повышает ставки, не повторяет предыдущий.
Структура следует драматической арке. Экспозиция (Cover + Problem), кульминация (Solution + Product + Market), доказательная база (Business Model + Traction + Competition), развязка (Team + Ask). Порядок не случаен - Problem до Solution всегда, без исключений. Если инвестор не почувствовал боль, решение ему безразлично.
Где чаще всего ломается нарратив. Пять точек разрыва. Market без связи с Problem - описали боль SMB, а TAM считают по enterprise. Traction без контекста - "10 000 пользователей" ничего не значит, "10 000 за 3 месяца без платного маркетинга" значит многое. Ask без обоснования - "$5M на рост" не объясняет ничего, разбивка по направлениям с привязкой к метрикам объясняет всё. Competition через принижение - инвестор знает конкурентов лично, признайте их силу. Начало с решения - инвестор ещё не понимает, зачем ему это.
Адаптация под стадию. Angel-инвестору усиливайте Team и Problem, минимизируйте Market. Seed-фонду - Traction и Market. Series A - Business Model и unit economics. Ядро нарратива одно, акценты разные.
Практический подход. Не пытайтесь собрать весь deck за раз. Начните с Problem-слайда. Если описание проблемы заставляет кивать, продолжайте. Если нет - уточняйте входные данные. Problem - фундамент, на котором стоят остальные девять слайдов.
Подробный гайд с промптами для каждого слайда в блоге: https://futurecraft.pro/ru/blog/pitch-deck-narrative-ai/
futurecraft.pro
Pitch Deck Narrative Arc: AI строит историю — futurecraft.pro
Нарратив для pitch deck: промпты для каждого слайда, логика переходов, примеры. Туториал с AI для подготовки презентации инвесторам.
AI генерирует посредственную рекламу не из-за ограничений модели, а из-за отсутствия структуры в промпте.
Запрос "напиши рекламный текст для курса по Excel" предсказуемо даёт список функций, пустые обещания и CTA "запишитесь сейчас". Модель заполняет пустоту средним по больнице. Фреймворк убирает эту пустоту — задаёт последовательность: какую эмоцию вызвать первой, когда вводить продукт, как подвести к действию.
Пять фреймворков покрывают 90% рекламных задач.
PAS (Problem - Agitate - Solution) - самый прямой. Три шага: назвать проблему, усилить боль, предложить решение. Работает для аудитории, которая уже осознаёт свою проблему. Формат: короткие объявления, посты, email-темы.
Пример разницы. Без фреймворка: "Наш курс включает 50+ уроков и сертификат. Запишитесь со скидкой 40%." С PAS: "Отчёт, который коллега собирает за 20 минут, у вас занимает полдня. За квартал - 130 часов на задачи, которые решаются тремя функциями. Курс закрывает этот разрыв за 6 недель." Первый описывает курс. Второй описывает ситуацию читателя.
AIDA (Attention - Interest - Desire - Action) - для холодной аудитории, которая пока не осознаёт проблему. Четыре фазы: факт, останавливающий скролл; контекст, почему это важно сейчас; результат через чужой кейс; одно действие. Подходит для лендингов, email-рассылок, описаний продуктов.
BAB (Before - After - Bridge) - фреймворк контраста. Текущая реальность, желаемая реальность, механизм перехода. Работает, когда нужно показать трансформацию. Ключевое правило: конкретные цифры в "Before" и "After", механизм вместо обещания в "Bridge".
FAB (Features - Advantages - Benefits) - технический фреймворк для B2B и продуктов, где характеристики решают. Переводит спецификации в преимущества, преимущества - в выгоды. Формат: таблица, не сплошной текст. Работает на этапе сравнения вариантов.
4U (Urgent - Unique - Ultra-specific - Useful) - для заголовков и коротких форматов. Четыре критерия: причина действовать сейчас, отличие от конкурентов, конкретные цифры, понятная выгода. Ограничение: 70 символов. "Бесплатный вебинар по таргету" превращается в "CPL 180 р вместо 500 р: воронка VK Ads для инфобизнеса (80 мест)".
Как выбирать. Аудитория знает проблему - PAS. Не осознаёт проблему - AIDA. Нужна трансформация - BAB. Техническое сравнение - FAB. Заголовок - 4U.
На практике фреймворки комбинируются. Заголовок по 4U, тело по PAS, лендинг по AIDA. AI справляется с составными промптами, если структура задана явно.
Три правила промпт-инженерии для рекламы:
1. Ограничения вместо свободы. "Напиши текст в 150 слов, без прилагательных в превосходной степени, с одной цифрой в каждом абзаце" - даёт текст, с которым можно работать.
2. Антипаттерны. Прямой запрет конкретных слов ("без
3. Итерация через критику. Сгенерировали текст - следующий промпт: "Оцени по конкретности, узнаваемости и действенности. Перепиши слабые части."
Типичные ошибки: генерация без описания аудитории (текст "для всех" = ни для кого), слишком много обещаний (ограничивайте: одно обещание, одно доказательство, одно действие), генерация 10 вариантов одним запросом (модель начинает повторяться - максимум 2-3 за раз, между запусками меняйте фреймворк).
Фреймворки не заменяют знание рынка. Идеально структурированный PAS провалится, если боль выбрана неверно. AI-тексты склонны быть гладкими, но безопасными - человеческая редактура нужна для остроты.
Подробный гайд с промптами и примерами в блоге: https://futurecraft.pro/ru/blog/ai-ad-copy-frameworks/
Запрос "напиши рекламный текст для курса по Excel" предсказуемо даёт список функций, пустые обещания и CTA "запишитесь сейчас". Модель заполняет пустоту средним по больнице. Фреймворк убирает эту пустоту — задаёт последовательность: какую эмоцию вызвать первой, когда вводить продукт, как подвести к действию.
Пять фреймворков покрывают 90% рекламных задач.
PAS (Problem - Agitate - Solution) - самый прямой. Три шага: назвать проблему, усилить боль, предложить решение. Работает для аудитории, которая уже осознаёт свою проблему. Формат: короткие объявления, посты, email-темы.
Пример разницы. Без фреймворка: "Наш курс включает 50+ уроков и сертификат. Запишитесь со скидкой 40%." С PAS: "Отчёт, который коллега собирает за 20 минут, у вас занимает полдня. За квартал - 130 часов на задачи, которые решаются тремя функциями. Курс закрывает этот разрыв за 6 недель." Первый описывает курс. Второй описывает ситуацию читателя.
AIDA (Attention - Interest - Desire - Action) - для холодной аудитории, которая пока не осознаёт проблему. Четыре фазы: факт, останавливающий скролл; контекст, почему это важно сейчас; результат через чужой кейс; одно действие. Подходит для лендингов, email-рассылок, описаний продуктов.
BAB (Before - After - Bridge) - фреймворк контраста. Текущая реальность, желаемая реальность, механизм перехода. Работает, когда нужно показать трансформацию. Ключевое правило: конкретные цифры в "Before" и "After", механизм вместо обещания в "Bridge".
FAB (Features - Advantages - Benefits) - технический фреймворк для B2B и продуктов, где характеристики решают. Переводит спецификации в преимущества, преимущества - в выгоды. Формат: таблица, не сплошной текст. Работает на этапе сравнения вариантов.
4U (Urgent - Unique - Ultra-specific - Useful) - для заголовков и коротких форматов. Четыре критерия: причина действовать сейчас, отличие от конкурентов, конкретные цифры, понятная выгода. Ограничение: 70 символов. "Бесплатный вебинар по таргету" превращается в "CPL 180 р вместо 500 р: воронка VK Ads для инфобизнеса (80 мест)".
Как выбирать. Аудитория знает проблему - PAS. Не осознаёт проблему - AIDA. Нужна трансформация - BAB. Техническое сравнение - FAB. Заголовок - 4U.
На практике фреймворки комбинируются. Заголовок по 4U, тело по PAS, лендинг по AIDA. AI справляется с составными промптами, если структура задана явно.
Три правила промпт-инженерии для рекламы:
1. Ограничения вместо свободы. "Напиши текст в 150 слов, без прилагательных в превосходной степени, с одной цифрой в каждом абзаце" - даёт текст, с которым можно работать.
2. Антипаттерны. Прямой запрет конкретных слов ("без
уникальный, инновационный, `лучший на рынке`") убирает маркетинговый шум эффективнее позитивных инструкций.3. Итерация через критику. Сгенерировали текст - следующий промпт: "Оцени по конкретности, узнаваемости и действенности. Перепиши слабые части."
Типичные ошибки: генерация без описания аудитории (текст "для всех" = ни для кого), слишком много обещаний (ограничивайте: одно обещание, одно доказательство, одно действие), генерация 10 вариантов одним запросом (модель начинает повторяться - максимум 2-3 за раз, между запусками меняйте фреймворк).
Фреймворки не заменяют знание рынка. Идеально структурированный PAS провалится, если боль выбрана неверно. AI-тексты склонны быть гладкими, но безопасными - человеческая редактура нужна для остроты.
Подробный гайд с промптами и примерами в блоге: https://futurecraft.pro/ru/blog/ai-ad-copy-frameworks/
futurecraft.pro
AI-копирайтинг для рекламы: 5 фреймворков с промптами — futurecraft.pro
Генерация конверсионных рекламных текстов с AI: фреймворки PAS, AIDA, BAB, FAB и 4U с готовыми промптами и примерами до/после.
SDR тратит 60-70% времени на лиды, которые никогда не закроются. Не потому что плохой продавец - потому что нет задокументированного ICP.
68% B2B-компаний работают без формального Ideal Customer Profile. Классический подход - воркшопы, опросы клиентов, профиль на доске - занимает 2-4 недели и выдаёт субъективное мнение, а не данные. AI сжимает процесс до 2-3 дней.
Три уровня данных, которые нужны для анализа:
1. CRM-данные - закрытые сделки (won/lost), активные клиенты с NPS и retention, churned с причинами ухода
2. Внешние источники - LinkedIn Sales Navigator, G2/Capterra reviews конкурентов, вакансии компаний (нанимают на роли, связанные с вашей проблемой - значит, проблема реальна)
3. Контекст продукта - 3-5 предложений о продукте, ценовой диапазон, ключевое отличие от альтернатив
Без третьего пункта AI выдаст generic-профиль из учебника по маркетингу.
Pipeline от данных до ICP:
- Загрузить CRM-выгрузку в LLM, найти паттерны: топ-3 индустрии по win rate, оптимальный размер, корреляция источника лида и конверсии
- Сгенерировать 2-3 ICP-гипотезы - не один профиль, а три варианта с firmographics, trigger events, buying signals и disqualifiers
- Зафиксировать каждый ICP в одностраничную карточку: единый формат для SDR, маркетинга и продукта
Scoring-модель - must-have (40% веса), should-have (35%), nice-to-have (25%). Каждый входящий лид получает числовой score: 80-100 - приоритет, 60-79 - стандарт, ниже 40 - дисквалификация. В автоматическом режиме: лид попадает в CRM, обогащается через Clay/Clearbit, данные уходят в LLM, score записывается обратно.
Negative ICP экономит больше ресурсов, чем позитивный. Определить, кому не продавать: компании с win rate ниже 10%, клиенты с churn до 6 месяцев, сделки с циклом вдвое длиннее среднего. Hard disqualifiers - автоматический фильтр в CRM, лид не попадает в pipeline.
Валидация обязательна. AI-сгенерированный ICP - гипотеза. Минимальные пороги для подтверждения: coverage > 40% (ICP покрывает существенную часть won-сделок), win rate для ICP-match > 1.5x от non-match, retention > 1.2x. Если не проходит - сужайте или расширяйте критерии.
Чего не делать: один раз определили ICP и забыли. Пересматривайте минимум раз в квартал. Триггеры для внеплановой ревизии - win rate упал на 15%+, новый продукт открывает сегмент, конкурент зашёл в ваш ICP-сегмент, churn растёт в конкретной нише.
Подробный гайд с промптами и шаблонами в блоге: https://futurecraft.pro/ru/blog/icp-definition-ai/
68% B2B-компаний работают без формального Ideal Customer Profile. Классический подход - воркшопы, опросы клиентов, профиль на доске - занимает 2-4 недели и выдаёт субъективное мнение, а не данные. AI сжимает процесс до 2-3 дней.
Три уровня данных, которые нужны для анализа:
1. CRM-данные - закрытые сделки (won/lost), активные клиенты с NPS и retention, churned с причинами ухода
2. Внешние источники - LinkedIn Sales Navigator, G2/Capterra reviews конкурентов, вакансии компаний (нанимают на роли, связанные с вашей проблемой - значит, проблема реальна)
3. Контекст продукта - 3-5 предложений о продукте, ценовой диапазон, ключевое отличие от альтернатив
Без третьего пункта AI выдаст generic-профиль из учебника по маркетингу.
Pipeline от данных до ICP:
- Загрузить CRM-выгрузку в LLM, найти паттерны: топ-3 индустрии по win rate, оптимальный размер, корреляция источника лида и конверсии
- Сгенерировать 2-3 ICP-гипотезы - не один профиль, а три варианта с firmographics, trigger events, buying signals и disqualifiers
- Зафиксировать каждый ICP в одностраничную карточку: единый формат для SDR, маркетинга и продукта
Scoring-модель - must-have (40% веса), should-have (35%), nice-to-have (25%). Каждый входящий лид получает числовой score: 80-100 - приоритет, 60-79 - стандарт, ниже 40 - дисквалификация. В автоматическом режиме: лид попадает в CRM, обогащается через Clay/Clearbit, данные уходят в LLM, score записывается обратно.
Negative ICP экономит больше ресурсов, чем позитивный. Определить, кому не продавать: компании с win rate ниже 10%, клиенты с churn до 6 месяцев, сделки с циклом вдвое длиннее среднего. Hard disqualifiers - автоматический фильтр в CRM, лид не попадает в pipeline.
Валидация обязательна. AI-сгенерированный ICP - гипотеза. Минимальные пороги для подтверждения: coverage > 40% (ICP покрывает существенную часть won-сделок), win rate для ICP-match > 1.5x от non-match, retention > 1.2x. Если не проходит - сужайте или расширяйте критерии.
Чего не делать: один раз определили ICP и забыли. Пересматривайте минимум раз в квартал. Триггеры для внеплановой ревизии - win rate упал на 15%+, новый продукт открывает сегмент, конкурент зашёл в ваш ICP-сегмент, churn растёт в конкретной нише.
Подробный гайд с промптами и шаблонами в блоге: https://futurecraft.pro/ru/blog/icp-definition-ai/
futurecraft.pro
ICP Definition с AI: точный портрет клиента вместо продаж всем подряд — futurecraft.pro
Как определить Ideal Customer Profile с помощью AI: промпты для анализа, шаблоны ICP-карточек, scoring-модели и пошаговый pipeline от данных до сегментов.
Из 1 000 триальных пользователей SaaS платят 30-50. Остальные уходят молча. Стандартная коммуникация за 14 дней триала - welcome-письмо и напоминание об окончании. Между ними - 12 дней тишины.
Проблема не в продукте. Проблема в отсутствии системы, которая проводит пользователя от первого входа до решения о покупке. Drip-цепочка из 7 писем закрывает этот разрыв.
Архитектура цепочки привязана к реальным данным по воронке. Дни 0-3 - пик активности (40-60% пользователей заходят повторно). День 4-7 - резкий провал до 20-30%. День 8-13 - только 10-15%. Каждое письмо бьёт в конкретный момент этой кривой:
Письмо 1 (день 0): Welcome + Quick Win. Задача - первый результат за 5 минут. Не обзор возможностей, не список фич. Одно конкретное действие. Целевой open rate - 70-80%. Если ниже 65% - проблема в теме письма.
Письмо 2 (день 1): Value Activation. Мост от quick win к ключевой функции. Превращает продукт из "интересной штуки" в инструмент для задачи.
Письмо 3 (день 3): Social Proof. Конкретный кейс с цифрами. Не "нам доверяют 10 000 компаний", а "[Компания] из [индустрии] увеличила [метрику] на [X]%". Если CRM хранит атрибут industry, LLM подбирает релевантный кейс автоматически.
Письмо 4 (день 5): Advanced Feature. Функция, которая создаёт switching cost. То, чего нет у конкурентов или что работает значительно лучше.
Письмо 5 (день 8): Objection Handling. FAQ из трёх вопросов. "Дорого", "сложно", "можно обойтись" - каждый ответ содержит факт или цифру. Ключевая метрика - не open rate, а reply rate. Цель: 3-5% ответов, каждый из которых - возможность для sales.
Письмо 6 (день 11): Urgency. Реальный дедлайн, не фальшивый. Триал заканчивается, данные могут быть потеряны. Без "не упустите" и "последний шанс" - факт и CTA.
Письмо 7 (день 13): Last Call. Максимум 80 слов. Никаких новых аргументов. Напоминание о результате + одна кнопка.
Персонализация через AI - главное преимущество. Один промпт с переменной {user_segment} создаёт три варианта каждого письма: для активных, пассивных и power users. Для каждого письма LLM генерирует 5-10 вариантов тем под A/B-тестирование. Вся генерация 7 писем x 3 сегмента x 10 вариантов тем обходится в $2-5.
Типичные ошибки, которые убивают конверсию: одинаковые письма для всех (минус 30-40% эффективности), более одного CTA на письмо (минус 20-30% конверсии по данным Campaign Monitor), письма длиннее 130 слов (вторую половину не читают), генерация без редактуры (AI-маркеры типа "В мире, где..." уничтожают доверие).
Реалистичная динамика: базовая коммуникация - 3% конверсии. Полная цепочка из 7 писем - 6-7%. Добавляем сегментацию - 8-9%. A/B тестирование тем и кейсы по индустрии - 10-12%.
Минимальный старт - три письма вместо семи: Welcome (день 0), Social Proof (день 5), Urgency + Last Call (день 12). Занимает 2-3 часа, поднимает конверсию до 5-7%.
Подробный гайд с шаблонами всех 7 писем - в блоге: https://futurecraft.pro/ru/blog/email-drip-sequence-ai/
Проблема не в продукте. Проблема в отсутствии системы, которая проводит пользователя от первого входа до решения о покупке. Drip-цепочка из 7 писем закрывает этот разрыв.
Архитектура цепочки привязана к реальным данным по воронке. Дни 0-3 - пик активности (40-60% пользователей заходят повторно). День 4-7 - резкий провал до 20-30%. День 8-13 - только 10-15%. Каждое письмо бьёт в конкретный момент этой кривой:
Письмо 1 (день 0): Welcome + Quick Win. Задача - первый результат за 5 минут. Не обзор возможностей, не список фич. Одно конкретное действие. Целевой open rate - 70-80%. Если ниже 65% - проблема в теме письма.
Письмо 2 (день 1): Value Activation. Мост от quick win к ключевой функции. Превращает продукт из "интересной штуки" в инструмент для задачи.
Письмо 3 (день 3): Social Proof. Конкретный кейс с цифрами. Не "нам доверяют 10 000 компаний", а "[Компания] из [индустрии] увеличила [метрику] на [X]%". Если CRM хранит атрибут industry, LLM подбирает релевантный кейс автоматически.
Письмо 4 (день 5): Advanced Feature. Функция, которая создаёт switching cost. То, чего нет у конкурентов или что работает значительно лучше.
Письмо 5 (день 8): Objection Handling. FAQ из трёх вопросов. "Дорого", "сложно", "можно обойтись" - каждый ответ содержит факт или цифру. Ключевая метрика - не open rate, а reply rate. Цель: 3-5% ответов, каждый из которых - возможность для sales.
Письмо 6 (день 11): Urgency. Реальный дедлайн, не фальшивый. Триал заканчивается, данные могут быть потеряны. Без "не упустите" и "последний шанс" - факт и CTA.
Письмо 7 (день 13): Last Call. Максимум 80 слов. Никаких новых аргументов. Напоминание о результате + одна кнопка.
Персонализация через AI - главное преимущество. Один промпт с переменной {user_segment} создаёт три варианта каждого письма: для активных, пассивных и power users. Для каждого письма LLM генерирует 5-10 вариантов тем под A/B-тестирование. Вся генерация 7 писем x 3 сегмента x 10 вариантов тем обходится в $2-5.
Типичные ошибки, которые убивают конверсию: одинаковые письма для всех (минус 30-40% эффективности), более одного CTA на письмо (минус 20-30% конверсии по данным Campaign Monitor), письма длиннее 130 слов (вторую половину не читают), генерация без редактуры (AI-маркеры типа "В мире, где..." уничтожают доверие).
Реалистичная динамика: базовая коммуникация - 3% конверсии. Полная цепочка из 7 писем - 6-7%. Добавляем сегментацию - 8-9%. A/B тестирование тем и кейсы по индустрии - 10-12%.
Минимальный старт - три письма вместо семи: Welcome (день 0), Social Proof (день 5), Urgency + Last Call (день 12). Занимает 2-3 часа, поднимает конверсию до 5-7%.
Подробный гайд с шаблонами всех 7 писем - в блоге: https://futurecraft.pro/ru/blog/email-drip-sequence-ai/
futurecraft.pro
Email Drip Sequence с AI: 7 писем от trial до paid — futurecraft.pro
AI-генерируемая drip-цепочка из 7 писем для SaaS trial-to-paid конверсии. Промпты, тайминг, шаблоны и метрики каждого письма.
👍1
82% стартапов умирают из-за кассовых разрывов, а не из-за плохого продукта. При этом большинство фаундеров смотрят на месячный P&L и думают, что контролируют финансы.
Месячный отчёт скрывает реальную картину. Выручка приходит 28-го, зарплаты уходят 5-го. На бумаге всё отлично. На счёте - две недели в минусе. Недельная гранулярность это показывает. Месячная - нет.
13 недель - один финансовый квартал. Достаточно короткий горизонт для точного прогноза, достаточно длинный для принятия решений. Проблемы видны за 4-8 недель до того, как станут критическими.
Структура таблицы - три блока:
Поступления - оплата по контрактам, новые продажи (взвешенные по вероятности из воронки), возвраты НДС, гранты, инвестиции. Ключевое: не выручка по начислению, а именно деньги на счёте.
Выплаты - зарплаты, аренда, подписки, маркетинг, подрядчики, налоги. Разделение на фиксированные и управляемые обязательно — при кассовом разрыве режутся только управляемые.
Итог - чистый cash flow за неделю + остаток на начало = остаток на конец. Каскадный пересчёт: изменение в любой неделе пересчитывает все последующие.
Cash Floor - минимальный допустимый остаток. Консервативный подход: 4 недели фиксированных расходов. Для стартапа с $20K/неделю фиксированных - это $80K. Любая неделя с прогнозом ниже этой суммы подсвечивается красным.
Новые продажи прогнозируются через воронку. Каждая сделка взвешивается по вероятности закрытия на текущем этапе. $10K на этапе переговоров (40%) = $4K в прогнозе. $15K на квалификации (15%) = $2.25K. Без взвешивания прогноз систематически завышает поступления.
Сценарный анализ - обязательная часть. Три сценария: base (текущие тренды), optimistic (конверсия x1.2, churn x0.8), pessimistic (конверсия x0.6, два крупных клиента задерживают на 4 недели, один уходит). Pessimistic отвечает на вопрос: сколько недель компания проживёт при худшем раскладе. Если меньше 8 - действовать надо сейчас.
Самый ценный артефакт - накопленные отклонения факт/план. Через 8-10 недель еженедельных обновлений видно, где прогноз систематически ошибается: завышаются ли поступления, недооцениваются ли расходы конкретной категории, какие строки наименее предсказуемы. Это данные, которые невозможно получить из P&L.
Связь с unit economics. LTV/CAC = 3.0 - отличный показатель. Но если Payback Period = 14 месяцев и компания агрессивно привлекает клиентов, расходы на CAC идут сегодня, а возврат - через год. Cash flow forecast покажет, хватит ли денег дожить до этого момента.
Типичные ошибки: считать pipeline по номиналу ($500K в воронке — не $500K на счёте), забывать про разовые расходы (ежегодные лицензии, бонусы), не обновлять прогноз еженедельно, игнорировать сезонность B2B-продаж.
Первая версия не должна быть идеальной. Открыть Google Sheets, 14 столбцов, текущий баланс, фиксированные расходы на 13 недель. 30 минут - и уже виден burn rate.
Подробный гайд с шаблоном и промптами в блоге: https://futurecraft.pro/ru/blog/cash-flow-forecast-13-week/
Месячный отчёт скрывает реальную картину. Выручка приходит 28-го, зарплаты уходят 5-го. На бумаге всё отлично. На счёте - две недели в минусе. Недельная гранулярность это показывает. Месячная - нет.
13 недель - один финансовый квартал. Достаточно короткий горизонт для точного прогноза, достаточно длинный для принятия решений. Проблемы видны за 4-8 недель до того, как станут критическими.
Структура таблицы - три блока:
Поступления - оплата по контрактам, новые продажи (взвешенные по вероятности из воронки), возвраты НДС, гранты, инвестиции. Ключевое: не выручка по начислению, а именно деньги на счёте.
Выплаты - зарплаты, аренда, подписки, маркетинг, подрядчики, налоги. Разделение на фиксированные и управляемые обязательно — при кассовом разрыве режутся только управляемые.
Итог - чистый cash flow за неделю + остаток на начало = остаток на конец. Каскадный пересчёт: изменение в любой неделе пересчитывает все последующие.
Cash Floor - минимальный допустимый остаток. Консервативный подход: 4 недели фиксированных расходов. Для стартапа с $20K/неделю фиксированных - это $80K. Любая неделя с прогнозом ниже этой суммы подсвечивается красным.
Новые продажи прогнозируются через воронку. Каждая сделка взвешивается по вероятности закрытия на текущем этапе. $10K на этапе переговоров (40%) = $4K в прогнозе. $15K на квалификации (15%) = $2.25K. Без взвешивания прогноз систематически завышает поступления.
Сценарный анализ - обязательная часть. Три сценария: base (текущие тренды), optimistic (конверсия x1.2, churn x0.8), pessimistic (конверсия x0.6, два крупных клиента задерживают на 4 недели, один уходит). Pessimistic отвечает на вопрос: сколько недель компания проживёт при худшем раскладе. Если меньше 8 - действовать надо сейчас.
Самый ценный артефакт - накопленные отклонения факт/план. Через 8-10 недель еженедельных обновлений видно, где прогноз систематически ошибается: завышаются ли поступления, недооцениваются ли расходы конкретной категории, какие строки наименее предсказуемы. Это данные, которые невозможно получить из P&L.
Связь с unit economics. LTV/CAC = 3.0 - отличный показатель. Но если Payback Period = 14 месяцев и компания агрессивно привлекает клиентов, расходы на CAC идут сегодня, а возврат - через год. Cash flow forecast покажет, хватит ли денег дожить до этого момента.
Типичные ошибки: считать pipeline по номиналу ($500K в воронке — не $500K на счёте), забывать про разовые расходы (ежегодные лицензии, бонусы), не обновлять прогноз еженедельно, игнорировать сезонность B2B-продаж.
Первая версия не должна быть идеальной. Открыть Google Sheets, 14 столбцов, текущий баланс, фиксированные расходы на 13 недель. 30 минут - и уже виден burn rate.
Подробный гайд с шаблоном и промптами в блоге: https://futurecraft.pro/ru/blog/cash-flow-forecast-13-week/
futurecraft.pro
Cash Flow Forecast на 13 недель: шаблон и формулы — futurecraft.pro
Как построить 13-недельный прогноз cash flow: структура таблицы, формулы, сценарный анализ и AI-промпты для автоматизации.
Три раунда по 20% dilution дают не 60% размытия, а 48.8%. Каждый следующий раунд размывает уже уменьшенную долю, и эта математика работает против основателей сильнее, чем кажется.
Типичный сценарий: 50% превращаются в 20%
Два сооснователя, 50/50. Три раунда: Pre-Seed ($500K при оценке $2M), Seed ($2M при $8M), Series A ($8M при $30M). Результат - каждый основатель владеет ~20.3% вместо начальных 50%. Суммарное размытие - 59.4%.
Это не плохие условия. Это стандартная математика привлечения капитала.
Формула кумулятивного размытия
Где d1, d2, d3 - dilution каждого раунда. Dilution раунда = сумма инвестиции / post-money valuation.
Option pool shuffle - скрытый усилитель dilution
Инвесторы требуют создать option pool до раунда. Pool создаётся из pre-money, размывая только существующих акционеров. При pre-money $8M и требовании pool 15% - эффективная pre-money для основателей около $6.8M. Формально оценка $8M, фактически основатели продают акции дешевле.
На Pre-Seed pool 10% стоил каждому фаундеру ~5 п.п. На Seed увеличение pool до 15% добавило ещё ~3 п.п. сверх dilution от самой инвестиции.
SAFE-ноты: невидимое размытие
SAFE и convertible notes не отображаются в cap table до конвертации. Но при следующем раунде они конвертируются и добавляют dilution поверх прямой инвестиции. $300K в SAFE с низким valuation cap ($3M) может стоить основателям 5-8% дополнительного размытия, которого не было видно на момент подписания.
Ключевые переменные: valuation cap и discount rate. Cap $3M при Seed с pre-money $8M означает, что SAFE-держатель получает акции по цене в 2.7 раза ниже, чем Seed-инвестор.
Liquidation preferences - cap table врёт на exit
Владея 20% компании, основатель может получить значительно меньше 20% при exit. 1x participating preference: инвестор забирает вложенное, потом ещё и участвует в разделе остатка. При скромном exit ($15-20M при $38M post-money) основатели получают непропорционально мало.
Как моделировать: 4 промпта
1. Базовая модель - cap table на 3 раунда с option pool и dilution по каждому акционеру
2. Сценарный анализ - три варианта Series A (консервативный / базовый / оптимистичный), сравнение dilution
3. SAFE-конвертация - как конвертируемые инструменты влияют на cap table при Seed
4. Sensitivity по option pool - разница между 10%, 15%, 20%, 25% pool перед Series A
AI справляется с арифметикой, но делает ошибки в многоступенчатых расчётах. Три проверки: сумма долей = 100% после каждого раунда, доля инвестора = инвестиция / post-money, price per share одинакова для всех участников раунда.
Когда моделировать: до переговоров, не после. Разница между pool 10% и 20% на Series A - это 5+ п.п. dilution для каждого основателя. Это видно только в модели.
Подробный гайд с формулами и промптами в блоге: https://futurecraft.pro/ru/blog/cap-table-modeling-ai/
Типичный сценарий: 50% превращаются в 20%
Два сооснователя, 50/50. Три раунда: Pre-Seed ($500K при оценке $2M), Seed ($2M при $8M), Series A ($8M при $30M). Результат - каждый основатель владеет ~20.3% вместо начальных 50%. Суммарное размытие - 59.4%.
Это не плохие условия. Это стандартная математика привлечения капитала.
Формула кумулятивного размытия
Итоговая доля = Начальная доля x (1 - d1) x (1 - d2) x (1 - d3)
Где d1, d2, d3 - dilution каждого раунда. Dilution раунда = сумма инвестиции / post-money valuation.
Option pool shuffle - скрытый усилитель dilution
Инвесторы требуют создать option pool до раунда. Pool создаётся из pre-money, размывая только существующих акционеров. При pre-money $8M и требовании pool 15% - эффективная pre-money для основателей около $6.8M. Формально оценка $8M, фактически основатели продают акции дешевле.
На Pre-Seed pool 10% стоил каждому фаундеру ~5 п.п. На Seed увеличение pool до 15% добавило ещё ~3 п.п. сверх dilution от самой инвестиции.
SAFE-ноты: невидимое размытие
SAFE и convertible notes не отображаются в cap table до конвертации. Но при следующем раунде они конвертируются и добавляют dilution поверх прямой инвестиции. $300K в SAFE с низким valuation cap ($3M) может стоить основателям 5-8% дополнительного размытия, которого не было видно на момент подписания.
Ключевые переменные: valuation cap и discount rate. Cap $3M при Seed с pre-money $8M означает, что SAFE-держатель получает акции по цене в 2.7 раза ниже, чем Seed-инвестор.
Liquidation preferences - cap table врёт на exit
Владея 20% компании, основатель может получить значительно меньше 20% при exit. 1x participating preference: инвестор забирает вложенное, потом ещё и участвует в разделе остатка. При скромном exit ($15-20M при $38M post-money) основатели получают непропорционально мало.
Как моделировать: 4 промпта
1. Базовая модель - cap table на 3 раунда с option pool и dilution по каждому акционеру
2. Сценарный анализ - три варианта Series A (консервативный / базовый / оптимистичный), сравнение dilution
3. SAFE-конвертация - как конвертируемые инструменты влияют на cap table при Seed
4. Sensitivity по option pool - разница между 10%, 15%, 20%, 25% pool перед Series A
AI справляется с арифметикой, но делает ошибки в многоступенчатых расчётах. Три проверки: сумма долей = 100% после каждого раунда, доля инвестора = инвестиция / post-money, price per share одинакова для всех участников раунда.
Когда моделировать: до переговоров, не после. Разница между pool 10% и 20% на Series A - это 5+ п.п. dilution для каждого основателя. Это видно только в модели.
Подробный гайд с формулами и промптами в блоге: https://futurecraft.pro/ru/blog/cap-table-modeling-ai/
futurecraft.pro
Cap Table Modeling: AI-симуляция 3 раундов и реальная dilution — futurecraft.pro
Моделирование cap table с AI: формулы dilution, расчёт Pre-Seed — Series A, промпты для симуляции и анализ размытия долей.
Test-Driven Development (TDD) с AI работает не потому, что AI пишет тесты быстрее, а потому что он снимает главный барьер: необходимость продумать API модуля до написания первой строки кода.
Классическая проблема TDD - цикл Red-Green-Refactor ломается на первом шаге. Чтобы написать тест, нужно определить интерфейс. Чтобы определить интерфейс, нужно понять архитектуру. Чтобы понять архитектуру, нужно мысленно написать реализацию. Круг замкнулся. Разработчик переключается на код "чтобы быстро проверить идею" и к test-first больше не возвращается.
AI разрывает этот круг. Описываешь модуль в промпте: вход, выход, edge cases. Claude генерирует полноценный тестовый файл. Все тесты падают - модуля ещё нет. Это нормально, Red phase завершена. Тестовый файл уже стал спецификацией: входной тип, выходная структура, поведение на граничных случаях.
Два отдельных промпта - обязательно. "Напиши функцию и тесты к ней" - это code-first с иллюзией test-first. AI сгенерирует реализацию и подгонит тесты под неё. Тесты будут проверять то, что код делает, а не то, что код должен делать. Разница становится критичной при рефакторинге.
Правильный workflow - четыре шага. Первый: промпт на тесты с описанием модуля, входных данных и edge cases. Явно указать "не пиши реализацию". Второй: отдельный промпт на минимальную реализацию, которая проходит все тесты. Третий: рефакторинг под защитой тестов. Четвёртый: новые требования - новые тесты, цикл повторяется.
Паттерны, которые работают. Один тест = одно поведение. Типизированные ожидания:
Антипаттерны. Тесты на внутреннюю реализацию - привязка к деталям ломает тесты при рефакторинге. Слишком много моков - если нужно замокать пять зависимостей, проблема в архитектуре. Генерация тестов и кода одним промптом - уже сказал выше, но повторю: всегда два отдельных шага.
Метрики разницы. При code-first покрытие после первой итерации обычно 40-60%. При test-first - 80-90%. Defect escape rate падает, потому что edge cases покрываются до написания кода. Рефакторинг становится безопасным, потому что тесты привязаны к контракту, а не к реализации.
Test-first работает и для инфраструктуры. Circuit breaker, валидаторы, парсеры - state machine полностью описывается через тесты. Переходы между состояниями, пороги, таймеры. Claude генерирует реализацию, которая корректно обрабатывает все переходы, потому что каждый зафиксирован в тесте.
Начать можно с одного изолированного модуля. Утилитная функция, парсер, валидатор - что-то без тяжёлых зависимостей. Написать тесты промптом, убедиться что падают, сгенерировать реализацию отдельным промптом. Один цикл покажет разницу.
Подробный гайд с примерами кода - в блоге: https://futurecraft.pro/ru/blog/tdd-with-ai/
Классическая проблема TDD - цикл Red-Green-Refactor ломается на первом шаге. Чтобы написать тест, нужно определить интерфейс. Чтобы определить интерфейс, нужно понять архитектуру. Чтобы понять архитектуру, нужно мысленно написать реализацию. Круг замкнулся. Разработчик переключается на код "чтобы быстро проверить идею" и к test-first больше не возвращается.
AI разрывает этот круг. Описываешь модуль в промпте: вход, выход, edge cases. Claude генерирует полноценный тестовый файл. Все тесты падают - модуля ещё нет. Это нормально, Red phase завершена. Тестовый файл уже стал спецификацией: входной тип, выходная структура, поведение на граничных случаях.
Два отдельных промпта - обязательно. "Напиши функцию и тесты к ней" - это code-first с иллюзией test-first. AI сгенерирует реализацию и подгонит тесты под неё. Тесты будут проверять то, что код делает, а не то, что код должен делать. Разница становится критичной при рефакторинге.
Правильный workflow - четыре шага. Первый: промпт на тесты с описанием модуля, входных данных и edge cases. Явно указать "не пиши реализацию". Второй: отдельный промпт на минимальную реализацию, которая проходит все тесты. Третий: рефакторинг под защитой тестов. Четвёртый: новые требования - новые тесты, цикл повторяется.
Паттерны, которые работают. Один тест = одно поведение. Типизированные ожидания:
toEqual({ ... }) вместо toBeTruthy(). Чем точнее тест, тем точнее реализация. Названия тестов как документация: it('returns empty array when no items match filter') — Claude использует это для понимания intent.Антипаттерны. Тесты на внутреннюю реализацию - привязка к деталям ломает тесты при рефакторинге. Слишком много моков - если нужно замокать пять зависимостей, проблема в архитектуре. Генерация тестов и кода одним промптом - уже сказал выше, но повторю: всегда два отдельных шага.
Метрики разницы. При code-first покрытие после первой итерации обычно 40-60%. При test-first - 80-90%. Defect escape rate падает, потому что edge cases покрываются до написания кода. Рефакторинг становится безопасным, потому что тесты привязаны к контракту, а не к реализации.
Test-first работает и для инфраструктуры. Circuit breaker, валидаторы, парсеры - state machine полностью описывается через тесты. Переходы между состояниями, пороги, таймеры. Claude генерирует реализацию, которая корректно обрабатывает все переходы, потому что каждый зафиксирован в тесте.
Начать можно с одного изолированного модуля. Утилитная функция, парсер, валидатор - что-то без тяжёлых зависимостей. Написать тесты промптом, убедиться что падают, сгенерировать реализацию отдельным промптом. Один цикл покажет разницу.
Подробный гайд с примерами кода - в блоге: https://futurecraft.pro/ru/blog/tdd-with-ai/
futurecraft.pro
TDD с AI: Claude пишет тесты первым, потом реализацию — futurecraft.pro
Как применять test-driven development с Claude Code: промпты, workflow test-first, сравнение подходов. Практическое руководство с примерами кода.
AI code review ловит больше багов, когда работает по фиксированной структуре, а не пытается проверить всё сразу.
Типичный ревьюер тратит 15-30 минут на PR. Большую часть этого времени он замечает naming, стиль, форматирование. Логические ошибки и уязвимости проскальзывают. Исследование Google (Sadowski et al., 2018) подтвердило: 68% пропущенных дефектов - логика и edge cases. Не форматирование.
Фиксированный порядок решает проблему. Четыре категории, каждая - отдельный проход через LLM:
Correctness - самая дорогая категория. Баг в бизнес-логике, попавший в production, стоит в 10-30x дороже пойманного до merge. Что проверять: граничные значения (null, 0, пустой массив), off-by-one в циклах, race conditions, обработка таймаутов и 500-х ошибок, переполнение типов, идемпотентность. Пример: функция скидок проверяет
Security - идёт второй, потому что уязвимость опаснее бага: баг видно по ошибкам, уязвимость эксплуатируют молча. Проверка по OWASP Top 10: инъекции, broken access control, hardcoded секреты, PII в логах, десериализация без валидации, CVE в зависимостях. Пример: Supabase Edge Function возвращает документ по ID без проверки user_id - IDOR, severity High. Фикс:
Performance - быстрый, но некорректный код бесполезен, поэтому третий приоритет. N+1 запросов (цикл с query внутри - при 500 пользователях это 501 запрос и 1-2.5 секунды latency), SELECT * вместо нужных полей, отсутствие индексов, memory leaks.
Readability - последняя категория, не блокирует merge. Однобуквенные переменные, dead code, несоответствие conventions проекта.
Ключевой принцип: промпт для каждой категории явно запрещает комментировать чужую область. Security-проход не трогает стиль. Correctness-проход не трогает производительность. Разделение устраняет шум.
Мульти-агентный подход усиливает результат. Первый агент (Claude) проходит все четыре этапа. Второй (GPT или Gemini) проверяет только Correctness и Security. Совпадение находок = высокая уверенность. Расхождение = ручная проверка. На практике это находит на 15-25% больше дефектов, чем одиночный проход.
Формат вывода структурирован: каждая находка получает уникальный ID ([C1], [S1], [P1], [R1]), severity, строку кода и fix в одном предложении. Correctness и Security блокируют merge. Performance и Readability - на усмотрение автора.
Интеграция в CI/CD: GitHub Action на каждый PR, только изменённые файлы, фильтр по расширениям. Стоимость - $0.06-0.15 за PR при использовании claude-sonnet-4. Час ревьюера стоит $50-100. На старте - информационный комментарий без блокировки. После 2-4 недель калибровки - блокировка для Critical/High. Типичная точность: 70-80%, из 10 замечаний 2-3 нерелевантны.
Метрики: True Positive Rate > 70%, Time to Review < 5 минут, Cost per PR < $0.10, снижение ручного ревью на 30-50%.
Подробный чеклист с промптами - в блоге: https://futurecraft.pro/ru/blog/ai-code-review-checklist/
Типичный ревьюер тратит 15-30 минут на PR. Большую часть этого времени он замечает naming, стиль, форматирование. Логические ошибки и уязвимости проскальзывают. Исследование Google (Sadowski et al., 2018) подтвердило: 68% пропущенных дефектов - логика и edge cases. Не форматирование.
Фиксированный порядок решает проблему. Четыре категории, каждая - отдельный проход через LLM:
Correctness - самая дорогая категория. Баг в бизнес-логике, попавший в production, стоит в 10-30x дороже пойманного до merge. Что проверять: граничные значения (null, 0, пустой массив), off-by-one в циклах, race conditions, обработка таймаутов и 500-х ошибок, переполнение типов, идемпотентность. Пример: функция скидок проверяет
quantity > 10 перед quantity > 50 - второе условие недостижимо. Тесты пройдут, если проверяют наличие скидки, а не её размер.Security - идёт второй, потому что уязвимость опаснее бага: баг видно по ошибкам, уязвимость эксплуатируют молча. Проверка по OWASP Top 10: инъекции, broken access control, hardcoded секреты, PII в логах, десериализация без валидации, CVE в зависимостях. Пример: Supabase Edge Function возвращает документ по ID без проверки user_id - IDOR, severity High. Фикс:
.eq('user_id', user.id) или RLS-политика.Performance - быстрый, но некорректный код бесполезен, поэтому третий приоритет. N+1 запросов (цикл с query внутри - при 500 пользователях это 501 запрос и 1-2.5 секунды latency), SELECT * вместо нужных полей, отсутствие индексов, memory leaks.
Readability - последняя категория, не блокирует merge. Однобуквенные переменные, dead code, несоответствие conventions проекта.
Ключевой принцип: промпт для каждой категории явно запрещает комментировать чужую область. Security-проход не трогает стиль. Correctness-проход не трогает производительность. Разделение устраняет шум.
Мульти-агентный подход усиливает результат. Первый агент (Claude) проходит все четыре этапа. Второй (GPT или Gemini) проверяет только Correctness и Security. Совпадение находок = высокая уверенность. Расхождение = ручная проверка. На практике это находит на 15-25% больше дефектов, чем одиночный проход.
Формат вывода структурирован: каждая находка получает уникальный ID ([C1], [S1], [P1], [R1]), severity, строку кода и fix в одном предложении. Correctness и Security блокируют merge. Performance и Readability - на усмотрение автора.
Интеграция в CI/CD: GitHub Action на каждый PR, только изменённые файлы, фильтр по расширениям. Стоимость - $0.06-0.15 за PR при использовании claude-sonnet-4. Час ревьюера стоит $50-100. На старте - информационный комментарий без блокировки. После 2-4 недель калибровки - блокировка для Critical/High. Типичная точность: 70-80%, из 10 замечаний 2-3 нерелевантны.
Метрики: True Positive Rate > 70%, Time to Review < 5 минут, Cost per PR < $0.10, снижение ручного ревью на 30-50%.
Подробный чеклист с промптами - в блоге: https://futurecraft.pro/ru/blog/ai-code-review-checklist/
Большинство SaaS-продуктов собирают аналитику, которую невозможно использовать. Не из-за плохих инструментов, а потому что никто не договорился о правилах именования событий.
Один разработчик пишет
Эта проблема решается не инструментом, а event taxonomy — формализованной структурой именования и классификации событий.
Три уровня таксономии
Каждое событие описывается через три уровня:
Объект — сущность продукта. Account, Project, Subscription, Report. Для типичного SaaS достаточно 8-12 объектов. Больше — таксономия слишком гранулярна.
Действие — что произошло с объектом. Стандартный набор: Created, Updated, Deleted, Viewed, Completed, Started, Submitted, Exported.
Свойства — контекст. Без них
Naming conventions
Формула: Object + Action в Title Case и past tense.
Свойства — snake_case. Булевы с префиксом
Запрещено: глагольные события без объекта (`Clicked` — что именно?), вложенные свойства (`plan.name`), массивы в корне, PII в свойствах.
Как сгенерировать за час
Процесс из четырёх шагов:
0-10 минут — собрать список экранов продукта, сформулировать 10 бизнес-вопросов, выгрузить текущие события (если есть).
10-25 минут — подставить данные в структурированный промпт. AI генерирует первую версию за 2-3 минуты. Проверить покрытие lifecycle от acquisition до retention.
25-40 минут — прогнать результат через валидационный промпт. Типичные находки: пропущены события отмены подписки, слишком гранулярный engagement, нет события-маркера activation. Этот подход повторяет паттерн LLM-as-Judge: один AI генерирует, другой проверяет.
40-60 минут — оформить документацию и план имплементации. Naming conventions, таблица событий, super properties, governance rules.
Типичные ошибки
100+ событий для MVP — data swamp. 25-35 событий покрывают 90% вопросов. Трекинг
Мониторинг после запуска
Три метрики: schema compliance rate (цель 99%+), property fill rate (сколько обязательных свойств заполнено), event volume anomalies (алерты на отклонения >50% от среднего за 7 дней).
Event taxonomy — не разовый проект. Это живой документ. AI сокращает проектирование с дней до часа, но governance остаётся за командой.
Подробный гайд с промптами и шаблоном - в блоге: https://futurecraft.pro/ru/blog/event-taxonomy-ai/
Один разработчик пишет
signup_completed, другой — user_signed_up, третий — registration_done. Через полгода в системе 200+ событий, 60% из которых дубликаты или мусор. Аналитик не может построить воронку, потому что не знает, какое из трёх событий регистрации актуально.Эта проблема решается не инструментом, а event taxonomy — формализованной структурой именования и классификации событий.
Три уровня таксономии
Каждое событие описывается через три уровня:
Объект — сущность продукта. Account, Project, Subscription, Report. Для типичного SaaS достаточно 8-12 объектов. Больше — таксономия слишком гранулярна.
Действие — что произошло с объектом. Стандартный набор: Created, Updated, Deleted, Viewed, Completed, Started, Submitted, Exported.
Свойства — контекст. Без них
Subscription Created бесполезно: непонятно какой план, какой период, откуда пришёл пользователь. Свойства бывают обязательные (timestamp, user_id), объектные (plan_name, billing_cycle) и контекстные (source, device_type).Naming conventions
Формула: Object + Action в Title Case и past tense.
Subscription Created, не Create Subscription и не subscription.create.Свойства — snake_case. Булевы с префиксом
is_`/`has_. Количества с суффиксом _count. Идентификаторы с _id. Временные метки с _at.Запрещено: глагольные события без объекта (`Clicked` — что именно?), вложенные свойства (`plan.name`), массивы в корне, PII в свойствах.
Как сгенерировать за час
Процесс из четырёх шагов:
0-10 минут — собрать список экранов продукта, сформулировать 10 бизнес-вопросов, выгрузить текущие события (если есть).
10-25 минут — подставить данные в структурированный промпт. AI генерирует первую версию за 2-3 минуты. Проверить покрытие lifecycle от acquisition до retention.
25-40 минут — прогнать результат через валидационный промпт. Типичные находки: пропущены события отмены подписки, слишком гранулярный engagement, нет события-маркера activation. Этот подход повторяет паттерн LLM-as-Judge: один AI генерирует, другой проверяет.
40-60 минут — оформить документацию и план имплементации. Naming conventions, таблица событий, super properties, governance rules.
Типичные ошибки
100+ событий для MVP — data swamp. 25-35 событий покрывают 90% вопросов. Трекинг
Button Clicked вместо Task Created — это UX-аналитика, а не product analytics. Отсутствие governance — и таксономия деградирует за 3-6 месяцев. Игнорирование negative events (`Subscription Cancelled`, `Account Deleted`) — AI часто пропускает их, фокусируясь на happy path.Мониторинг после запуска
Три метрики: schema compliance rate (цель 99%+), property fill rate (сколько обязательных свойств заполнено), event volume anomalies (алерты на отклонения >50% от среднего за 7 дней).
Event taxonomy — не разовый проект. Это живой документ. AI сокращает проектирование с дней до часа, но governance остаётся за командой.
Подробный гайд с промптами и шаблоном - в блоге: https://futurecraft.pro/ru/blog/event-taxonomy-ai/
Magic number - это конкретное действие, совершённое конкретное число раз за конкретный период, после которого retention скачкообразно растёт. Не абстрактная метрика, а формула: "пользователь, который сделал X минимум N раз за первые D дней, остаётся с вероятностью Y%".
Классические примеры. Facebook - 7 друзей за 10 дней, retention в 3 раза выше. Slack - 2000 сообщений в команде, 93% команд продолжали платить. Twitter - 30 подписок, возвращаемость на 60% выше. Dropbox - 1 файл в shared folder, конверсия в платный план в 4 раза больше.
Звучит как серебряная пуля. Проблема в том, что найти magic number правильно - значительно сложнее, чем кажется из этих кейсов.
Методология поиска
Берёшь все события за последние 6 месяцев. Для каждого пользователя считаешь, сколько раз он совершил каждое действие в первые 14 дней после регистрации. Параллельно строишь таблицу 30-day retention: вернулся ли пользователь через месяц.
Почему именно 14 дней? Это активационное окно. Короче - отсечёшь пользователей с медленным онбордингом. Длиннее - перепутаешь причину и следствие. Пользователь не потому остался, что сделал действие на 25-й день. Он сделал его, потому что уже решил остаться.
Дальше - перебор порогов. Для каждого действия проверяешь: какой retention у тех, кто совершил его >= 1, >= 2, >= 3... до 20 раз. И сравниваешь с retention тех, кто не дотянул до порога. Чем больше разрыв - тем сильнее кандидат.
Пример вывода: invite_teammate >= 3 даёт 72% retention против 18% у тех, кто пригласил меньше. Разрыв в 54 п.п. — сильный сигнал.
Три ловушки, которые ломают анализ
Первая - принять корреляцию за каузацию. Пользователи, создавшие 10 проектов за первую неделю, пришли с сильным намерением. Заставить всех создать 10 проектов — не значит получить тот же retention. Единственный способ подтвердить причинно-следственную связь - A/B тест: одной группе стандартный онбординг, другой - с подталкиванием к magic number действию.
Вторая - игнорировать confounders. Если magic number работает только для органических пользователей, это свойство аудитории, а не продукта. Обязательно стратифицировать по источнику трафика, тарифу и времени регистрации.
Третья - зафиксировать число навсегда. Продукт меняется, аудитория меняется. То, что работало в прошлом году, может потерять значимость после редизайна. Пересчёт - каждый квартал.
Визуализация порогов
Для топ-5 кандидатов строишь график: ось X - порог, ось Y - retention rate. Ищешь точку перелома: где retention перестаёт расти. Retention растёт с 20% при threshold=1 до 65% при threshold=5, потом плато - 67% при threshold=6, 68% при threshold=7. Magic number = 5.
Что дальше
Найденный magic number превращается в операционную метрику. Activation rate - доля новых пользователей, достигших magic number за активационное окно. Падение - сигнал о проблеме в онбординге. Каждый экран, каждый email, каждое push-уведомление теперь направлено на одну цель: помочь пользователю дойти до этого числа.
Важно: цель не в том, чтобы заставить совершить N действий. Цель - помочь получить ценность, которую пользователь получает после N реальных действий. Magic number - инструмент фокусировки, не подмены смысла метрикой.
Подробный гайд с SQL-запросами и промптами - в блоге: https://futurecraft.pro/ru/blog/magic-number-retention/
Классические примеры. Facebook - 7 друзей за 10 дней, retention в 3 раза выше. Slack - 2000 сообщений в команде, 93% команд продолжали платить. Twitter - 30 подписок, возвращаемость на 60% выше. Dropbox - 1 файл в shared folder, конверсия в платный план в 4 раза больше.
Звучит как серебряная пуля. Проблема в том, что найти magic number правильно - значительно сложнее, чем кажется из этих кейсов.
Методология поиска
Берёшь все события за последние 6 месяцев. Для каждого пользователя считаешь, сколько раз он совершил каждое действие в первые 14 дней после регистрации. Параллельно строишь таблицу 30-day retention: вернулся ли пользователь через месяц.
Почему именно 14 дней? Это активационное окно. Короче - отсечёшь пользователей с медленным онбордингом. Длиннее - перепутаешь причину и следствие. Пользователь не потому остался, что сделал действие на 25-й день. Он сделал его, потому что уже решил остаться.
Дальше - перебор порогов. Для каждого действия проверяешь: какой retention у тех, кто совершил его >= 1, >= 2, >= 3... до 20 раз. И сравниваешь с retention тех, кто не дотянул до порога. Чем больше разрыв - тем сильнее кандидат.
Пример вывода: invite_teammate >= 3 даёт 72% retention против 18% у тех, кто пригласил меньше. Разрыв в 54 п.п. — сильный сигнал.
Три ловушки, которые ломают анализ
Первая - принять корреляцию за каузацию. Пользователи, создавшие 10 проектов за первую неделю, пришли с сильным намерением. Заставить всех создать 10 проектов — не значит получить тот же retention. Единственный способ подтвердить причинно-следственную связь - A/B тест: одной группе стандартный онбординг, другой - с подталкиванием к magic number действию.
Вторая - игнорировать confounders. Если magic number работает только для органических пользователей, это свойство аудитории, а не продукта. Обязательно стратифицировать по источнику трафика, тарифу и времени регистрации.
Третья - зафиксировать число навсегда. Продукт меняется, аудитория меняется. То, что работало в прошлом году, может потерять значимость после редизайна. Пересчёт - каждый квартал.
Визуализация порогов
Для топ-5 кандидатов строишь график: ось X - порог, ось Y - retention rate. Ищешь точку перелома: где retention перестаёт расти. Retention растёт с 20% при threshold=1 до 65% при threshold=5, потом плато - 67% при threshold=6, 68% при threshold=7. Magic number = 5.
Что дальше
Найденный magic number превращается в операционную метрику. Activation rate - доля новых пользователей, достигших magic number за активационное окно. Падение - сигнал о проблеме в онбординге. Каждый экран, каждый email, каждое push-уведомление теперь направлено на одну цель: помочь пользователю дойти до этого числа.
Важно: цель не в том, чтобы заставить совершить N действий. Цель - помочь получить ценность, которую пользователь получает после N реальных действий. Magic number - инструмент фокусировки, не подмены смысла метрикой.
Подробный гайд с SQL-запросами и промптами - в блоге: https://futurecraft.pro/ru/blog/magic-number-retention/
LLM сокращают время написания PRD с 8-16 часов до 1.5-3 часов. Это не прогноз и не рекламный слоган. Это результат workflow из 7 шагов, где каждая секция генерируется отдельным промптом с каскадным контекстом.
Почему классические PRD не работают в маленьких командах
В командах из 3-10 человек три проблемы убивают документацию.
Непропорциональные затраты. Описание фичи, которая делается за неделю, требует 2-3 дня на документирование. Команда выбирает "просто начнём делать". Итог: scope creep, переделки, разное понимание у разработчиков и дизайнеров.
Неполное покрытие. Даже опытные продакт-менеджеры пропускают секции: edge cases, error states, rollback plan, success metrics с порогами. Удерживать 15 секций в голове при описании каждой фичи физически невозможно.
Устаревание. PRD написан в понедельник, к пятнице половина решений поменялась. Обновить 15-страничный документ дороже, чем написать новый.
Структура из 8 модульных секций
Порядок принципиален: Problem Statement и Target Users задают контекст для LLM, а все следующие промпты получают output предыдущих.
- Problem Statement - текущее состояние, pain points с метриками, целевое состояние, impact hypothesis. Ключевое: "23% churn из exit survey" даёт конкретный output. "Высокий churn" даёт generic текст.
- Target Users через JTBD — максимум 3 persona. Ограничение обязательно, иначе LLM генерирует 7-10 типов и размывает фокус.
- Solution Overview - что строим, какие capabilities закрывают какие pain points, happy path. Без технических деталей и UI.
- User Stories с Acceptance Criteria в формате Given/When/Then. Максимальная экономия времени. Отдельный акцент на negative criteria: "система НЕ должна обновлять данные чаще раза в 5 минут".
- Technical Constraints - совместно с техлидом. LLM структурирует по категориям: инфраструктура, данные, интеграции, перформанс, безопасность.
- Edge Cases - пропускают чаще всего. Промпт генерирует 20-40 кейсов по пяти категориям. Половина нерелевантна, но отфильтровать за 15-20 минут проще, чем генерировать с нуля за 2-3 часа.
- Success Metrics - primary, secondary, guardrail (которые НЕ должны ухудшиться), exit criteria с числовыми порогами.
- Out of Scope - что не делаем, почему, когда может вернуться. Плюс допущения и открытые вопросы.
Три принципа качественной генерации
Реальные данные. LLM отлично структурирует, но плохо изобретает метрики. Конкретные числа из аналитики на входе дают конкретный output.
Жёсткие лимиты в промптах. "Максимум 3 persona", "3-5 pain points", "5-8 шагов". Без этого фильтровать дольше, чем писать вручную.
Negative constraints. "Не включай технические детали", "Не упоминай UI-элементы". Модель следует явным запретам точнее, чем неявным ожиданиям.
Минимальный жизнеспособный PRD: три секции - Problem Statement, Solution Overview, User Stories с Acceptance Criteria. Этого достаточно для команды из 3-5 человек. Остальные секции добавляются по мере роста сложности.
Промпты работают с любой LLM. Качество зависит от входных данных, не от модели.
Полный гайд с промптами для всех 8 секций и готовым шаблоном: https://futurecraft.pro/ru/blog/ai-powered-prd/
Почему классические PRD не работают в маленьких командах
В командах из 3-10 человек три проблемы убивают документацию.
Непропорциональные затраты. Описание фичи, которая делается за неделю, требует 2-3 дня на документирование. Команда выбирает "просто начнём делать". Итог: scope creep, переделки, разное понимание у разработчиков и дизайнеров.
Неполное покрытие. Даже опытные продакт-менеджеры пропускают секции: edge cases, error states, rollback plan, success metrics с порогами. Удерживать 15 секций в голове при описании каждой фичи физически невозможно.
Устаревание. PRD написан в понедельник, к пятнице половина решений поменялась. Обновить 15-страничный документ дороже, чем написать новый.
Структура из 8 модульных секций
Порядок принципиален: Problem Statement и Target Users задают контекст для LLM, а все следующие промпты получают output предыдущих.
- Problem Statement - текущее состояние, pain points с метриками, целевое состояние, impact hypothesis. Ключевое: "23% churn из exit survey" даёт конкретный output. "Высокий churn" даёт generic текст.
- Target Users через JTBD — максимум 3 persona. Ограничение обязательно, иначе LLM генерирует 7-10 типов и размывает фокус.
- Solution Overview - что строим, какие capabilities закрывают какие pain points, happy path. Без технических деталей и UI.
- User Stories с Acceptance Criteria в формате Given/When/Then. Максимальная экономия времени. Отдельный акцент на negative criteria: "система НЕ должна обновлять данные чаще раза в 5 минут".
- Technical Constraints - совместно с техлидом. LLM структурирует по категориям: инфраструктура, данные, интеграции, перформанс, безопасность.
- Edge Cases - пропускают чаще всего. Промпт генерирует 20-40 кейсов по пяти категориям. Половина нерелевантна, но отфильтровать за 15-20 минут проще, чем генерировать с нуля за 2-3 часа.
- Success Metrics - primary, secondary, guardrail (которые НЕ должны ухудшиться), exit criteria с числовыми порогами.
- Out of Scope - что не делаем, почему, когда может вернуться. Плюс допущения и открытые вопросы.
Три принципа качественной генерации
Реальные данные. LLM отлично структурирует, но плохо изобретает метрики. Конкретные числа из аналитики на входе дают конкретный output.
Жёсткие лимиты в промптах. "Максимум 3 persona", "3-5 pain points", "5-8 шагов". Без этого фильтровать дольше, чем писать вручную.
Negative constraints. "Не включай технические детали", "Не упоминай UI-элементы". Модель следует явным запретам точнее, чем неявным ожиданиям.
Минимальный жизнеспособный PRD: три секции - Problem Statement, Solution Overview, User Stories с Acceptance Criteria. Этого достаточно для команды из 3-5 человек. Остальные секции добавляются по мере роста сложности.
Промпты работают с любой LLM. Качество зависит от входных данных, не от модели.
Полный гайд с промптами для всех 8 секций и готовым шаблоном: https://futurecraft.pro/ru/blog/ai-powered-prd/
Forwarded from JourneyBay
JourneyBay 2.0 уже доступен 🚀
Не косметическое обновление. Мы переписали AI-движок и превратили JourneyBay в AI-платформу для путешествий — ту, где AI редактирует поездку, а не просто отвечает на вопросы.
Что нового внутри:
• Поездка из одной фразы — короткий запрос превращается в дни, места, карту и первый маршрут
• AI-чат с 25 инструментами: ищет, проверяет, показывает места карточками, переносит активности
• Импорт броней из PDF и фото — авторазбор и добавление в нужный день
• Подготовка рядом с маршрутом: чек-листы, документы и визовый контекст из официальных источников
• Свой LLM-ключ (OpenAI · Claude · Gemini) или MCP-доступ для Claude Desktop и Codex
• Планирование по всем странам и гражданствам
• Места под настроение — рекомендации с учётом темпа и предпочтений
Главная идея: вся поездка — один живой маршрут.
Подробнее: https://journeybay.co/
Скачать
iOS
Android
RuStore
MCP docs
Не косметическое обновление. Мы переписали AI-движок и превратили JourneyBay в AI-платформу для путешествий — ту, где AI редактирует поездку, а не просто отвечает на вопросы.
Что нового внутри:
• Поездка из одной фразы — короткий запрос превращается в дни, места, карту и первый маршрут
• AI-чат с 25 инструментами: ищет, проверяет, показывает места карточками, переносит активности
• Импорт броней из PDF и фото — авторазбор и добавление в нужный день
• Подготовка рядом с маршрутом: чек-листы, документы и визовый контекст из официальных источников
• Свой LLM-ключ (OpenAI · Claude · Gemini) или MCP-доступ для Claude Desktop и Codex
• Планирование по всем странам и гражданствам
• Места под настроение — рекомендации с учётом темпа и предпочтений
Главная идея: вся поездка — один живой маршрут.
Подробнее: https://journeybay.co/
Скачать
iOS
Android
RuStore
MCP docs
70% стартапов получают отказ не из-за продукта, а из-за бизнес-модели. Business Model Canvas заполняют один раз и считают задачу закрытой. Инвестор читает его как карту рисков и за 10 минут находит дыры, на закрытие которых уйдёт полгода.
AI может найти эти дыры до питча. Разберём, как проверить каждый из 9 блоков BMC.
Подготовка. BMC нужно заполнить текстом, а не набором ключевых слов. "B2B SaaS для HR" не даёт AI контекста. "Платформа автоматизации рекрутинга для IT-компаний 50-500 сотрудников, средний чек $200/мес, основной канал: контент-маркетинг" даёт. Для каждого блока хватит 2-3 предложений с указанием стадии, рынка и текущих метрик.
Что проверять в каждом блоке.
Customer Segments: сегмент конкретный (можно составить список из 100 компаний?), TAM/SAM/SOM обоснован, есть приоритизация. Типичная ошибка: "все малые бизнесы". Вопрос инвестора: почему магазин одежды на Shopify и дистрибьютор электроники на собственной платформе в одном сегменте? Рекомендация: сузить до "DTC бренды на Shopify с GMV $100K-$1M/год".
Value Propositions: связь с измеримой болью клиента, 10x improvement test, ответ на "почему сейчас". Типичная ошибка: описание технологии вместо выгоды. "Экономим время" vs. "сокращаем наём с 45 до 12 дней". Второе можно проверить, первое нет.
Channels: CAC по каждому каналу, масштабируемость при 10x росте бюджета, channel-market fit. Типичная ошибка: enterprise-продукт с привлечением через TikTok. Другая частая проблема: зависимость от одного канала. Что будет, если он закроется?
Customer Relationships: модель обслуживания совпадает с чеком, есть retention-стратегия. Типичная ошибка: high-touch onboarding при $20/мес не масштабируется. Ещё хуже: план привлечения есть, плана удержания нет.
Revenue Streams: подтверждённая готовность платить, expansion revenue, pricing привязан к value metric. Типичная ошибка: цена за "место", когда ценность в объёме обработанных данных. Net Revenue Retention ниже 100% при отсутствии upsell/cross-sell.
Key Resources: single points of failure (один разработчик знает всю кодовую базу), реальный moat (не "AI-алгоритм" без патента или уникальных данных), founder-market fit. Нет плана найма при 5x росте? Это красный флаг.
Key Activities: приоритизация (если 15 "ключевых" активностей, ничего не ключевое), метрики эффективности. Смешивание execution и strategy в одном списке говорит о том, что приоритеты не расставлены.
Key Partnerships: формализация (устная договорённость это не партнёрство), взаимная ценность, конкурентный риск. Что получает партнёр? Может ли он стать конкурентом? Работает ли партнёрство при 10x росте?
Cost Structure: fixed/variable split, скрытые расходы (compliance, legal, tech debt), burn rate trajectory. Типичная ошибка: занижение расходов на найм и инфраструктуру.
Мета-анализ: самое важное. Проблемы отдельных блоков найти легко. Опаснее несоответствия между блоками. Premium-сегмент с low-touch каналами и низким чеком. Enterprise-продукт с командой из 2 человек без планов найма sales. Ключевая активность "AI R&D" при нуле ML-инженеров в ресурсах.
Как приоритизировать результаты. AI находит 15-25 проблем в любом BMC. Это нормально. Разделите на три группы. Критические (исправить до питча): несоответствия, которые ломают модель, например CAC выше LTV. Важные (подготовить ответ): инвестор спросит, нужен план. Низкий приоритет (принять как факт стадии): отсутствие патентов на pre-seed.
Порядок работы. Начните с Customer Segments и Value Propositions. Это фундамент. Если здесь проблемы, остальные блоки не имеют значения. После исправления отдельных блоков запустите мета-анализ связей. Исправили критическое? Запустите тест снова. Одной итерации недостаточно.
AI-стресс-тест не заменяет разговоры с клиентами и финансовое моделирование. Он закрывает слепые зоны, которые основатель не видит из-за близости к продукту.
Полный гайд с готовыми промптами для всех 9 блоков и мета-анализа — https://futurecraft.pro/ru/blog/business-model-canvas-ai/
AI может найти эти дыры до питча. Разберём, как проверить каждый из 9 блоков BMC.
Подготовка. BMC нужно заполнить текстом, а не набором ключевых слов. "B2B SaaS для HR" не даёт AI контекста. "Платформа автоматизации рекрутинга для IT-компаний 50-500 сотрудников, средний чек $200/мес, основной канал: контент-маркетинг" даёт. Для каждого блока хватит 2-3 предложений с указанием стадии, рынка и текущих метрик.
Что проверять в каждом блоке.
Customer Segments: сегмент конкретный (можно составить список из 100 компаний?), TAM/SAM/SOM обоснован, есть приоритизация. Типичная ошибка: "все малые бизнесы". Вопрос инвестора: почему магазин одежды на Shopify и дистрибьютор электроники на собственной платформе в одном сегменте? Рекомендация: сузить до "DTC бренды на Shopify с GMV $100K-$1M/год".
Value Propositions: связь с измеримой болью клиента, 10x improvement test, ответ на "почему сейчас". Типичная ошибка: описание технологии вместо выгоды. "Экономим время" vs. "сокращаем наём с 45 до 12 дней". Второе можно проверить, первое нет.
Channels: CAC по каждому каналу, масштабируемость при 10x росте бюджета, channel-market fit. Типичная ошибка: enterprise-продукт с привлечением через TikTok. Другая частая проблема: зависимость от одного канала. Что будет, если он закроется?
Customer Relationships: модель обслуживания совпадает с чеком, есть retention-стратегия. Типичная ошибка: high-touch onboarding при $20/мес не масштабируется. Ещё хуже: план привлечения есть, плана удержания нет.
Revenue Streams: подтверждённая готовность платить, expansion revenue, pricing привязан к value metric. Типичная ошибка: цена за "место", когда ценность в объёме обработанных данных. Net Revenue Retention ниже 100% при отсутствии upsell/cross-sell.
Key Resources: single points of failure (один разработчик знает всю кодовую базу), реальный moat (не "AI-алгоритм" без патента или уникальных данных), founder-market fit. Нет плана найма при 5x росте? Это красный флаг.
Key Activities: приоритизация (если 15 "ключевых" активностей, ничего не ключевое), метрики эффективности. Смешивание execution и strategy в одном списке говорит о том, что приоритеты не расставлены.
Key Partnerships: формализация (устная договорённость это не партнёрство), взаимная ценность, конкурентный риск. Что получает партнёр? Может ли он стать конкурентом? Работает ли партнёрство при 10x росте?
Cost Structure: fixed/variable split, скрытые расходы (compliance, legal, tech debt), burn rate trajectory. Типичная ошибка: занижение расходов на найм и инфраструктуру.
Мета-анализ: самое важное. Проблемы отдельных блоков найти легко. Опаснее несоответствия между блоками. Premium-сегмент с low-touch каналами и низким чеком. Enterprise-продукт с командой из 2 человек без планов найма sales. Ключевая активность "AI R&D" при нуле ML-инженеров в ресурсах.
Как приоритизировать результаты. AI находит 15-25 проблем в любом BMC. Это нормально. Разделите на три группы. Критические (исправить до питча): несоответствия, которые ломают модель, например CAC выше LTV. Важные (подготовить ответ): инвестор спросит, нужен план. Низкий приоритет (принять как факт стадии): отсутствие патентов на pre-seed.
Порядок работы. Начните с Customer Segments и Value Propositions. Это фундамент. Если здесь проблемы, остальные блоки не имеют значения. После исправления отдельных блоков запустите мета-анализ связей. Исправили критическое? Запустите тест снова. Одной итерации недостаточно.
AI-стресс-тест не заменяет разговоры с клиентами и финансовое моделирование. Он закрывает слепые зоны, которые основатель не видит из-за близости к продукту.
Полный гайд с готовыми промптами для всех 9 блоков и мета-анализа — https://futurecraft.pro/ru/blog/business-model-canvas-ai/
42% питч-деков инвесторы отклоняют из-за неубедительной оценки рынка. Не потому что рынок маленький. Потому что «TAM $50B» без источника и методологии выглядит как число из воздуха.
TAM, SAM и SOM решают одну задачу: перевести абстрактное «рынок большой» в конкретные цифры, которые инвестор может проверить.
TAM (Total Addressable Market) показывает максимальный потолок. Сколько денег тратится на решение проблемы продукта во всём мире или в выбранном регионе.
SAM (Serviceable Addressable Market) сужает TAM до реальности. Часть рынка, которую продукт может обслужить с учётом географии, языка, ценовой категории и каналов дистрибуции.
SOM (Serviceable Obtainable Market) отвечает на вопрос «сколько вы реально получите». Доля SAM, которую стартап способен захватить за 1-3 года с текущими ресурсами.
Два метода расчёта
Top-down берёт общий размер рынка из аналитических отчётов (Gartner, Statista, Grand View Research) и сужает фильтрами до целевого сегмента. Bottom-up считает от конкретных клиентов: количество целевых компаний, умноженное на средний годовой контракт.
Лучшая практика: считать обоими методами и показать сравнение. Если результаты расходятся менее чем в 3 раза, это сильный сигнал адекватности. Расхождение в 5 раз и больше означает ошибку в допущениях.
Пример на реальном кейсе
Продукт: SaaS для автоматизации email-маркетинга. Целевой клиент: e-commerce, 100-1000 сотрудников, США + Западная Европа.
• TAM top-down: $5.67B (рынок email-маркетинга $12.6B x 45% доля автоматизации)
• TAM bottom-up: $936M (78K компаний x $12K ACV)
• SAM: $334M (top-down) vs $936M (bottom-up)
• SOM Year 1: $4.8M = 400 клиентов x $12K ACV
SOM расписан через воронку: 5000 лидов x 8% конверсия = 400 клиентов. 5000 лидов = контент-маркетинг (2000) + paid acquisition (2000) + partnerships (1000). Каждый слой проверяем. 1.4% SAM в первый год вполне адекватно для конкурентного рынка.
Пять типичных ошибок
Первая: TAM = весь рынок. «Рынок CRM составляет $80B» это не TAM для инструмента управления контактами в малом бизнесе. Инвесторы видят подмену мгновенно.
Вторая: один источник данных. Gartner оценивает рынок в $15B, Grand View Research в $22B, Mordor Intelligence в $11B. Три отчёта дают разброс в два раза. Один отчёт без объяснения выбора ослабляет позицию.
Третья: SOM без воронки. «Захватим 10% рынка за 3 года» без расчёта каналов привлечения, конверсий и unit economics. SOM строится снизу вверх: каналы, лиды, конверсия, клиенты, выручка.
Четвёртая: статичная модель. Рынок растёт или сжимается. Конкуренты появляются и уходят. Модель без CAGR и сценарного анализа устаревает за полгода. Три сценария (консервативный, базовый, оптимистичный) показывают чувствительность к допущениям.
Пятая: игнорирование конкурентов. Если топ-5 игроков занимают 70% SAM, получить 5% за первый год нереалистично. Модель должна учитывать конкурентный ландшафт.
Бенчмарки по стадиям
Для Pre-Seed: TAM $1-10B, SAM $100M-1B, SOM Year 1 $0.5-2M (0.1-0.5% SAM). Для Seed: TAM $5-50B, SAM $500M-5B, SOM $2-10M (0.2-1% SAM). Для Series A: TAM $10-100B, SAM $1-10B, SOM $10-50M (0.5-2% SAM).
Ключевые пропорции: SAM/TAM обычно 5-20%. Если SAM составляет 80% TAM, фильтры слишком широкие. SOM/SAM в первый год: 0.5-3%. Выше 5% за первый год неубедительно.
Как представлять инвестору
Один слайд. Оба метода расчёта рядом. Каждый множитель с объяснением. Не «SAM = $334M», а «SAM = $5.67B x 34% (mid-market) x 28% (e-commerce) x 62% (US+EU) = $334M». SOM привязан к операционному плану. Каждая внешняя цифра со ссылкой на источник в footnotes.
AI сокращает работу по оценке рынка с дней до часов. Промпты для расчёта TAM, bottom-up SAM, SOM через воронку и валидации допущений работают с Claude, GPT-4o и Gemini. Но каждое допущение проверяется вручную. AI помогает считать, не заменяет проверку.
Подробный гайд с формулами и промптами - на блоге: https://futurecraft.pro/ru/blog/tam-sam-som-calculator/
TAM, SAM и SOM решают одну задачу: перевести абстрактное «рынок большой» в конкретные цифры, которые инвестор может проверить.
TAM (Total Addressable Market) показывает максимальный потолок. Сколько денег тратится на решение проблемы продукта во всём мире или в выбранном регионе.
SAM (Serviceable Addressable Market) сужает TAM до реальности. Часть рынка, которую продукт может обслужить с учётом географии, языка, ценовой категории и каналов дистрибуции.
SOM (Serviceable Obtainable Market) отвечает на вопрос «сколько вы реально получите». Доля SAM, которую стартап способен захватить за 1-3 года с текущими ресурсами.
Два метода расчёта
Top-down берёт общий размер рынка из аналитических отчётов (Gartner, Statista, Grand View Research) и сужает фильтрами до целевого сегмента. Bottom-up считает от конкретных клиентов: количество целевых компаний, умноженное на средний годовой контракт.
Лучшая практика: считать обоими методами и показать сравнение. Если результаты расходятся менее чем в 3 раза, это сильный сигнал адекватности. Расхождение в 5 раз и больше означает ошибку в допущениях.
Пример на реальном кейсе
Продукт: SaaS для автоматизации email-маркетинга. Целевой клиент: e-commerce, 100-1000 сотрудников, США + Западная Европа.
• TAM top-down: $5.67B (рынок email-маркетинга $12.6B x 45% доля автоматизации)
• TAM bottom-up: $936M (78K компаний x $12K ACV)
• SAM: $334M (top-down) vs $936M (bottom-up)
• SOM Year 1: $4.8M = 400 клиентов x $12K ACV
SOM расписан через воронку: 5000 лидов x 8% конверсия = 400 клиентов. 5000 лидов = контент-маркетинг (2000) + paid acquisition (2000) + partnerships (1000). Каждый слой проверяем. 1.4% SAM в первый год вполне адекватно для конкурентного рынка.
Пять типичных ошибок
Первая: TAM = весь рынок. «Рынок CRM составляет $80B» это не TAM для инструмента управления контактами в малом бизнесе. Инвесторы видят подмену мгновенно.
Вторая: один источник данных. Gartner оценивает рынок в $15B, Grand View Research в $22B, Mordor Intelligence в $11B. Три отчёта дают разброс в два раза. Один отчёт без объяснения выбора ослабляет позицию.
Третья: SOM без воронки. «Захватим 10% рынка за 3 года» без расчёта каналов привлечения, конверсий и unit economics. SOM строится снизу вверх: каналы, лиды, конверсия, клиенты, выручка.
Четвёртая: статичная модель. Рынок растёт или сжимается. Конкуренты появляются и уходят. Модель без CAGR и сценарного анализа устаревает за полгода. Три сценария (консервативный, базовый, оптимистичный) показывают чувствительность к допущениям.
Пятая: игнорирование конкурентов. Если топ-5 игроков занимают 70% SAM, получить 5% за первый год нереалистично. Модель должна учитывать конкурентный ландшафт.
Бенчмарки по стадиям
Для Pre-Seed: TAM $1-10B, SAM $100M-1B, SOM Year 1 $0.5-2M (0.1-0.5% SAM). Для Seed: TAM $5-50B, SAM $500M-5B, SOM $2-10M (0.2-1% SAM). Для Series A: TAM $10-100B, SAM $1-10B, SOM $10-50M (0.5-2% SAM).
Ключевые пропорции: SAM/TAM обычно 5-20%. Если SAM составляет 80% TAM, фильтры слишком широкие. SOM/SAM в первый год: 0.5-3%. Выше 5% за первый год неубедительно.
Как представлять инвестору
Один слайд. Оба метода расчёта рядом. Каждый множитель с объяснением. Не «SAM = $334M», а «SAM = $5.67B x 34% (mid-market) x 28% (e-commerce) x 62% (US+EU) = $334M». SOM привязан к операционному плану. Каждая внешняя цифра со ссылкой на источник в footnotes.
AI сокращает работу по оценке рынка с дней до часов. Промпты для расчёта TAM, bottom-up SAM, SOM через воронку и валидации допущений работают с Claude, GPT-4o и Gemini. Но каждое допущение проверяется вручную. AI помогает считать, не заменяет проверку.
Подробный гайд с формулами и промптами - на блоге: https://futurecraft.pro/ru/blog/tam-sam-som-calculator/
💯2
Инвесторы задают одни и те же 20 вопросов на каждой встрече. Разница между "funded" и "passed" чаще определяется не продуктом, а глубиной и скоростью ответов.
Разобрал, как подготовить ответы на все 20 типовых вопросов инвестора с помощью Claude - с промптами, шаблонами и workflow.
Корень проблемы: фаундер и инвестор видят разное
Фаундер знает продукт. Инвестор оценивает бизнес. На вопрос "какой ваш CAC?" фаундер называет цифру из головы. Claude, получив реальные данные (расходы на маркетинг, конверсии, период атрибуции), считает CAC по каждому каналу. На выходе - не одна приблизительная цифра, а таблица с разбивкой, которую инвестор проверит прямо на встрече. Три причины, почему AI-ответы сильнее ручных:
Структура. Claude форматирует ответ по привычным инвестору frameworks: TAM-SAM-SOM, unit economics waterfall, cohort retention.
Полнота. На вопрос о конкурентах фаундер перечисляет 3-4 компании. Claude выдает матрицу: прямые, косвенные, потенциальные конкуренты плюс позиционирование. Вместо "мы отличаемся UX" появляется конкретика: "Competitor A обрабатывает запросы за 48 часов, мы за 12 минут."
Цифры вместо нарратива. "Мы растем быстро" превращается в "MoM revenue growth 18%, organic составляет 62% от total acquisition". Вторую инвестор записывает, первую забывает.
Четыре блока вопросов
Все 20 вопросов распределяются по четырем блокам. Каждый требует отдельного промпта с контекстом: попытка получить все 20 ответов одним запросом снижает качество каждого в 3-4 раза.
Блок 1 - рынок и возможность (вопросы 1-5): размер рынка, конкуренты, unfair advantage, why now, какую проблему решаете. Минимум $1B TAM для Series A. Промпт считает рынок bottom-up: количество клиентов на средний чек и частоту покупки.
Блок 2 - бизнес-модель и unit economics (вопросы 6-10): revenue model, юнит-экономика, каналы привлечения, ценообразование, burn rate. Здесь фаундеры проваливаются чаще всего - не потому что цифры плохие, а потому что не подготовили разбивку. Claude рассчитывает LTV, LTV/CAC ratio, payback period и sensitivity analysis: как метрики меняются при churn +2% и CAC +20%.
Блок 3 - traction и метрики роста (вопросы 11-15): traction slide, retention, ICP, cohort data, ключевые метрики. Промпт строит retention curve по месячным когортам и выделяет тренды.
Блок 4 - команда, стратегия, раунд (вопросы 16-20): почему именно эта команда, GTM strategy, use of funds, риски, конкретный ask. Инвестор хочет честный анализ рисков с планом mitigation по категориям: market, technology, execution, competitive, regulatory.
Workflow подготовки за 4-6 часов
Шаг 1: загрузить в Claude все данные - финансовые отчеты, метрики, customer interviews, competitive research. Чем больше данных, тем точнее.
Шаг 2: пройти все 20 вопросов с промптами, сохранить ответы в один документ. Время - 2-3 часа.
Шаг 3: stress-test. Попросить Claude сыграть скептичного партнера из top-tier VC и задать по два follow-up к каждому ответу - именно они вскрывают дыры, которые фаундер не видит.
Шаг 4: доработать слабые ответы. Обычно 3-4 прохода закрывают проблемы.
Шаг 5: сжать 20 ответов в one-page memo - он работает как follow-up.
Три ошибки, которые убивают подготовку
Нет реальных данных. Claude генерирует правдоподобные цифры - без реальных метрик ответы будут красивыми и пустыми. Каждую цифру нужно подтвердить источником.
Copy-paste без сокращения. Ответ Claude оптимизирован под полноту, а ответ на pitch-встрече - под 30-60 секунд. Каждый нужно сжать до формата "headline + proof point + one number."
Игнорирование слабых мест. Если Claude указывает, что moat слабый или unit economics не сходятся, это не баг в промпте, а сигнал менять стратегию.
Итого: 4-6 часов вместо 2-3 недель. 20 промптов покрывают 90% вопросов от pre-seed до Series A. Все промпты, шаблоны ответов и workflow целиком: https://futurecraft.pro/ru/blog/investor-questions-ai/
Разобрал, как подготовить ответы на все 20 типовых вопросов инвестора с помощью Claude - с промптами, шаблонами и workflow.
Корень проблемы: фаундер и инвестор видят разное
Фаундер знает продукт. Инвестор оценивает бизнес. На вопрос "какой ваш CAC?" фаундер называет цифру из головы. Claude, получив реальные данные (расходы на маркетинг, конверсии, период атрибуции), считает CAC по каждому каналу. На выходе - не одна приблизительная цифра, а таблица с разбивкой, которую инвестор проверит прямо на встрече. Три причины, почему AI-ответы сильнее ручных:
Структура. Claude форматирует ответ по привычным инвестору frameworks: TAM-SAM-SOM, unit economics waterfall, cohort retention.
Полнота. На вопрос о конкурентах фаундер перечисляет 3-4 компании. Claude выдает матрицу: прямые, косвенные, потенциальные конкуренты плюс позиционирование. Вместо "мы отличаемся UX" появляется конкретика: "Competitor A обрабатывает запросы за 48 часов, мы за 12 минут."
Цифры вместо нарратива. "Мы растем быстро" превращается в "MoM revenue growth 18%, organic составляет 62% от total acquisition". Вторую инвестор записывает, первую забывает.
Четыре блока вопросов
Все 20 вопросов распределяются по четырем блокам. Каждый требует отдельного промпта с контекстом: попытка получить все 20 ответов одним запросом снижает качество каждого в 3-4 раза.
Блок 1 - рынок и возможность (вопросы 1-5): размер рынка, конкуренты, unfair advantage, why now, какую проблему решаете. Минимум $1B TAM для Series A. Промпт считает рынок bottom-up: количество клиентов на средний чек и частоту покупки.
Блок 2 - бизнес-модель и unit economics (вопросы 6-10): revenue model, юнит-экономика, каналы привлечения, ценообразование, burn rate. Здесь фаундеры проваливаются чаще всего - не потому что цифры плохие, а потому что не подготовили разбивку. Claude рассчитывает LTV, LTV/CAC ratio, payback period и sensitivity analysis: как метрики меняются при churn +2% и CAC +20%.
Блок 3 - traction и метрики роста (вопросы 11-15): traction slide, retention, ICP, cohort data, ключевые метрики. Промпт строит retention curve по месячным когортам и выделяет тренды.
Блок 4 - команда, стратегия, раунд (вопросы 16-20): почему именно эта команда, GTM strategy, use of funds, риски, конкретный ask. Инвестор хочет честный анализ рисков с планом mitigation по категориям: market, technology, execution, competitive, regulatory.
Workflow подготовки за 4-6 часов
Шаг 1: загрузить в Claude все данные - финансовые отчеты, метрики, customer interviews, competitive research. Чем больше данных, тем точнее.
Шаг 2: пройти все 20 вопросов с промптами, сохранить ответы в один документ. Время - 2-3 часа.
Шаг 3: stress-test. Попросить Claude сыграть скептичного партнера из top-tier VC и задать по два follow-up к каждому ответу - именно они вскрывают дыры, которые фаундер не видит.
Шаг 4: доработать слабые ответы. Обычно 3-4 прохода закрывают проблемы.
Шаг 5: сжать 20 ответов в one-page memo - он работает как follow-up.
Три ошибки, которые убивают подготовку
Нет реальных данных. Claude генерирует правдоподобные цифры - без реальных метрик ответы будут красивыми и пустыми. Каждую цифру нужно подтвердить источником.
Copy-paste без сокращения. Ответ Claude оптимизирован под полноту, а ответ на pitch-встрече - под 30-60 секунд. Каждый нужно сжать до формата "headline + proof point + one number."
Игнорирование слабых мест. Если Claude указывает, что moat слабый или unit economics не сходятся, это не баг в промпте, а сигнал менять стратегию.
Итого: 4-6 часов вместо 2-3 недель. 20 промптов покрывают 90% вопросов от pre-seed до Series A. Все промпты, шаблоны ответов и workflow целиком: https://futurecraft.pro/ru/blog/investor-questions-ai/
👍2
Solo-фаундеры тратят в среднем 4-6 часов на одну SEO-статью. При темпе 8 статей в месяц это 32-48 часов чистого времени — половина рабочей недели уходит только на тексты. AI-pipeline сокращает это до 8-12 часов в месяц без потери качества по метрикам трафика.
Собрал production-ready pipeline от keyword research до публикации. Каждый этап — промпт, инструмент и метрика контроля качества.
Архитектура pipeline: 6 этапов
Шесть последовательных этапов, пропуск любого снижает итог:
Keyword Research (2 часа в месяц) - Content Brief (1.5 часа) - Draft Generation (2 часа) - SEO-оптимизация (1.5 часа) - Human Review (2 часа) - Публикация и дистрибуция (1 час).
Суммарно 10 часов на 8 статей против 40+ часов ручного производства. Разница в 4 раза.
Главный принцип: AI генерирует черновик, человек принимает решения. Обратная схема работает хуже — правки черновика занимают больше времени, чем валидация готового текста.
Этап 1: Keyword Research с AI-кластеризацией
AI автоматизирует три из четырех шагов: данные по volume и KD берутся из SEO-инструментов, кластеризацию и приоритизацию делает Claude.
Промпт группирует ключевые слова в кластеры (один кластер = одна статья), определяет primary keyword с максимальным volume при KD ниже 40, назначает search intent и формат. Сортировка: (volume / KD) * intent_weight, где informational = 1, commercial = 1.5, transactional = 2.
Метрика качества: суммарный monthly search volume кластера выше 500. Ниже порога производство не оправдано.
Этап 2: Content Brief
Brief определяет структуру статьи до написания. Без него AI генерирует generic-контент, неотличимый от выдачи.
Brief включает уникальный angle (не "полное руководство", а конкретное отличие от топ-10), outline с H2/H3, обязательные данные по секциям и места для internal links. Перед генерацией полезно скормить AI top-3 статьи из выдачи для анализа content gaps.
Этап 3: секционная генерация черновика
Частая ошибка: скормить brief целиком и попросить "напиши статью" — результат поверхностный. Правильно - генерация по секциям: каждый H2-блок отдельным промптом с контекстом предыдущих.
Это дает на 30-40% более глубокий контент при том же объеме: модель удерживает фокус на одной теме, плотность keywords контролируется по секциям, а при неудаче переделывается одна секция, а не весь текст.
Этап 4: SEO-оптимизация
Техническая оптимизация: title tag до 60 символов с keyword в начале, meta description до 155 символов, URL slug из 3-5 слов, keyword density 3-5 на 1000 слов, H2 под keyword-вариации, alt-тексты для изображений.
Внутренняя перелинковка - отдельная задача: AI находит связи между статьями, минимум 3 internal links на статью.
Этап 5: Human Review
AI не заменяет редактора. AI генерирует 80% контента, последние 20% определяют разницу между средней и сильной статьей.
Чеклист: факт-чекинг каждого числового утверждения, удаление AI-маркеров ("важно отметить", "давайте рассмотрим"), добавление tone of voice через примеры из практики и нестандартные мнения.
Целевое время ревью: 15-20 минут на статью. Больше 30 - проблема в качестве brief или промптов.
Стоимость и инструменты
Полный стек: Claude Pro ($20), Ahrefs Lite ($99-129), Surfer SEO ($69), Grammarly ($12). Итого $200-230 в месяц против $2000-4000 за SEO-копирайтера на тот же объем.
Минимальный стек для старта: Claude/GPT ($20) + Google Search Console (бесплатно), $2.50 за статью.
Масштабирование до 20 статей
Pipeline масштабируется до 15-20 статей без роста времени на ревью. Три условия: шаблонизация промптов (четыре шаблона — tutorial, listicle, comparison, case study — покрывают 90% задач), batch processing (keyword research и briefs в один сеанс, черновики пакетами по 3-4), quality gates между этапами (density checker, readability score, duplicate content scanner).
При 20 статьях стоимость одной падает до $1.50-2.00.
8 SEO-статей в месяц, $200-230, 10-12 часов работы. Полный pipeline с промптами для каждого этапа: https://futurecraft.pro/ru/blog/ai-content-engine/
Собрал production-ready pipeline от keyword research до публикации. Каждый этап — промпт, инструмент и метрика контроля качества.
Архитектура pipeline: 6 этапов
Шесть последовательных этапов, пропуск любого снижает итог:
Keyword Research (2 часа в месяц) - Content Brief (1.5 часа) - Draft Generation (2 часа) - SEO-оптимизация (1.5 часа) - Human Review (2 часа) - Публикация и дистрибуция (1 час).
Суммарно 10 часов на 8 статей против 40+ часов ручного производства. Разница в 4 раза.
Главный принцип: AI генерирует черновик, человек принимает решения. Обратная схема работает хуже — правки черновика занимают больше времени, чем валидация готового текста.
Этап 1: Keyword Research с AI-кластеризацией
AI автоматизирует три из четырех шагов: данные по volume и KD берутся из SEO-инструментов, кластеризацию и приоритизацию делает Claude.
Промпт группирует ключевые слова в кластеры (один кластер = одна статья), определяет primary keyword с максимальным volume при KD ниже 40, назначает search intent и формат. Сортировка: (volume / KD) * intent_weight, где informational = 1, commercial = 1.5, transactional = 2.
Метрика качества: суммарный monthly search volume кластера выше 500. Ниже порога производство не оправдано.
Этап 2: Content Brief
Brief определяет структуру статьи до написания. Без него AI генерирует generic-контент, неотличимый от выдачи.
Brief включает уникальный angle (не "полное руководство", а конкретное отличие от топ-10), outline с H2/H3, обязательные данные по секциям и места для internal links. Перед генерацией полезно скормить AI top-3 статьи из выдачи для анализа content gaps.
Этап 3: секционная генерация черновика
Частая ошибка: скормить brief целиком и попросить "напиши статью" — результат поверхностный. Правильно - генерация по секциям: каждый H2-блок отдельным промптом с контекстом предыдущих.
Это дает на 30-40% более глубокий контент при том же объеме: модель удерживает фокус на одной теме, плотность keywords контролируется по секциям, а при неудаче переделывается одна секция, а не весь текст.
Этап 4: SEO-оптимизация
Техническая оптимизация: title tag до 60 символов с keyword в начале, meta description до 155 символов, URL slug из 3-5 слов, keyword density 3-5 на 1000 слов, H2 под keyword-вариации, alt-тексты для изображений.
Внутренняя перелинковка - отдельная задача: AI находит связи между статьями, минимум 3 internal links на статью.
Этап 5: Human Review
AI не заменяет редактора. AI генерирует 80% контента, последние 20% определяют разницу между средней и сильной статьей.
Чеклист: факт-чекинг каждого числового утверждения, удаление AI-маркеров ("важно отметить", "давайте рассмотрим"), добавление tone of voice через примеры из практики и нестандартные мнения.
Целевое время ревью: 15-20 минут на статью. Больше 30 - проблема в качестве brief или промптов.
Стоимость и инструменты
Полный стек: Claude Pro ($20), Ahrefs Lite ($99-129), Surfer SEO ($69), Grammarly ($12). Итого $200-230 в месяц против $2000-4000 за SEO-копирайтера на тот же объем.
Минимальный стек для старта: Claude/GPT ($20) + Google Search Console (бесплатно), $2.50 за статью.
Масштабирование до 20 статей
Pipeline масштабируется до 15-20 статей без роста времени на ревью. Три условия: шаблонизация промптов (четыре шаблона — tutorial, listicle, comparison, case study — покрывают 90% задач), batch processing (keyword research и briefs в один сеанс, черновики пакетами по 3-4), quality gates между этапами (density checker, readability score, duplicate content scanner).
При 20 статьях стоимость одной падает до $1.50-2.00.
8 SEO-статей в месяц, $200-230, 10-12 часов работы. Полный pipeline с промптами для каждого этапа: https://futurecraft.pro/ru/blog/ai-content-engine/
🔥3
Большинство веб-приложений содержат хотя бы одну уязвимость из OWASP Top 10. Стандартный security-аудит занимает 2-3 недели и стоит от $10 000. LLM сокращает первичный аудит до нескольких часов: сканирует код на паттерны, а не ищет конкретные CVE.
Собрал 15 уязвимостей из аудита production-кода с помощью Claude.
Методология: три прохода
Первый — широкий скан: LLM получает весь проект и ищет паттерны уязвимостей. Второй — глубокий анализ: каждый паттерн проверяется в контексте (middleware, ORM, фреймворк). Третий — верификация: ручная проверка находок, LLM дает false positives.
Промпт задает структуру ответа и приоритет категорий — иначе LLM смешивает критические уязвимости с мелкими замечаниями.
Injection (A03) - три типа
SQL Injection через конкатенацию строк. Самая частая находка, встречается даже в проектах с ORM. Исправление: параметризованный запрос для значений, whitelist для идентификаторов.
NoSQL Injection в MongoDB. Передача req.body напрямую в запрос позволяет через оператор $ne обойти проверку пароля. Исправление: приведение к строке через String() и сравнение паролей через bcrypt.compare.
Command Injection через child_process. Пользовательский ввод в shell-команде позволяет выполнить произвольный код. Исправление: execFile вместо exec плюс regex-валидация ввода.
Broken Access Control (A01)
IDOR — небезопасная прямая ссылка на объект. Любой авторизованный пользователь видит чужой заказ через перебор ID. Исправление: добавить AND user_id = $2 в запрос.
Path Traversal при отдаче файлов. Запрос /api/files/../../etc/passwd дает доступ к системным файлам. Исправление: secure_filename, send_from_directory для ограничения директории, abspath-проверка.
Mass Assignment — перезапись полей через API. Пользователь отправляет в теле {"role": "admin"} и повышает себе роль. Исправление: деструктуризация выбирает только разрешенные поля.
Cryptographic Failures (A02)
JWT без проверки алгоритма. Атакующий создает токен с alg: "none" или alg: "HS256", подписывая публичным ключом сервера. Исправление: явно задать algorithms: ['RS256'], добавить issuer/audience.
Хранение секретов в коде. API-ключи, пароли, connection strings прямо в исходниках. Исправление: переменные окружения с валидацией при старте, которая падает при отсутствии переменной.
Security Misconfiguration и Insecure Design (A05, A04)
CORS с origin: '*' и credentials: true позволяет любому сайту делать запросы от имени авторизованного пользователя. Исправление: whitelist разрешенных origin.
Verbose Error Messages. Stack trace утекает клиенту, раскрывая структуру БД и пути файлов. Исправление: errorId вместо деталей, детали — в логах.
SSRF — сервер делает запрос по URL от пользователя, открывая доступ к AWS metadata API. Исправление: DNS-резолвинг проверяет, что IP не из приватной сети, плюс блокировка редиректов и таймаут.
Race Condition при платежах. Два одновременных запроса на вывод читают один баланс, оба проходят проверку, баланс уходит в минус. Исправление: транзакция с SELECT FOR UPDATE блокирует строку на время операции.
Authentication Failures и Integrity (A07, A08)
Timing Attack при сравнении токенов. Оператор === завершается на первом несовпадающем байте — timing-атака. Исправление: crypto.timingSafeEqual сравнивает все байты за одинаковое время.
Отсутствие rate limiting на аутентификации. Бесконечный перебор паролей. Исправление: rate limit по email (не только по IP) плюс account lockout.
Prototype Pollution через слияние объектов. Тело запроса {"__proto__": {"isAdmin": true}} заражает все объекты приложения. Исправление: блокировка ключей proto, constructor, prototype.
Автоматизация в CI
Минимальный pipeline: Semgrep для OWASP Top 10, npm audit для зависимостей, Gitleaks для секретов. LLM-аудит запускается отдельно на pre-merge review.
Полный чеклист из 15 пунктов, каждый с конкретной уязвимостью и вектором атаки: https://futurecraft.pro/ru/blog/ai-security-audit/
Собрал 15 уязвимостей из аудита production-кода с помощью Claude.
Методология: три прохода
Первый — широкий скан: LLM получает весь проект и ищет паттерны уязвимостей. Второй — глубокий анализ: каждый паттерн проверяется в контексте (middleware, ORM, фреймворк). Третий — верификация: ручная проверка находок, LLM дает false positives.
Промпт задает структуру ответа и приоритет категорий — иначе LLM смешивает критические уязвимости с мелкими замечаниями.
Injection (A03) - три типа
SQL Injection через конкатенацию строк. Самая частая находка, встречается даже в проектах с ORM. Исправление: параметризованный запрос для значений, whitelist для идентификаторов.
NoSQL Injection в MongoDB. Передача req.body напрямую в запрос позволяет через оператор $ne обойти проверку пароля. Исправление: приведение к строке через String() и сравнение паролей через bcrypt.compare.
Command Injection через child_process. Пользовательский ввод в shell-команде позволяет выполнить произвольный код. Исправление: execFile вместо exec плюс regex-валидация ввода.
Broken Access Control (A01)
IDOR — небезопасная прямая ссылка на объект. Любой авторизованный пользователь видит чужой заказ через перебор ID. Исправление: добавить AND user_id = $2 в запрос.
Path Traversal при отдаче файлов. Запрос /api/files/../../etc/passwd дает доступ к системным файлам. Исправление: secure_filename, send_from_directory для ограничения директории, abspath-проверка.
Mass Assignment — перезапись полей через API. Пользователь отправляет в теле {"role": "admin"} и повышает себе роль. Исправление: деструктуризация выбирает только разрешенные поля.
Cryptographic Failures (A02)
JWT без проверки алгоритма. Атакующий создает токен с alg: "none" или alg: "HS256", подписывая публичным ключом сервера. Исправление: явно задать algorithms: ['RS256'], добавить issuer/audience.
Хранение секретов в коде. API-ключи, пароли, connection strings прямо в исходниках. Исправление: переменные окружения с валидацией при старте, которая падает при отсутствии переменной.
Security Misconfiguration и Insecure Design (A05, A04)
CORS с origin: '*' и credentials: true позволяет любому сайту делать запросы от имени авторизованного пользователя. Исправление: whitelist разрешенных origin.
Verbose Error Messages. Stack trace утекает клиенту, раскрывая структуру БД и пути файлов. Исправление: errorId вместо деталей, детали — в логах.
SSRF — сервер делает запрос по URL от пользователя, открывая доступ к AWS metadata API. Исправление: DNS-резолвинг проверяет, что IP не из приватной сети, плюс блокировка редиректов и таймаут.
Race Condition при платежах. Два одновременных запроса на вывод читают один баланс, оба проходят проверку, баланс уходит в минус. Исправление: транзакция с SELECT FOR UPDATE блокирует строку на время операции.
Authentication Failures и Integrity (A07, A08)
Timing Attack при сравнении токенов. Оператор === завершается на первом несовпадающем байте — timing-атака. Исправление: crypto.timingSafeEqual сравнивает все байты за одинаковое время.
Отсутствие rate limiting на аутентификации. Бесконечный перебор паролей. Исправление: rate limit по email (не только по IP) плюс account lockout.
Prototype Pollution через слияние объектов. Тело запроса {"__proto__": {"isAdmin": true}} заражает все объекты приложения. Исправление: блокировка ключей proto, constructor, prototype.
Автоматизация в CI
Минимальный pipeline: Semgrep для OWASP Top 10, npm audit для зависимостей, Gitleaks для секретов. LLM-аудит запускается отдельно на pre-merge review.
Полный чеклист из 15 пунктов, каждый с конкретной уязвимостью и вектором атаки: https://futurecraft.pro/ru/blog/ai-security-audit/
💯2
Forwarded from JourneyBay
JourneyBay теперь работает внутри ChatGPT 🚀 -> 💬
Планирование поездки больше не требует десятка вкладок. Опишите поездку словами прямо в ChatGPT - и JourneyBay соберёт всё в диалоге:
• «Создай поездку в Барселону на 4 дня»
• «Собери маршрут по дням»
• «Найди места с рамэном в Токио»
• «Покажи мои поездки»
• «Какой у меня на завтра маршрут?»
И многое другое.
В ответ открываются интерактивные карты, расписания дня и карточки мест - прямо в чате.
Как подключить: найдите «JourneyBay» в каталоге приложений ChatGPT.
Ссылка на App в ChatGPT💬
Напоминаем также, что JourneyBay можно подключить и в других агентов через MCP-сервер.
Планирование поездки больше не требует десятка вкладок. Опишите поездку словами прямо в ChatGPT - и JourneyBay соберёт всё в диалоге:
• «Создай поездку в Барселону на 4 дня»
• «Собери маршрут по дням»
• «Найди места с рамэном в Токио»
• «Покажи мои поездки»
• «Какой у меня на завтра маршрут?»
И многое другое.
В ответ открываются интерактивные карты, расписания дня и карточки мест - прямо в чате.
Как подключить: найдите «JourneyBay» в каталоге приложений ChatGPT.
Ссылка на App в ChatGPT
Напоминаем также, что JourneyBay можно подключить и в других агентов через MCP-сервер.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Команды принимают десятки архитектурных решений в месяц, а документируют единицы. Через полгода новый разработчик спрашивает: "Почему здесь Redis, а не PostgreSQL?"
Никто не помнит — два часа раскопок по Git и Slack ради решения, которое исходно заняло 15 минут.
Architecture Decision Records решают эту проблему. Один документ, одно решение, семь секций. Концепцию предложил Michael Nygard в 2011 году, но в большинстве команд ADR не пишут — оформление занимает 30-40 минут, а разработчик уже на следующей задаче. AI сжимает это до 3-5 минут.
Семь секций: Status, Date, Context, Decision, Consequences, Alternatives Considered, References.
Context — самая важная. "Выбрали Redis для кэширования" — ноль информации. "Выбрали Redis, потому что PostgreSQL LISTEN/NOTIFY не давал sub-millisecond latency при 10K RPS" — полная картина для будущего читателя.
Alternatives Considered — секция, которую чаще всего пропускают и которая приносит больше всего пользы. Через год кто-то спросит "а почему не Kafka?" — ответ уже записан.
Базовый промпт: три входа (решение, контекст проекта, формат с семью секциями) плюс жёсткие правила — активный залог, конкретные метрики вместо "быстрее/лучше", каждый пункт Consequences верифицируем. Без этих ограничений модель генерирует воду. Закрывает 80% случаев.
Специализированные варианты для остальных 20%: миграции добавляют Migration Strategy, Rollback Plan и Success Criteria; выбор технологии — таблицу Evaluation Criteria с весами и Proof of Concept; отказ от решения — What Changed и Lessons Learned.
Ретроспективная генерация. Для команд без единого ADR: скормить AI diff и комментарии PR, попросить найти архитектурное решение по критериям (новая зависимость, изменение схемы БД, новый паттерн, изменение API). Закрывает решения, принятые месяцы назад и не записанные вовремя.
CI-автоматизация. GitHub Action детектит архитектурные изменения и выдаёт warning, если PR не содержит ADR-файла. Предупреждение, не блокировка — блокировка убивает adoption быстрее, чем отсутствие документации.
Компаунд-эффект. Ключевые ADR попадают в CLAUDE.md или .cursorrules — AI-агент использует event bus вместо REST, потому что ADR-005 зафиксировал event-driven архитектуру.
Частые ошибки: абстрактный Context вместо цифр, scope на 10 решений в одном файле, неактуальный Status после замены решения, отсутствие Alternatives.
Метрики: ADR coverage >70% PR, Time-to-ADR <24ч, Reference rate >2/мес.
Шаблон, промпты, CI-конфиг и пример на реальном проекте: https://futurecraft.pro/ru/blog/adr-template-ai/
Никто не помнит — два часа раскопок по Git и Slack ради решения, которое исходно заняло 15 минут.
Architecture Decision Records решают эту проблему. Один документ, одно решение, семь секций. Концепцию предложил Michael Nygard в 2011 году, но в большинстве команд ADR не пишут — оформление занимает 30-40 минут, а разработчик уже на следующей задаче. AI сжимает это до 3-5 минут.
Семь секций: Status, Date, Context, Decision, Consequences, Alternatives Considered, References.
Context — самая важная. "Выбрали Redis для кэширования" — ноль информации. "Выбрали Redis, потому что PostgreSQL LISTEN/NOTIFY не давал sub-millisecond latency при 10K RPS" — полная картина для будущего читателя.
Alternatives Considered — секция, которую чаще всего пропускают и которая приносит больше всего пользы. Через год кто-то спросит "а почему не Kafka?" — ответ уже записан.
Базовый промпт: три входа (решение, контекст проекта, формат с семью секциями) плюс жёсткие правила — активный залог, конкретные метрики вместо "быстрее/лучше", каждый пункт Consequences верифицируем. Без этих ограничений модель генерирует воду. Закрывает 80% случаев.
Специализированные варианты для остальных 20%: миграции добавляют Migration Strategy, Rollback Plan и Success Criteria; выбор технологии — таблицу Evaluation Criteria с весами и Proof of Concept; отказ от решения — What Changed и Lessons Learned.
Ретроспективная генерация. Для команд без единого ADR: скормить AI diff и комментарии PR, попросить найти архитектурное решение по критериям (новая зависимость, изменение схемы БД, новый паттерн, изменение API). Закрывает решения, принятые месяцы назад и не записанные вовремя.
CI-автоматизация. GitHub Action детектит архитектурные изменения и выдаёт warning, если PR не содержит ADR-файла. Предупреждение, не блокировка — блокировка убивает adoption быстрее, чем отсутствие документации.
Компаунд-эффект. Ключевые ADR попадают в CLAUDE.md или .cursorrules — AI-агент использует event bus вместо REST, потому что ADR-005 зафиксировал event-driven архитектуру.
Частые ошибки: абстрактный Context вместо цифр, scope на 10 решений в одном файле, неактуальный Status после замены решения, отсутствие Alternatives.
Метрики: ADR coverage >70% PR, Time-to-ADR <24ч, Reference rate >2/мес.
Шаблон, промпты, CI-конфиг и пример на реальном проекте: https://futurecraft.pro/ru/blog/adr-template-ai/
🔥1