Весь каталог целиком

Ты — продуктовый стратег, который видел много закрытых проектов. Разбери мою идею SaaS честно, не подбадривая.

Идея: {что за сервис}
Кому: {для кого, максимально узко}
Какую работу человек делает сейчас без нас: {как решают эту задачу сегодня}
Как планирую брать деньги: {модель и цена}
Сколько времени и денег готов вложить до первых денег: {ресурс}

Разбери:
1. Проблема: она болит регулярно или это разовое неудобство? Отвечай прямо.
2. Кто платит: сам пользователь или его руководитель — и почему это меняет продукт.
3. Три главных риска: почему проект может не взлететь. Для каждого — как проверить его дешевле всего.
4. Что уже есть на рынке, включая Excel, блокнот и «ничего не делать» — их тоже считай конкурентами.
5. Самое опасное допущение: если оно неверно, всё остальное бессмысленно.
6. План проверки на неделю: что сделать по дням, чтобы получить сигнал без кода.
7. Критерий отказа: какой результат означает, что идею надо бросить.

Если идея слабая — скажи это в первом абзаце.

Помоги очертить MVP так, чтобы его можно было выпустить и продавать.

Продукт: {что делает сервис}
Главный сценарий: {что пользователь делает от входа до результата}
Кто пользователь: {описание}
Сколько времени на разработку: {срок}
Кто разрабатывает: {один разработчик / команда / без кода}

Сделай:
1. Один путь пользователя от регистрации до первой пользы — по шагам, без ветвлений.
2. Функции, без которых этот путь не работает. Каждая — с обоснованием, почему без неё нельзя.
3. Функции, которые кажутся обязательными, но в MVP не нужны — и чем их заменить временно (ручная работа, письмо, таблица).
4. Что вырезать совсем и почему это не помешает продавать.
5. Границы: чего продукт НЕ делает. Формулировки для сайта, чтобы не было ложных ожиданий.
6. Оценка объёма в неделях с разбивкой и с указанием, где оценка самая ненадёжная.
7. Что можно делать руками первые месяцы вместо автоматизации.

Правило: если функцию можно на старте заменить человеком — в MVP её не включай.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

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

Что за продукт: {описание}
Что я умею: {языки и инструменты, честно}
Срок до запуска: {время}
Кто будет поддерживать: {я один / команда / подрядчик}
Особые требования: {платежи, файлы, реальное время, офлайн, интеграции}
Бюджет на инфраструктуру в месяц: {сумма}

Разбери:
1. Рекомендуемый набор: фронтенд, бэкенд, база, хостинг, авторизация, платежи, почта.
2. Для каждого пункта — почему именно он в моей ситуации и какая разумная альтернатива.
3. Цена выбора: что станет неудобно через год.
4. Что можно не писать самому, а взять готовым сервисом, и сколько это стоит.
5. Чего избегать именно в моём случае и почему.
6. Оценка счёта за инфраструктуру на 100, 1000 и 10 000 пользователей.
7. Что из выбранного будет тяжелее всего заменить потом — и как уменьшить эту привязку.

Учитывай мои навыки: незнакомая технология в короткий срок — это риск, а не преимущество.

Напиши первый экран лендинга для SaaS-продукта.

Продукт: {что делает}
Для кого: {узкая аудитория}
Какую работу заменяет: {что человек делает сейчас}
Главная выгода в цифрах: {экономия времени, денег, ошибок}
Модель: {бесплатный тариф / пробный период / только платно}
Чем отличается от ближайшего конкурента: {факт}

Дай:
1. Пять вариантов заголовка: понятных, а не остроумных. Без метафор и без слова «платформа».
2. К каждому — подзаголовок: для кого и что произойдёт после регистрации.
3. Текст на кнопке — три варианта, разной степени обязательности.
4. Подпись под кнопкой, снимающая страх: карта, отмена, время на настройку.
5. Три доказательства рядом с первым экраном, которые можно показать без клиентской базы.
6. Что убрать: типичные фразы, которые ничего не сообщают.
7. Проверка: прочитайте заголовок вслух и скажите, поймёт ли его человек, впервые услышавший о продукте.

