Лев Корнев - Развитие продукта

Сильный продакт, держи команду!

В День самоуправления в школе я стал директором. Ещё тогда меня драйвило управление: твои решения влияют на всю систему.

Спустя годы в Яндекс Маркете я отвечал за самовывоз и вёл кросс-контурный проект по оборотной таре. Прямых подчинённых ещё не было, за общий результат нескольких команд уже отвечал я.

Этот проект показал, что я вывожу большую зону ответственности. Плюс я сам говорил руководителю, что хочу в пиплменеджмент. В итоге мне предложили возглавить продуктовую команду в коммерции Маркета.

В новой роли я собирал стратегию целой области: связывал её с целями бизнеса, договаривался со стейкхолдерами по приоритетам. И растил продактов внутри команды.

Сила продакта и готовность руководить людьми - разные компетенции.
Лиду нужно давать обратную связь, подбирать задачи на вырост, разбирать ошибки и помогать команде профессионально грейдапится. Без интереса к развитию людей команда быстро превращается в подряд для решений самого руководителя.

Управленческий навык можно проверять постепенно. Сначала дать продакту кросс-контурный проект. Он получит большую зону ответственности, будет вести несколько команд и договариваться со стейкхолдерами.

Затем предложить один цикл или месяц в роли лида. У Владимира Тарасова в Искусстве управленческой борьбы есть мысль: новому руководителю нужно дать поддержку и возможность вернуться на прежнюю роль.

Если роль не подошла - провести карьерную рокировку, как в правительстве: перевести из B2B в B2C, дать новый рынок или более крупный продукт.

Команда - отдельный карьерный выбор. Один продакт растёт через людей, другой через масштаб продукта.

А вы бы согласились на месяц стать лидом с возможностью вернуться?
❤️ попробовал бы роль лида
😈 дайте продукт покрупнее

@product_lev
#pm #productmanagement #управление #лидерство #карьера

Грейд догоняет ответственность: как заметить рост

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

Горизонтальный рост обычно виднее: продакт погрузился в техничку, маркетинг, интервью, A/B.
Для этого полезны задачи на шаг сложнее привычных, чтобы было интересно и посильно.

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

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

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

А по каким сигналам вы понимаете, что продакту пора дать больше масштаба?

❤️ выросла зона - вырос грейд
😈 ещё полгода докажи

@product_lev
#pm #productmanagement #рост #управление #команда

Корпоративное таинство под названием 1-1

Два человека закрываются в переговорке.
Иногда уходят в кофейню за отдельный столик.
О чём говорили - никто не знает

Так и должно быть: ван-ту-ван - личный разговор
Когда я прихожу на one-to-one к своему руководителю, примерно 80% разговора строю вокруг текущих задач: куда я их двигаю, где сомневаюсь, какие вижу риски и не пропускаю ли я какое-то течение внутри компании
Мне важно проверить две вещи: я правильно понимаю контекст вокруг, руководитель понимает, куда я иду.

Там же можно энергичнее обсудить то, что не вынесешь на общий статус
Например, поведение коллег и как лучше выстроить с ними коммуникацию
Не чтоб посплетничать, а чтобы эффективнее договориться.

Когда я с другой стороны стола и встречаюсь с продактом, то жду от него повестку, движение продукта и новости с полей
В ответ могу дать контекст сверху, поделиться стратегическим видением, помочь ускорить решение или подключиться там, где нужен мой вес(BTW -16кг с июня, кто знает, тот в курсе)
Это постоянный баланс: что продакт решает сам, а что стоит эскалировать

Универсального 1-1 при этом нет.

Одному человеку нужно помочь перепроверить аналитику, другому - разобраться в сложной коммуникации.
Третьему достаточно сверить направление и дальше не мешать.

Адизес писал про разные стили управления. С 1-1 та же история: кому-то нужен весь контекст, а кого-то он только раздражает.
Одному важнее конкретное решение, другому - большая картина или отношения внутри команды.

Оставшиеся 20% у меня обычно про личное. Чтобы не только двигать продукты в одну сторону, но и самим оставаться на одной волне.

Хороший 1-1 - не статус без свидетелей и необязательная психотерапия, а личный управленческий канал, который каждый раз приходится настраивать под двух конкретных людей.

❤️ сверяю направление и контекст
😈 сплетни и ябедничество

@product_lev

#pm #productmanagement #управление #лидерство #onetoone

Задача ушла, продукт остался

Когда я переходил из логистики в коммерцию в Яндексе, то полностью передавал продукт самовывоза новому менеджеру.

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

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

