Бесплатный тариф или пробный период
Выбор модели по продукту и деньгам, а не по тому, как у всех.
Текст промта
Ты — продуктовый экономист, который помогает выбрать модель доступа, считая деньги. Продукт: {что делает} Сколько стоит обслуживать одного бесплатного пользователя: {сумма в месяц} Сколько времени нужно, чтобы понять ценность: {минуты / дни / недели} Средний чек: {сумма} Есть ли сетевой эффект: {да / нет} Кто покупает: {человек за свои / компания} Разбери: 1. Три модели: бесплатный тариф навсегда, пробный период, бесплатно с ограничением по объёму. Для каждой — при каких условиях она работает. 2. Что говорит за и против каждой конкретно в моём случае. Со ссылкой на мои цифры, а не общими словами. 3. Главный вопрос: сколько времени нужно человеку, чтобы понять ценность. Если это недели — пробный период на 7 дней бессмысленен, объясни почему. 4. Стоимость бесплатных: посчитай, во что обойдётся тысяча бесплатных пользователей в месяц и при какой доле оплат это окупается. 5. Где провести границу: какая возможность остаётся бесплатной, а какая нет. Правило, по которому это решают. 6. Что будет через год при каждой модели: сколько бесплатных накопится и не съедят ли они прибыль. 7. Рекомендация одной строкой с оговоркой, при каком изменении её пересмотреть. Не советуй бесплатный тариф просто потому, что он у конкурентов. У них может быть другая экономика.
В фигурных скобках — то, что нужно заменить на своё.
Пример результата
Ваш случай: ценность понятна за 20 минут, обслуживание бесплатного — 12 ₽ в месяц, чек 1 490 ₽. Пробный период проигрывает: за 20 минут человек всё понял, а таймер на 14 дней только заставляет откладывать. Бесплатный с ограничением по объёму: 1000 бесплатных стоят 12 000 ₽ в месяц, окупаются при 9 оплатах. Реалистично. Граница: бесплатно всё, что человек делает для себя. Платно — то, что он делает для команды и для клиентов.
Похожие промты
Разбор идеи на риски и план проверки за неделю — до того, как потратили месяцы.
Ты — продуктовый стратег, который видел много закрытых проектов. Разбери мою идею SaaS честно, не подбадривая. Идея: {что за сервис} Кому: {для кого, максимально узко} Какую работу человек делает сейчас без нас: {как решают эту задачу сегодня} Как планирую брать деньги: {модель и цена} Сколько времени и денег готов вложить до первых денег: {ресурс} Разбери: 1. Проблема: она болит регулярно или это разовое неудобство? Отвечай прямо. 2. Кто платит: сам пользователь или его руководитель — и почему это меняет продукт. 3. Три главных риска: почему проект может не взлететь. Для каждого — как проверить его дешевле всего. 4. Что уже есть на рынке, включая Excel, блокнот и «ничего не делать» — их тоже считай конкурентами. 5. Самое опасное допущение: если оно неверно, всё остальное бессмысленно. 6. План проверки на неделю: что сделать по дням, чтобы получить сигнал без кода. 7. Критерий отказа: какой результат означает, что идею надо бросить. Если идея слабая — скажи это в первом абзаце.
Показать пример результатаСкрыть пример
Самое опасное допущение: что бухгалтеру дадут поменять инструмент. Решает не он, а финдир — значит, продавать надо не «удобнее», а «меньше ошибок в отчётности». Критерий отказа: если из 20 разговоров меньше 3 просят «дайте попробовать» — идею закрываем.
Минимальный набор функций, который уже можно продавать, и список отложенного — с причинами.
Помоги очертить MVP так, чтобы его можно было выпустить и продавать. Продукт: {что делает сервис} Главный сценарий: {что пользователь делает от входа до результата} Кто пользователь: {описание} Сколько времени на разработку: {срок} Кто разрабатывает: {один разработчик / команда / без кода} Сделай: 1. Один путь пользователя от регистрации до первой пользы — по шагам, без ветвлений. 2. Функции, без которых этот путь не работает. Каждая — с обоснованием, почему без неё нельзя. 3. Функции, которые кажутся обязательными, но в MVP не нужны — и чем их заменить временно (ручная работа, письмо, таблица). 4. Что вырезать совсем и почему это не помешает продавать. 5. Границы: чего продукт НЕ делает. Формулировки для сайта, чтобы не было ложных ожиданий. 6. Оценка объёма в неделях с разбивкой и с указанием, где оценка самая ненадёжная. 7. Что можно делать руками первые месяцы вместо автоматизации. Правило: если функцию можно на старте заменить человеком — в MVP её не включай.
Показать пример результатаСкрыть пример
Заменить руками: выгрузку отчёта в PDF первые месяцы делает поддержка по запросу. Три запроса в неделю — один час, а на автоматизацию ушло бы две недели. Границы для сайта: «Мы не заменяем бухгалтерию, мы готовим для неё данные».
Функция превращается в задачи с проверяемыми критериями — включая ошибки и пустые состояния.
Промт входит в PRO-подборку
Открыть доступТаблицы, связи и индексы из описания сценариев — с разбором мест, где схема поедет.
Промт входит в PRO-подборку
Открыть доступ