Unit economics большинства SaaS-продуктов - это три формулы в Google Sheets, которые никто не обновляет. LTV:CAC = 3.2, все довольны, расходимся. А потом churn растёт два месяца подряд - и никто не замечает, пока деньги не заканчиваются.

Проблема не в математике. Формулы элементарные: LTV = ARPU / Churn Rate, CAC = расходы / клиенты, Payback = CAC / (ARPU x Margin). Проблема в том, что статичная таблица даёт одну точку, а решения требуют диапазона.

Что происходит, если churn вырастет на 2%? Как изменится экономика при удвоении бюджета на рекламу? Какой эффект даст повышение цены на $10? Каждый такой вопрос в таблице - новая формула, новая ячейка, час работы. Или один промпт.

Разберём на конкретном примере. B2B SaaS, $11K MRR, два тарифа ($19 и $49), 420 клиентов:

- ARPU = $26.86
- LTV = $436 (при margin 78% и churn 4.8%)
- CAC = $120
- LTV:CAC = 3.6:1
- Payback = 5.7 месяцев

На первый взгляд - отличные показатели. Но sensitivity analysis через AI вскрывает три скрытые проблемы:

1. Logo churn 6.2% - выше бенчмарка для B2B. Средняя жизнь клиента 16 месяцев. При росте до 8% LTV падает до $340, а LTV:CAC - до 2.8:1.

2. Paid CAC сильно выше blended. Из 35 новых клиентов в месяц 12 приходят из органики. Paid CAC = $183, и LTV:CAC для платных каналов уже 2.4:1 - пограничная зона.

3. Дешёвый тариф захватывает долю. 74% клиентов на $19 (было 68% три месяца назад). Тренд продолжится - ARPU упадёт, paid LTV:CAC уйдёт ниже 2:1.

Ни одна из этих проблем не видна в статичной таблице. Все три - очевидны при запуске 30+ сценариев через промпт.

Ключевой инсайт из sensitivity analysis: для большинства SaaS churn влияет на LTV сильнее, чем цена. Снижение churn на 1% даёт больший прирост, чем повышение цены на $5. При этом усилия распределяются наоборот: недели на ценообразование, минимум на retention.

Минимальный набор для мониторинга - три числа: LTV:CAC, Payback Period, Monthly Churn. Обновление раз в месяц. Этого достаточно, чтобы видеть тренд и реагировать вовремя.

Бенчмарки для ориентира:
- LTV:CAC < 1:1 - убыток. 3:1 - норма. > 5:1 - недоинвестируете в рост
- Payback > 18 мес - вопрос, хватит ли денег. < 6 мес - сильный сигнал
- Net Revenue Retention > 100% - рост без новых клиентов

Подробный гайд с промптами - в блоге: https://futurecraft.pro/ru/blog/unit-economics-calculator-ai/

Мульти-агентная система из 5 агентов обходится дешевле, чем один большой промпт. Это не интуитивно, но объяснимо.

Почему один агент не справляется

Возьмём задачу "спланируй поездку в Японию на 10 дней". Один агент должен: понять намерение (NLU), найти достопримечательности (поиск), построить маршрут (оптимизация), написать описания (генерация текста), проверить на ошибки (валидация). Каждый шаг требует разную температуру, иногда разную модель. NLU - 0. Генерация текста - 0.7. Оптимизация - reasoning-модель вроде o3.

Один промпт на 3000+ токенов с противоречивыми инструкциями даёт непредсказуемое поведение. Отладить конкретный шаг невозможно.

Правило: больше двух шагов с разными требованиями к модели - пора разделять на агентов.

Три паттерна оркестрации

1. Sequential Pipeline - агенты в цепочке, выход одного = вход следующего. Просто, предсказуемо, легко отлаживать. Минус: время = сумма всех шагов, нет параллелизма.