С точки зрения теории делегирование - это передача не только действия, но и полномочий, необходимых для результата.

Можно делегировать:
- отдельную задачу
- участок работы
- целый продукт
В последнем случае нужно передать:
- контекст и ограничения
- таргет
- право принимать решения
- контрольные точки

Если человек только исполняет твой план, ты делегировал задачу. Если сам решает, что делать и почему - передал продукт.

В моём случае после короткого переходного периода продукт спокойно жил без меня.

А у вас чаще делегируют задачи или действительно отдают продукт?
❤️ отдаю продукт
😈 отдаю только задачи
@product_lev
#pm #productmanagement #управление #делегирование #команда

Что почитать?

Нарративное лидерство, Артём Мушин-Македонский
Кому: тем, кому приходится убеждать, обучать и вести людей за собой
Оценка: 10 историй из 10

Отзыв:

В книжном клубе читали книгу после "Наш айсберг тает" Джона Коттера, поэтому я ждал больших управленческих речей, главного пингвина, чего-то вроде "I have a dream".

Но книга оказалась заметно прикладнее.

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

Что забрал себе:
1) Нарратив - это управленческий инструмент, а не только красивые тексты
2) Начать применять его можно с простой истории о том, что хорошего произошло в компании
3) Истории особенно полезны в маркетинге, продажах, обучении и коучинге
4) История не всегда лучше прямой просьбы
5) ИИ уже неплохо помогает собрать структуру истории, но остаётся металлический привкус
Главная мысль для меня: продакт постоянно объясняет, почему сейчас нужно взяться именно за эту задачу, зачем менять процесс, или чего хорошего сделала команда. Можно ограничиться сухим фактом, а можно показать ситуацию, действие и результат с потенциалом изменить слушателя.

Часть 2. Как читали в клубе
Книгу обсудили вместе с автором! 💥
С Артёмом поговорили про Chief Story Officer - человека, который помогает распространять практику работы с нарративами по всей компании.

Галя(главный чтец) собрала скилл по инструкциям Артёма. Посмотрели, где заканчивается автоматизация и начинается человеческая интонация.

Если интересно читать не только про инструменты управления, но и про то, как люди понимают смысл и принимают решения, присоединяйтесь к нашему Книжному клубу для менеджеров.

#чтопочитать #книжныйклуб #управление #лидерство #нарратив #сторителлинг #productmanagement

Мы всё считали в Hyundai Solaris

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

Оценить в Hyundai Solaris

В Маркете у нас был жирный проект по оборотной таре. Делали его год. Смотрели, как он влияет на GMV, считали экономию и в какой-то момент начали переводить её в Hyundai Solaris.

Почему именно Solaris?

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

На внутренних синках результат становился понятнее. Его можно было запомнить, обсудить и объяснить человеку, который не сидел вместе с нами в таблицах, не знал бенчмарок.

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

Пока думал над этим постом, понял, что в быту у меня есть похожий подход:
Личные траты иногда перевожу в кружки кофе или походы в кафе.
Можно быстро понять, что это нормальная трата в кофе/ресторанах и не париться о потраченных деньгах.
А у вас есть своя единица измерения?

❤️ понимаю деньги через кофе
😈 всё считаю в сторипоинтах

@product_lev
#pm #productmanagement #ценность #мотивация #метрики

Cost of Delay: сколько стоит подождать

Дано:
В бэклоге две задачи
Обе - месяц разработки, стоят одинаково, риски и уверенность в оценке схожи
Первая может принести 3 млн рублей/год
Вторая - 500 тысяч
Какую берём первой?

.
.
.

Не все вводные были в условии.

Первая сохранит ценность и через месяц. А у второй открыто короткое окно возможностей:
- партнёр готов к интеграции сейчас
- HR-коммуникации могут включить запуск в ближайшую рассылку
- начался высокий сезон

Если не успеть сейчас, следующая возможность появится через квартал. Или не появится вообще.

Cost of Delay показывает, как быстро задача теряет ожидаемую ценность, пока лежит в бэклоге.
Сама задача не стала ценнее, просто её ценность может протухать
Поэтому при приоритизации стоит учитывать: Что останется от ценности, если подождать месяц?

❤️ знаю цену ожидания
😈 важная задача и в следующем квартале важная

#pm #product #приоритизация #costofdelay

Сетапим задачи по-модному

Я перестал писать промпты руками. Почти..

