# Встреча 6 — The Founders Circle

## Слайд 1
**Добро пожаловать**
The Founders
Circle

Встреча 6

Сегодня не слушаем. Работаем.
Каждый уходит с движением, не с конспектом.
Михаэль · Встреча 6 из 8 · Slide 1/10

## Слайд 2
**Тема: первая сессия в продукте**
Тема встречи

Первая сессия в продукте.

От «вошёл» до «понял что делать и есть ли смысл возвращаться».
Сегодня делаем эту сессию проходимой.

Первые 60 секунд — это ориентация, а не Aha. Aha приходит позже: для B2B и tools — часто не в первой сессии вообще. Наша задача — не сломать путь к нему.
Михаэль · Встреча 6 из 8 · Slide 2/10

## Слайд 3
**Aha живёт в продукте**
Определение, с которым работаем

Aha живёт в продукте.

Конкретное действие юзера + его признание «это работает для меня».
Лендинг обещает, продукт доказывает. Время до Aha — от минут до недель, зависит от продукта.

Dropbox (B2C)

Файл с одного устройства появился на другом

→ 2–5 мин, требует install на обоих

Slack (B2B)

Команда отвечает в твоём канале, а не в почте

→ несколько дней использования

Notion

Первая собственная страница, которой реально пользуешься

→ 1–2 сессии + возврат

MetaMinder

Создано обучение для сотрудников за 1 минуту, без навыков

→ первая сессия

Сегодняшняя цель: не «достичь Aha», а сделать путь к нему проходимым.
Михаэль · Встреча 6 из 8 · Slide 3/10

## Слайд 4
**Онбординг = путь к Aha**
Архитектура первой сессии

Онбординг = кратчайший путь к Aha.

Не тур по продукту. Не wizard из 8 шагов. Набор решений, проводящих юзера к первому результату без застревания — минуты для B2C, первая сессия для продуктивных tools, 2–3 сессии для B2B.

Empty state

Никогда не пустой

Пустой дашборд = юзер уходит. Дай pre-filled sample или одну яркую CTA на первое действие.

3–5 шагов

Не тур, а последовательность

Путь к первому результату. Не объяснение интерфейса, а действия, ведущие к Aha.

Подсказки

По месту, не списком

Tooltip на поле ввода > модалка «вот 12 фич продукта». Контекст > лекция.

Progress

Видно сколько осталось

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

Pre-filled sample

Быстрее, чем пустой workspace

Notion: template gallery. Linear: демо-issues. Slack: welcome-бот. Первый Aha без усилий.
Михаэль · Встреча 6 из 8 · Slide 4/10

## Слайд 5
**Универсальный промпт**
Промпт для AI

Эталон качества: Linear · Notion · Superhuman

Production-ready продукт за один вечер

Универсальный промпт. Заполни поля 1–12 своим контекстом, отдай в Lovable / Claude Code / v0. Любой продукт — рабочий за вечер.

Скопируй промпт целиком · заполни [квадратные скобки] · отдай AI

Копировать промпт

