Эпилог: упаковка и вывод MVP

Я закрыл JobTrack по Definition of Done. README на месте, JSON export проверил руками, public URL и demo mode записал, ограничения прятать под ковёр не стал.

И вот тут я ловлю новую дыру.

Продукт готов. Отправить его человеку всё ещё неловко.

Ссылка есть, а объяснения нет. На первом экране видно, как добавить вакансию. И всё. Что такое JobTrack, кому он нужен, зачем открывать его вместо таблицы — экран молчит.

В README всё честно, но README пользователь читать не будет.

Пост в чат тоже можно. Но там пока голые технические факты: MVP, export, localStorage, statuses. Звучит как инвентаризация склада, а не приглашение попробовать продукт.

Плохой prompt звучит так:

Сделай лендинг для JobTrack.

Агент, конечно, сделает всё)

Большой герой-экран, градиент, 6 преимуществ, отзывы, блок цен, FAQ, интеграции, которых нет, и кнопку начать бесплатно.

Получится не упаковка MVP, а красивая ложь с блёстками. Именно это потом и ломает доверие: продукт маленький, а обещает как взрослая SaaS-платформа.

Короче, мне нужен не театральный лендинг. Мне нужно объяснить в двух строчках, что это, для кого, зачем открыть, дать живую ссылку или честный demo mode, показать один короткий сценарий и прямо сказать, где лежат данные. Плюс одно-два места, куда вынести это в первый раз.

Теперь задача — вывести MVP наружу без вранья.

Зачем нужен launch package

После Definition of Done продукт технически принят: проверки зелёные, сценарий отрабатывает, README не врёт. Но показать его живому человеку всё ещё может быть нечего. Нужна упаковка.

Чтобы показать MVP живому человеку, нужна упаковка:

• что это;
• для кого;
• какую боль закрывает;
• что можно сделать сейчас;
• где открыть;
• какие ограничения есть;
• что попросить у первого пользователя;
• как понять, был ли интерес.

Без упаковки ты будешь объяснять продукт голосом каждому человеку. Это плохой тест: человек реагирует на твоё объяснение, а не на продукт. Проверять так можно только собственную харизму, а не MVP.

Launch package выводит MVP наружу без вранья и без лишней стройки: без домена ради медали, брендбука ради самоуспокоения и CRM, которую никто не просил.

Деплой в курсе уже закрывает модуль 15 через фазу deploy-strategy. Модуль 16 работает поверх этого: упаковка, первые каналы, ручная аналитика, feedback log и минимальный мониторинг — это зона post-release.

SPP держит память о проекте в docs/spp/pipeline-state.md — что за продукт, что уже сделано, какие решения приняты. Поэтому работу можно прервать и продолжить в новой сессии. Следующий модуль — это следующая фаза того же pipeline, а не отдельный разрозненный шаг.

Что входит в упаковку MVP

Для JobTrack упаковка состоит из 6 частей:

Часть	Что фиксирует
Offer	кому продукт помогает и в какой ситуации
Landing page или публичный блок	короткое объяснение, CTA, ограничения, data note
Public URL или demo mode	как человек получает доступ
Demo flow	какой сценарий должен пройти пользователь
Launch message	что отправить в чат, пост или личное сообщение
Launch metrics	какие ручные сигналы записываем после вывода

Это не полноценный go-to-market. CRM, реклама, email-воронка, платёжка и брендбук идут мимо кассы. MVP нужен понятный вход, и на этом всё.

Лендинг для MVP

Лендинг первого MVP не продаёт большое будущее. Он объясняет текущий сценарий: для кого продукт, какую боль закрывает и что можно сделать сейчас.

Минимальная структура:

# JobTrack

Короткий headline:
Трекер вакансий для активного поиска работы.

Для кого:
Для IT-соискателя, который откликается на несколько вакансий в неделю и теряет статусы в таблицах, вкладках и чатах.

Что можно сделать сейчас:
- добавить вакансию вручную;
- указать source и status;
- записать next step или notes;
- выгрузить JSON export.

Что не входит:
- импорт с job-сайтов;
- auth и синхронизация между устройствами;
- напоминания;
- AI-рекомендации.

Data note:
Данные хранятся локально или в выбранном MVP storage. Перед сменой устройства сделай JSON export.

CTA:
Открыть demo / попросить доступ / посмотреть локальное demo.

Если продукт уже встроен в само приложение, отдельный лендинг не обязателен. Можно сделать публичный блок на первом экране: название, короткий оффер, ограничения, CTA и data note. Главное — чтобы смысл читался без твоего голосового комментария.

Public URL, demo mode и домен

Финальный модуль не требует покупать домен. Домен — инструмент, а не медаль на груди.

Допустимые варианты:

• local demo mode, если ты показываешь MVP сам на экране;
• preview/public URL хостинга, если даёшь ссылку 2–3 людям;
• поддомен, если уже нужен аккуратный внешний пилот;
• домен, если продукт выходит в публичный режим и название имеет смысл закрепить.

Выбор должен быть записан в docs/launch.md и docs/release.md. Не называй это public launch, если на деле это screen share. Себя обманывать особенно тупо: потом метрики будут из того же воздуха.

Demo flow

Demo flow — это маршрут, который пользователь должен пройти без подсказок.

Для JobTrack:

1. Открыть landing page или public URL.
2. Понять, что JobTrack делает.
3. Добавить вакансию с title, company, url и source.
4. Увидеть вакансию в списке.
5. Изменить status.
6. Записать next step или notes.
7. Сделать JSON export.
8. Понять known limitations.

Если без твоих объяснений человек не понимает, зачем нажимать CTA, проблема не в пользователе. Проблема в упаковке.

Каналы первого вывода

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

Нормальные варианты:

• 2–3 личных контакта из сегмента;
• маленький пост в профильном чате;
• сообщение в сообществе, где уже обсуждают поиск работы;
• личный outreach к людям из discovery;
• короткий demo-call, если продукт пока локальный.

Плохие варианты:

• массовая реклама;
• Product Hunt ради галочки;
• длинный тред с обещаниями v2;
• пост в широкую аудиторию без сегмента;
• покупка домена и логотипа вместо проверки входа.

За охватом здесь гнаться рано. Сначала проверь вход: понимает ли человек продукт и проходит ли demo flow.

Launch message

Сообщение для первого вывода должно просить действие, а не оценку идеи.

Плохой вариант:

Я сделал классный сервис для поиска работы, посмотрите, что думаете.

Нормальный вариант:

Я собрал маленький JobTrack MVP для людей, которые ведут много откликов и теряют следующие шаги.

Сейчас он умеет только ручное добавление вакансии, status/source, next step/notes и JSON export.

Попробуй пройти один сценарий: добавь 3-5 вакансий, поменяй status у одной и сделай export.

Мне важно понять, понятно ли это без объяснений и где ты бы вернулся к таблице.

Такой текст честно показывает границы и сразу задаёт проверяемое действие.

Privacy и data note

Упаковка должна прямо сказать, что происходит с данными.

Для JobTrack это критично: поиск работы, компании, статусы откликов и заметки могут быть чувствительными.

Минимум:

• где живут данные;
• есть ли синхронизация;
• как сделать export;
• что не надо вводить;
• кто увидит notes;
• как удалить тестовые данные.

Если storage локальный, напиши это явно. Если public URL не хранит данные на сервере, тоже напиши. Если хранит — скажи где и зачем.

Минимальная аналитика запуска

Для запуска не нужен analytics stack. Хватает ручной таблицы или docs/launch.md. Иначе ты начнёшь строить приборную панель раньше, чем появится первый нормальный сигнал.

Записывай:

• кому отправил ссылку;
• открыл ли человек landing page;
• нажал ли demo или public URL;
• прошёл ли demo flow;
• где остановился;
• попросил ли доступ ещё раз;
• сделал ли JSON export;
• какую фразу сказал после сценария.

Это не полноценный feedback loop. Это запусковая диагностика: работает ли упаковка и вход в продукт.

Что не надо делать

Не надо:

• обещать функции вне MVP;
• писать шаблонный маркетинговый текст;
• делать блок цен;
• делать отзывы без реальных пользователей;
• покупать домен ради ощущения запуска;
• запускать массовую рекламу;
• добавлять фичи перед первым выводом;
• выдавать локальное demo за публичный продукт.

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

Роль ИИ на этом этапе

ИИ полезен как редактор упаковки и проверяющий на ложные обещания. Главное правило: не придумывай traction, отзывы, метрики, цены и интеграции, которых нет.

Хороший prompt:

Read docs/design.md, docs/release.md, and docs/launch.md.
Review the MVP launch package.

Check:
- landing copy explains who it is for, what pain it solves, and what the user can do now;
- CTA matches the real access mode;
- launch message asks for a concrete action, not generic opinion;
- privacy/data note is clear;
- no promised feature is outside accepted MVP scope;
- no generic marketing copy;
- no invented traction, testimonials, metrics, pricing, integrations, or roadmap.

Return must-fix issues only.
Do not rewrite the whole launch page.

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

Что должно получиться

На выходе:

• docs/launch.md с offer, landing copy, access mode, demo flow, launch channels, launch metrics и data note;
• landing page или публичный блок внутри MVP;
• public URL, поддомен или честный local demo mode;
• launch message для 1–2 каналов;
• ручная аналитика запуска;
• следующий шаг после вывода: собрать feedback или поправить упаковку.