В прошлом году смотрел первую конфу у Вани Замесина про вайбкодинг. Он тогда только погружался в вйбкодинг, но собрал ребят, которые уже напилили рабочие SaaSочки.
У меня был шок, когда на демо Сева Устинов или Харитон Матвеев показали, как дают команды голосом через SpeechKit. Я тогда сказал жене: "Посмотри, это же работа с Джарвисом, как у Тони Старка. Вот тебе будущее"

У меня оно наступило. Круто!)

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

Дальше прошу агента самому собрать из этого план решения, но не выполнять его сразу. Сначала он кратко пишет, как понял задачу, и задает вопросы, если чего-то не хватает.

Для меня это убрало проблему белого листа.

Не нужно одновременно думать, структурировать и писать. Сначала выгружаешь мысли, модель собирает структуру под моим контролем.

Вторая часть сетапа - контекст. Многое не нужно объяснять заново.

Я храню его в Obsidian, сами файлы лежат в GitLab.

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

По сути, весь мой сетап сейчас: голос + база контекста.

А какие вы используете приемы?

#pm #Obsidian #AIagents #продуктовыйменеджмент

S3: где приложение хранит файлы

Для меня S3 всегда звучал как техническое файловое хранилище. В целом это недалеко от истины.

S3 (Simple Storage Service) - сервис Amazon, который позволяет отделить хранение файлов от серверов самого приложения.

Он настолько популяризировал подход Object Storage, что сегодня многие другие хранилища поддерживают тот же S3 API и называются S3-compatible.

В S3 удобно хранить картинки, видео, документы, бэкапы и другие файлы приложения.

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

При этом Object Storage подходит не для любых данных. Объекты удобно положить и забрать целиком, но это не лучший вариант для постоянного изменения маленьких частей данных или сложных запросов по их содержимому.

Кроме Object Storage существуют еще File Storage и Block Storage - это уже другие модели хранения под другие задачи.

❤️ знаю, где у продукта лежат картинки
😈 папка uploads на сервере надежнее

#pm #product #словарик #s3 #storage

YT/YTsaurus: база данных на максималках?

В прошлом посте я свалил в один блок DWH, ClickHouse и YT. Разберемся, что из этого что.

YT (сейчас YTsaurus) - распределенная платформа для хранения и обработки больших объемов данных, изначально разработанная в Яндексе.

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

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

Отсюда и связь с прошлым постом:

YT - платформа хранения и вычислений
DWH - концепция аналитического хранилища
ClickHouse - СУБД для быстрых аналитических запросов
BI - инструменты, через которые результаты анализа доходят до человека

Поэтому фраза «данные лежат в YT» вполне нормальна, но описывает только часть возможностей YT

А еще поверх YT можно встретить YQL, CHYT и другие способы добраться до данных - но это уже следующий уровень кроличьей норы.

❤️ работал с YT
😈 моя распределенная система - Excel с презами по папкам

#pm #product #словарик #yt #ytsaurus #data

Grafana, BI и продуктовая аналитика: если везде графики, в чем разница?

В прошлых постах разобрались:
• Grafana хорошо показывает техническое здоровье системы
• я использовал ее и для простых продуктовых метрик
Зачем тогда вообще нужны другие инструменты?

Разница в вопросах, на которые они помогают отвечать:

Grafana - что происходит с системой?
ошибки, нагрузка, задержки, изменение метрик во времени

BI (Business Intelligence) - что происходит с бизнесом?
выручка по продуктам, продажи по регионам, динамика показателей
Tableau, Power BI и Metabase - примеры BI-инструментов(чтоб потом потом поиском по каналу найти:) )

Продуктовая аналитика - что делают пользователи?
воронки, retention, когорты, путь внутри продукта.
Amplitude, MyTracker и похожие системы работают с событиями пользователей
MyTracker заодно закрывает задачи маркетинговой аналитики и атрибуции

Под красивыми графиками лежит еще один слой - хранение и обработка данных.
Например, DWH(Data Warehouse) - аналитическое хранилище
ClickHouse - конкретная СУБД
YT/YTsaurus - распределенная платформа для хранения и обработки больших данных, про нее отдельно

Итого, графики могут выглядеть одинаково, но под ними разные модели данных и задачи.

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

❤️ знаю, где какой дашборд лежит
😈 иксель закроет все три задачи, топ СУБД

#pm #product #словарик #bi #analytics #grafana

Grafana и Prometheus: что я забыл в DevOps-инструментах

В прошлом посте было три типа телеметрии для Observability: Metrics, Logs и Traces
Prometheus работает прежде всего с Metrics - числовыми показателями состояния системы во времени.