# Промпт для AI: собери мне production-ready продукт Собери production-ready продукт, готовый к первым реальным пользователям сегодня. Это не прототип и не MVP-скетч — это живой продукт, который можно задеплоить, открыть, зарегистрироваться и начать пользоваться. Работающая аутентификация, реальная БД, error handling, responsive, accessible, готовый к продакшн-деплою, с полной документацией. **Начни с плана.** До единой строки кода опиши: архитектура файлов (список папок и файлов), схема БД (таблицы, колонки, связи, RLS-политики), auth-флоу, 3–5 acceptance criteria для главного сценария. Потом кодь. --- ## Мой продукт **1. Название:** [одно слово или короткая фраза. Пример: Clearbrief] **2. Одна фраза о продукте:** [формула: «Помогает [кому] делать [что] вместо [как они это делают сейчас без меня]». Пример: «Помогает продакт-менеджерам собирать PRD из переписок и заметок вместо ручной сборки из Slack и Notion»] **3. Кто пользователь:** [2–3 предложения своими словами. Роль, размер компании, контекст работы, какие инструменты использует сейчас, сколько времени тратит на проблему. Пример: «Продакт-менеджер в SaaS-компании 20–200 человек. Ведёт 2–4 проекта параллельно, тонет в обсуждениях в Slack и Notion, тратит 3–5 часов в неделю на сборку и обновление документов»] **4. Главное действие и результат:** [формула: «Пользователь [делает X] → получает [Y]». Одно действие, один результат — не список. Пример: «Пользователь вставляет переписку, заметки или расшифровку встречи → получает структурированный PRD-черновик с разделами Problem, Users, Requirements, Risks»] **5. Как часто пользователь это делает:** [выбери одно: разово / раз в месяц / раз в неделю / несколько раз в неделю / каждый день / несколько раз в день] **6. Разделы продукта:** [2–4 ключевых раздела по именам, главный раздел первым. Пример: «Drafts (главный), Library, Templates, Settings». Если не уверен — напиши «решай сам»] **7. Источник данных для главного действия:** [откуда берутся данные, с которыми работает пользователь. Пример: «Пользователь вставляет текст вручную» / «Загружает PDF или DOCX» / «Подключает Google Drive» / «Записывает голос» / «Импортирует из URL»] **8. Что сохраняется в аккаунте пользователя:** [что должно оставаться после выхода и возврата. Пример: «История всех PRD, шаблоны, настройки профиля». Если ничего — напиши «ничего, полный stateless»] **9. Язык интерфейса и документации:** [русский / английский / иврит / другое] **10. Пример данных для демо (опц):** [конкретные названия, имена, цифры для seed-данных в БД, чтобы новый пользователь видел продукт живым. Пример: «В Library — 3 прошлых PRD: "Bulk export for Free tier", "Multi-seat billing", "Onboarding v2"». Если пусто — AI сгенерирует сам] **11. Визуальный стиль (опц):** [тёмный минимализм / светлый / корпоративный / яркий / акцентный #HEX. Если пусто — тёмный минимализм с одним спокойным акцентом] **12. Монетизация (опц):** [бесплатный / freemium с лимитом на бесплатном тарифе / платный с первого дня + сумма. Пример: «Freemium: 5 бесплатных PRD в месяц, потом $19/мес». Если пусто — полностью бесплатный, но с инфраструктурой под будущий платный тариф] --- ## Технический стек (production-grade, апрель 2026) - **Frontend:** React 19 + TypeScript (строгий режим, без `any`) + Tailwind v4 + Shadcn/ui - **Backend:** Supabase — auth (Google OAuth + email/password), Postgres с Row Level Security, Storage для файлов - **State:** TanStack Query для server state, Zustand для client state (если нужен глобальный) - **Валидация:** Zod для всех внешних данных и форм - **Routing:** react-router-dom с защищёнными маршрутами - **Deployment:** готово к Vercel / Netlify из коробки. `.env.example` с переменными. Если AI-инструмент не поддерживает Supabase — используй ближайший аналог (Firebase / Convex / Neon + встроенная auth), сохраняя функциональную эквивалентность: real auth, real persistence, real RLS-семантика. --- ## Архитектурные правила (hard requirements) **Максимум 500 строк на файл.** Это не guideline — это hard limit, который заставляет архитектуру оставаться модульной. Если файл приближается к лимиту — дели. **Структура проекта:** - `src/components/` — UI-компоненты, один компонент = один файл - `src/features/{название_фичи}/` — фичи с их собственными компонентами, хуками, типами - `src/hooks/` — переиспользуемые хуки - `src/lib/` — утилиты, клиенты API, конфиг Supabase - `src/types/` — общие TypeScript-типы - `src/routes/` — страницы и роутинг - `docs/` — вся документация (см. раздел ниже) **Один компонент = одна ответственность.** Контейнерные компоненты отделены от презентационных. Логика данных — в хуках, не в JSX. **Никаких `any`, `@ts-ignore`, `eslint-disable`** кроме документированных исключений. Если AI вынужден заглушать тип — объяснить комментарием. --- ## Документация (обязательна, не опциональна) Создай полный пакет документации. Каждый документ — лаконичный и полезный, не энциклопедический. Всё на языке из поля 9 (технические термины — React, Supabase, RLS — остаются в оригинале). **`README.md`** (корень) — публичное лицо проекта: - Одна фраза о продукте - Стек в одну строку - 3-шаговый quickstart: clone → install → env → run - Ссылки на остальные документы **`docs/PRD.md`** — продуктовая спецификация: - Проблема и целевой пользователь (из полей 2–3) - User stories для главного флоу и каждого раздела - Функциональные требования по разделам - Нефункциональные требования: performance, security, accessibility (WCAG AA) - Метрики успеха и список аналитических событий для будущей интеграции с Mixpanel/PostHog - Roadmap: что вошло в v0.1.0 / что отложили **`docs/ARCHITECTURE.md`** — техническое устройство: - Диаграмма компонентов (mermaid) - Обоснование выбора стека (почему Supabase, почему TanStack Query, почему Zod) - Структура папок и принцип «один файл — одна ответственность» - Data flow: client → API → DB - Auth-флоу end-to-end с диаграммой - Стратегия кеширования и инвалидации - Стратегия обработки ошибок (error boundaries, retry-логика, fallback-состояния) **`docs/DATABASE.md`** — схема данных: - ER-диаграмма (mermaid) - Описание каждой таблицы: колонки, типы, constraints - RLS-политики с объяснением бизнес-логики каждой - Индексы и обоснование - SQL-миграции в отдельных файлах `supabase/migrations/` **`docs/DEPLOYMENT.md`** — деплой: - Пошаговая настройка Supabase (создание проекта, запуск миграций, OAuth-клиенты для Google) - Пошаговый деплой на Vercel / Netlify - Переменные окружения — что откуда взять - Подключение домена и SSL - Где смотреть логи и мониторинг **`docs/DECISIONS.md`** — ADR (Architecture Decision Records): - Ключевые технические решения в формате: Контекст → Решение → Альтернативы → Trade-offs - Что бы пересмотрел при росте нагрузки / команды **`CLAUDE.md`** (корень) — контекст для будущих AI-сессий разработки: - Что за проект одной фразой - Conventions: naming, структура файлов, паттерны - Правило 500 строк на файл - Где что лежит и куда добавлять новый функционал - Команды: запуск, тесты, деплой - Что НЕ ломать (критические инварианты) **`CHANGELOG.md`** (корень) — стартует с v0.1.0 с описанием того, что включено в этот билд. --- ## Что значит «готово к пользователям» (acceptance criteria) Продукт считается готовым, когда выполнено **всё**: - [ ] Новый пользователь может зарегистрироваться (Google OAuth + email) → подтвердить email → попасть в приложение. Флоу работает end-to-end. - [ ] Главное действие из поля 4 выполняется end-to-end и результат сохраняется в БД. После refresh результат на месте. - [ ] Все разделы из поля 6 заполнены реальными или seed-данными. Пустых экранов «Coming soon» нет нигде. - [ ] Error states работают: ошибка сети, невалидный ввод, пустой результат, unauthorized — каждая показывает понятное сообщение с действием, не ломает приложение. - [ ] Loading states везде: skeleton для данных <3 сек, streaming/progress для операций >3 сек. - [ ] Мобильный работает: нет горизонтального скролла, touch-области ≥44px, навигация адаптирована. - [ ] Accessibility: keyboard nav (Tab/Enter/Escape), aria-labels на всех интерактивных элементах, focus-states видимы, контрастность WCAG AA. - [ ] RLS-политики в Supabase: пользователь видит только свои данные. Проверен минимум один сценарий попытки чужого доступа. - [ ] `.env.example` со всеми переменными. README с 3-шаговым гайдом запуска. - [ ] Полный пакет документации создан: README, PRD, ARCHITECTURE, DATABASE, DEPLOYMENT, DECISIONS, CLAUDE.md, CHANGELOG. Всё на языке из поля 9. - [ ] Работает один из сценариев деплоя: либо готов к `vercel deploy`, либо открывается через preview-ссылку билдера. --- ## Решай сам — умные дефолты Где пользователь не дал ответа, принимай разумное решение и не спрашивай. В конце перечисли блоком **«Дефолты, которые я применил»**: - Тип навигации (sidebar / top-nav) — из типа продукта - Цвет и визуальный стиль — если не указан, тёмный минимализм - Tone of voice — профессиональный, лаконичный, глаголы в активном залоге - Структура таблиц и колонок — из логики продукта - Seed-данные если поле 10 пусто — правдоподобные (реальные имена, даты, названия) - Формат результата главного действия — выбери то, что реально полезно для этого продукта --- ## Категорически нельзя - Mock-auth, fake-login, hardcoded-пользователи — только настоящий auth через Supabase - Данные в localStorage вместо БД (кроме UI preferences вроде темы) - Плашки «Coming soon» / «Under construction» / «In development» - Файлы больше 500 строк - `any` и `@ts-ignore` без документированной причины - Welcome-модалка со списком фич - Пустой главный раздел «Welcome, let's get started» - Lorem Ipsum, placeholder-тексты, «click here», `{productName}` в рантайме - Sensitive данные (API ключи, секреты) в клиентском коде - Пропущенная документация — даже если продукт работает, без docs это НЕ production-ready --- ## Формат ответа 1. **План** (до кода): структура файлов списком, схема БД, auth-флоу, 3–5 acceptance criteria для главного сценария 2. **Код** — в порядке зависимостей (lib → types → hooks → components → routes) 3. **Документация** — README, PRD, ARCHITECTURE, DATABASE, DEPLOYMENT, DECISIONS, CLAUDE.md, CHANGELOG 4. **Блок «Дефолты, которые я применил»** — решения, принятые за пользователя 5. **Инструкция по запуску и деплою** — в README, 3 шага максимум
Михаэль · Встреча 6 из 8 · Slide 5/10