Пиши так, чтобы из заголовка было ясно, что продукт делает, даже без картинки.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Преврати список изменений в заметки о релизе и письмо пользователям.

Изменения: {вставьте список коммитов, задач или своих заметок}
Продукт: {что делает}
Кто читает: {технические пользователи / обычные}
Есть ли ломающие изменения: {да, какие / нет}
Что нужно сделать пользователю: {ничего / обновить настройки / перейти на новое}

Сделай:
1. Заметки о релизе: сгруппировать по «новое», «стало лучше», «исправили». Каждый пункт — на языке пользы, а не кода.
2. Ломающие изменения — отдельным блоком в начале, с точным сроком и инструкцией.
3. Письмо: тема, первая строка, три абзаца, одна кнопка. Про одно главное изменение, остальные — ссылкой.
4. Короткий пост для соцсетей о самом заметном.
5. Что из списка пользователям вообще не нужно сообщать — и почему.
6. Проверка тона: убрать «мы усердно работали» и «рады сообщить», оставить, что теперь можно делать.

Правило: пункт «исправили ошибки» без уточнения не пишем — либо конкретно, либо не упоминаем.

Подбери метрики для моего продукта под текущую стадию.

Продукт и модель: {что и как платят}
Стадия: {нет пользователей / первые клиенты / стабильные продажи}
Сколько платящих сейчас: {число}
Что уже считаю: {список}
Главный вопрос, на который нужен ответ: {например «стоит ли вкладываться в рекламу»}

Сделай:
1. Пять-семь метрик, и не больше. Для каждой: что показывает, как считается, как часто смотреть.
2. Почему остальные популярные метрики на моей стадии только отвлекают.
3. Одно число, по которому видно, здоров ли продукт, — и как его считать именно у меня.
4. Ориентиры: какое значение считать плохим, нормальным и хорошим для моей модели.
5. Как каждую метрику можно случайно обмануть и что смотреть рядом, чтобы этого не вышло.
6. Что записывать в продукте уже сейчас, чтобы через полгода было что анализировать.
7. Какое решение я приму, если метрика уйдёт в минус, — по каждой.

Если метрика ни к какому решению не ведёт — не включай её.

Ты — руководитель поддержки. Напиши шаблоны ответов.

Продукт: {что это}
Частые обращения: {перечислите пять-семь}
Тон общения: {как разговариваете с клиентами}
Что можете и чего не можете: {границы — возвраты, доступ, сроки}

Для каждого обращения выдай:
1. Ответ до шести строк: суть в первой.
2. Что уточнить, если данных не хватает, — одним вопросом, а не списком.
3. Вариант, когда виноваты мы: без «приносим извинения за доставленные неудобства».
4. Вариант, когда помочь нельзя: что предложить взамен.
5. Пометку, когда шаблон использовать нельзя и нужен живой ответ.

Шаблон обязан оставлять место для одной живой фразы: письмо, целиком собранное из заготовки, читается как автоответчик.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Ты — технический писатель. Напиши страницу подключения.

Что подключают: {функция или API}
Кто читает: {уровень читателя}
Что нужно получить заранее: {ключи, доступы}
Частые ошибки: {что ломается у людей}

Структура:
1. Что получится в результате — одним абзацем и одним примером ответа.
2. Что понадобится до начала: список из трёх-четырёх пунктов.
3. Минимальный рабочий пример: столько кода, сколько нужно, чтобы увидеть первый ответ, и ни строкой больше.
4. Разбор ответа по полям: что означает каждое и какие бывают значения.
5. Ошибки: код, что означает, что делать. Таблицей.
6. Ограничения: частота запросов, размеры, сроки жизни ключей.
7. Что делать, если не работает: три проверки по порядку.

Первый пример должен запускаться копированием: если для этого надо что-то дописать, читатель уйдёт в поддержку.

Ты — специалист по онбордингу. Напиши цепочку писем на пробный период.