Например, метрика покажет: 12:03 → 2% запросов завершились ошибкой
Лог сохранит конкретное событие: 12:03:14 → / payment → ошибка 500
Поэтому метрики помогают увидеть, что с системой происходит по конкретным параметрам, а логи - разобраться, что именно происходило в конкретном случае.

Сервис может вести счетчики запросов и ошибок, а Prometheus регулярно забирать их значения.
Бывает и наоборот: показатель рассчитывают из множества логов - это logs-based metrics.

Grafana подключается к Prometheus и другим источникам и превращает эти данные в графики, дашборды с алертами.

Отсюда мой микроскоп для гвоздей:
Grafana хорошо показывает техническое здоровье системы во времени, но продуктовая аналитика часто требует восстановить поведение конкретного пользователя.
В следующем посте: почему для этого используют другие инструменты и причем тут BI

❤️ смотрю в Графану сам
😈 узнаю о проблемах от пользователей

#pm #product #словарик #grafana #prometheus #observability

Observability: что происходит внутри IT-системы

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

Впереди серия постов, комментарии экспертов приветствуются!

Observability (наблюдаемость системы) помогает понять, что происходит внутри IT-системы и почему: мониторить ее в обычное время и расследовать, что пошло не так при инциденте.

Термин пришел в IT из теории управления observability означает возможность определить внутреннее состояние системы по ее внешним сигналам. Термин формализовал математик Рудольф Кальман в 1960-х. Позже идея перекочевала в эксплуатацию сложных программных систем.
Monitoring отвечает «всё ли работает?», observability помогает разобраться «а что именно произошло?»

Обычно выделяют три основных типа телеметрии:
Metrics - числа во времени: запросы, ошибки, задержки
Logs - записи о конкретных событиях и ошибках
Traces - путь конкретного запроса через сервисы

А Grafana и Prometheus... уже инструменты внутри observability, о них в следующем посте.

❤️ знаю, что метрики и логи это разное
😈 не поднимался тот сервис, который не падал

#pm #product #cловарикпродакта #observability

Формальный результат: не перепутать движение с прогрессом

Мы часто целимся в формальный результат не потому, что он важнее, а потому что к нему проще построить маршрут. Получить диплом, запустить проект, выполнить план легче, чем ответить на более неприятный вопрос: что в реальности изменилось благодаря моим действиям?
Формальный результат даёт ощущение завершённости и контроля.
И в этом его главная ловушка: можно очень дисциплинированно двигаться вперёд, но не туда.

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

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

❤️ стараюсь рефлексировать
😈 котлетка растет от зеленого KPI

#pm #productmanagement #мысли

Contextual Product Management: подход зависит от задачи

Заметил интересный термин в статье, делюсь.

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

Contextual Product Management предлагает сначала понять среду: насколько продукт зрелый, велика ли неопределённость, какова цена ошибки... после этого выбирать процессы, метрики и глубину исследований.

Термин нужен как защита от слепого копирования практик: что ускоряет одну команду, может замедлить другую.

В научных работах понятие закрепилось недавно, хотя сам принцип вырос из теории ситуационного управления, держу в курсе.

❤️ контекст - всему голова
😈 RICE и SMART на все случаи
#pm #product #productmanagement #словарикпродакта

Среднее и медиана: у нас всё хорошо, но это не точно

Зарплаты пяти сотрудников: 100, 110, 120, 130 и 1 000 тысяч.

👉 Среднее: сумма значений / их количество = 292 тысячи.

👉 Медиана: значение посередине ряда = 120 тысяч.

Один руководитель поднял среднюю зарплату компании почти в 2,5 раза.

Среднее полезно для расчёта экономики: средний чек, ARPU.
Медиана лучше показывает типичный опыт: время доставки, загрузки или ответа поддержки.

Пример из отслеживания здоровья сайта: типичный запрос занимал около 50 мс, но 6% запросов были в 20 раз медленнее. Среднее не показывало проблему, поэтому вместо него смотрим перцентили:

p50 - это медиана, то есть время, быстрее которого выполняется 50% запросов

p95 - значение, быстрее которого укладываются 95% запросов

p99 - почти все запросы, кроме самых редких задержек

Одна цифра редко описывает всё распределение. Лучше смотреть и на центр, и на хвосты.

❤️ смотрю распределение целиком
😈 беру цифру, которая красивее в презентации

#pm #product #аналитика #словарикпродакта

Сторипоинты: абстракция сложности по Фибоначчи

Story points — относительная единица трудоёмкости, которой команда оценивает усилия, необходимые для выполнения задачи, сравнивая её с другими задачами.