2. Fan-Out / Fan-In - несколько агентов работают параллельно над разными аспектами одной задачи. Время = самый медленный агент. Подходит для code review, мульти-аспектного анализа, валидации с разных точек зрения.

3. Router - агент-маршрутизатор на дешёвой модели классифицирует запрос и направляет к специализированному агенту. Как API gateway в микросервисах. 80%+ запросов обрабатываются дешёвыми агентами.

Специализация: кто что делает

Типичный набор для продукта:
- Classifier (Gemini Flash, temp 0) - определение intent, ~200 токенов промпт
- Extractor (DeepSeek Chat, temp 0) - извлечение данных, ~500 токенов
- Planner (Claude Sonnet / o3, temp 0.3) - генерация планов, ~1500 токенов
- Writer (Gemini Flash, temp 0.7) - текст для пользователя, ~800 токенов
- Validator (GPT-4o, temp 0) - проверка JSON-схемы и фактов, ~400 токенов
- Judge - оценка качества output по критериям, не генерация контента

Почему pipeline дешевле

Один агент на Claude Sonnet: ~3000 input + ~2000 output токенов = ~$0.025.
Pipeline из 5 агентов с mix моделей: ~2500 input + ~1800 output = ~$0.008.

Classifier на Flash - $0.0001 за вызов. Extractor на DeepSeek - $0.00014/1M input. Дорогую модель использует только Planner, и его промпт короче - параметры уже извлечены. Экономия 60-70%.

Что ломает мульти-агентные системы

- Over-engineering: три агента для задачи, которую решает один промпт с structured output
- Нет fallback: один агент недоступен - весь pipeline мёртв
- Слишком длинные цепочки: 8 агентов x 3 секунды P95 = 24 секунды на ответ
- Нет circuit breaker: агент вернул битый JSON, следующий его получил, оркестратор сделал 3 retry - потрачены токены впустую

С чего начать: Classifier + Worker. Classifier определяет тип задачи на дешёвой модели, Worker обрабатывает на подходящей. Добавить structured output (Pydantic-схемы) и трейсинг (Langfuse). Потом - Judge-агент для автоматической оценки качества.

Подробный гайд с примерами кода в блоге: https://futurecraft.pro/ru/blog/multi-agent-architecture/

Промпты в production ломаются молча. Кто-то поправил системный промпт классификатора, accuracy упала с 0.94 до 0.81, но узнали об этом через неделю - по жалобам пользователей. Потому что промпт лежал в коде, без версионирования, без тестов, без привязки к метрикам.

При 20-50 промптах в проекте это становится системной проблемой. Три человека редактируют один файл: продакт правит тон, ML-инженер режет токены, разработчик рефакторит шаблон. Результат непредсказуем.

Четыре слоя prompt engineering system:

1. Registry - централизованное хранилище. Каждый промпт: имя, версия (автоинкремент), лейбл (production/staging), переменные, параметры модели. Два подхода: Langfuse из коробки или YAML-файлы в Git с CI-синхронизацией в Langfuse

2. Testing - eval pipeline перед деплоем. Датасет из 20-30 примеров на каждый промпт. Скрипт прогоняет новую версию, считает accuracy, блокирует merge если ниже порога. Запускается в CI автоматически при изменении файлов в prompts/

3. Deploy - доставка без деплоя кода. Три стратегии:
- Мгновенное переключение - сменить лейбл на production, приложение подхватит
- Canary - 5% трафика на новую версию, сравнение метрик в реальном времени
- Feature flags - таргетирование по пользователям, сегментам, регионам

4. Monitor - версия промпта в метаданных каждого LLM-вызова. Дашборд: accuracy, latency p95, token usage, error rate, cost per request. Алерт при деградации больше 10% от baseline, автоматический откат к предыдущей версии

Паттерны организации:

- Композиция вместо монолитов. Промпт на 3000 токенов - кошмар для тестирования. Разбить на компоненты: core-логика, output-format, language-rules. Каждый компонент тестируется и версионируется отдельно

