Your product, especially if you manage people directly, is not the product. It’s the process that builds the product.

Designers output interfaces/interactions, engineers output code, product managers output process.

Чем выше вы в карьере продуктового менеджера и/или чем более сложными продуктами вы занимаетесь, тем более актуальным является ясное понимание этого. Нельзя быть одиноким ковбоем и единственным носителем сакрального знания о том, «что такое хорошо». Четкий процесс и правильные профессионалы на своих местах, плюс тесное взаимодействие и обсуждение - ключ к стабильно повторяемому результату.

Друг подбросил замечательный пост с наблюдениями о продакт-менеджменте за 10 лет, стоит прочтения:
https://medium.com/@danhilltech/observations-on-product-management-3abc7e00148e

Нужны ли вам спринты фиксированной длины?

Если кратко, то:

1. Да, спринты фиксированной длины очень сильно помогают, когда команда только начинает, она еще не сработана, и вы не знаете реальной velovcity этой команды на этом проекте. Эта задает ритмичность и столь необходимые искусственные ограничения.

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

3. Обратная сторона: это ведет к неизбежным подтасовкам: мы либо берем слишком маленькую цель (ведь задача спринта - сделать явный инкремент в продукте), либо придумываем цель под те таски, которые поместились в спринт после оценки команды.

4. Последний вариант, к сожалению, самый частый. У этого много причин:
* РО не успевает или не может придумать явную цель с понятным инкрементом
* продукт имеет большое количество пользователей (особенно это касается В2В энтерпрайз) и есть много мест, которые нужно пофиксить “на вчера”
* спринты сложены из багов или техдолга, а не исходят из цели.

5. Основная проблема со спринтами: мы опасаемся брать большие значимые цели, которые сделают многих счастливыми, потому что они ТОЧНО не помещаются в спринт. Что делать в таком случае:
* Для этого существуют эпики. Эпик может длиться более одного спринта (в отличие от истории).
* Эпики все равно нужно бить на части, и эти части должны быть более-менее независимыми друг от друга в части функционала (это сложная тема, которую в комментарии не раскрыть, но это возможно).
* Попробовать (это челлендж лично для меня, с учетом энтерпайз продукта, в который коммитят 20+ скрам-команд) добиться выпуска shippable инкремента КАЖДЫЙ СПРИНТ. Покрытого юнит и интеграционными тестами, с зелеными тест-планами, сданного по Definition of Done, принятых в вашей компании. По этому пункту я планирую написать больше в ближайшее время.

Красивый пост с картинками, который меня вдохновил (очень рекомендую): https://hackernoon.com/fixed-length-iterations-vs-continuous-flow-afd0d32ab50

P.S. Идея отказаться от спринтов ради более гармоничной работы вокруг целей разного объема (не подпиливать их под 14 дней) мне пока кажется нецелесообразным. Пока более разумной выглядит мысль брать задачи объемом меньше спринта, которые могут быть явно отданы в релиз, а оставшееся время просто начинать делать следующие задачи из топа бэклога. При этом успешность спринта оценивать только по основной цели, а не дополнительным задачам.

Если вы пропустили полезную ссылку в посте из последнего сообщения, - вот полезная мысль на тему “инкремент каждый спринт”:

ЦЕЛЬ СПРИНТА - это смысл в наборе задач, которые помещены в спринт. Цель оправдывает этот набор задач и делает его гармоничным. Благодаря цели, этот набор задач приведет к инкременту который заслуживает релиза как отдельный артефакт, при этом несет ясную ценность, выходящую за рамки просто написанного кода. Иными словами, именно цель спринта делает спринт и его результат большим, чем просто набор задач в спринте. … Без целей теряется смысл использования скрама.

Мысль кажется банальной только тем, кто не пробовал внедрять скрам и добиваться ритмичной прогнозируемой работы большого количества команд в течение продолжительного периода времени 😭🤦‍♂️

Оригинал:
https://dzone.com/articles/sprint-goals-in-practice

Ной Вайс, бывший вице-президент по продукту Foursqare и нынешний продакт хэд в Slack, делится своим простым подходом к роадмаппингу и приоритезации бэклога.

Исходя их его опыта, для очень быстро растущих компаний (исповедующих lean startup подход), классические подходы, включая OKR, слишком тяжеловесны: оверхэды на метрики отнимают много времени, квартальный цикл коррекции слишком крупный для их темпов.

Вместо этого они делят фичи на три блока: #now, #next, #later