Продукт: {что это}
Длительность триала: {дней}
Момент первой пользы: {что человек должен сделать, чтобы понять ценность}
Где люди застревают: {перечислите}
Что происходит в конце: {списание / блокировка / урезание}

Для каждого письма:
1. День отправки и повод — не «третий день триала», а событие.
2. Тема до 45 знаков.
3. Текст до восьми строк, одно действие в конце.
4. Кому это письмо не отправлять: тому, кто уже сделал это действие.

Обязательно:
5. Письмо для тех, кто ни разу не заходил после регистрации.
6. Письмо за два дня до конца: что именно человек потеряет, конкретно.
7. Письмо после окончания, если не оплатил, — без давления.

Цепочка ведёт к первой пользе, а не к оплате: не дошедший до неё не заплатит, сколько ни напоминай.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Ты — инженер, который ведёт разбор инцидентов. Составь разбор.

Что произошло: {опишите}
Когда заметили и как: {кто первым увидел}
Сколько длилось: {время}
Кого затронуло: {сколько людей, что не работало}
Как починили: {что сделали}

Выдай:
1. Хронологию по минутам: когда началось, когда заметили, когда починили.
2. Что именно сломалось — техническая причина одним абзацем.
3. Почему это стало возможно: не «разработчик ошибся», а чего не хватало в устройстве системы, чтобы ошибка не долетела до людей.
4. Почему заметили не сразу — и как узнать раньше в следующий раз.
5. Три действия: что сделать сегодня, на этой неделе, в этом квартале.
6. Что делать не надо, хотя первым приходит в голову.

Ни одной фамилии: разбор, который ищет виноватого, в следующий раз просто не состоится — люди перестанут сообщать о проблемах.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Ты — продуктовый дизайнер. Замени обучающий тур подсказками по месту.

Продукт: {что это}
Что сейчас в онбординге: {тур, видео, ничего}
Где люди застревают: {если знаете}
Ключевое действие: {что должны сделать}

Выдай:
1. Три-четыре момента, где нужна подсказка. Момент — это не экран, а состояние: пусто, первый раз, после ошибки, перед необратимым действием.
2. Для каждого: что показать, в одном предложении, и куда. Подсказка живёт рядом с элементом, а не в центре экрана.
3. Условие показа и условие исчезновения навсегда. Подсказка, которая возвращается на десятый раз, — раздражитель.
4. Что вместо подсказки решается интерфейсом. Если поле нуждается в объяснении, чаще дешевле переименовать поле.
5. Что убрать из тура целиком. Тур при первом входе смотрят 20% и не помнят ничего: человек ещё не знает, зачем ему это.
6. Как не мешать опытным: способ закрыть всё разом.
7. Что мерить: доля дошедших до ключевого действия, до и после.

Правило: подсказка появляется, когда человек уже пытается что-то сделать. До попытки объяснять нечего — ему ещё не нужно.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Ты — продуктовый аналитик. Разбери ответы опроса.

Что спрашивали: {формулировка}
Оценки и комментарии: {вставьте}
Сколько ответило и из скольких: {числа}
Продукт: {что это}

Разбери:
1. Кто отвечал. Отвечают крайности — очень довольные и очень злые. Середина молчит, и её в этих данных нет.
2. Темы в комментариях с числом упоминаний. Одно упоминание — не тема.
3. Что из названного вы правда собираетесь чинить, а что нет. Список, который никто не собирается делать, хуже отсутствия списка.
4. Кому ответить лично и что написать: низкие оценки с внятным комментарием — это бесплатное интервью, если написать в тот же день.
5. Что сделать с высокими оценками: попросить отзыв или рекомендацию, но не в том же письме, где благодарите.
6. Одно изменение в продукте на ближайший месяц.
7. Что спросить в следующий раз, чтобы данные были полезнее.

Само число оценки не решает ничего. Решают комментарии и то, кто именно их написал: жалоба крупного клиента и жалоба на бесплатном тарифе стоят разного.

Ты — маркетолог продукта. Напиши страницу для переходящих с конкурента.

