Product Management

Роадмаппинг здорового человека "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. Никогда не возвращаться чтоб фиксить дырки в продукте. Приводит к тому, что коллективное бессознательное команды погружается в грусть и фрустрацию. 🧟‍♂️ ... ЧТО ДЕЛАТЬ? (в посте по ссылке⬇️)

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

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

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.

Сегодня некоторым товарищам я обещал выложить еще материалов по 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.

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

«Все заняты» - это НЕ стратегия приоритезации. Постоянное обучение и улучшение должны быть встроены в рабочий процесс команды. На самом деле, хоть это все отлично звучит в теории, все просто слишком заняты разработкой фич и фиксом багов. Основная причина состоит в том, что отсутствует безопасный способ для команд и их лидеров сказать «Нет» каким-то из задач. 🕹Решение: Командами нужно управлять по результатам (outcomes), а не количеству написанного кода. Результаты - это измеряемое поведение клиентов. В результате качество решений определяется не по дате поставки клиентам фич, а по степени эффективности изменения пользовательского поведения в необходимую сторону. 🏋️‍♀️ Как это работает: Ожидаемые результаты (outcomes) работают как фильтры. Каждая новая задача должна пройти через анализ по двум непростым пунктам: * Как эта идея поможет нам достичь желаемого поведения клиентов (customer behavior)? * Почему эта идея выглядит более привлекательно, чем другие идеи, над которым мы сейчас работаем? Если идея, независимо от того, насколько она драйвит или кто ее автор (читай: топ-менеджер), не согласуется с ожидаемыми целями команды в терминах поведения клиентов/пользователей, у вас есть прозрачный, объективный способ сказать «НЕТ»😾 Оригинал поста от автора LEAN UX на англ.: https://medium.com/@jboogie/everyone-is-too-busy-is-not-a-prioritization-strategy-45ac4d525ab5

Objectives and Key Results  - методология постановки целей от Google, которая учитывает острую потребность гармонизировать потребности/стратегию организации и личные цели/амбиции каждого сотрудника. Этот тот случай, когда, казалось бы, неподъемная задача по синхронизации фокуса и направления усилий всей компании делается через ОЧЕНЬ простую методологию, с понятными шагами и критериями оценки. 5-минутный обзор 80-минутного воркшопа  - ниже по ссылке. Автор воркшопа для портфельных компаний Гугла - бывший продакт-менеджер blogger.com (третий по траффику бизнес Google), а сейчас - партнер в GV (Google Ventures). Также в русскоязычном саммари видео есть ссылки на дополнительные ресурсы по теме, включая внутренюю методичку Google для новых сотрудников, и, собственно, оригинал видео для фанатов. https://medium.com/@mishanestor/objectives-and-key-results-методология-постановки-целей-от-google-aa3cba5e763b

Продолжаю делиться любимыми блогами. Сегодня попался замечательный пост с верхнеуровневым обзором самых важных вещей при разработке продукта. Начал делать саммари на русском для вас (и для себя), в итоге получилось чуть больше, чем ожидал - а это говорит о том, что пост был наполнен смыслом 😉 Сделал вам Medium-пост на русском. Если на этой неделе вы планируете прочитать один пост, то стоит почитать именно этот - в оригинале или в моем вольном переводе. Итак, вице-президент Facebook по продуктовому дизайну (Julie Zhuo) отвечает на вопрос: «Как разработать полезный продукт с ноля». https://medium.com/@mishanestor/как-разработать-полезный-продукт-с-ноля-378536be35eb

Классный анализ упущенных перспектив Trello на фоне их недавней продажи за $425 млн компании Atlassian (создателям JIRA /Confluence). Анализ от Hiten Shah, фаундера KISSmetrics, фокусируется на нескольких ключевых возможностях Trello: 1. Начать монетизироваться раньше. Trello были сильно сфокусированы на расширении базы free пользователей - и она у них была намного больше, чем у Dropbox в тот же период (10 млн юзеров через 3 года после запуска против 4 млн у Dropbox). 2. Дать более явные выгоды от платной подписки. Набор эмоджи и кастомные бэкграунды досок - явно не то, что стоит дополнительных затрат (для сравнения тот же Dropbox Professional, которым я пользуюсь не один год, увеличивает объём диска с 2 Гб до 1 Тб - то есть, в 50 раз). 3. Раньше задуматься о малом бизнесе. SMB ждали понятных предложений и прайсинга, но и здесь Trello потерпели неудачу. Как горизонтальное решение, они боялись сузиться до конкретной ниши/ниш, делать отдельные лендинги и фичи под сегменты рынка, в итоге бизнесы не получили ожидаемой пользы, коммуникация была размыта, а прайсинг не отражал реального использования продукта внутри компании. 4. Делать интеграции - раньше и больше. Яркий пример - управление issues из Github внутри Трелло. Эта возможность была упущена, а технология быстро синхронизируемой канбан-доски уже перестала быть недостижимой. В итоге Github сделал это сам. 5. Делать продукт для Enterprise. Хотя Trello и заявили о стратегии выхода в энтерпрайз через год после запуска, их стратегия была наивной: "Мы приходим в компанию и говорим: у вас 2000 человек пользуется Трелло, не хотите поговорить об этом?". Да, возможно и пользуются, го это отдельные департаменты, отдельные доски. Это очень далеко от единой системы записей и уж тем более от бизнес-процессов и workflow (что в базовом виде хорошо реализовано в той же JIRA от Atlassian). Полная история - по ссылке: https://blog.usejournal.com/why-trello-failed-to-build-a-1-billion-business-e1579511d5dc Интересных вам выходных! 🤓

И раз уж мы говорим о юзабилити - не забываем, что в Shared Media этого канала вы можете удобно видеть список всех ссылок и файлов:

Всем чмоки 🙂 Design Thinking сегодня, как секс среди подростков 🤐 или digital 10 лет назад - все говорят, никто не делает. В общем, один прекрасный парень объединил несколько известных подходов: Double Diamond от британской школы дизайна, Human-Centered Design от IDEO и, собственно, Design Thinking. Я бы не сказал, что получилось слишком просто🤖, но раз уж эту неделю я посвятил данной теме, будет грешно не поделиться: https://medium.com/digital-experience-design/how-to-apply-a-design-thinking-hcd-ux-or-any-creative-process-from-scratch-b8786efbf812 Неплохой способ увидеть все три методологии в одном месте и попробовать уловить их суть.

Мы все знаем IDEO, но не все видели их прекрасный и информативный раздел со всевозможными методами исследований в процессе разработки продукта/дизайна. Очень рекомендую: http://www.designkit.org/methods

Например, отличный пост о принципах дизайна Watsapp: https://medium.com/facebook-design/one-year-designing-at-whatsapp-c20b4c46bae6 Золотая цитата из поста: " If the feature needs explanation, it’s not ready." Сложно спорить 🙂