В Agile-командах оценка обычно учитывает объём, сложность и неопределённость задачи. Сторипоинты используют вместе с планинг-покером и выставляют по шкале Фибоначчи: 1, 2, 3, 5, 8.

По канону пять сторипоинтов не означают пять дней. Задача просто больше тройки и меньше восьмёрки относительно понятного команде примера.

А в гайде по Scrum сторипоинтов вообще нет! Это отдельная практика оценки, выросшая из Extreme Programming.

По моему опыту, абстрактная конструкция плохо переживает встречу с реальностью: при финальном планировании сторипоинты всё равно превращались в дни по курсу один к одному.
Сторипоинты полезны скорее как повод обсудить сложность, риски и уверенность команды в оценке. В том числе понять, какой Confidence ставить инициативе в RICE.

Вы как работаете со сторипоинтами?
❤️ реально относительные
😈 один сторипоинт = один день
#pm #product #словарикпродакта

Human-in-the-loop: оставьте человеку красную кнопку

HITL - подход, при котором ИИ выполняет часть работы, а человек остается внутри процесса: проверяет результат, принимает сложные решения и корректирует систему.

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

Чем выше риск и ниже уверенность модели, тем раньше подключается человек.
Для продукта важно заранее определить границы автономности: какие решения ИИ принимает сам, где нужен контроль, какой уровень confidence запускает эскалацию и как сохраняется обратная связь.

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

Хороший HITL сокращает ручную работу и сохраняет контроль над критичными решениями.

❤️ оставляю человеку финальное решение
😈 подключаю человека после инцидента

#pm #product #HITL #словарикпродакта

Selection bias: когда выборка решила за вас
Закрываю гештальт по A/B, кто знает - тот в курсе:)

Selection bias - смещение отбора, которое возникает, когда пользователи в анализе системно отличаются от тех, о ком команда хочет сделать вывод.

Например, запустили новую механику рекомендаций и посмотрели конверсию сегменты: результат отличный! Вот только воспользовались ей самые активные пользователи, которые и раньше покупали чаще.

В итоге команда приписывает продукту эффект, который появился из-за состава выборки, а не из-за продуктового изменения.

Selection bias встречается в опросах, исследованиях, пилотах и A/B-тестах. Например, когда NPS собирают только у постоянных клиентов, анализируют только завершивших onboarding или исключают пользователей, которые перестали пользоваться продуктом после изменения.

С SRM (Sample Ratio Mismatch) есть пересечение, но это разные проблемы. SRM показывает, что участники распределились между группами не в ожидаемой пропорции. Selection bias шире: группы могут идеально разделиться 50/50, но выборка все равно окажется смещенной из-за того, кого включили в анализ.

Хорошая метрика на плохой выборке дает плохое решение с красивым графиком😎

❤️ проверяю состав выборки, осознанно выбираю сегменты
😈 спрашиваю мнение только у выживших

#pm #product #словарикпродакта #ab #analytics

Stage-Gate: инвестиционные ворота продукта

Stage-Gate, или Phase-Gate, это фреймворк управления разработкой продукта через инвестиции.

В классике проект проходит путь:
Discovery → Scoping → Business Case → Develop → Test & Validate → Launch
из нестандартных названий этапов:
Scoping - оценка рынка, пользователя и технической реализации
Business Case - формирование концепции продукта, его экономики и плана разработки.

Между этапами стоят гейты, где команда подтверждает готовность двигаться дальше. На встрече обсуждают три вещи:
1 - deliverables - обязательные артефакты этапа
2 - criteria - критерии оценки проекта
3 - outputs - решения по итогам

Решений обычно четыре:
Go означает продолжить и выделить ресурсы
Kill закрывает проект
Hold ставит его на паузу
Recycle возвращает команду на доработку текущего этапа.
Вместе с решением фиксируют ресурсы, ответственных и дату следующего Gate.

Историческая справка:
Stage-Gate появился в 1980-х в работах Роберта Купера по управлению разработкой новых продуктов. Он не вырос из Double Diamond, который появился позже. Double Diamond помогает организовать поиск проблемы и решения, Stage-Gate управляет инвестициями, доказательствами и допуском проекта к следующему этапу.

Самостоятельность Stage-Gate в том, что он управляет всем инвестиционным циклом продукта: задает этапы, правила допуска,
набор доказательств и моменты остановки проекта.

❤️ проходил Gate
😈 сначала запустили, потом собрали Business Case
#pm #product #словарикпродакта