First Principles in Scrum: OpenClaw Scrum and Scrum@Scale: Create Trust at Machine Speed by Jeff Sutherland is the featured book 📖 on Leanpub!
Link: https://leanpub.com/firstprinciplesinscrumscrumandscrumscaleforopenclaw
#computer_programming #business_and_management #scrum #leadership_agile #agile_enterprise #enterprise_management #scrum_project_management #product_management #teamwork
Три принципа международных компаний, которые помогают мне в работе CPO
Всем привет! Меня зовут Денис Улизко, я CPO CRM-системы Automation of Sales в МТС. Начинал с простого sales: сначала работал в банках, потом в телекоме, а затем углубился в ИТ-направление. За 10 лет продуктового опыта успел поработать в России и за границей — как с небольшими стартапами, так и с достаточно крупными игроками в своей нише. В этом посте расскажу, какие три механики я забрал с международного рынка и теперь использую в работе почти ежедневно: от процесса интервью и принятия решений до рабочей коммуникации. Читать дальше
Как не надо выступать на демо и зачем вообще выступать
Может показаться, что достаточно хорошо работать, и вас оценят. Это не так. Команды, которые «просто кодят», но не могут объяснить внутреннему заказчику, что они сделали, часто расформировывают после проекта. Да, очень хорошую или очень плохую работу тяжело спрятать. Но если задача была не самая бизнес-важная, за сроки вышли, но работа сделана всё равно хорошая, — вот в этом месте очень легко облажаться. Любое техническое выступление — это не пробубнить заголовки задач в Джире. Это про политику. Первая цель всегда — доказать, что команда действовала адекватно. Команды, которые показывают управляемость и результат, получают новые проекты и финансирование. Раньше, когда я был молодым Product Owner’ом, я думал: «Ну зайди ты в трекер, там же всё видно!» Оказалось, что для бизнеса это чёрный ящик. А умные люди очень не любят чёрные ящики, очень не любят красивые отчёты с суммаризациями и очень не любят ощущение, что им пытаются продать что-то без понимания смысла. Если вы не рассказали о результате правильно, то для многих результата часто просто не существует. Давайте разберём задачу выступления и оптимальную стратегию.
https://habr.com/ru/companies/centicore_group/articles/1034228/
#демо #презентация_продукта #product_management #софтскиллы #коммуникации_в_IT #стейкхолдеры #отчётность #бизнесметрики #публичные_выступления
First Principles in Scrum: OpenClaw Scrum and Scrum@Scale by Jeff Sutherland is a new release on Leanpub!
Link: https://leanpub.com/firstprinciplesinscrumscrumandscrumscaleforopenclaw
#books #ebooks #newreleases #leanpublishing #selfpublishing #computer_programming #business_and_management #scrum #leadership_agile #agile_enterprise #enterprise_management #scrum_project_management #product_management #teamwork
Как войти в новый домен и не утонуть в фактах
Первое погружение в незнакомый домен выглядит примерно так: темно, непонятно, и все вокруг явно что-то знают, чего не знаешь ты. «Изучи конкурентов» и «eat your dog's food» — это само собой. Но что делать дальше, когда база пройдена, а понимание домена всё равно не складывается в рабочую картину? Гайд для продактов, дизайнеров и исследователей, которые хотят за первые недели разобраться достаточно — чтобы принимать решения, а не кивать на встречах.
https://habr.com/ru/articles/1032554/
#product_management #UX #onboarding #системное_мышление #карьера
15 команд, 1 продукт, 14 проектов в Jira. Что не так?
Пока команда одна — всё логично: бэклог, доска, понятный поток. Но когда команд становится пятнадцать и все работают над одним продуктом — Jira начинает вести себя странно. Product Owner открывает утро с обхода четырёх проектов, задачи дублируются, а зависимости живут в комментариях. Разбираемся, почему это не про «плохую Jira», а про конфликт моделей.
https://habr.com/ru/companies/simpleone/articles/1031342/
#Jira #масштабирование #scrum #safe #less #продуктовая_разработка #бэклог #управление_зависимостями #многокомандная_разработка #product_management
Шум или ущерб: как заранее отличить громкий негатив от материального кризиса
Теги: product management , risk management , marketplace , telecom , customer experience , pre-mortem Коротко о главном У меня возникла идея для сервиса Интуицын — предзапусковую репетицию риска. Он превращает спорное коммерческое решение (изменение тарифа, новые правила для партнёров, комиссия за способ оплаты, ребрендинг) в карту риска: кто отреагирует, насколько это материально, через какие каналы пойдёт распространение недовольства и что можно изменить до публичного контакта с рынком. В этой части (1 из 2) — продуктовый и аналитический разбор без технических деталей. Я покажу, как сервис отработал на 3 реальных кейсах из недавней истории российского рынка: тарифы у мобильных операторов, штрафы для партнёров маркетплейса и одновременный ребрендинг с запуском премиального направления. Два из трёх кейсов в реальности закончились публичным конфликтом, действиями ФАС, забастовкой партнёров или их сочетанием. Третий — на бумаге выглядел как идеальный кандидат на скандал и был так помечен сравнительным baseline-прогнозом обычной языковой модели — но в реальности прошёл без материального ущерба. Сервис правильно отранжировал материальные кейсы в верхней части риска, а спорный «двойной» — в нижней, и всё это до того, как ему сообщили исход. Сервис проверяли на двух последовательных ретроспективных слепых прогонах: первый — 6 кейсов, расширенный — 20, всего 26 кейсов российского рынка. Cуммарно когортный слой правильно классифицировал 26 из 26 исходов; обычный сравнительный baseline-прогноз большой языковой моделью — 22 из 26, в остальных 4 случаях принял громкий, но переносимый негатив за материальный провал. На последнем 20-кейсовом расширении ранжирование разделило набор без ошибок: верхние 10 — все материальные кейсы, нижние 10 — все без материального ущерба. Это пилотный сигнал, а не финальное доказательство.
https://habr.com/ru/articles/1031144/
#product_management #risk_management #marketplace #telecom #customer_experience #premortem
Сначала бизнес, потом юзеры: продуктовый подход к внутренним инструментам на примере PWA-конструктора
Привет! Я Софа, ведущий b2e дизайнер в Perfomance Lab, и я считаю, что внутренние продукты недооценены, а процесс их создания в корне отличается от b2c/b2b. Сегодня речь пойдёт про последнее упомянутое решение — PWA-конструктор, который помогает нашим медиабаерам проверять свои гипотезы быстрее и создавать более 20 приложений каждый день. Я расскажу, зачем мы начали его делать и с какими сложностями столкнулись.
https://habr.com/ru/articles/1030434/
#B2E #product_design #продукт #менеджмент #ux #uxкоманда #development #research #soft_skills #product_management
Aha! Builder 정식 출시: AI 기반의 제품 관리자용 비즈니스 앱 구축 도구
Aha! Builder는 제품 관리자가 AI 어시스턴트 Elle를 활용하여 코딩 지식 없이도 인터랙티브 프로토타입과 엔터프라이즈급 비즈니스 애플리케이션을 직접 구축할 수 있도록 지원한다.
Мета-работа, память агентов и Product Graph: почему AI не спасёт продукт без структуры знаний
За годы работы в разнообразных командах я много раз видел одну и ту же ситуацию. Компания растёт, продукт усложняется, и в какой-то момент возникает естественное желание разбить всё на отдельные продуктовые команды. Каждая отвечает за свой кусок функционала, свою часть пользовательского пути, свою метрику, свой backlog. На бумаге это выглядит правильно: меньше зависимостей, больше автономии, быстрее принятие решений. Но у такого подхода есть побочный эффект, о котором обычно говорят слишком поздно. Знание о продукте начинает фрагментироваться. Одна команда знает, почему была изменена логика онбординга. Другая помнит, какие ограничения есть у биллинга. Третья когда-то проводила исследование, из которого следовало, что пользователи вообще не понимают текущую модель прав доступа. Где-то это лежит в презентации. Где-то в Notion. Где-то в Confluence. Где-то в почте. Чаще всего — в голове конкретного человека. Пока этот человек рядом, система вроде бы работает. Можно написать ему в Slack, позвать на встречу, спросить: «А почему мы тогда сделали именно так?» Он вспомнит, расскажет, иногда даже найдёт старую ссылку. Но стоит человеку уйти, сменить роль или просто перестать быть доступным, как часть продуктовой памяти исчезает вместе с ним. И это не исключение. Это нормальное состояние большинства организаций. Однажды в большой корпорации у нас сменился Product Owner. На первой встрече с новым PO я спросил, что ему передал предыдущий. Ответ был примерно такой: «Мы встретились, он рассказал мне, что к чему».
https://habr.com/ru/articles/1029336/
#управление_знаниями #product_management #product_owner #ииагенты #ии
Leanpub
Habr
bot