Далее:
1. Все равно стоит согласовать несколько ключевых целей на уровне компании/продукта.
2. Собрать фичи/идеи из всех мест, где они у вас накапливаются 😉
3. Разложить на категории:
a. #now - 1 месяц (1-2 спринта)
b. #next - 3 месяца (сразу после #now)
c. #later - когда-то)
4. Далее у автора идет мысль о том, как удобно управлять проектами в Асане, с чем я согласиться не могу в контексте софтверной разработки :), но для синхронизации на уровне верхнеуровневой истории, с привязкой тикетов и идей, при достаточной дисциплинированности, и только между РО/ВА, чтоб не загружать разработчиков сырыми идеями - может быть.

https://medium.com/@noah_weiss/now-next-later-roadmaps-without-the-drudgery-1cfe65656645

Больше о целях компании на примере OKR: https://news.1rj.ru/str/productdev/19

It’s a fine line between acknowledging there are issues but without taking too much of the blame.

Это должно быть мантрой каждого продакт овнера, мне кажется)

Сказано об Адаме Моссери, VP of Product Facebook, который отвечает в том числе за Newsfeed - сердце и основу интерфейса Facebook.

Отличная история об отличном парне, на родном языке:
https://digiday.com/media/hes-not-pr-guy-adam-mosseri-facebooks-head-news-feed-become-unlikely-good-guy-publishers/

Недавно я писал о простом способе определения приоритетов в роадмапе/бэклоге продукта - раскладывание по трем категориям #now, #next, #later (https://news.1rj.ru/str/productdev/34).

Еще один перпендикулярный (в буквальном смысле) взгляд - это категоризация по трем типам фич:

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

2. Основанные на фидбеке пользователей. Customer voice - наше все. У вас может быть 100500 тикетов или комментариев на аппсторе. Обещания самым крупных энтерпрайз-клиентам. Хотелки. Вещи, которые реально упрощают жизнь, но без которых тоже можно существовать. Не все эти фичи нужно всегда воплощать, но профессиональный РО всегда старается получать ПРЯМУЮ обратную связь от пользователей (избегайте агрегированных субъективных идей сейлз-менеджеров, саппорта, партнеров или CSM). Читайте тикеты, организовывайте конференц-звонки, слушайте клиентов/пользователей.

3. Основанные на вашем видении. Здесь могут быть вещи, которые приятно удивят ваших пользователей, например улучшения UX или скорости работы. Обычно для появления этих фич требуется несколько ингредиентов: внимательно слушать пользователей для выявления их настоящих проблем (но не их варианты решения проблем, которые могут быть не универсальными!), понимание возможностей технологии, продуманный UXи упаковка фичи, ее встраивание в существующий опыт/продукт.

Безусловно, некоторые фичи попадают в несколько категорий, но редко во все три.

Основная идея состоит в том, что:

1. Вы с командой четко отдаете себе отчет, к какой категории относится то, над чем вы работаете - какова цель (ответ на вопрос WHY)

2. Вы стараетесь включать в мажорные релизы понемногу из каждой категории - МЕТРИКИ: улучшения для бизнеса/стейкхолдеров; ФИДБЕК: демонстрируете, что слышите пользователей; ВИДЕНИЕ: удивляете и показываете, что продует/компания является экспертом и может производить инновации.

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

Как расставляет квартальные приоритеты в разработке Pandora

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

Сегодня - о системе выбора приоритетов, которая работает даже для стартапов на ранней стадии, где вообще часто очень мало ориентиров и не на что опереться. Систему придумал и внедрил СТО Pandora (сервис стриминга музыки а-ля Spotify). Оригинал для любителей лонгридов: https://goo.gl/b9v9Ga

Вкратце, вот сама система:

1. В начале каждого квартала задайте себе вопрос: Что было бы крайне тупо в нашем положении не сделать в следующие 90 дней? (формулировка важна, она отсекает большую часть nice to have фич, хотя они все равно просочатся).
2. Вопрос себе могу задавать все сотрудники компании - все идеи приветствуются, у каждого может быть свой инсайт.
3. Опишите каждую идею в нескольких пунктах на одном слайде (не более слайда на идею). Каждый может описывать свои идеи.
4. Оцените приблизительно объем работы разработчиков для воплощения каждой из идей.
5. Пандора оценивает этот объем в долларах: $5 - это объем, который требует одного сферического разработчика в вакууме в течении месяца. Соответственно, три месяца одного человека = $15
6. Если у вас 10 разработчиков, у вас всего $150 долларов, которыми вы можете распоряжаться.
7. (Подсказка: вы можете оценивать в командо-спринтах, если ваш R&D крупный - например у нас сейчас 20+ серам-команд, и оценивать на уровне одного разработчика будет затратно. С другой стороны, если вы планируете на уровне команд, а не всей компании, размер в разработчиков-месяцах все еще подходит вам).
8. Итак, на каждом слайд с идеей у вас должна быть стоимость в долларах.
9. Выберите маленькую команду, которая будет заниматься планированием. Идеально, если это ключевые люди в компании (например, фаундеры, продакт-менеджеры, деливери, директора CSM и т.д.). Берите людей, которые точно заинтересованы в успехе компании/продукта, не просто классных сотрудников (они могут трудиться ради ЗП). Демократия здесь излишня.
10. К примеру, если у вас 5 людей в этом «комитете» ;), и объем доступных разработчиков $150 - выдайте каждому по 6 стикеров стоимостью $5 каждый.
11. Распечатайте слайды и повесьте их на стену. Кратко (минута максимум) презентуйте команде каждую из идей.
12. После этого каждый из «комитета» с помощью своих стикеров «покупает» те фичи, которые особенно ценны для бизнеса на их взгляд.
13. Как вы понимаете, это приводит к очень жесткой расстановке приоритетов.
14. После первого круга вы можете торговаться и договариваться между собой, перемещать стикеры, так чтоб в итоге у вас был полный список фич, которые вы можете и хотите купить в этом квартале.
15. Кроме пользы в приоритетах, этот метод обеспечивает buy-in, то есть каждый психологически включается в то, чтоб этих целей достичь.
16. Получив ограниченный, достижимый объем функциональнсти в разработку, можно переходить к детализации историй, критериев приемки, UX и прототипам и т.д., в обычном вашем режиме работы.

Через 90 дней повторить все с ноля, заново, не опираясь на идеи, ранее сгенерированные в предыдущем цикле.

Отличное обсуждение на ту же тему приоритетов на Quora:

https://www.quora.com/Product-Management/What-are-the-best-ways-to-prioritize-a-list-of-product-features

[прочесть за обедом] Что такое Product Owner и с чем его есть - в одной статье: https://productcoalition.com/product-owner-theses-2de0c60310f1

И о полезном.

Наша наивная идея (и эти грешат многие материалы и тренинги по разработке продукта) состоит в том, что бэклог - это набор user stories для новых фич.

Но жестокая действительность разбивает наши мечты, приходя в виде тикетов от саппорта, технического долга вследствие срезания углов («надо успеть к релизу»), и ультиматумов (обоснованных!) от команды о необходимости выделять время для проработки архитектуры («ребята, ну сколько можно говорить и рисовать, давайте писать код!»).

Один из подходов, о которых я еще не писал - это матрица для форматирования бэклога на основе двух осей:
Прошлое - Будущее
Бизнес - Разработка

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

В зависимости от специфики и зрелости вашего продукта, это соотношение будет разным. Очевидно, максимум внимания хочется уделять новым фичам. Я бы сказал, в моем случае (В2В энтерпрайз софт, с которым работают крупные глобальных корпорации, и есть определенные платформенные зависимости, 20+ скрам-команд, которые координируют свои усилия) это выглядит так:

Новый функционал - 60%
Техдолг - 10%
Проработка архитектуры - 10%
Саппорт - 20%
(один из разработчиков в каждой команде резервируется под сложные кейсы и срочную помощь энтерпрайз-кастомерам, изменения вносятся сразу также в коробку и выходят в следующем релизе для всех)

В итоге, приходится признать, что если ваш продукт довольно зрел, то на собственно развитие вы будете тратить не более 60-70% - и это еще очень хорошие цифры 😉

P.S> Это ок, если ситуативно цифры прыгают: например, одна из моих команд сейчас будет перевозить целый пул сервисов на новый фреймворк, и в краткой перспективе это выглядит как пробуксовка с точки зрения клиентов, но в итоге это ускорит работу критически важных компонентов архитектуры, добавит отказоустойчивости - в итоге снизит количество саппорт-тикетов и освободит время команды на разработку новой функциональности.

Картинка для визуализации. На эти квадранты хорошо наложить ваши таски (стикеры?) и проанализировать вашу текущую реальность. Потом поставить цели (напр., снизить время на техдолг с 20% до 10%).

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

История состоит в том, что один из ивестных фондов собрал фаундеров своих портфельных стартапов и менторов, и попытался их быстро проапгредить.
Темы, которые попытались покрыть:
1. Как думать, словно ты продакт-менеджер :)
2. Как понять, что строить именно сейчас
3. Как строить стратегию, базируясь на видении продукта
4. Как общаться со стейкхолдерами (не только акционерами/топами, но и командой)
5. Как разработать продуктовые истории, которые реально цепляют людей
6. Как создать исключительную продуктовую команду
7. Как вырасти из РМ в продакт-лидера
8. Как принимать решения, основываясь на данных
9. Как вырасти из РМ в фаундера и реального владельца продукта.

