Product Owner of NORM (PO) / Владелец продукта NORM

Зачем эта роль

PO NORM существует, потому что у компании есть главный продукт-актив акционеров — методологический стек NORM — и у этого актива должен быть один человек, отвечающий за то, чтобы он рос, развивался и оставался отчуждаемым от компании. Без PO NORM методология превращается либо в личную экспертизу одного-двух носителей (которая не масштабируется), либо в набор разрозненных регламентов без архитектуры (которые не складываются в продукт), либо в «то, что мы делаем» без артефактов, которые можно продать или передать.

PO NORM собирает методологию в продуктовый стек с архитектурой, AI-усилением и дисциплиной развития. Его роль постоянна и существует над операционкой компании: он не отвечает за продажи, не управляет проектами, не ведёт клиентов. Его единственная зона — продукт NORM как актив на горизонте 5+ лет.

PO NORM — Entrepreneur + Integrator в логике PAEI. Entrepreneur — поиск возможностей в развитии стека: какие новые блоки добавить, какие AI-агенты встроить, какие закономерности из практики оформить в методологию. Integrator — сборка пяти блоков в единое целое, поддержание согласованности между ними. Сильная сторона — продуктовое мышление, видение архитектуры, дисциплина развития. Слабая сторона (то, что НЕ должно быть в его зоне) — продажи, управление проектами, операционная систематизация компании.

Что входит в NORM

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

• Блок стратегии — как клиент формулирует свою стратегию, как переводит её в операционные приоритеты
• Блок управления людьми — как клиент работает с командой: найм, развитие, оценка, удержание
• Блок клиентского пути — как клиент работает со своими клиентами: воронка, продажи, удержание, расширение охвата
• Блок операционной дисциплины — как клиент удерживает операционную управляемость: регламенты, метрики, ритуалы
• Блок знаний и AI — как клиент работает с информацией и AI: контекстная инфраструктура, AI-агенты, AI-усиление процессов

Стек поставляется не как набор документов, а как технологическая платформа с встроенными AI-агентами, дашбордами и автоматизацией процессов. Это позволяет применять его в живом контуре клиента, а не только на бумаге. AI-усиление — не опция, а часть архитектуры стека: каждый блок имеет свои AI-агенты, дашборды и точки автоматизации.

Отчуждаемость как часть продукта

Особенность PO NORM — отчуждаемость продукта зашита в обещание самой роли. Стек должен быть применим и развиваем без зависимости от одного носителя. Это не побочный эффект работы PO, это прямая часть продукта, выражающаяся в специальной метрике (Product Severability) и в дисциплине самой роли.

Это означает, что PO NORM работает не только с содержанием стека (что в нём есть), но и с его архитектурой передачи: как обучить новых senior-носителей, как описать каждый блок в форме, которую может применить не автор, как встроить дисциплину передачи в собственный рабочий процесс. Без этой работы стек остаётся «методологией одного человека» — не активом.

Аналогично CSO с его Sales Playbook, у PO NORM это делает роль ответственной не только за развитие продукта, но и за превращение собственного опыта в актив, не зависящий от носителя.

PO NORM и COO: разделение ролей

PO NORM и COO — обе работают с методологическим стеком компании, обе влияют на то, как организована работа. Но они работают на разных сторонах одной системы и решают разные задачи. Это разделение критично, потому что иначе функция методологии будет либо размыта между двумя ролями, либо концентрироваться в одной с потерей профессионального качества.

Короткая формулировка:

• PO NORM владеет методологическим стеком как продуктом: что в стеке есть, какие блоки добавить, какие переработать, что в стеке больше не работает. Горизонт — эволюция продукта на годы.
• COO владеет процессами и регламентами компании: как стек применяется внутри NOTA, какие SOP нужны, какие стандарты клиентского пути ввести, как организован найм, IT, PMO. Горизонт — операционная управляемость на месяцы и кварталы.

В чём это проявляется:

Когда это важно понимать:

• Когда CVD приносит паттерн с проекта — решает PO NORM, входит ли паттерн в стек
• Когда нужно внедрить стандарт работы внутри компании (например, общий формат квартального обзора с клиентом) — решает COO, как это раскатать
• COO — главный внутренний потребитель PO NORM: NOTA как нулевой клиент применяет стек первой, до внешних клиентов
• Эволюция методологии — итеративный диалог между ними: PO NORM проектирует, COO внедряет внутри, обратная связь корректирует и продукт, и внедрение

Две траектории применения стека

Стек NORM применяется по двум независимым траекториям, и PO NORM отвечает за обе:

• Внешняя траектория: CVD применяют стек на клиентах через консультативные проекты. PO поставляет CVD рабочую методологию, которой они могут опираться на проектах, и принимает обратную связь о применимости.
• Внутренняя траектория: NOTA применяет стек к самой себе как «нулевой клиент». COO заказывает у PO применение блоков к компании, доводит до работающей конфигурации. Внутренняя референс-конфигурация даёт CVD возможность показать клиенту: «методология работает у нас самих».

Обе траектории питают развитие стека: внешние внедрения дают валидацию на платящих клиентах (метрика External PMF Validation), внутреннее применение даёт возможность тестировать новые блоки до выхода на рынок.

Продукт должности

Воспроизводимый и отчуждаемый AI-powered методологический стек NORM, состоящий из пяти поименованных блоков (стратегия, управление людьми, клиентский путь, операционная дисциплина, знания и AI). Стек поставляется не как набор документов, а как технологическая платформа с встроенными AI-агентами, дашбордами и автоматизацией процессов — что позволяет применять его в живом контуре клиента, а не только на бумаге. Стек применим и развиваем без операционного участия CEO: senior-носители способны провести полный цикл консалтинга, продуктовые решения принимаются командой PO без эскалации.

Главный потребитель и его требования

Главный потребитель: Shareholders (получают продукт-актив, ради которого существует стратегия компании).

Shareholders получают от PO NORM не «методологическую работу», а реальный актив, который может расти в стоимости и существовать на горизонте 5+ лет независимо от текущей команды. Конкретные требования:

• Стек подтверждён на платящих клиентах вне якоря. Главный замер — реальные внедрения NORM у независимых клиентов, не аффилированных с якорными аккаунтами. Стек, который работает только на одном специфическом клиенте, — это ещё не продукт.
• Стек отчуждаем от любого конкретного носителя. К горизонту, согласованному в стратегии, в компании должно быть несколько senior-носителей, способных применять стек самостоятельно. Продуктовые решения принимаются командой PO без эскалации к CEO.
• AI-усиление — реальное, а не косметика. Каждый блок стека имеет встроенные AI-агенты, дашборды, точки автоматизации, которые работают в реальной среде клиента. Не «методология с AI-обвесом», а архитектура, в которой AI — несущий элемент.
• Стек согласован между блоками. Пять блоков NORM не существуют отдельно; они образуют целое, в котором применение одного блока поддерживает применение другого. Если блоки конфликтуют между собой или дублируют друг друга — это сигнал о провале интеграции.
• Развитие стека — управляемое, а не стихийное. Изменения в продукте проходят через PO как фильтр: что добавить, что переработать, что вывести из стека. Без PO как фильтра стек либо стагнирует, либо разрастается до невозможности применить.

Вторичный потребитель: CVD-руководители — применяют стек на клиентах. Получают рабочую методологию, на которую можно опираться на консультативных проектах и в работе с конкретными клиентскими задачами. Поставляют PO обратную связь с реальных проектов как сигнал для эволюции.

Третичный потребитель: внутренние «нулевые клиенты» NOTA — CEO, COO, CMO — применяют блоки стека внутри компании. NOTA как первый кейс валидации каждого блока. Это особая роль: они не платят за стек, но дают живую референс-конфигурацию для внешних клиентов.

Run / Change / Disrupt

Run (поддержание потока)

То, что PO NORM делает каждую неделю и каждый месяц, чтобы стек жил:

• Управление архитектурой стека: согласованность пяти блоков, отсутствие дублирования, прозрачность связей между блоками
• Курирование AI-усиления: какие AI-агенты в каких блоках, как они работают, как обновляются под изменения моделей
• Ведение продуктового бэклога NORM: какие изменения вносятся в каждый блок, в каком приоритете
• Координация с CVD на проектах: применимость стека на конкретных клиентах, обратная связь, тактическая поддержка
• Координация с COO по внутреннему применению: какие блоки внедряются внутри NOTA, в каком порядке, какие адаптации нужны
• Поддержка senior-носителей: 1:1, обучение, разбор сложных кейсов с проектов
• Производство и обновление публичных артефактов стека: документация, обучающие материалы, демо-кейсы
• Координация с CMO по позиционированию стека на рынке: что в стеке, как это рассказать

Change (улучшение того, как роль работает)

То, что PO NORM делает на горизонте квартала, чтобы стек становился лучше:

• Эволюция блоков по обратной связи с реальных внедрений (внешние и внутренние)
• Включение новых паттернов в стек: PM/CVD/FDE/AIA приносят паттерны с проектов, PO решает, что войдёт в стек и в каком виде
• Развитие AI-усиления: освоение новых моделей, новых паттернов AI-оркестрации, обновление агентов под новые возможности
• Развитие команды senior-носителей: рост, наставничество, расширение круга людей, способных применять стек
• Подготовка к публичным внешним кейсам: какие проекты могут стать публичными подтверждениями PMF
• Эволюция формата передачи стека: как сделать его более воспроизводимым, как сократить время вхождения нового носителя

Disrupt (переизобретение роли)

То, что меняет саму конфигурацию роли в системе:

• AI-усиление PO: автоматическое выявление паттернов с проектов в реестр кандидатов на включение в стек, AI-ассистент для разбора применимости новых блоков, автоматическое обновление документации стека
• Превращение стека в self-serve платформу: клиент применяет стек самостоятельно через платформу с встроенными AI-агентами, без обязательного консультативного сопровождения
• Переход от «стек как продукт NOTA» к «стек как открытый стандарт индустрии» — компания становится владельцем методологии, которую применяют другие игроки рынка
• Расширение модели на смежные продуктовые линейки: тот же подход (5 блоков, AI-усиление) применяется к другим методологиям

Метрики

PO NORM измеряется композитом из 2 метрик — это сознательное исключение из стандарта 3-5 метрик. Природа продукта (методологический стек на горизонте 5+ лет) сводится к двум стратегическим вопросам: подтверждается ли стек реальным рынком вне якорного клиента, и можно ли передать стек носителям, не зависящим от основателя. Дополнительные операционные метрики на этом горизонте создавали бы шум, не сигнал.

Логика композита: одна метрика — внешняя валидация PMF (наличие нескольких независимых платящих клиентов вне якорного БАУ-Сервиса, применяющих методологию NORM), отражающая главное стратегическое обещание перед Shareholders — «стек применим к среднему бизнесу русскоговорящего и MENA-контура, не только в условиях якорного клиента». Вторая — отделимость продукта от основателя (степень, в которой методологический стек может быть применён командой из 2–3 senior-носителей без личного участия PO NORM), отражающая критерий перехода компании из персональной экспертизы в продуктовую модель.

Метрики дополняют друг друга по логике «есть ли product-market fit / является ли это продуктом или зависит от человека». Если PMF подтверждён, но Severability низкий — продукт работает только в руках основателя, при передаче или росте всё развалится. Если Severability высокий, но PMF не подтверждён — стандартизировали то, что рынок не покупает.

Полный список метрик с определениями и порогами — в свойстве Metrics ниже.

🟢 Full Zone of Genius (зона полной автономии)

Решения, которые PO NORM принимает сам, без согласования с кем-либо. Это широкая зона в продуктовых вопросах, ограниченная границей с применением стека (CVD на проектах, COO внутри NOTA), стратегией (CEO, Shareholders) и позиционированием на рынке (CMO).

