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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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