Обложка

Этот файл собран в review-слое проекта, чтобы его было удобно читать и оценивать отдельно от внутренней кухни.

03. Архитектура продукта

Короткая версия решения

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

1. Диагностика входа

Функция:

2. Основная программа

Это основной пилотный продукт.

Внутри него:

Именно этот пакет должен стать главным объектом первых продаж.

3. Premium-ветка

Это расширение для тех, кому после глубокой диагностики нужна уже прикладная упаковка новой роли:

Ключевая мысль:

мы не продаем три метода. Мы продаем связанный маршрут. И у клиента в конце должен быть не только опыт, но и deliverable:

Именно этот deliverable делает продукт взрослым и дорогим.

Что подтверждают исходные материалы

Сигнал 1. Этап 1. Пакет скрининга

Источник 02_База_знаний/Опорные_документы/Этап_1_Скрининг.md подчеркивает следующее: option_c: premium-продукт для экспертов и предпринимателей, которым нужна личная распаковка, новый фокус и последующая упаковка бренда. Критерии скрининга; market_window: спрос на self-clarity, профессиональный разворот и личный бренд есть, но широкая эзотерическая подача сужает рынок; speed_to_test: быстрее всего тестируется формат диагностической сессии и 1:1 пилота; fit_for_operator: сильнее всего проект совпадает с третьим слоем оператора, когда итогом становится не просто инсайт, а прикладной вектор и новая форма действия; budget_fit: старт можно сделать без большого бюджета через warm-аудиторию, интервью и контент; operational_complexity: координация...

Сигнал 2. Паспорт проекта

Источник Паспорт_проекта.md подчеркивает следующее: Рынку нужно продавать понятный маршрут: диагностика -> синтез -> новый вектор -> следующая форма действия. Текущий статус; статус_машины: полный rerun завершен; стадия_проекта: ready-to-test; внутренний_слой: deep block pack v2 собран; чистовой_слой: пакеты для заказчика и конечного потребителя собраны; экспортный_слой: КП, презентация, финмодель и сайт подготовлены к выдаче; реальный_следующий_шаг: проверка с основательницами и запуск пилота. Что уже собрано; исходная идея и bootstrapped brief; screening-пакет и ключевое стратегическое решение; глубокие блоки по рынку, аудитории, архитектуре продукта, цене, каналам и рискам; naming/brand fram...

Сигнал 3. Карта проекта

Источник Карта_проекта.md подчеркивает следующее: ### 00_Оценка/ Это самый удобный слой для оператора:; 01_Внутреннее/; что читать, чтобы оценить качество мысли и сборки; 02_Финал/; что читать, чтобы оценить уже конечную выдачу ### .machine/ Это короткая служебная память проекта для самой машины:; knowledge.md; оперативная правда проекта; plan.md; текущий исполняемый план; design_system.md; visual direction; comments.md; журнал правок и review-loop; reference_projects.md; внутренние и внешние референсы. Главные папки внутри базы знаний; 02_База_знаний/Опорные_документы/Этап_1_Скрининг.md; 02_База_знаний/Опорные_документы/Этап_2_Индекс_блоков.md; `02_База_знаний/Реестры/Реестр_источников_и_артефак...

Сигнал 4. 04. Концепция и архитектура продукта

Источник 02_База_знаний/Блоки/04_Концепция_и_архитектура_продукта.md подчеркивает следующее: Минимальный deliverable должен включать:; краткую формулу главного запроса клиента; ключевые различения о нем; вероятные рабочие векторы; не рекомендованные векторы; следующий шаг на 30-60 дней Для premium-ветки deliverable расширяется:; позиционирование; смысловая формула; базовая архитектура личного бренда; контент/публичный образ/экспертная рамка. Роли внутри команды ### Психолог-расстановщик Отвечает за:; глубинное поле запроса; внутренние блоки и динамики; то, что человек не всегда может назвать словами ### Астролог Отвечает за:; символическую карту человека; потенциалы, ритмы, склонности, узлы; язык более широкой интерпретации ### Оператор проекта Отвечает за:; с...

Сигнал 5. 01. Контекст и версия правды

Источник 02_База_знаний/Блоки/01_Контекст_и_версия_правды.md подчеркивает следующее: # 01. Контекст и версия правды. Главная формула проекта Вектор Сборки; это сервис глубокой диагностики и перевода человека в новый вектор реализации. Это значит, что продукт не заканчивается на понимании себя. Он должен довести человека до следующей формы действия:; новой роли; новой ниши; нового продукта; нового позиционирования; нового публичного образа; нового сценария профессионального движения. Почему этот проект вообще может существовать На рынке давно есть по отдельности:; расстановки; астрология; личный бренд; карьерные консультации; распаковка личности Нового в чистом смысле "по методам" здесь мало. Но есть незакрытое пространство между двумя мирами: 1.

Роль блока в системе проекта

Блок 03. Архитектура продукта нужен, чтобы удержать для проекта vector relaunch lab не один красивый тезис, а взрослую рабочую рамку: что здесь является ядром, как это считывается рынком, чем подтверждается в исходниках и во что должно превратиться в упаковке, продаже и дальнейшем действии.

Развернутая рабочая рамка

Здесь мы фиксируем не список всего, что можно сделать, а архитектуру основного продукта: ядро старта, дополнительные ветки, уровни глубины, ограничения и точки, где продукт реально приносит ценность. Это означает, что блок нельзя собирать только как красивый текст для передачи клиенту. Он должен одновременно выдерживать роль внутреннего source of truth, материала для презентации, опоры для сайта и фильтра для будущих решений команды. Если хотя бы одна из этих функций разваливается, проект начинает терять цельность.

Что этот блок должен изменить в упаковке

Для сайта и презентации это должно превращаться в четкую структуру продукта: формат, этапы, состав, варианты прохождения, optional-слои и понятную логику “что человек получает на каждом шаге”. Поэтому после сборки блока команда должна понимать не только “что написать”, но и “что убрать”, “что вынести на первый экран”, “какие доказательства нужны рядом” и “какой CTA здесь звучит честно”.

Решения, которые отсюда должны вытекать

Хороший стратегический блок всегда заканчивается не ощущением глубины, а набором конкретных решений: что именно остается ядром, какие ветки пока не расширяем, где нужен ручной контроль, какие смыслы переводим в отдельные deliverables, какие файлы создаем следующими и что считаем признаком зрелой упаковки на текущем этапе.

Что должно получиться на выходе из этого блока

Риски и контрольные вопросы

Контрольный список следующего шага