• Содержание методологического стека. Что в каждом блоке NORM присутствует, какие подходы используются, как структурированы артефакты блока. PO решает по профессиональному суждению.
• Архитектура стека: связи между пятью блоками. Как блоки взаимодействуют, какие точки интеграции, как одно поддерживает другое. Это собирающая зона PO как Integrator'а.
• AI-усиление каждого блока. Какие AI-агенты, какие модели, какие паттерны автоматизации. PO решает в рамках утверждённого бюджета на AI-инфраструктуру.
• Продуктовый бэклог NORM. Что в каком приоритете развивается, что выводится из стека, что замораживается. PO ведёт бэклог сам.
• Решения о включении паттернов с проектов в стек. Когда CVD/PM/FDE/AIA приносят паттерн — PO решает, входит ли он в стек, в каком блоке, в какой форме. Это профессиональный фильтр PO.
• Формат и структура артефактов стека. Как структурированы документы, демо, обучающие материалы. PO решает по требованиям применимости и передаваемости.
• Тактика развития senior-носителей. Кого растить как следующего носителя, в каком темпе, через какие проекты, какой формат обучения. PO решает по контексту команды.
• Содержание обратной связи COO по внутреннему применению. Какие блоки готовы к внедрению внутри NOTA, в каком порядке, в какой адаптации. PO координируется с COO, но решение о готовности блока за PO.
• Тактические переговоры с C-level клиента по содержанию стека. Когда PO лично подключается к клиенту по продуктовым вопросам — формат, аргументы, ритм. CVD ведёт аккаунт в целом, PO подключается на коротком отрезке по профильным вопросам.

Принцип: всё, что касается что находится в стеке и как он устроен внутри согласованной стратегии — это зелёная песочница PO NORM. Зрелость PO измеряется тем, насколько широка его автономия в продуктовых решениях без потери согласованности стека и без выхода за рамки утверждённой стратегии.

🟡 Decisions Requiring Collaboration (коллегиальные решения)

Решения, которые PO NORM принимает в коллаборации с другими ролями. Здесь критично понимать с кем и как принимается решение.

• Стратегическое позиционирование NORM на рынке → с CEO и CMO. Как: PO отвечает на вопрос «что в стеке есть» (содержание), CMO формулирует «как это рассказать рынку» (форма), CEO утверждает финальное позиционирование на стратегическом горизонте.
• Внедрение блоков методологического стека внутри NOTA как нулевого клиента → с COO. Как: COO формулирует, какой блок нужно внедрить и зачем (по обратной связи от CVD), PO валидирует готовность блока, помогает с адаптацией; COO внедряет внутри.
• Применение блоков стека на проектах CVD → с CVD и AIA (когда блок касается AI-инфраструктуры). Как: CVD/AIA формулирует, какой блок хочет применить и зачем, PO валидирует применимость и помогает с адаптацией под конкретного клиента.
• Включение крупных архитектурных изменений в стек (новый блок, существенная переработка существующего блока) → с CEO и Shareholders. Как: PO формулирует обоснование с продуктовой и стратегической перспективой, CEO выносит на Diwan/Shareholders, утверждается как изменение продукта-актива.
• Бюджет на развитие стека (внутренняя команда PO, AI-инфраструктура, инструменты) → с CEO. Как: PO формулирует план на основе текущего состояния стека и приоритетов на год, CEO утверждает на годовом плане.
• Привлечение нового senior-носителя в команду стека → с CEO и HR Manager. Как: PO формулирует профиль и обоснование, кадровое решение принимает CEO по согласованию с HR Manager.
• Обратная связь о сделках, влияющая на продукт компании (что в продукте/услугах нужно изменить по результатам отказов или возражений) → с CSO и CEO. Как: CSO агрегирует паттерны отказов и возражений с воронки, передаёт PO; PO итерирует продуктовые гипотезы, CEO утверждает стратегические изменения.

🔴 Decisions That Should Never Be Made (зона запрета)

Решения, которые PO NORM не принимает ни в одиночку, ни в коллаборации.

