Product Management

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

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

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

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

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

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

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

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

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

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

Критически важные качества для 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. Как понять, что строить именно сейчас
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/

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

И о полезном.

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

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

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

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

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

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

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

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

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

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

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

Как расставляет квартальные приоритеты в разработке 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 дней повторить все с ноля, заново, не опираясь на идеи, ранее сгенерированные в предыдущем цикле.

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

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

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

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

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

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

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

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

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

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

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/

Ной Вайс, бывший вице-президент по продукту 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://t.me/productdev/19

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

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

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

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

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

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

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 дней) мне пока кажется нецелесообразным. Пока более разумной выглядит мысль брать задачи объемом меньше спринта, которые могут быть явно отданы в релиз, а оставшееся время просто начинать делать следующие задачи из топа бэклога. При этом успешность спринта оценивать только по основной цели, а не дополнительным задачам.

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

Роадмаппинг здорового человека

"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

Желаю вам продуктивного подведения итогов и разумного взвешенного планирования - с вашими пользователями в уме 😉

Говорят (спасибо, Женя!), ссылка из последнего поста об инструментах не всем видна, вот она ещё раз:
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://bangbangeducation.ru/talks

Перестаньте играть в Тетрис (в разработке продукта) 🤹‍♀️

На прошлой неделе я делился замечательной цитатой:
«If Tetris has taught me anything it's that errors pile up and accomplishments disappear»

Я сделал саммари оригинального поста с некоторыми рефлексиями из собственного опыта (здесь: https://medium.com/@mishanestor/перестаньте-играть-в-тетрис-в-разработке-продукта-a89cb55bb681 ).
О чем же идет речь?

КТО ВИНОВАТ?

Несколько признаков того, что вы играете в тетрис в своей работе РМ:

1. Докинуть несколько маленьких историй в спринт, чтоб дать всем ощущение инкремента и скорости в разработке. 🎰
2. Ориентироваться на то, чтоб все выглядели занятыми, независимо от влияния на бизнес-результаты и эффективность/комфорт работы команды. 🚣‍♀️
3. Попытки планировать на год/квартал с участием топ-менеджмента, которые выглядят как «а как бы нам этот паззл собрать так, чтоб побольше впихнуть в квартал» 🤞
4. Просить другие функции (напр., UX) делать работу «впрок», что приводит к неадекватным зависимостям и блокирует полезные улучшения в продукте. 🤦‍♂️
5. Никогда не возвращаться чтоб фиксить дырки в продукте. Приводит к тому, что коллективное бессознательное команды погружается в грусть и фрустрацию. 🧟‍♂️
...

ЧТО ДЕЛАТЬ?

(в посте по ссылке⬇️)