Ответы по версии 1st Round:

http://firstround.com/review/17-product-managers-who-will-own-the-future-of-nyc-tech-and-the-9-frameworks-theyll-use-to-do-it/

Критически важные качества для Product Owner:

1. Адвокат пользователей/клиентов. Как я могу облегчить жизнь своим юзерам? Что их бесит? Чего им не хватает? Если вас не волнуют проблемы ваших пользователей и вам не хочется построить для них лучшее решение - это будет очень трудная и скучная работа, и легко выгореть.
2. Способность найти корень проблемы. Например, можно попросить человека решить почти невозможную задачу: «Помыть все автомобили в Лондоне за день/неделю», и посмотреть на его ход мыслей. Хороший Product Owner сразу спросит «Зачем?». Возможно, проблема в другой и ее можно решить другим, более дешевым способом. По этой же причине, когда вы видите человека, сразу же бегущего выполнять любые указание клиентов/стейкхолдеров - перед вами максимум Project Manager, но никак не Product Owner.
3. Не плоское мышление. Способность подумать, а не идти самым тупым путем. Возможно, есть готовые решения, и не нужно изобретать велосипеды. Возможно, прикручивать конвенциональное решение/библиотеку будет дороже в долгосрочной перспективе, чем подумать и внести минимальные изменения, которые дадут свое решение без лишних зависимостей и оверхэдов. Универсальных ответов здесь нет, и людей, действующих «по накатанной» без использования мозга, сразу видно.
4. Страсть к своему делу. Когда человек рассказывает о своей последней любимой фичуле, его глаза загораются, он начинает быстрее дышать и говорить 😉 Он думает о следующем эпике в душе утром. Он спросит у каждого разработчика, как его дела по задачам текущего спринта (ну и конечно он знает, кто чем занимается и способен понять ответ коллеги, но это другая история). Работа такого Product Owner выглядит как хобби, которым он занимается в течение недели, и еще получает деньги бонусом.
5. Он рекрутер. Этот человек находит ресурсы. Не только людей, коллег и соседние команды/департаменты включаются в его задачи и проблемы, но и - немаловажно - он способен найти ресурсы в своих людях, больше ресурсов чем те сами знали о себе. Человек способен рассказывать о будущем продукта так, что тебе хочется нажать на быструю перемотку и побыстрее оказаться в этом сладком будущем. Это очень полезное качество не только, чтоб собирать деньги на Кикстартере 😉 , но и для работы с командой и пользователями/клиентами.

Бонус. WHAT, WHY, not HOW. Одно из очень спорных, но чаще всего вредных качеств для Product Owners: непреодолимое желание переступить за рамки «ЧТО делать» и начать описывать и рассказывать «КАК делать». Даже для технических Product Owners, и я все время слышу от умных людей это ошибочное убеждение, что утро РО должно начинаться с перечитывания Software Requirements и BABOK. Это, конечно, не лишне, но в скроем вы стремитесь работать со зрелыми специалистами, формирующими самоорганизующуюся команду, которой не нужно подсказывать по каждой мелочи. Плюс вы наступаете на горло собственной песне - только джуны хотят, чтоб им все разжевали, но вам будет очень сложно удерживать синьоров, лидов и архитекторов, если вы будете им рассказывать все до мелочей. И главное, что вы должны осознавать - вы этих мелочей на самом деле не знаете, иначе это у вас было бы 15 лет опыта программирования сложных систем. Каждый должен заниматься своим делом, и лучше направить эту энергию на то, чтоб убедиться, а то ли вы строите, что нужно строить именно сейчас, и будут ли этим пользоваться.

На самом деле все еще жестче: РО единолично стоит отвечать только на вопрос WHY - вопрос, связанный с корневой проблемой юзера (job to be done) или бизнес-задачей (напр, увеличить retention), и даже WHAT решать с командой. У всех нужно развивать чувство product ownership, в конце концов.

Аминь )

Утром попался пост парня о том, как всю свою профессиональную жизнь продакт-менеджера старался дистанцироваться от команды разработки 😂 (WHY?!).

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

Но: это все нивелирует идею и перспективу иметь команду, которой не пофиг, которая проактивна и не заметает мусор под ковёр («все равно наш РМ не даст нам это исправить, у них сроки, давайте даже не будем его драконить»). И главное - все это приводит к тому, что вы не продакт, а проджект менеджер. А это совсем другая кухня.