## Слайд 6
**Участники и задачи**
Что делаем сейчас

5 фаундеров. Параллельная работа.

Открываешь промпт. Заполняешь под свою задачу. Начинаешь. Я подключаюсь к каждому в этом порядке — не ждёшь.

1

Laura

QA/RA assistant

Собрать первый продуктовый экран

Заполни промпт под QA/RA assistant. Главное действие — загрузить документ, получить ответ со ссылкой на параграф. Документ остаётся приватным.

2

Mila

Hobbix

Продуманный флоу после авторизации → ценность

Что видит юзер сразу после login, как удерживаешь внимание, как доносишь ценность Hobbix не словами, а действиями за первые минуты.

3

Vlad

Выбор идеи + первый экран

Зафиксировать идею и собрать функц. экран

Сначала вслух 3 вопроса (кому конкретно / какое ОДНО действие / что он получит обратно). Проходишь — заполняешь промпт под выбранную идею.

4

Lea

Default She

Выбрать категорию → флоу до Aha

Первое решение: одна категория, на которой фокусируемся. Узкий аватар, одна боль, одно ключевое действие. Под неё — флоу auth → результат → Aha.

5

Inna + Aleksandra

Dira.click

Провалидировать флоу с ИИ → Aha

Промпт выше — для web. Для бота: даёшь Claude/GPT роль типичного клиента, прогоняешь текущий флоу, фиксируешь точки трения, дорабатываешь онбординг и момент первой выдачи.
Михаэль · Встреча 6 из 8 · Slide 6/10

