Интересный список инструментов для продакт-менеджера, собранный по нескольким категориям:
* Product Roadmapping
* Project Management
* Product Research
* Wireframing/Specs
* Analytics
* User Experience
* Landing Pages
* Email Marketing
* Design & User Interface
* Stock Photos & Videos
Список небольшой, но лично я не люблю мега-каталоги из 100+ инструментов, там легко потеряться и пропустить что-то действительно интересное - например, https://thenounproject.com (всевозможные иконки на любой случай жизни), или http://emptystat.es (Empty States, идеи для пустых экранов в ваших приложениях ! 😉 )
https://www.aha.io/roadmapping/guide/product-management/which-tools-do-product-managers-use
* Product Roadmapping
* Project Management
* Product Research
* Wireframing/Specs
* Analytics
* User Experience
* Landing Pages
* Email Marketing
* Design & User Interface
* Stock Photos & Videos
Список небольшой, но лично я не люблю мега-каталоги из 100+ инструментов, там легко потеряться и пропустить что-то действительно интересное - например, https://thenounproject.com (всевозможные иконки на любой случай жизни), или http://emptystat.es (Empty States, идеи для пустых экранов в ваших приложениях ! 😉 )
https://www.aha.io/roadmapping/guide/product-management/which-tools-do-product-managers-use
Говорят (спасибо, Женя!), ссылка из последнего поста об инструментах не всем видна, вот она ещё раз:
https://www.aha.io/roadmapping/guide/product-management/which-tools-do-product-managers-use
Весь сайт заслуживает внимания на самом деле, кто-то постарался структурировать немного полезной информации.
https://www.aha.io/roadmapping/guide/product-management/which-tools-do-product-managers-use
Весь сайт заслуживает внимания на самом деле, кто-то постарался структурировать немного полезной информации.
www.aha.io
Which Tools Do Product Managers Use? (Top Picks for 2024)
Product managers use specialized tools for strategy, analytics, feedback, design, and collaboration. Explore top picks for all product development stages.
Роадмаппинг здорового человека
"Roadmaps should be lists of questions, not lists of features"
Парадоксальную вещь напишу. Если вы время от времени думаете: “а запишу-ка я себе заново вот самые срочные доработки/улучшения в продукте, которые вот нужно сделать совсем в следующем спринте”, и у вас получится список на 6 месяцев - значит, все хорошо. Ну в самом деле. Это значит, что вы думаете о вечном (зачеркнуто) о важном, и знаете чего от вас ждут пользователи/бизнес. И главное, у вас есть простор для полезных упражнений по приоритезации. Ограничения ресурсов есть везде - будь вы стартап, энтерпрайз с миллионами долларов дохода, или Google.
Буквально в середине этой недели у меня наконец-то закончился очередной забег “быстро-быстро фиксим все, что мешает нашим самым крупным клиентами и за что нам стыдно”, возник легкий вакуум, и в четверг-пятницу нам удалось немного позаниматься важными делами - благо канун нового года стимулирует к итогам и планированию.
Одна из самых полезных вещей, которые быстро можно сделать (кроме сортировки по принципу business value vs. оценка времени на разработку, конечно) - это:
1. Взять свой роадмап на период (квартал, полгода, год, просто набор самых важных фич которые вам “очень нужно” произвести)
2. Убрать из него таймлайн и любые привязки ко времени (комитменты, запросы от клиентов, обещания стейкхолдерам..)
3. По каждому эпику/истории/фиче задать себе один из двух вопросов (на выбор, с чем вам в данный момент комфортнее работать):
* Зачем мы это делаем? Как это облегчит жизнь нашему пользователю (клиенту, сейлзам, CSM, - но первично все же юзеру)?
* Если мы реализуем эту фичу в самом офигезно идеальном виде, как мы об этом узнаем? (подсказка: метрики).
Поскольку с “зачем” нам все же проще (специфика, в которую здесь вдаваться не буду), мы по каждому эпику написали список метрик, по которым мы явно можем отследить влияние (impact) нашей работы на жизнь живых пользователей. Например, уменьшится количество инцидентов/обращений по этому блоку функционала, увеличится количество создаваемых сущностей в этом разделе, снизится время на онбординг новых пользователей, снизятся затраты на поддержку вот этой фичи, увеличится доход с вот этого типа лицензий и т.д. У вас это могут быть метрики, характерные вашему продукту и бизнесу.
Самое главное - они легко рождаются в процессе таких размышлений. Сам процесс выглядит незатейливо: если у вас есть продуктовая команда, возьмите список фич и каждый отдельно выпишите по ним на стикеры свои метрики/признаки. Потом сравните ваши идеи, объедините их в кластеры, обсудите. Итоги впишите в документ (Confluence, GoogleDoc..).
Что интересно - на первый взгляд это мало связано с приоритетами, но на самом деле нет. Как только вы думаете о метриках, вы автоматически начинаете думать о пользовательском поведении и его изменении в результате вашей работы. Это очень тонкий момент, и очень продуктивный способ начать думать именно в таком ключе (не говоря уже о том, что вы получаете субпродукт в виде метрик, по которым можете впоследствии отслеживать эффективность/целесообразность внедрения функционала и улучшений (все же вы могли ошибаться, и это тоже бывает: build-measure-learn цикл никто не отменял).
Как только вы начинаете думать о поведении пользователей, вы можете увидеть новые способы удовлетворить их потребности, или же несколько фич, направленные на решение одной и той же проблемы. В последнем случае вы можете от чего-то отказаться, или напротив - объединить несколько эпиков в один и сэкономить на оверхэдах в виде кик-офф презентаций, сдаче эпиков по Definition of Done, нагрзочному тестированию и т.п. Последний вариант звучит не очень lean, но вы можете быть уже далеко позади стадии поиска product-market fit, и искать способы оптимизации.
Пост, который меня вдохновил вспомнить об этом полезном занятии как раз перед каникулами: https://medium.com/@jboogie/roadmaps-are-linear-software-projects-arent-e50fb142036f
Желаю вам продуктивного подведения итогов и разумного взвешенного планирования - с вашими пользователями в уме 😉
"Roadmaps should be lists of questions, not lists of features"
Парадоксальную вещь напишу. Если вы время от времени думаете: “а запишу-ка я себе заново вот самые срочные доработки/улучшения в продукте, которые вот нужно сделать совсем в следующем спринте”, и у вас получится список на 6 месяцев - значит, все хорошо. Ну в самом деле. Это значит, что вы думаете о вечном (зачеркнуто) о важном, и знаете чего от вас ждут пользователи/бизнес. И главное, у вас есть простор для полезных упражнений по приоритезации. Ограничения ресурсов есть везде - будь вы стартап, энтерпрайз с миллионами долларов дохода, или Google.
Буквально в середине этой недели у меня наконец-то закончился очередной забег “быстро-быстро фиксим все, что мешает нашим самым крупным клиентами и за что нам стыдно”, возник легкий вакуум, и в четверг-пятницу нам удалось немного позаниматься важными делами - благо канун нового года стимулирует к итогам и планированию.
Одна из самых полезных вещей, которые быстро можно сделать (кроме сортировки по принципу business value vs. оценка времени на разработку, конечно) - это:
1. Взять свой роадмап на период (квартал, полгода, год, просто набор самых важных фич которые вам “очень нужно” произвести)
2. Убрать из него таймлайн и любые привязки ко времени (комитменты, запросы от клиентов, обещания стейкхолдерам..)
3. По каждому эпику/истории/фиче задать себе один из двух вопросов (на выбор, с чем вам в данный момент комфортнее работать):
* Зачем мы это делаем? Как это облегчит жизнь нашему пользователю (клиенту, сейлзам, CSM, - но первично все же юзеру)?
* Если мы реализуем эту фичу в самом офигезно идеальном виде, как мы об этом узнаем? (подсказка: метрики).
Поскольку с “зачем” нам все же проще (специфика, в которую здесь вдаваться не буду), мы по каждому эпику написали список метрик, по которым мы явно можем отследить влияние (impact) нашей работы на жизнь живых пользователей. Например, уменьшится количество инцидентов/обращений по этому блоку функционала, увеличится количество создаваемых сущностей в этом разделе, снизится время на онбординг новых пользователей, снизятся затраты на поддержку вот этой фичи, увеличится доход с вот этого типа лицензий и т.д. У вас это могут быть метрики, характерные вашему продукту и бизнесу.
Самое главное - они легко рождаются в процессе таких размышлений. Сам процесс выглядит незатейливо: если у вас есть продуктовая команда, возьмите список фич и каждый отдельно выпишите по ним на стикеры свои метрики/признаки. Потом сравните ваши идеи, объедините их в кластеры, обсудите. Итоги впишите в документ (Confluence, GoogleDoc..).
Что интересно - на первый взгляд это мало связано с приоритетами, но на самом деле нет. Как только вы думаете о метриках, вы автоматически начинаете думать о пользовательском поведении и его изменении в результате вашей работы. Это очень тонкий момент, и очень продуктивный способ начать думать именно в таком ключе (не говоря уже о том, что вы получаете субпродукт в виде метрик, по которым можете впоследствии отслеживать эффективность/целесообразность внедрения функционала и улучшений (все же вы могли ошибаться, и это тоже бывает: build-measure-learn цикл никто не отменял).
Как только вы начинаете думать о поведении пользователей, вы можете увидеть новые способы удовлетворить их потребности, или же несколько фич, направленные на решение одной и той же проблемы. В последнем случае вы можете от чего-то отказаться, или напротив - объединить несколько эпиков в один и сэкономить на оверхэдах в виде кик-офф презентаций, сдаче эпиков по Definition of Done, нагрзочному тестированию и т.п. Последний вариант звучит не очень lean, но вы можете быть уже далеко позади стадии поиска product-market fit, и искать способы оптимизации.
Пост, который меня вдохновил вспомнить об этом полезном занятии как раз перед каникулами: https://medium.com/@jboogie/roadmaps-are-linear-software-projects-arent-e50fb142036f
Желаю вам продуктивного подведения итогов и разумного взвешенного планирования - с вашими пользователями в уме 😉
Medium
Roadmaps are linear. Software projects aren’t.
This post was originally published to my newsletter subscribers (12k of them now). If you’d like to get these in your inbox sign up here.
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
Designers output interfaces/interactions, engineers output code, product managers output process.
Чем выше вы в карьере продуктового менеджера и/или чем более сложными продуктами вы занимаетесь, тем более актуальным является ясное понимание этого. Нельзя быть одиноким ковбоем и единственным носителем сакрального знания о том, «что такое хорошо». Четкий процесс и правильные профессионалы на своих местах, плюс тесное взаимодействие и обсуждение - ключ к стабильно повторяемому результату.
Друг подбросил замечательный пост с наблюдениями о продакт-менеджменте за 10 лет, стоит прочтения:
https://medium.com/@danhilltech/observations-on-product-management-3abc7e00148e
Medium
Observations on Product Management
I’ve spent 10 years now building products — from consulting, to startups, to larger teams like Airbnb. I wanted to capture some of the…
Нужны ли вам спринты фиксированной длины?
Если кратко, то:
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 дней) мне пока кажется нецелесообразным. Пока более разумной выглядит мысль брать задачи объемом меньше спринта, которые могут быть явно отданы в релиз, а оставшееся время просто начинать делать следующие задачи из топа бэклога. При этом успешность спринта оценивать только по основной цели, а не дополнительным задачам.
Если кратко, то:
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 дней) мне пока кажется нецелесообразным. Пока более разумной выглядит мысль брать задачи объемом меньше спринта, которые могут быть явно отданы в релиз, а оставшееся время просто начинать делать следующие задачи из топа бэклога. При этом успешность спринта оценивать только по основной цели, а не дополнительным задачам.
Hacker Noon
Fixed Length Iterations vs. Continuous Flow
Your team is mulling over two approaches to goal setting:
Если вы пропустили полезную ссылку в посте из последнего сообщения, - вот полезная мысль на тему “инкремент каждый спринт”:
ЦЕЛЬ СПРИНТА - это смысл в наборе задач, которые помещены в спринт. Цель оправдывает этот набор задач и делает его гармоничным. Благодаря цели, этот набор задач приведет к инкременту который заслуживает релиза как отдельный артефакт, при этом несет ясную ценность, выходящую за рамки просто написанного кода. Иными словами, именно цель спринта делает спринт и его результат большим, чем просто набор задач в спринте. … Без целей теряется смысл использования скрама.
Мысль кажется банальной только тем, кто не пробовал внедрять скрам и добиваться ритмичной прогнозируемой работы большого количества команд в течение продолжительного периода времени 😭🤦♂️
Оригинал:
https://dzone.com/articles/sprint-goals-in-practice
ЦЕЛЬ СПРИНТА - это смысл в наборе задач, которые помещены в спринт. Цель оправдывает этот набор задач и делает его гармоничным. Благодаря цели, этот набор задач приведет к инкременту который заслуживает релиза как отдельный артефакт, при этом несет ясную ценность, выходящую за рамки просто написанного кода. Иными словами, именно цель спринта делает спринт и его результат большим, чем просто набор задач в спринте. … Без целей теряется смысл использования скрама.
Мысль кажется банальной только тем, кто не пробовал внедрять скрам и добиваться ритмичной прогнозируемой работы большого количества команд в течение продолжительного периода времени 😭🤦♂️
Оригинал:
https://dzone.com/articles/sprint-goals-in-practice
DZone
Sprint Goals in Practice
"Onward! onward! must we travel? When will come the goal? Riddle I may not unravel, Cease to vex my soul."
Ной Вайс, бывший вице-президент по продукту 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
Исходя их его опыта, для очень быстро растущих компаний (исповедующих 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
Medium
#now, #next, #later: Roadmaps without the Drudgery
A deceptively simple process for prioritizing projects that won’t cause a revolt.
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/
Это должно быть мантрой каждого продакт овнера, мне кажется)
Сказано об Адаме Моссери, 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/
Digiday
‘He’s not a PR guy’: Adam Mosseri, Facebook’s head of news feed, has become an unlikely good guy to publishers
Publishers that find themselves at the end of their rope with Facebook have found one person they don't hate: Adam Mosseri, its head of news feed.
Недавно я писал о простом способе определения приоритетов в роадмапе/бэклоге продукта - раскладывание по трем категориям #now, #next, #later (https://news.1rj.ru/str/productdev/34).
Еще один перпендикулярный (в буквальном смысле) взгляд - это категоризация по трем типам фич:
1. Влияющие на метрики. В здоровых организациях есть большие цели, и можно соотносить метрики с ними). Это то, что драйвит использование продукта, достижение финансовых целей, снижение оттока и т.д. На самом деле очень небольшое количество фич действительно серьезно влияют на метрики. Эти фичи нужно знать, понимать, сколько они требуют инвестиций и быть готовыми воплощать их, несмотря ни на что.
2. Основанные на фидбеке пользователей. Customer voice - наше все. У вас может быть 100500 тикетов или комментариев на аппсторе. Обещания самым крупных энтерпрайз-клиентам. Хотелки. Вещи, которые реально упрощают жизнь, но без которых тоже можно существовать. Не все эти фичи нужно всегда воплощать, но профессиональный РО всегда старается получать ПРЯМУЮ обратную связь от пользователей (избегайте агрегированных субъективных идей сейлз-менеджеров, саппорта, партнеров или CSM). Читайте тикеты, организовывайте конференц-звонки, слушайте клиентов/пользователей.
3. Основанные на вашем видении. Здесь могут быть вещи, которые приятно удивят ваших пользователей, например улучшения UX или скорости работы. Обычно для появления этих фич требуется несколько ингредиентов: внимательно слушать пользователей для выявления их настоящих проблем (но не их варианты решения проблем, которые могут быть не универсальными!), понимание возможностей технологии, продуманный UXи упаковка фичи, ее встраивание в существующий опыт/продукт.
Безусловно, некоторые фичи попадают в несколько категорий, но редко во все три.
Основная идея состоит в том, что:
1. Вы с командой четко отдаете себе отчет, к какой категории относится то, над чем вы работаете - какова цель (ответ на вопрос WHY)
2. Вы стараетесь включать в мажорные релизы понемногу из каждой категории - МЕТРИКИ: улучшения для бизнеса/стейкхолдеров; ФИДБЕК: демонстрируете, что слышите пользователей; ВИДЕНИЕ: удивляете и показываете, что продует/компания является экспертом и может производить инновации.
И наоборот, если ваш анализ покажет, что одна из категорий отсутствует в вашем роадмапе и планах на релизы - очевидно, у вас есть проблема, и ее нужно исправлять.
Еще один перпендикулярный (в буквальном смысле) взгляд - это категоризация по трем типам фич:
1. Влияющие на метрики. В здоровых организациях есть большие цели, и можно соотносить метрики с ними). Это то, что драйвит использование продукта, достижение финансовых целей, снижение оттока и т.д. На самом деле очень небольшое количество фич действительно серьезно влияют на метрики. Эти фичи нужно знать, понимать, сколько они требуют инвестиций и быть готовыми воплощать их, несмотря ни на что.
2. Основанные на фидбеке пользователей. Customer voice - наше все. У вас может быть 100500 тикетов или комментариев на аппсторе. Обещания самым крупных энтерпрайз-клиентам. Хотелки. Вещи, которые реально упрощают жизнь, но без которых тоже можно существовать. Не все эти фичи нужно всегда воплощать, но профессиональный РО всегда старается получать ПРЯМУЮ обратную связь от пользователей (избегайте агрегированных субъективных идей сейлз-менеджеров, саппорта, партнеров или CSM). Читайте тикеты, организовывайте конференц-звонки, слушайте клиентов/пользователей.
3. Основанные на вашем видении. Здесь могут быть вещи, которые приятно удивят ваших пользователей, например улучшения UX или скорости работы. Обычно для появления этих фич требуется несколько ингредиентов: внимательно слушать пользователей для выявления их настоящих проблем (но не их варианты решения проблем, которые могут быть не универсальными!), понимание возможностей технологии, продуманный UXи упаковка фичи, ее встраивание в существующий опыт/продукт.
Безусловно, некоторые фичи попадают в несколько категорий, но редко во все три.
Основная идея состоит в том, что:
1. Вы с командой четко отдаете себе отчет, к какой категории относится то, над чем вы работаете - какова цель (ответ на вопрос WHY)
2. Вы стараетесь включать в мажорные релизы понемногу из каждой категории - МЕТРИКИ: улучшения для бизнеса/стейкхолдеров; ФИДБЕК: демонстрируете, что слышите пользователей; ВИДЕНИЕ: удивляете и показываете, что продует/компания является экспертом и может производить инновации.
И наоборот, если ваш анализ покажет, что одна из категорий отсутствует в вашем роадмапе и планах на релизы - очевидно, у вас есть проблема, и ее нужно исправлять.
Telegram
Product Development and Management 🏋️♀️
Ной Вайс, бывший вице-президент по продукту Foursqare и нынешний продакт хэд в Slack, делится своим простым подходом к роадмаппингу и приоритезации бэклога.
Исходя их его опыта, для очень быстро растущих компаний (исповедующих lean startup подход), классические…
Исходя их его опыта, для очень быстро растущих компаний (исповедующих lean startup подход), классические…
Как расставляет квартальные приоритеты в разработке 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 дней повторить все с ноля, заново, не опираясь на идеи, ранее сгенерированные в предыдущем цикле.
Продолжаем нашу серию о том, как расставлять приоритеты в краткой и среднесрочной перспективе. Тема, вне всякого сомнения, сложная и этого заслуживает. При этом, естественно, самые рабочие варианты - самые простые.
Сегодня - о системе выбора приоритетов, которая работает даже для стартапов на ранней стадии, где вообще часто очень мало ориентиров и не на что опереться. Систему придумал и внедрил СТО 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 дней повторить все с ноля, заново, не опираясь на идеи, ранее сгенерированные в предыдущем цикле.
Firstround
This Product Prioritization System Nabbed Pandora 70 Million Monthly Users with Just 40 Engineers
Pandora CTO Tom Conrad explains how Pandora picks the most important features to build with its limited engineering power.
Отличное обсуждение на ту же тему приоритетов на Quora:
https://www.quora.com/Product-Management/What-are-the-best-ways-to-prioritize-a-list-of-product-features
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
ProductCoalition.com
The Scrum Product Owner Theses
From Product Discovery to Product Delivery
И о полезном.
Наша наивная идея (и эти грешат многие материалы и тренинги по разработке продукта) состоит в том, что бэклог - это набор user stories для новых фич.
Но жестокая действительность разбивает наши мечты, приходя в виде тикетов от саппорта, технического долга вследствие срезания углов («надо успеть к релизу»), и ультиматумов (обоснованных!) от команды о необходимости выделять время для проработки архитектуры («ребята, ну сколько можно говорить и рисовать, давайте писать код!»).
Один из подходов, о которых я еще не писал - это матрица для форматирования бэклога на основе двух осей:
Прошлое - Будущее
Бизнес - Разработка
Основная идея состоит в том, чтоб зарезервировать % времени под каждый блок работы, и перестать мучаться в сомнениях при планировании каждого спринта.
В зависимости от специфики и зрелости вашего продукта, это соотношение будет разным. Очевидно, максимум внимания хочется уделять новым фичам. Я бы сказал, в моем случае (В2В энтерпрайз софт, с которым работают крупные глобальных корпорации, и есть определенные платформенные зависимости, 20+ скрам-команд, которые координируют свои усилия) это выглядит так:
Новый функционал - 60%
Техдолг - 10%
Проработка архитектуры - 10%
Саппорт - 20%
(один из разработчиков в каждой команде резервируется под сложные кейсы и срочную помощь энтерпрайз-кастомерам, изменения вносятся сразу также в коробку и выходят в следующем релизе для всех)
В итоге, приходится признать, что если ваш продукт довольно зрел, то на собственно развитие вы будете тратить не более 60-70% - и это еще очень хорошие цифры 😉
P.S> Это ок, если ситуативно цифры прыгают: например, одна из моих команд сейчас будет перевозить целый пул сервисов на новый фреймворк, и в краткой перспективе это выглядит как пробуксовка с точки зрения клиентов, но в итоге это ускорит работу критически важных компонентов архитектуры, добавит отказоустойчивости - в итоге снизит количество саппорт-тикетов и освободит время команды на разработку новой функциональности.
Наша наивная идея (и эти грешат многие материалы и тренинги по разработке продукта) состоит в том, что бэклог - это набор user stories для новых фич.
Но жестокая действительность разбивает наши мечты, приходя в виде тикетов от саппорта, технического долга вследствие срезания углов («надо успеть к релизу»), и ультиматумов (обоснованных!) от команды о необходимости выделять время для проработки архитектуры («ребята, ну сколько можно говорить и рисовать, давайте писать код!»).
Один из подходов, о которых я еще не писал - это матрица для форматирования бэклога на основе двух осей:
Прошлое - Будущее
Бизнес - Разработка
Основная идея состоит в том, чтоб зарезервировать % времени под каждый блок работы, и перестать мучаться в сомнениях при планировании каждого спринта.
В зависимости от специфики и зрелости вашего продукта, это соотношение будет разным. Очевидно, максимум внимания хочется уделять новым фичам. Я бы сказал, в моем случае (В2В энтерпрайз софт, с которым работают крупные глобальных корпорации, и есть определенные платформенные зависимости, 20+ скрам-команд, которые координируют свои усилия) это выглядит так:
Новый функционал - 60%
Техдолг - 10%
Проработка архитектуры - 10%
Саппорт - 20%
(один из разработчиков в каждой команде резервируется под сложные кейсы и срочную помощь энтерпрайз-кастомерам, изменения вносятся сразу также в коробку и выходят в следующем релизе для всех)
В итоге, приходится признать, что если ваш продукт довольно зрел, то на собственно развитие вы будете тратить не более 60-70% - и это еще очень хорошие цифры 😉
P.S> Это ок, если ситуативно цифры прыгают: например, одна из моих команд сейчас будет перевозить целый пул сервисов на новый фреймворк, и в краткой перспективе это выглядит как пробуксовка с точки зрения клиентов, но в итоге это ускорит работу критически важных компонентов архитектуры, добавит отказоустойчивости - в итоге снизит количество саппорт-тикетов и освободит время команды на разработку новой функциональности.
Очень хорошая подборка советов начинающим продакт-менеджерам и фаундерам стартапов (очень сжато, и на самом деле подойдет менеджерам в любых областях, не только в разработке софта).
История состоит в том, что один из ивестных фондов собрал фаундеров своих портфельных стартапов и менторов, и попытался их быстро проапгредить.
Темы, которые попытались покрыть:
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/
История состоит в том, что один из ивестных фондов собрал фаундеров своих портфельных стартапов и менторов, и попытался их быстро проапгредить.
Темы, которые попытались покрыть:
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/
Firstround
17 Product Managers Who Will Own the Future of NYC Tech — and the 9 Frameworks They’ll Use to Do It
Last year, First Round hosted a seminar of 17 rising star product managers in NYC, taught by some of the best product leaders in the tech industry. Here's who they are and what they learned.
Критически важные качества для 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, в конце концов.
Аминь )
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
В общем, конечно, мотивы могут быть разгаданы: не идти на поводу разработчиков и не утонуть в анализе багов и спорах о необходимости рефакторинга.
Но: это все нивелирует идею и перспективу иметь команду, которой не пофиг, которая проактивна и не заметает мусор под ковёр («все равно наш РМ не даст нам это исправить, у них сроки, давайте даже не будем его драконить»). И главное - все это приводит к тому, что вы не продакт, а проджект менеджер. А это совсем другая кухня.
В общем, если дать три совета:
1. Не бойтесь своей команды. Дружите, работайте вместе и находите компромиссы.
2. Не бойтесь вникать в технические детали. Я против того, чтоб РО/РМ диктовал реализацию, но проводить с командой груминг (рефайнмент) вы обязаны, не говоря уже о понимании того, как устроен продукт.
3. Ищите совместных решений и находите здоровый баланс между: новыми фичами, багфиксом/саппортом, техдолгом. Как я уже неоднократно писал, это ок если у вас на новую функциональность уходит 60-70% ресурсов, все прочее - самообман.
4. Бонус :) Обратная сторона тенденции тесно работать с командой все же существует - РО/РМ, которые не сильный бизнес/гуманитарной стороне вопроса, таким образом сбегают от юзеров, бизнеса, требований, необходимости все это балансировать и принимать тяжелые, но необходимые решения по бэклогу/роадмапу. Это тоже не ок :)
На конференциях обсуждают проблему, озвученную выше, и вы можете послушать, о чем идёт речь, если чувствуете, что сталкиваетесь с этим: https://youtu.be/Y-glrQUalXs
YouTube
Дистанцирование продакта от команды / Евгений Некрасов, Avito
Презентация — https://goo.gl/4AXjSp
ProductCamp Perm, февраль 2018
Основатель: Михаил Карпов
Организатор и ключевой спонсор: RealtimeBoard
Партнёры: Дом.ру и Xsolla
ProductCamp Perm, февраль 2018
Основатель: Михаил Карпов
Организатор и ключевой спонсор: RealtimeBoard
Партнёры: Дом.ру и Xsolla
Вы конечно же читаете канал Кости Горского из Интеркома, но если вдруг пропустили - вот как раз последний пост на тему важности тесной работы с командой: https://news.1rj.ru/str/desprod/277
Telegram
Design & Productivity
Сегодня я в Лондоне. Осенью мы открыли тут небольшой офис разработки, так как в Дублине не успеваем нанимать людей с такой скоростью, с какой бы хотелось. В Лондоне клёво. На фотке — мой любимый кофешоп — Department of coffee and social affairs. Ещё в Лондоне…
Коллега поделился неплохим обзором общих антипаттернов по тестированию. Если вы РО/РМ, который давно работает (особенно в энтерпрайз) разработке, ничего особо нового вы не увидите. С другой стороны, иногда полезно уложить все в общую картину и вспомнить основы.
Вы, конечно, не отвечаете за тестирование ;), но понимать что такое хорошо, а что такое плохо - вы обязаны, не говоря уже о том, чтоб разговаривать со своими разработчиками на одном языке.
https://habr.com/post/358178/ - RU версия
http://blog.codepipes.com/testing/software-testing-antipatterns.html - EN оригинал
Вы, конечно, не отвечаете за тестирование ;), но понимать что такое хорошо, а что такое плохо - вы обязаны, не говоря уже о том, чтоб разговаривать со своими разработчиками на одном языке.
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
MTP организовывают самые интересные конференции и тренинги по продакт менеджменту, две самые крупные - летом в Сан-Франциско и осенью в Лондоне; очень советую.
Я напишу о контенте и выводах, а сейчас хотел поделиться одним очень простым наблюдением. Огромная польза для РО/РМ с пост-СССР пространства состоит просто в возможности в течение дня отмериваться опытом с другими продактами со всего мира, узнавать как они решают те же проблемы, над которыми ты бьешься каждый день. Это незаменимо, особенно если вы строите продукт на глобальный рынок, или как минимум стремитесь быть специалистом топ-уровня.
Продолжение следует :)
https://www.eventbrite.com/e/product-management-essentials-102-training-workshop-amsterdam-tickets-43599757047
Eventbrite
Product Management Essentials 102 Training Workshop - Amsterdam
Increasing your strategic impact as a product manager
Training Workshop Overview
Essentials 102 is an overview course intended for confident product managers who are looking to increase their strategic skills and influence. The intention of this course is…
Training Workshop Overview
Essentials 102 is an overview course intended for confident product managers who are looking to increase their strategic skills and influence. The intention of this course is…
Customer requirements are not Product Requirements.
Да, нужно слушать customer voice. Но это лишь один из источников наравне с сейлз, маркетингом, customer success, стейкхолдерами. В сумме все это может корректировать очередность выпуска фич в вашем роадмапе, но:
1. Помните о стратегии и видении; очень, очень легко потеряться в штамповке фич, которые «все юзеры хотят и ждут».
2. Продолжение п.1: не превращайте ваш продукт в франкейнштейна из меню и настроек («мы просто сделаем это опциональным»).
3. Помните, что решение о приоритетах бэклога принимает Product Owner/Manager, а не клиент. И даже не директор департамента или член совета директоров, которому кто-то позвонил.
И самое главное - все specials и кастомная разработка приводят вас в проектному мышлению и уводят от продуктового, демотивирует команду и уводят вас от стратегии по запуску и проверке фич, которые вы как продакт запланировали для достижения ваших целей.
Да, нужно слушать customer voice. Но это лишь один из источников наравне с сейлз, маркетингом, customer success, стейкхолдерами. В сумме все это может корректировать очередность выпуска фич в вашем роадмапе, но:
1. Помните о стратегии и видении; очень, очень легко потеряться в штамповке фич, которые «все юзеры хотят и ждут».
2. Продолжение п.1: не превращайте ваш продукт в франкейнштейна из меню и настроек («мы просто сделаем это опциональным»).
3. Помните, что решение о приоритетах бэклога принимает Product Owner/Manager, а не клиент. И даже не директор департамента или член совета директоров, которому кто-то позвонил.
И самое главное - все specials и кастомная разработка приводят вас в проектному мышлению и уводят от продуктового, демотивирует команду и уводят вас от стратегии по запуску и проверке фич, которые вы как продакт запланировали для достижения ваших целей.