Ваш продукт: {что это}
Конкурент: {кто}
Чем вы лучше именно для его пользователей: {реальные отличия}
Чем он лучше вас: {честно}
Что мешает переехать: {данные, привычка, договор}

Напиши:
1. Заголовок без выпадов в сторону конкурента. Человек им пользуется — критика звучит как обвинение в глупом выборе.
2. Три отличия, важные именно его пользователям. Не общий список функций, а то, на что жалуются в его сообществе.
3. Признание того, в чём он лучше. Страница без этого не вызывает доверия: люди знают продукт, которым пользуются.
4. Что происходит с данными при переезде: можно ли перенести, за сколько времени, кто делает.
5. Первые 15 минут после перехода: что человек увидит и что успеет.
6. Кому переезжать не стоит. Это отсекает тех, кто вернётся недовольным и напишет отзыв.
7. Таблица сравнения — если она честная. Таблица, где у вас все галочки, читается как реклама и не работает.

Не сравнивайте цены как единственный довод. Тот, кто переехал ради цены, уедет от вас так же — за той же ценой.

Ты — редактор интерфейсов. Перепиши тексты ошибок.

Продукт: {что это}
Список ошибок: {как звучат сейчас}
Кто пользуется: {аудитория}

Для каждой ошибки:
1. Что произошло — без технических слов, если человек не технический.
2. Что делать прямо сейчас. Одно действие. «Обратитесь в поддержку» — не действие, а перекладывание.
3. Чья вина. Свою признавайте прямо: «это на нашей стороне» снимает раздражение лучше извинений.
4. Что случилось с данными, которые человек уже ввёл. Самый частый страх — что всё пропало.
5. Где показать: у поля, полосой сверху, окном. Окно — только для необратимого.
6. Что писать в лог, а что человеку. Код ошибки нужен поддержке, а не читателю, но пусть будет мелким шрифтом внизу.
7. Три ошибки, которые надо не переписать, а убрать: их можно предотвратить интерфейсом.

Не пиши «что-то пошло не так». Это самая бесполезная фраза в интерфейсах: не сообщает ничего и звучит как отговорка.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Ты — технический писатель. Напиши страницу быстрого старта.

Продукт: {что это}
Кому: {разработчик, аналитик, обычный пользователь}
Что человек должен получить в конце: {результат}
Что нужно до начала: {ключ, аккаунт, установка}

Напиши:
1. Что получится в конце — первой строкой, до всяких вступлений. Человек должен понять, стоит ли тратить десять минут.
2. Что нужно до начала, списком. Не в середине, где это обнаружится на четвёртом шаге.
3. Шаги. Каждый — одно действие и одна проверка: как понять, что шаг удался. Шаг без проверки заканчивается тем, что человек идёт дальше со сломанным состоянием.
4. Готовый код или готовые значения, которые можно скопировать целиком и запустить. Плейсхолдеры вида «ваш_ключ» — единственное, что человек меняет.
5. Что пойдёт не так у половины: три частые ошибки и что при них делать, прямо на этой странице, а не в разделе «решение проблем».
6. Что дальше — три ссылки, не больше.
7. Чего здесь быть не должно: архитектуры, объяснений, почему всё устроено именно так, полного списка параметров.

Проверка страницы: дайте её человеку, который продукт не видел, и молча смотрите. Каждое место, где он остановился, — правка.

Ты — исследователь. Подготовь разговор с ушедшим клиентом.

Продукт: {что это}
Кто ушёл: {сегмент, сколько платил, сколько был с вами}
Что известно из данных: {последние действия}
Что хотите понять: {решение, которое от этого зависит}

Подготовь:
1. Как позвать: письмо в три строки, без обещания подарка. Подарок приводит вежливые ответы вместо честных.
2. Первый вопрос — не «почему вы ушли». На него отвечают заготовкой. Начните с того, что человек делал в продукте в последний месяц.
3. Восемь вопросов про факты, а не про мнения: что делали, чем заменили, кто принимал решение, что было последней каплей.
4. Вопрос про альтернативу: чем пользуетесь сейчас и что там лучше. Ответ на него полезнее всей остальной беседы.
5. Что не спрашивать: вернётесь ли, что нам улучшить. Оба вопроса дают вежливую неправду.
6. Как реагировать на критику: не защищаться и не чинить на ходу. Один раз возразили — человек перестал говорить.
7. Что сделать после: чего не обещать и что написать в благодарности.

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