Курс заканчивается не тем, что MVP просто существует. Он заканчивается тем, что MVP можно открыть, показать и отправить первому человеку без тебя рядом в роли экскурсовода.

Цель: собрать launch package для принятого MVP: landing, public URL или demo mode, demo flow, launch message, первые каналы и ручную аналитику запуска. Это не ещё один слой фичей, а упаковка того, что уже прошло приёмку.

Шаг 0. Запусти SPP post-release workflow

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

Используй /spp.

Мы на модуле 16. MVP принят по Definition of Done.
Нужно упаковать мой проект для первого вывода наружу.

Задача:
- создать docs/launch.md;
- сформулировать offer;
- подготовить landing page или публичный блок MVP;
- выбрать public URL, поддомен или local demo mode;
- описать demo flow;
- подготовить launch message;
- выбрать 1-2 узких канала первого вывода;
- записать privacy/data note;
- настроить ручную аналитику запуска;
- не добавлять новые фичи и не обещать то, чего нет в MVP.

Шаг 1. Создай docs/launch.md

Структура:

# JobTrack launch package

## Offer
- Segment:
- Pain:
- Promise:
- Current MVP capabilities:
- Not included:

## Access mode
- Public URL / preview URL / subdomain / local demo mode:
- Date checked:
- Known limitations:

## Landing copy
- Headline:
- Subheadline:
- For whom:
- What you can do now:
- CTA:
- Data note:

## Demo flow
1. ...

## Launch channels
- Channel:
- Why this channel:
- Message:

## Launch metrics
- Sent to:
- Landing opened:
- Demo/public URL clicked:
- Demo flow completed:
- Export used:
- Feedback / quote:

## Next step after launch
- collect feedback / fix packaging / adjust access / park:

Шаг 2. Сформулируй оффер

Для JobTrack оффер должен быть маленьким и честным. Он объясняет, кому это нужно сейчас, какую боль закрывает MVP и где его границы:

JobTrack помогает активному IT-соискателю держать вакансии, статусы откликов и следующий шаг в одном месте.

Сейчас MVP умеет ручное добавление вакансии, source/status, next step/notes и JSON export.

Проверь:

• есть конкретный сегмент;
• есть конкретная боль;
• нет обещания импорта, auth, синхронизации, AI-рекомендаций и напоминаний;
• понятно, зачем открыть продукт сейчас.

Шаг 3. Собери landing page или публичный блок

Если в проекте уже есть публичная страница, добавь туда MVP-блок. Если нет — сделай простой landing page. Главная задача страницы — быстро довести человека до demo flow, а не доказать, что ты умеешь собирать красивый лендинг.

Минимальные блоки:

• headline;
• 1 абзац для кого и зачем;
• список того, что можно сделать сейчас;
• known limitations;
• data note;
• CTA: открыть demo / попросить доступ / посмотреть local demo;
• contact или feedback channel.

Не делай декоративный лендинг с 6 секциями ради ощущения запуска. Пользователь должен понять продукт, увидеть ограничения и перейти в demo flow.

Шаг 4. Проверь public URL или demo mode

Выбери один режим доступа и не распыляйся:

• public URL хостинга;
• preview URL;
• поддомен;
• local demo mode.

Запиши выбор в docs/launch.md и docs/release.md.

Проверь:

• ссылка открывается в приватном окне;
• это последняя версия;
• mobile не ломается;
• SSL работает, если URL публичный;
• env/secrets не раскрыты;
• limitations видны или доступны.

Не покупай домен ради галочки. Если demo локальный, так и напиши. Честный local demo mode лучше, чем публичная ссылка, которая открывается через раз.

Шаг 5. Подготовь demo flow

Demo flow для JobTrack:

1. Открыть landing page или публичный блок.
2. Нажать CTA.
3. Добавить вакансию с title, company, url и source.
4. Увидеть вакансию в списке.
5. Изменить status.
6. Записать next step или notes.
7. Сделать JSON export.
8. Прочитать known limitations.

Пройди flow сам без подсказок из головы. Если инструкция нужна на каждом шаге, значит упаковка или UI copy ещё не готовы к первому человеку.

Шаг 6. Проверь SEO/sharing baseline

Полный чеклист — в материале «SEO baseline для MVP». Здесь повтори его, если после модулей 14–15 менялись title, description, OG или favicon. Перед отправкой ссылки проверь:

• title;
• meta description;
• Open Graph title/description/image, если есть;
• favicon;
• mobile preview;
• robots.txt, если страница публичная;
• превью в мессенджере или хотя бы визуальный fallback.

Это не SEO-кампания. Это санитария публичной ссылки: человек должен понять, что открыл, а превью не должно выглядеть случайным черновиком.