• Продажи и привлечение клиентов. Это зона CSO (новые сделки) и CVD (расширение охвата существующих клиентов). PO может подключаться к клиенту по продуктовым вопросам, но не ведёт продажу.
• Управление проектами на стороне клиента. Это зона PM. PO не вмешивается в проектное управление.
• Реализация конкретных решений на проекте (код, конфигурации, интеграции). Это зона FDE и AIA. PO держит методологию, не реализует её на конкретных проектах.
• Управление дивизионами и портфелем CVD. Это зона CVD как руководителя дивизиона. PO влияет на стек, но не управляет тем, как CVD ведёт свой портфель.
• Маркетинговые формулировки и материалы. Это зона CMO. PO отвечает на вопрос «что в стеке есть», но не определяет, какими словами это рассказывается рынку.
• Внедрение операционных регламентов внутри компании. Это зона COO. PO поставляет COO готовые блоки стека, но не внедряет регламенты в NOTA сам.
• Культура компании, ценности, идентичность команды. Это зона CEO. PO работает с продуктом, не с культурой.
• Стратегические решения о направлении развития компании (выход на новые рынки, M&A, запуск новых продуктовых линий). Это зона CEO и Diwan. PO даёт продуктовую обратную связь, но не определяет стратегию.
• Финансовая стратегия компании, ценообразование на стек, инвестиционные решения. Это зона GM и CEO. PO работает в рамках утверждённого бюджета развития стека.
• Кадровые решения по C-Suite или CVD ролям. Это зона CEO и Diwan. PO может высказать мнение по продуктовой совместимости, но решение не его.

Принцип: красная песочница PO NORM — это граница с применением стека (CVD, PM, FDE, AIA, COO), граница с маркетинговой стороной продукта (CMO), граница с коммерческим контуром (CSO), граница с культурой (CEO) и граница со стратегическим контуром (CEO, Diwan, GM). PO работает с содержанием продукта; всё, что вне этого — не его.

Цикл PDCA

PO NORM управляет двумя вложенными циклами с разной частотой. Внешний цикл — управление продуктом-активом на горизонте года и больше; внутренний — управление каждым изменением в стеке.

Цикл управления изменением в стеке (короткий, по изменению)

• Plan — постановка изменения: формулировка гипотезы (что добавить/переработать в каком блоке), обоснование (источник — обратная связь с проекта, новая возможность AI, разрыв в покрытии), целевая форма артефакта.
• Do — реализация: разработка изменения, валидация на тестовом кейсе (внутри NOTA как нулевого клиента или на пилотном проекте CVD), оформление артефакта в стеке.
• Check — валидация: применение в реальном проекте (внутреннем или внешнем), сбор обратной связи, замер применимости.
• Act — закрепление или откат: при положительной валидации — публикация изменения в стеке, обновление документации; при провале — откат и фиксация в копилку гипотез, не оправдавших себя.

Цикл управления стеком как продуктом (длинный, годовой)

• Plan — годовой продуктовый план: приоритеты развития блоков, бюджет на AI-инфраструктуру и команду, цели по числу senior-носителей и валидаций PMF.
• Do — ведение продукта: управление бэклогом, координация с CVD/COO/CMO, развитие senior-носителей, обновление AI-усиления, обработка обратной связи с проектов.
• Check — годовой замер: External PMF Validation за год, Product Severability на конец года, оценка зрелости стека по блокам, разбор валидированных и невалидированных гипотез.
• Act — корректировка стратегии продукта: обновление приоритетов по блокам на следующий год, корректировка плана развития senior-носителей, обновление дорожной карты AI-усиления, при необходимости — стратегические изменения архитектуры стека (через CEO/Shareholders).

Внутренний цикл (изменение) питает внешний (продукт): каждое изменение либо подтверждает, либо опровергает продуктовые гипотезы; накопленный опыт формирует картину, в каком направлении эволюционирует стек. Внешний цикл задаёт рамки для внутреннего: годовой продуктовый план определяет, какие изменения PO берёт в работу.