Ты — редактор. Напиши письма про деньги.

Продукт и цена: {что и сколько}
Как устроена подписка: {период, автопродление}
Что сейчас отправляете: {как есть}

Напиши пять писем:
1. Оплата прошла: что оплачено, на какой срок, сумма, где чек. Короткое, но со всеми числами — его сохраняют.
2. Скоро автопродление: за 3-5 дней, с суммой и датой. Это письмо предотвращает больше споров по картам, чем любая страница условий.
3. Продление прошло: то же, что первое, но без поздравлений.
4. Подписка заканчивается и не продлится: что перестанет работать и что останется.
5. Возврат: подтверждение, сумма, срок зачисления, что с доступом.

Для каждого: тема до 40 символов, тело до 100 слов, одна кнопка.

Правила: сумма и дата в первых двух строках; ссылка на отмену в каждом письме про деньги; никаких предложений купить больше в письме о списании — это выглядит как торговля на чужом кошельке.

Письмо о предстоящем списании — самое важное. Его пропускают ради «чтобы не отпугнуть», а потом получают возвраты и споры.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Ты — продуктовый маркетолог, который пишет FAQ из настоящих вопросов, а не из удобных.

Продукт: {что делает}
Цена и модель: {подписка, тариф}
Кто покупает: {аудитория}
Что спрашивают в поддержке до покупки: {реальные вопросы, если есть}
Чего боятся: {главное сомнение}

Собери:
1. Десять вопросов в том виде, как их задаёт человек, — со сленгом и сомнением, а не в корпоративной формулировке.
2. Порядок: от самого частого к редкому. Первые три решают, дочитают ли остальные.
3. Ответы: два-три предложения, прямо. Если ответ «нет» — так и пиши, а потом объясняй, что есть взамен.
4. Три неудобных вопроса, которые обычно прячут: про отмену, про перенос данных, про то, что будет, если вы закроетесь. Ответ на них поднимает доверие сильнее рекламы.
5. Где во всём этом место ссылке: на тариф, на документацию, на живого человека.
6. Что НЕ включать: вопросы, придуманные ради ключевых слов. Они видны сразу и портят впечатление.
7. Как понять, каких вопросов не хватает: три способа собрать их из реальности.

Не пиши маркетинговый ответ на технический вопрос. Человек, спросивший про экспорт данных, хочет узнать про экспорт, а не про вашу миссию.

Ты — руководитель поддержки, который пишет сообщения об авариях так, чтобы люди не разбегались.

Что сломалось: {функция или сервис}
Кого затронуло: {всех / часть / определённые тарифы}
Когда началось: {время}
Что известно о причине: {или «выясняем»}
Когда починим: {оценка или «пока не знаем»}
Теряются ли данные: {да / нет / выясняем}

Напиши три текста:
1. Первое сообщение, в первые 15 минут: что не работает, кого касается, когда следующее обновление. Причину знать не обязательно — важно показать, что вы видите проблему.
2. Обновление по ходу: что уже сделали, что осталось. Без технических подробностей, которые ничего не значат для клиента.
3. Итоговое: что это было, что чинили, что сделаем, чтобы не повторилось.

Плюс:
4. Что говорить, если не знаете срок. Врать нельзя, молчать нельзя — как сформулировать.
5. Отдельная строка про данные: этот вопрос задают первым, даже если не пишут о нём.
6. Чего не писать никогда: пять формулировок, после которых клиенты злятся сильнее.
7. Кому и когда написать лично, а не только повесить на статусной странице.

Пиши как человек, а не как юридический отдел. «Мы сожалеем о доставленных неудобствах» — это не извинение.

Ты — исследователь, который проводит интервью так, чтобы получить факты, а не вежливые похвалы.