Где взять OG-image 1200x630. Не нужен дизайнер. Два простых способа: сгенерировать картинку через ИИ (попроси «сделай OG-изображение 1200x630 для JobTrack: название, короткий подзаголовок, спокойный фон») и доработать текст; либо снять скриншот главного экрана и вставить его в простой шаблон с названием. Проверь, что текст читается в превью мессенджера и не обещает больше, чем есть в MVP.

Шаг 7. Выбери 1–2 канала первого вывода

Выбери узко. Первый вывод нужен для сигналов, а не для охвата:

• 2–3 личных контакта из сегмента;
• профильный чат про поиск работы;
• маленький пост в канале;
• личный outreach к людям из discovery;
• demo-call, если нет публичного URL.

Не запускай массовую рекламу. Не тащи продукт на широкую аудиторию, пока не проверил вход, demo flow и понятность ограничений.

Шаг 8. Подготовь launch message

Шаблон:

Я собрал маленький JobTrack MVP для людей, которые ведут много откликов и теряют следующие шаги.

Сейчас он умеет только ручное добавление вакансии, source/status, next step/notes и JSON export.

Попробуй пройти один сценарий: добавь 3-5 вакансий, поменяй status у одной и сделай export.

Мне важно понять, понятно ли это без объяснений и где ты бы вернулся к таблице.

Ссылка: <public URL / demo mode>

Подстрой текст под канал, но не убирай ограничения. Ограничения — это не слабость, это честность MVP и защита от бессмысленных ожиданий.

Шаг 9. Запиши privacy/data note

Для JobTrack data note обязателен.

Минимальный текст:

Данные вакансий используются только для MVP-сценария.
В текущей версии нет auth и синхронизации между устройствами.
Перед сменой браузера или устройства сделай JSON export.
Не вводи приватные переписки, зарплаты и персональные данные, если они не нужны для проверки сценария.

Если storage отличается, перепиши текст под реальность. Privacy note должен описывать фактическое поведение продукта, а не желаемую архитектуру.

Шаг 10. Настрой ручную аналитику запуска через post-release

В SPP это фаза 9 post-release: минимальный мониторинг, ручные сигналы и канал обратной связи после первого вывода. В docs/launch.md или таблице запиши:

• кому отправил;
• канал;
• открыл ли landing page;
• нажал ли demo или public URL;
• прошёл ли demo flow;
• где остановился;
• сделал ли JSON export;
• написал ли feedback;
• следующая ручная проверка.

Не ставь analytics stack ради 2–3 первых людей. Ручной список быстрее, честнее и лучше показывает, где человек реально застрял.

Минимальный мониторинг после запуска. Как минимум попроси первых пользователей присылать скриншот, если что-то сломалось или повело себя странно. Опционально добавь простой счётчик визитов или лёгкий error tracking, если стек это позволяет без возни. Если сознательно решаешь ничего не ставить сейчас, запиши это одной строкой в docs/launch.md: мониторинг out of scope до первых сигналов.

Шаг 11. Обнови release/todo

В docs/release.md добавь:

• launch package готов;
• access mode;
• public URL или local demo mode;
• дата проверки;
• known limitations.

В docs/todo.md:

• MVP done остаётся done;
• launch package done;
• next step после вывода: собрать feedback, поправить упаковку или закрыть риск;
• новые фичи не добавлять до первых сигналов запуска.

Шаг 12. Запусти: отправь launch message реальным людям

Упаковка без отправки — это не запуск. Отправь launch message по выбранным каналам минимум нескольким людям. Ориентир для первого запуска — 10 человек из сегмента: личные контакты, профильный чат, короткий пост.

Запуск считается состоявшимся, когда:

• сообщение реально отправлено живым людям, а не «отправлю завтра»;
• прошло несколько дней, чтобы люди успели среагировать;
• реакции записаны: кто открыл, кто попробовал demo, кто ответил, кто промолчал.

Зафиксируй это в ручной аналитике из Шага 10. Молчание — тоже сигнал, записывай и его.

Шаг 13. Собери первый фидбек

Ответы людей собери в docs/feedback.md. Эталон структуры — в дополнительном материале «Эталонные артефакты». Записывай факты использования, цитаты, где человек застрял, что попросил.

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

Что дальше

Курс закончился, но цикл продукта — нет. Дальше работа идёт тем же циклом:

1. Собранный фидбек и backlog v2 — вход для следующей итерации.
2. Возвращаешься в модуль 10 и планируешь следующий slice из backlog v2.
3. Реализуешь его по модулю 11: одна задача, проверка, маленький commit.
4. Снова приёмка (модуль 15) и, если нужно, вывод изменений (модуль 16).

Продукт живёт циклами discovery — scope — design — plan — implementation — release — feedback, а не одним большим релизом. Теперь задача — не героически строить всё подряд, а выбирать следующий маленький шаг по фактам.