## Слайд 7
**Commitment wall**
Commitment wall

Каждый говорит вслух.

Обязательство, произнесённое группе, держится сильнее. Три строки по порядку — без комментариев, без «но».

Сегодня я сделал(а)

[конкретный артефакт: URL / переписанный Hero / выбранная идея]

К Неделе 7 я сделаю

[конкретная метрика: 10 юзеров прошли / 5 интервью / email-список из N]

Моя пара проверки

[имя из группы, которому пишешь в среду с доказательством]

Пара пишет друг другу в среду со скриншотом прогресса. Нет скриншота = нет ответа.
Михаэль · Встреча 6 из 8 · Slide 7/10

## Слайд 8
**ДЗ на неделю**
Задание на неделю

5 человек — 5 задач.

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

Laura

10 QA/RA specialists из waitlist вошли, загрузили документ, получили первый ответ. Цифры: сколько дошли до ответа, сколько застряли на каком шаге. Плюс 3 цитаты про ответ (корректный? понятный? полезный?).

Mila

10 новых юзеров прошли первую сессию Hobbix. Сколько прошли без блоков. Где выпадают остальные (точка + причина). 3 коротких видеозаписи залипания или первой успешной сессии.

Vlad

5 человек из аватара прошли первую сессию твоего продукта. Дошли ли до первого результата? Что делали, что было непонятно? Приносишь их слова, не пересказ — можно голосовыми.

Lea

5 женщин из аватара прошли новую первую сессию Default She. Прошли ли до первого результата? Где выпали? Запись экрана 2-3 сессий (со звуком — пусть говорят вслух что думают).

Inna + Aleksandra

10 новых юзеров прошли переделанный экран Dira. Сравниваете drop-off до и после на этом конкретном экране — числа, не ощущения. Плюс короткая гипотеза: почему стало лучше/хуже.
Михаэль · Встреча 6 из 8 · Slide 8/10

## Слайд 9
**Неделя 7**
Следующая встреча

Неделя 7: Онбординг, UI/UX, путь к Aha

На M6 собрали каркас + первый флоу. На M7 делаем его лёгким и доводим до Aha — работаем с полным путём продукта от входа к результату.

→ Онбординг и UI/UX в деталях — micro-interactions, progressive disclosure, empty states

→ Что превращает первый результат в Aha — признание ценности, связь с целью

→ Friction audit на всём флоу — 5 типов трения, как находить и убирать

→ Полный путь юзера: вход → onboarding → Aha → возврат

Приходишь с данными от живых юзеров. Без данных — работаем на теории.
Михаэль · Встреча 6 из 8 · Slide 9/10

## Слайд 10
**Закрытие**
Продукт становится готовым,
когда за него платят.

Сегодня — каркас и рабочий первый флоу.
Через неделю — лёгкий путь до Aha.
Через месяц — первые деньги на счёт.

Не жди идеального момента. Ни один продукт не был готов в день первой продажи.
Готовым его делает первый юзер, который открыл кошелёк.

M7 → данные от живых юзеров  ·  M9 → первые продажи

Каждый коммит между ними — шаг к первому чеку.

Среда — чек с парой. Без доказательства прогресса — нет ответа.
Михаэль · Встреча 6 из 8 · Slide 10/10