Что хочу узнать: {вопрос, ради которого всё затевается}
С кем говорю: {кто эти люди}
Есть ли уже продукт: {да / нет / прототип}
Сколько времени на разговор: {минуты}

Собери:
1. Главный вопрос исследования одной строкой. Если их несколько — скажи, что интервью развалится, и помоги выбрать один.
2. Разогрев: два вопроса, после которых человек начнёт рассказывать, а не отвечать односложно.
3. Двенадцать вопросов о прошлом: что делал, когда столкнулся, чем решил, сколько потратил. Только о том, что уже случилось.
4. Запрещённые вопросы: список из пяти, которые здесь напрашиваются, но дают ложь. «Вы бы пользовались?» — первый из них. Объясни, почему они не работают.
5. Как копать вглубь: три фразы, которыми продолжают рассказ, не подсказывая ответ.
6. Что делать, если человек начал хвалить продукт: как вернуть разговор к фактам.
7. Последний вопрос, который часто даёт больше всего.
8. Что записывать во время и что разобрать сразу после, пока помнится.

Не спрашивай про будущее и про гипотетическое. Люди не умеют предсказывать своё поведение, и это не их вина.

Ты — продуктовый экономист, который помогает выбрать модель доступа, считая деньги.

Продукт: {что делает}
Сколько стоит обслуживать одного бесплатного пользователя: {сумма в месяц}
Сколько времени нужно, чтобы понять ценность: {минуты / дни / недели}
Средний чек: {сумма}
Есть ли сетевой эффект: {да / нет}
Кто покупает: {человек за свои / компания}

Разбери:
1. Три модели: бесплатный тариф навсегда, пробный период, бесплатно с ограничением по объёму. Для каждой — при каких условиях она работает.
2. Что говорит за и против каждой конкретно в моём случае. Со ссылкой на мои цифры, а не общими словами.
3. Главный вопрос: сколько времени нужно человеку, чтобы понять ценность. Если это недели — пробный период на 7 дней бессмысленен, объясни почему.
4. Стоимость бесплатных: посчитай, во что обойдётся тысяча бесплатных пользователей в месяц и при какой доле оплат это окупается.
5. Где провести границу: какая возможность остаётся бесплатной, а какая нет. Правило, по которому это решают.
6. Что будет через год при каждой модели: сколько бесплатных накопится и не съедят ли они прибыль.
7. Рекомендация одной строкой с оговоркой, при каком изменении её пересмотреть.

Не советуй бесплатный тариф просто потому, что он у конкурентов. У них может быть другая экономика.

Ты — продуктовый редактор, который пишет дайджесты изменений так, чтобы их открывали второй раз.

Что сделали за неделю: {список изменений как есть, из задач}
Кому пишем: {все / определённые тарифы}
Есть ли что-то, что сломалось: {да / нет}

Собери:
1. Отбор: что вообще идёт в письмо. Не всё подряд — правило, по которому решают, полезное тут изменение или внутреннее.
2. Порядок: с чего начать. Первым идёт то, что меняет чью-то работу, а не то, над чем больше трудились.
3. Каждый пункт: одна строка о том, что теперь можно, а не что мы сделали. «Добавили фильтр по дате» — про нас. «Отчёт за произвольный период — в два клика» — про них.
4. Мелочи: собрать в один блок «по мелочи», а не растягивать письмо.
5. Исправления: как писать о починенном, не подчёркивая, что оно было сломано, но и не пряча.
6. Тема письма: конкретная, из главного изменения, без слова «обновление».
7. Одна ссылка на действие: что человек может сделать прямо сейчас.
8. Длина: сколько экранов телефона это должно занимать. Назови предел и держись его.

Не пиши «мы рады сообщить». Никому не интересно, чему вы рады.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.

Role: {specialist}, {years} years in {niche}.
Task: prepare {deliverable} for {audience}.

Context:
— channel: {channel}
— goal: {goal}
— constraints: {constraints}

Answer format:
1. {first block}
2. {second block}
3. {third block}

Tone: {tone}. Length: {length}.