- Naming convention: {domain}-{task}-{variant}. Без этого при 50 промптах наступает хаос: ticket-classifier-v2, order-summarizer-short, quality-judge-relevance

- Метаданные: owner, model_compatibility, avg_tokens, cost_per_call, test_accuracy, dataset_size. Без них аудит невозможен

Пороги масштабирования:
- 10 промптов - нужен registry
- 30 промптов - нужен CI eval
- 50 промптов - нужен RBAC
- 100 промптов - нужен автооткат

С чего начать за 4 недели:
- Неделя 1: инвентаризация - собрать все промпты в единый формат
- Неделя 2: датасеты - 20-30 примеров на промпт из production-логов
- Неделя 3: eval pipeline в CI
- Неделя 4: версия промпта в каждом трейсе + дашборд + алерты

Подробный гайд с кодом и шаблонами в блоге: https://futurecraft.pro/ru/blog/prompt-engineering-system/

78% откликов на вакансии в LinkedIn - от кандидатов, которые не соответствуют требованиям. На hh ситуация аналогичная. Рекрутеры тратят 23 часа в неделю на скрининг нерелевантных резюме. Причина - сами тексты вакансий.

Что не так с типичной вакансией

Три источника текста: шаблон с прошлого найма, список требований от тимлида, корпоративное описание из HR. Результат предсказуем:

- 10-12 технологий в требованиях без приоритизации. Кандидат не понимает, что используется ежедневно, а что вписали «на всякий случай»
- Обязанности описывают любую backend-позицию в мире: «разработка серверной части, проектирование API, код-ревью»
- «Конкурентная зарплата» и «дружный коллектив» - информационный ноль
- Нет контекста задач: что делать в первый месяц, какую проблему решает команда, почему открылась позиция

Сильные специалисты пропускают вакансию, если не попадают в 100% списка. Слабые откликаются на всё подряд. ATS фильтрует по ключевым словам - кандидаты вставляют ключевые слова белым шрифтом. Обе стороны оптимизируют под алгоритм, а не под качество найма.

Что работает

Конкретные задачи вместо абстрактных обязанностей. Не «разработка высоконагруженных систем», а «перевести монолит биллинга (PostgreSQL, 50M транзакций/месяц) на event-driven архитектуру за 6 месяцев». Кандидат за 30 секунд оценивает: интересно, по силам, хочу.

Разделение must-have и nice-to-have. Максимум 5 обязательных, максимум 5 желательных. Исследование LinkedIn: женщины откликаются при соответствии 100% требований, мужчины - при 60%. Чёткое разделение расширяет воронку.

Прозрачность условий. Зарплатная вилка, формат работы, размер команды, стек в продакшне. Каждый скрытый параметр - это отказ на этапе оффера.

Двухшаговая генерация через LLM

Инженеры понимают задачу, но не пишут тексты. HR пишет, но не знает контекста. LLM закрывает этот разрыв.

Шаг 1 - сбор сырых данных: 5-10 минут голосового от нанимающего менеджера, текущий стек, контекст команды, причина открытия позиции, провалы прошлого найма.

Шаг 2 - генерация с ограничениями: начать с задачи (не с компании), разделить требования, описать первые 3 месяца, запретить клише («динамично развивающаяся», «лидер рынка», «проактивный»).

Шаг 3 - ревью вторым промптом. Проверяет конкретность, фильтрацию, клише, баланс требований, прозрачность условий. Двухшаговый подход стабильно превосходит одноразовую генерацию.

Типичные ошибки

LLM раздувает требования - добавляет технологии, которых нет во входных данных. Генерирует восторженный тон: «уникальная возможность», «невероятная команда». Явно ограничивай и то, и другое в промпте.

Не адаптировать под площадку - LinkedIn (лимит 2600 символов) и hh.ru (структурированные поля) требуют разного формата.

Пропускать ревью менеджера - AI не знает, что «Kafka - это планы на следующий год, а не текущий стек».

