Product Owner для строительного маркетплейса

Контекст проекта

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

Я заходил как Product Owner: собирал продуктовую рамку, уточнял рынок, фиксировал зоны ответственности, строил модель взаимодействия между отделами и переводил неопределённость в последовательные спринты.

Экономика и риски запуска

В презентации отдельно фиксировалась денежная логика: стадия посева, инвестиции, запуск, операционный ноль, точка безубыточности и точка роста. Для такого продукта это критично: маркетплейс нельзя запускать только “по вдохновению”, его нужно собирать через unit-экономику, каналы, ФОТ, склад, логистику, рекламу и P&L.

• Собрал предварительную финансовую модель и список метрик для контроля.
• Зафиксировал зависимость продукта от складов, ПВЗ, РТТ, логистики и оплаты.
• Разделил проект на этапы, где сначала появляется управляемость, потом рост.

Предпроектная работа

Первый большой блок — pre-project. В нём нужно было собрать требования, выбрать архитектуру, сформировать команду и составить план проекта. Это была точка, где хаотичная идея стала управляемым набором эпиков и задач.

Research, рынок и вопросы к отделам

Проект нельзя было делать в вакууме. Я собрал конкурентный срез по регионам, посмотрел на “ВсеИнструменты”, выделил долю B2B-клиентов и сформировал вопросы к отделам: склады, ПВЗ, формат выдачи, логистика, копирование успешных паттернов под нашу нишу.

• Проверял не только “кто конкуренты”, а где у них физическая инфраструктура.
• Отдельно вынес B2B как значимую часть рынка и будущих сценариев.
• Собрал вопросы для отделов, без которых продуктовая модель была бы фантазией.

Scrum без религиозности

Важное решение — не тащить методологию “как в книжке”. Я упростил Scrum под реальную скорость проекта: оставил stakeholder → PO → product backlog → sprint planning → sprint backlog → sprint → review → retrospective → план изменений.

Так команда получила понятный ритм, но без лишней бюрократии. Методология стала инструментом ускорения, а не отдельной работой ради процесса.

Операционный слой

На уровне операций я фиксировал встречи, WBS, календарь, подрядчиков, зоны ответственности и документацию. Это скучная часть, но именно она превращает красивую презентацию маркетплейса в проект, который можно делать.

• 35+ командных созвонов и ресерча.
• Документы по бизнес-потребностям, стейкхолдерам, рынку и требованиям.
• Оценка объёма работ через WBS и согласование встреч.
• Формирование команды: дизайн inhouse, разработка outsource, исследования inhouse, маркетинг смешанно.

Подключение дизайна и второй эпик

Следующий блок был связан с ИИ-дизайнером, правками по документам и подготовкой к дальнейшему продуктовому дизайну. Параллельно в плане уже был второй эпик — Discovery & Research с данными, benchmarking, CustDev, сегментацией и переходом к продуктовому дизайну.

Результат и эффект

Главный результат — у проекта появилась управляемая продуктовая рамка: стало понятно, что исследуем, какие отделы подключаем, какую команду собираем, как планируем, какие метрики смотрим и как презентуем инкремент стейкхолдерам.

Как Product Owner я не просто “вёл задачи”: я связывал бизнес, финансы, исследования, дизайн, разработку, юридическую часть и менеджмент в один понятный рабочий контур.