Используя код - elevatedesign - вы можете получить доступ к просмотру фильма Design Disruptors от InVision (https://www.designdisruptors.com). В создании фильма приняли участие представители ведущих технологических компаний мира - от Head of Design Dropbox до VP Product Design Facebook. Фильм сделан очень качественно.

Не так много фильмов о продуктовом дизайне есть в принципе. Прекрасное занятия для воскресного вечера 😉

Ссылка на просмотр: https://www.designdisruptors.com/priority-access

Сегодня некоторым товарищам я обещал выложить еще материалов по UX/UI.
У меня есть несколько самых любимых системных описаний темы, сегодня выложу одно из них, на днях - следующее. Поскольку вчера мы сомтрели фильм, спонсором которого выступил InVision (см предыдущий пост), то и начнем мы с их ресурса DesignBetter. Ниже ссылки на 4 прекрасные интерактивные книги, с врезками из видео, аудио комментариев ведущих специалистов, ссылками на полезные материалы, в общем - настоящее сокровище, не на один вечер/день. Итак:

1. Principles of Product Design от InVision: https://www.designbetter.co/principles-of-product-design

2. Design Thinking Handbook: https://www.designbetter.co/design-thinking

3. Design Leadership Handbook: https://www.designbetter.co/design-leadership-handbook

4. Design Systems Handbook: https://www.designbetter.co/design-systems-handbook

В принципе, уже неделю можно ничего не писать 😉 Но есть еще один кладезь ресурсов по UX/UI, и уже после него с этой темой можно будет сделать паузу, и делиться материалами по другим аспектам Product Development.

Atomic Design - одна из популярных методологий UI/UX дизайна, предполагающая работу с компонентами интерфейса на разных уровнях - от сайта до кнопки.

Популярность методологии вызвана тем, что она позволяет реиспользовать и миксовать разные компоненты и блоки, при этом обеспечивать единое ощущение и целостность UX.

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

⭐️⭐️⭐️ http://atomicdesign.bradfrost.com/table-of-contents/

Если вы все еще не верите, что это важно и полезно, вот несколько публикаций об этой методологии:

1. 10 reasons you should be using Atomic Design: http://www.creativebloq.com/web-design/10-reasons-you-should-be-using-atomic-design-61620771

2. Atomic design: how to design systems of components: https://uxdesign.cc/atomic-design-how-to-design-systems-of-components-ab41f24f260e

3. Brad Frost: Atomic Design - видео от автора: https://vimeo.com/109130093

Почему я пишу о системах UI и почему такой акцент на UX? Во-первых, это очевидно - сложно делать продукт, не разбираясь в эих темах. Даже если у вас в команде замечательные дизайнеры, логику интерфейсов важно понимать (и часто прототипировать) самим. Во-вторых, важно быть способным оценить решения, которые вам предлагают. В-третьих, это просто очень интересно, ведь дизайн в разработке софтовых продутов - это не картинки в фотошопе/иллюстраторе, а прежде всего логика и experience.

Попался замечательный канал с массой видео от авторов и продактов из крупнейших технологических кампаний. Все бесплатно, но на английском (но без англ в этой сфере нечего делать в принципе):
https://www.youtube.com/channel/UC6hlQ0x6kPbAGjYkoz53cvA

Для примера - видео от Head of Product о ее десятилетнем опыте запуска продуктов в Amazon:

https://youtu.be/4BPUMsDdR0c
(не забывайте смотреть описания видео - там основные пункты и ссылки на слайды)

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

На прошлой неделе я делился замечательной цитатой:
«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. Никогда не возвращаться чтоб фиксить дырки в продукте. Приводит к тому, что коллективное бессознательное команды погружается в грусть и фрустрацию. 🧟‍♂️
...

ЧТО ДЕЛАТЬ?

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

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

https://bangbangeducation.ru/talks

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

* 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

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

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

"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

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

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%).