Метрики

Конверсия просмотр-отклик: целевой 8-15%. Доля релевантных откликов: до AI - 15-25%, после - 40-60%. Сохраняй связку «текст вакансии - результат найма» для каждой позиции.

Подробный гайд с промптами и примерами в блоге: https://futurecraft.pro/ru/blog/ai-job-descriptions/

В 68% компаний до 200 человек интервью проходят без подготовленных вопросов. Интервьюер импровизирует, кандидат получает рандомный опыт, решение принимается на ощущениях.

Structured interview kit - это четыре компонента, которые превращают хаотичный процесс в воспроизводимую систему.

Матрица компетенций - список навыков, привязанных к этапам интервью. Каждая компетенция - один этап, один интервьюер. Без матрицы два человека задают одинаковые вопросы, пропуская критичные области. Типичная матрица: 6-8 компетенций, разделённых на hard и soft skills, с весами - critical, important, nice-to-have.

Вопросы по компетенциям - behavioral (прошлый опыт) и situational (гипотетические сценарии). Каждый вопрос тестирует ровно одну компетенцию. Если вопрос проверяет две - его невозможно нормально оценить. К каждому вопросу идут follow-up, критерии сильного ответа и red flags.

Пример для компетенции "Приоритизация":
- Behavioral: "Расскажите о ситуации, когда запросов было больше, чем ресурсов. Как решали, что попадёт в релиз?"
- Red flag: "Я делал всё, что просил CEO" - нет самостоятельности в принятии решений.

Scorecard - шкала от 1 до 4 с конкретными индикаторами на каждом уровне. "Хорошие коммуникативные навыки" - плохой индикатор. "Структурировал ответ, назвал цифры, задал уточняющий вопрос" - хороший. Scorecard заполняется сразу после интервью, до разговора с другими интервьюерами. Иначе срабатывает эффект якоря.

Debrief agenda - структура финальной встречи. Порядок:
1. Каждый зачитывает оценки (без обсуждения до конца раунда)
2. Модератор выносит расхождения в 2+ балла
3. Обсуждение red flags и рисков
4. Голосование: Strong Yes / Yes / No / Strong No

Порядок выступлений: от junior к senior. Если первым говорит CTO и ставит Strong Yes, остальные подсознательно подтягивают оценки вверх.

AI генерирует весь kit за 30 минут. Ключевое - качество промпта. Чем точнее описана позиция, стек, культура компании, тем релевантнее результат. После 10+ наймов накапливается библиотека проверенных вопросов с реальными примерами сильных и слабых ответов.

Три уровня автоматизации:
- Шаблоны промптов в базе знаний команды - экономят 3-4 часа на вакансию
- Библиотека вопросов - AI подбирает из проверенных, а не генерирует с нуля
- Интеграция с ATS - scorecards в системе, автоматический анализ расхождений

Structured interview - не бюрократия. Это воспроизводимость: одинаковые вопросы, единая шкала, решения на данных.

Подробный гайд с промптами и шаблонами в блоге: https://futurecraft.pro/ru/blog/structured-interview-kit/

Ручной анализ 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/

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/

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/

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/

Из 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/

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/

Три раунда по 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%.

Это не плохие условия. Это стандартная математика привлечения капитала.

Формула кумулятивного размытия

Итоговая доля = Начальная доля 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/

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. Явно указать "не пиши реализацию". Второй: отдельный промпт на минимальную реализацию, которая проходит все тесты. Третий: рефакторинг под защитой тестов. Четвёртый: новые требования - новые тесты, цикл повторяется.

Паттерны, которые работают. Один тест = одно поведение. Типизированные ожидания: 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/

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-х ошибок, переполнение типов, идемпотентность. Пример: функция скидок проверяет 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-продуктов собирают аналитику, которую невозможно использовать. Не из-за плохих инструментов, а потому что никто не договорился о правилах именования событий.

Один разработчик пишет 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/

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/

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

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/