В общем, если дать три совета:

1. Не бойтесь своей команды. Дружите, работайте вместе и находите компромиссы.

2. Не бойтесь вникать в технические детали. Я против того, чтоб РО/РМ диктовал реализацию, но проводить с командой груминг (рефайнмент) вы обязаны, не говоря уже о понимании того, как устроен продукт.

3. Ищите совместных решений и находите здоровый баланс между: новыми фичами, багфиксом/саппортом, техдолгом. Как я уже неоднократно писал, это ок если у вас на новую функциональность уходит 60-70% ресурсов, все прочее - самообман.

4. Бонус :) Обратная сторона тенденции тесно работать с командой все же существует - РО/РМ, которые не сильный бизнес/гуманитарной стороне вопроса, таким образом сбегают от юзеров, бизнеса, требований, необходимости все это балансировать и принимать тяжелые, но необходимые решения по бэклогу/роадмапу. Это тоже не ок :)

На конференциях обсуждают проблему, озвученную выше, и вы можете послушать, о чем идёт речь, если чувствуете, что сталкиваетесь с этим: https://youtu.be/Y-glrQUalXs

Вы конечно же читаете канал Кости Горского из Интеркома, но если вдруг пропустили - вот как раз последний пост на тему важности тесной работы с командой: https://news.1rj.ru/str/desprod/277

Коллега поделился неплохим обзором общих антипаттернов по тестированию. Если вы РО/РМ, который давно работает (особенно в энтерпрайз) разработке, ничего особо нового вы не увидите. С другой стороны, иногда полезно уложить все в общую картину и вспомнить основы.

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

https://habr.com/post/358178/ - RU версия
http://blog.codepipes.com/testing/software-testing-antipatterns.html - EN оригинал

Вчера я был на замечательном воркшопе от MindTheProduct в Амстердаме.
MTP организовывают самые интересные конференции и тренинги по продакт менеджменту, две самые крупные - летом в Сан-Франциско и осенью в Лондоне; очень советую.

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

Продолжение следует :)
https://www.eventbrite.com/e/product-management-essentials-102-training-workshop-amsterdam-tickets-43599757047

Customer requirements are not Product Requirements.

Да, нужно слушать customer voice. Но это лишь один из источников наравне с сейлз, маркетингом, customer success, стейкхолдерами. В сумме все это может корректировать очередность выпуска фич в вашем роадмапе, но:

1. Помните о стратегии и видении; очень, очень легко потеряться в штамповке фич, которые «все юзеры хотят и ждут».
2. Продолжение п.1: не превращайте ваш продукт в франкейнштейна из меню и настроек («мы просто сделаем это опциональным»).
3. Помните, что решение о приоритетах бэклога принимает Product Owner/Manager, а не клиент. И даже не директор департамента или член совета директоров, которому кто-то позвонил.

И самое главное - все specials и кастомная разработка приводят вас в проектному мышлению и уводят от продуктового, демотивирует команду и уводят вас от стратегии по запуску и проверке фич, которые вы как продакт запланировали для достижения ваших целей.

Материалы с воркшопа Mind The Product. Если у вас нет времени или лишних денег посещать такого рода воркшопы (хотя стоит найти и то, и другое!), делюсь кратким гайдом с подборкой классных отобранных материалов по продакт менеджменту. Вы можете (и должны!) быть продакт менеджерами мирового уровня, а для этого нужно учиться )
Здесь нет контента самого воркшопа, выжимки по нему я напишу позже, как и обещал.

Материалы с воркшопа Mind The Product.

Не так давно я писал о том, что вопрос WHY - главное орудие РО.
https://news.1rj.ru/str/productdev/43
Вчера мы проводили второй день тренинга по agile для всей команды и отдельное внимание уделили масштабированию на примере SAFe. Что интересно, это как эти три вопроса ложатся на уровни процесса:
1. WHY: уровень бизнеса/портфолио. Зачем мы финансируем вот эту программу в нашем портфеле, какие бизнес-задачи мы хотим решить.
2. WHAT: уровень программ/бизнес-эпиков. Что мы планируем строить, какие верхнеуровневые наборы фич можем здесь сформулировать.
3. HOW: уровень фич/скрам-команд. Как именно мы реализуем вот эту юзер-стори, какие технологии выберем, как это встроится в существующий продукт.

Естественно, здесь масса нюансов - и роль продакт-менеджера, и вовлечение архитектора, и идентификация зависимостей, внедрение Program Increment Planning и т.д., но в целом Фреймворк ещё раз подчеркивает важность умения «отпускать» - децентрализовать и давать командам свободу находить лучший способ реализации.