Архив недели
Понедельник
Здравствуйте. Я — Алексей Рытов. Менеджер продукта в Semrush, автор телеграм-канала «Притчи продуктолога» t.me/product_prover…
Раньше был UX-дизайнером, создал первую в России школу UX. А еще, я именно тот мотоциклист, что мешает вам спать по ночам.
Каждый день на этой неделе у нас будет новая тема:
Планируем квартал.
Спринт: планинг, груминг, стендап, ретро, демо.
Проверка фич и статистика.
Плохая/хорошая команда.
Эксперименты.
Технический долг.
Кто такой менеджер продукта.
Я буду делиться, практикой своего 20-летнего рабочего стажа и выводами, которые я из этой практики сделал. Теории не будет. Буду рад, если вы поделитесь своим опытом. Прекрасно, если он отличается от моего. Готов отвечать на вопросы, особенно по «теме дня».
Стратегия и тактика.
Мы планируем поквартально. Три месяца — это достаточно много, чтобы сделать что-то существенное. И это достаточно мало, можно вовремя скорректировать планы. Но прежде, чем говорить о планировании квартала, я хочу прояснить вопросы стратегии и тактики.
Спринт (2 недели) — это тактическое планирование. Квартал (3 месяца) — это тоже тактическое планирование. Для хорошей тактики нужна стратегия на 1-2 года. Если у вас нет стратегии, то не понятно, как планировать тактические действия.
Главное заблуждение в развитии продукта звучит так:
Мы будем делать много мелких полезных вещей и это приведет к одному большому хорошему результату.
Если у вас нет стратегии развития продукта, ваше тактические планы (1-3 месяца) имеют все шансы на рандомный результат. Это как с шансом найти миллион долларов. Как известно, шанс 50% — или найдешь или не найдешь :-)
Моя продуктовая стратегия — это пара листов текста. В ней написано, куда мы движемся в ближайший год-два и почему именно туда. Например, для нашей команды цель на год — избавиться от устаревших частей продукта и устранить технические препятствия к дальнейшему развитию.
@produnderhood Можете посоветовать что прикладного про стратегию почитать?
Вопрос хороший, но я затрудняюсь посоветовать литературу. Может быть читателя смогут? Что почитать про составление стратегии? twitter.com/Uran_90/status…
Тема дня: Планирование квартала.
Так совпало, что именно сегодня мы планируем работы на ближайшие три месяца. Расскажу об этом. Наша команда состоит из:
Продукт овнер (я)
UX
UI
4-5. Два бэкенд разработчика (один из них тех.лид)
6-8. Три фронтенд разработчика
QA
В прошлом квартале планировать всей командой было некогда. Я написал все цели единолично. Команда прочла их и сказала ОК. Это плохой паттерн. Разработчики не чувствуют причастности к планам, не понимают, откуда они взялись. Не надо жалеть времени, чтобы планировать всей командой.
Сегодня мы целый день посвятим планированию квартала. Проходит это так:
Накидываем идеи.
Группируем, укрупняем.
Сверяем со стратегией.
Оцениваем, что влезет.
Финализируем.
Накидываем идеи.
Все участники команды берут стикеры и пишут любые вещи, которыми на их взгляд должна заниматься команда в ближайшие три месяца. Один стикер = одна идея. Наклеивают стикеры на доску и устно поясняют.
Группируем, укрупняем.
Стикеры объединяем в группы. Нет универсального правила, как это делать. Может быть, руководствуясь, техническими особенностями. Или еще чем-то.
Сверяем со стратегией.
Мы сознательно не вспоминали стратегию в начале планирования. Чтобы не ограничивать фантазию коллег. Но теперь пришла пора посмотреть на все группы стикеров и отбросить те, что не помогают достижению стратегических целей.
Оцениваем, что влезет.
Каждую группу карточек оцениваем, сколько времени нужно на разработку. Конечно, оценка очень примерная. Мы оцениваем с точностью до 2 недель работы всей команды. Обсуждают все, но последнее слово за разработчиками. Продукт овнер в этом вопросе не главный.
Финализируем.
У нас получился набор эпиков (группы карточек). Каждый эпик оценен, и понятно, что влезет в квартал, а что нет. Продукт овнер должен решить, что берем в работу, а что нет. Команда в вопросах приоритета не главная.
Каждый эпик оформляем как цель. Как именно — зависит от фреймворка целеполагания, которым вы пользуетесь. Я много лет пользовался SMART и OKR — хорошие фреймворки. Но сейчас мы используем Semrush Rhythm — на мой взгляд он круче.
Коротко о Semrush Rhythm.
Там есть иерархия целей, чтобы малые цели могли работать на достижение больших. Но мне больше всего нравится, как формулируется цель. Очень помогает в работе.
Цель в Semrush Rhythm — это ставка. Например:
Мы ставим 2 месяца работы команды и 30 тысяч рекламного бюджета на создание MVP продукта. Успехом считаем 1000 регистраций и 20 покупок. В случае успеха делаем .... фичу. В случае неуспеха .... вкладываем еще 10 тысяч в рекламу.
Хорошего вам планирования!
@produnderhood Можете привести примеры, какого рода задачи обычно разработчики накидывают? Интересно особенно с учётом того что b2b продукт - сами не пользуются.
Разработчики накидывают вполне себе продуктовые задачи, потому что понимают что нужно продукту. Сегодня удивила такая цель от разрабов:
«Дать еще один шанс проигравшему в эксперименте концепту ХХХ, попробовать его улучшить». twitter.com/Uran_90/status…
@produnderhood Идеи генерите сами, или проводите кастдевы/глубинные интервью?
Откуда я беру идеи для эпиков:
- Анализ данных продукта.
- Фидбэк пользователей, интервью.
- Юзабилити-тестирование.
- Стратегические цели.
- Техническая необходимость. twitter.com/in_carne/statu…
Вторник
Тема дня: Спринт: планинг, груминг (PBR), стендап, ретро, демо.
Уверен, для многих из вас все, что я сегодня напишу, будет звучать как прописные истины для детсадовцев. Отлично, если это так. Но для кого-то может оказаться полезным.
Начну с PBR, Product Backlog Refinement. Я привык называть это «груминг».
ГРУМИНГ — это, наверное, самая важная встреча команды. На ней мы обсуждаем предстоящие задачи. Цель — понять, что именно нужно сделать, декомпозировать задачу и оценить её.
Результат груминга — оцененные и декомпозированные задачи, полностью готовые к работе. Если этого не сделать ДО планинга, то планинг растянется на целый день, всех вымотает и будет некачественным.
В течение двухнедельного спринта мы проводим два груминга по полтора часа. На одном разбираем продуктовые задачи, на втором — технические. Иногда назначаем внеочередной груминг. Но обычно обходимся одной встречей в неделю.
ПЛАНИНГ — это время взять подготовленные на груминге задачи и решить, что именно влезет в спринт. Если груминг был проведен качественно, то планинг занимает 30 минут. На практике приходится обсуждать нюансы — «догрумливать на планинге». Тогда планинг занимает два-три часа.
Когда-то давно меня учили, что планинг может занимать целый день. На практике сложно что-то обсуждать группой из 7-10 человек в течение целого дня. Через пару часов большая часть людей отключается, и беседа идем между двумя самыми активными. Подход кажется неэффективным.
СТЕНДАП (дэйли) — встреча на 15 минут, где каждый отвечает на вопросы: что делал, что собираюсь делать, какие есть проблемы. Проблемы не обсуждаются, а выносятся на парковку — реальную или виртуальную доску, где на стикерах записаны проблемы со стендапа.
Есть огромное желание начать обсуждать проблемы прямо на стендапе. Особенно, когда кажется, что решить их можно быстро. Не стоит этого делать, ведь у каждого выступающего есть всего полторы-две минуты. Лучше потратьте их на уточняющие вопросы.
Перейдя на удаленку, мы перестали видеться в офисе и решать мелкие вопросы между делом. Поэтому на парковке после стендапов скапливалось много проблем. Мы начинали их обсуждать после стендапа и делали это по часу. Стендап вроде 15 минут, а реально полтора часа.
В результате решили, что дэйли встреча будет максимум 30 минут: 15 минут на стендап, 15 на парковку. Не больше. Если остались вопросы, которые нужно обсуждать всей командой — планируем внеочередной груминг. Но обычно это не требуется, большинство проблем решаются в личном порядке
Если какая-то проблема висит на парковке неделю и не решается, лучше оформить ее как задачу и обсудить на груминге.
РЕТРО, ретроспектива — встреча раз в спринт, где команда может выяснить отношения и позитивно поконфликтовать. Есть много прикольных фреймворков, как проводить ретро. Но мы пользуемся самым простым: плюсы, минусы, голосование, обсуждение, решения.
Мы проводим ретро так. Каждый пишет на стикерах «плюсы» — что хорошего было в спринте. По очереди наклеивает на доску и поясняет на словах. Потом тоже самое с «минусами». Плюсы не обсуждаем. Минусы обсуждаем и принимаем практические решения.
Все минусы не успеть обсудить. Поэтому каждый отдает свой голос за три самых важных на его взгляд проблемы. Начинаем обсуждать проблем, которые набрали наибольшее количество голосов. Стараемся сформулировать конкретные шаги, как решить проблему. Эти решения выписываем на доску.
Ретро занимает у нас два часа. Что не успели обсудить — не обсуждаем. Если какая-то проблема останется через две недели, ее обязательно «накинут» еще раз. Как говорят автомобилисты: «Хороший стук себя проявит».
Важно правило для ретро: «Я-послание». Говоришь о себе и своих проблемах, а не о других людях.
Правильно: я часто не могу начать тестирование, потому что в комментариях нет ссылки на merge request.
Неправильно: Ваня и Петя вечно забывают написать merge request в комментариях.
У нас есть правило: мы можем пропустить ретро, если никто из команды не против. Но нельзя делать это больше одного раза подряд. А вообще, ретроспективы очень нужны и в команде и в семье, я об этом писал: t.me/product_prover…
ДЕМО — встреча в конце спринта, где мы показываем то, что сделали в спринте. Цель — получить фидбэк от всех заинтересованных лиц. Ну и конечно же похвастаться, какие мы молодцы.
Мы показываем фичи только на продакшене. Раньше многие команды выходили, показывали новую фичу на тестовом сервере и говорили «в понедельник выльем в прод». Проходило две недели, они опять выходил на демо, и оказывалось, что фича до сих пор не в продакшене.
Когда команд стало много, а стейкхолдеров еще больше, демо стало менее эффективным. На качественную обратную связь и вопросы не хватает времени. Поэтому сейчас для меня важнее написать в специальный чат о новой фиче.
У нас есть деплой-чат с Слаке, куда все команды пишут о вылитых в прод фичах. Текст, ссылки и скриншоты. Все задают вопросы, ставят смайлики. По сути — то же демо, просто в чате.
Чат решает проблему многих вступающих на демо — стеснение. Не все любят и умеют выступать публично. А внятно написать в чат — способны все, мы же айтишники, в конце концов.
May Scrum be with you!
Среда
Тема дня: Проверка фич и статистика.
Довольно частый вопрос: «Как вы проверяете фичу»? Мне кажется, что прежде всего надо проверять не каждую фичу, а продукт в целом.
Статистика по продукту должна собираться автоматически и отображаться в легком для интерпретации виде. Зашёл на дашборд, посмотрел, всё понял. У меня есть дашборд с воронкой, дашборд с ретеншном, дашборд про деньги и т.п. А еще есть дашборд про быстродействие.
Старики говорят: «За двумя метриками погонишься — ни одну не улучшишь». Невозможно улучшать все продуктовые метрики одновременно. Лучше сосредоточиться на чем-то одном. Как минимум, в течение 2-3 месяцев. Например улучшать количество первых платежей. Или увеличивать средний чек.
О какой продуктовой метрике может идти речь, если у нас рефакторинг и мы меняем стек? У моей команды как раз такой период. При этом у нас критерий успеха — количество первых платежей. Наша цель — их не уронить нашим рефакторингом. Очень хорошая цель!
Не важно, какие BI системы вы используете. Главное, чтобы вам нравилось. Мы, например, собираем данные через OWOX, а продуктовые дашборды конструируем в Tableau. Для сбора технических данных и дашбордов активно использовали Splunk. Сейчас для техники что-то другое.
О продактах и аналитиках. Наши аналитики супер умные ребята и девчата. Мне до них далеко во всем, что касается SQL, алгоритмов и статистики. Но им нужно подробно ставить задание, что именно мне нужно. Польза аналитического дашборда во многом зависит от квалификации заказчика.
Какую статистику собирать и как ее отображать? Все придумано до нас. Но в обилии информации легко потеряться. Мне повезло работать с опытными людьми — могу подсматривать. Если у вас нет таких коллег, пригласите специалиста в ресторан и пока жарят стейк, откройте ноутбук.
Итак, ответим на частый вопрос: «Как вы проверяете фичу»? Ответ: «Головой». К сожалению мне не известен универсальный алгоритм для проверки эффективности фичи. Все фичи разные, и анализировать их надо по-разному.
Технически я проверяю фичи через GA ивенты. На этапе прототипа, пишу задание разработчикам. В GA есть вложенные сущности: категории, экшны, лэйблы, вэлью. Если все действия в продукте обвешать правильно написанными ивентами, анализировать поведение пользователя будет легко.
К примеру, вот GA ивент при отправке поискового запроса (в фигурных скобках — переменные):
GA-Category: {report_name}:search
GA-Action: load:send-search-query
GA-Label: search-type: by-auto-suggestion; search-query:{search_query_text}
Такими GA ивентами мы обвешиваем все элементы интерфейса и все действия пользователя. Задание пишу я сам, потому что у меня нет выделенного «личного» аналитика, который бы знал, как именно работает продукт. Одно время писал UX, но ему было тяжеловато делать это правильно.
Когда фичу выкатили, я жду, пока накопятся ивенты. Потом иду в BigQuery, где у нас хранятся все данные, и делают SQL запрос, который мне нужен. Я очень плохо знаю SQL, но если ивенты отправляются правильно, то даже минимальных знаний достаточно.
Выше я приводил пример GA ивента для поиска. Я могу сгруппировать данные по Action и вывести список Label. И увижу, что именно ищут пользователи. С группировкой категория/экшн/лэйбл можно играться бесконечно и получать ответы на вопросы про любое действие пользователя.
В принципе, можно обойтись вообще без знания SQL. Статистику ивентов можно смотреть в интерфейсе Google Analytics. Главное правильно расставить эти ивенты. Иначе вложенность будет вас только запутывать, а не помогать.
Для меня анализ фичи — творческий процесс. Я делаю запросы, смотрю на статистику с разных сторон и делаю выводы. Эти выводы вместе с цифрами и SQL-запросами я сохраняю в текстовый документ в понятном для посторонних людей виде. Можно показать команде и всем желающим.
Текстовый документ с аналитикой по фичам я веду много лет. Он довольно большой :-) Зато когда меня спрашивают о фиче, которую мы запустили 3 года назад, я могу прислать готовые к чтению выводы и ссылки на исходные данные и SQL-запросы.
Наверное, я никому не помог в вопросе «Как проверить фичу». Возможно читатели знают более универсальные и менее творческие способы проверки. Поделитесь, пожалуйста!
Keep calm and do query.
@produnderhood а можно по подробнее про Semrush Rhythm рассказать, чем принципиально отличается от OKR и от Spotify Rhythm
Мы взяли Spotify Rhythm (мы это не скрываем) и немного доработали под свои нужды. От ОКР отличается довольно сильно. twitter.com/ECalyari/statu…
Отличия Rhythm от OKR:
- Ресурсы на выполнение обязательно указывать.
- Заранее есть план на успех и неуспех.
- Успех — это минимальный устраивающий тебя результат, а не амбициозная цель, которую запрещено выполнять на 100% (самая большая глупость ОКР).
- Есть иерархия целей.
Четверг
Тема дня: Плохая/хорошая команда.
Плохой команду делают: непрофессионализм, инфантилизм, апатичность, лень, неправильный фокус, ссоры, боязнь конфликтов. Что-то одно у кого-то одного — уже плохо. Ниже разберем подробнее. Беру из моего личного 20-летнего опыта.
Непрофессионализм.
Если разработчик плохо программирует, его не спасет то, что он отличный парень. Точнее, это еще хуже. Свой первый продукт я написал со старинным другом. После первых продаж оказалось, что код написан так плохо, что его уже не спасти. Продукт пришлось закрыть.
Инфантилизм.
Я работал со взрослыми парнями, у некоторых были жены и дети. Они часто пошло шутили над единственной девушкой в команде. Могли долго ржать над фамилией иностранного коллеги. Это была не грубость, а поведение школьников-старшеклассников. Здорово утомляет и раздражает
Апатичность.
Продуктовая разработка подразумевает вовлеченность команды во все процессы. Если человеку ничего не нужно, он не хочет ничего менять, ничего обсуждать — это токсичное поведение. Как-то раз у нас упал сервер, а половина команды сказала: «Ой да фигня».
Лень.
Хард и софт скиллы разбиваются о лень. У некоторых она проявляется в любви поговорить и нелюбви что-то из разговоров исполнить. Лень передается воздушно-капельным путем.
Неправильный фокус.
Команда создает продукт, который помогает пользователям решать их проблемы, а бизнесу зарабатывать деньги. У нас нет цели освоить новый фреймворк или получить лучший ДМС в мире. Это все хорошо, и часто достижимо, но не является целью. Не все это понимают.
Ссоры.
Конфликты — хорошо. Ссоры — плохо. Они на глазах высасывают из людей энергию. Люди опускают руки и просто не могут работать в такой атмосфере. Приложите все усилия, чтобы неконструктивных ссор не было. А конфликты решались адекватно и регулярно. Проводите ретроспективы!
Боязнь конфликтов.
Люди в команде должны говорить правду друг другу. Вежливо, правильно, но говорить. Если команда терпит ленивого говнокодера, потому что он хороший парень — это ужасно. У нас команды нанимают и увольняют людей. Это сложно, это стресс. Но этому нужно учиться.
Хорошей команду делают: профессионализм, проактивность, честность, постоянные изменения, человечность, юмор, безопасность. Разберем подробнее.
Профессионализм.
Разница в эффективности между хорошим и посредственным таксистом, пожалуй, 30%. Разница между хорошим и посредственным программистом — тысячи процентов. Хорошие разрабы сэкономят вам много времени и денег. Не все должны быть звездами, но костяк команды — должен.
Проактивность.
Современный стиль создания продукта — глубокая вовлеченность каждого в процессы. Разработчики должны понимать продуктовые задачи, дизайнеры — технические ограничения и т.п. Если человек пассивный и хочет «писать код в уголке», ему органически будет сложно работать.
Честность.
Если вы постоянно что-то обсуждаете, сообща решаете проблемы, страхуете друг друга — обязательно кто-то где-то накосячит. Это не страшно, если об этом честно говорят. Честность помогает работать и помогает увольняться. Решил уйти — скажи заранее.
Постоянные изменения.
Залог здоровья команды — постоянные изменения. Я предпочту команду с кучей проблем, которая регулярно проводит ретроспективы и выполняет их решения. Чем команду, в которой все хорошо, но которая не проводит ретро и не меняется.
Человечность.
Приятно работать с людьми, которые знают о твоих увлечениях и достижениях твоих детей. Мы всё же люди, а не боевые юниты.
Юмор.
Наш IT-директор раньше был офицером на флоте. Рассказывал, как у них были учения, где их всем штабом отправляли в бункер на неделю. Делать там было особо нечего, если бы не шутки, сошли бы с ума. В командах разработки что-то подобное. Хотя дел много, но без юмора тоже никак
Безопасность.
Хорошая команда — это почти семья. Люди разные, случаются и конфликты. Но важно, чтобы все чувствовали себя безопасно. Должна быть гарантия, что тебя не унизят, не подставят, не будут сплетничать за спиной.
Как железо оттачивает железо, так и люди совершенствуют друг друга.
Притчи 27:17
@produnderhood Как, по вашему, вежливо и правильно сказать ленивому говнокодеру, что он ленивый говнокодер и должен быть уволен, чтобы это не стало ссорой а вежливо и правильно решилось увольнением говнокодера?
На ретроспективе сформулировать "я-послание". В этом спринте мне пришлось переделывать за Джорджем модальное окно, я демотивирован, и мне сложно дальше работать, потому что я считаю, что код такого качества разрушает наш продукт, а нежелание Джорджа править код меня угнетает. twitter.com/martosaur/stat…
@produnderhood Насчёт инфантилизма, шутейки это полбеды. Хуже когда человек не способен отвечать за свою итерацию работы от и до, ждёт инструкций, напоминаний и замалчивает косяки, считает личные проблемы достаточной причиной запороть сроки и часто проект.
Согласен. Вы лучше меня сформулировали проблему. Я указал внешние токсичные маркеры, а вы — ухватили самую суть. twitter.com/fromSyberia/st…
@produnderhood А откуда тезис про нежелание джорджа править код появился? Ну а в целом формулировка "пришлось переделывать за X" моментально попадает в категорию pointing fingers и противоречит blameless culture
Я старался говорить о своих чувствах. Да, вышло не идеально, ваши претензии справедливы. Предлагайте свой вариант. twitter.com/martosaur/stat…
Пятница
Тема дня: Эксперименты.
В продуктовой разработке многие любят эксперименты. Они бывают разными, но в основном говорят об А/Б-экспериментах. Что лучше конвертит — большая картинка или маленькая кнопка?
Легко сделать небольшой А/Б-эксперимент, выяснить, что кнопка конвертит лучше картинки, внедрить победивший вариант. И делать такие эксперименты часто. Наверняка ведь, сделав 100 мелких улучшений, получим один большой хороший результат. И кажется, что это data driven design.
Множество мелких экспериментов не обязательно приведут к одному большому хорошему результату. Кроме того, не у всех продукты с гигантским трафиком. У многих просто не хватит пользователей, чтобы проверять через А/Б-эксперименты любые изменения.
У некоторых продуктов А/Б-эксперименты заменяют продуктовую стратегию. Это приводит к ужасным результатам. Из-за этого я раньше презирал эксперименты. Но потом понял, что без них не обойтись. Я об этом писал в своем телеграм-канале t.me/product_prover…
— Используйте эксперименты не вместо продуктовой стратегии, а вместе с ней, для проверки.
— Не проверяйте экспериментами слишком мелкие изменения.
— Не оправдывайте экспериментами откровенную глупость и плохой UX.
На днях я рассказывал про систему целеполагания Semrush Rhythm. Т.к. мои эксперименты довольно крупные, то у меня 1 цель = 1 эксперименту. Оказалось, что удобно описывать эксперимент терминами цели:
Критерий успеха MRR >… В случае успеха мы... В случае неуспеха мы...
Мы делаем много экспериментов. Каждый эксперимент имеет подробное описание. Коллеги могут зайти и увидеть все подробности:
- Цель, описание
- Даты проведения
- Аудитория, язык
- Отслеживаемые метрики
- Критерии успеха
- Скриншоты вариантов
- Ссылка на дашборд со статистикой
Важно, чтобы в описании эксперимента появился результат. Некоторые эксперименты могут идти и месяц, а некоторые 4 (если метрика — ретеншн третьего месяца). Когда все закончится, надо не забыть зайти в описание эксперимента и добавить — выиграл он или проиграл и что делаем дальше
Если вы делаете что-то глобальное. Например, переписываете продукт на новом стеке. Тогда нет цели «сделать лучше», а есть цель «не сделать хуже». Критерий успеха такого эксперимента может звучать так: MRR экспериментальной версии не хуже, чем контрольной.
Критерием успех эксперимента могут быть не только продуктовые метрики типа MRR, ARPPU, Retention. Но и результат фидбэка. Например:
Мы получили менее 50% негативного фидбэка. При этом фидбэк прислали больше 1% пользователей.
Очень круто, когда подсчет статистики экспериментов автоматизирован. У нас все эксперименты попадают в специальную систему и на дашборде автоматически выводятся все важные метрики. Если какая-то метрика достигла статистически значимой разницы — она подсвечивается.
Автоматизация подсчета статистики экспериментов экономит много времени. А еще избавляет от ошибочных расчетов. А то скажут потом, что 50 платежей больше, чем 40, значит эксперимент победил. А что там нет статистически значимой разницы и не вспомнят :-)
Аналитик не тимошка, знает немножко.
Суббота
Тема дня: Технический долг.
Менеджмент давит на команду разработки: «Давай новые фичи быстрее, нет времени на рефакторинг». В чем-то они правы, не будет прибыли, продукт умрет. А в чем-то неправы — однажды скорость разработки упадет до нуля, а люди уволятся.
Кажется, технический долг — это дело технического директора. Я считаю, что это дело менеджера продукта. От состояния технической базы зависит скорость развития и конкурентоспособность продукта. Тот, кто это не понимает, вместо развития продукта полгода ждет пока «все перепишут».
Менеджеру продукта может показаться, что технический долг — это страшилка ленивых программистов. Вместо того, чтобы что-то полезное сделать, они хотят переписать всё на модный фреймворк. Разработчики часто не могут внятно донести ценность изменений и этим усугубляют конфликт.
Относитесь к работе с техническим долгом как к уходу за зубами. Лучше чистить их два раза в день, чем раз в два года вырывать зуб и вставлять новый. Вот краткая памятка о том, как правильно вести технический бэклог и регулярно с ним работать: t.me/product_prover…
Воскресенье
Тема дня: Кто такой менеджер продукта.
Мне кажется, что сейчас только ленивый не устраивает вебинары и не открывает курсы. Так что информацию вы найдете и сами. Давайте лучше порассуждаем, их каких профессий приходят в эту специальность.
Основные группы навыков менеджера продукта:
- Работа с требованиями: бизнес, стейкхолдеры.
- Работа с пользователями: касдев, ресечи.
- Аналитика: статистика, эксперименты.
- Дизайн: UX и UI.
- Маркетинг: раскрутка, поддержка.
- Техника: стеки, архитектура.
- Менеджмент.
Исходя из требуемых для профессии менеджера продукта навыков, можно понять, кто приходит в эту профессию:
- Не продуктовые менеджеры.
- Маркетологи.
- Разработчики.
- UX/UI-дизайнеры.
- Аналитики.
- Сейлзы.
Честно признаюсь, продуктов из аналитиков и сейлзов не встречал.
К списку выше стоит добавить «чистых продуктов» — людей, кто сразу выучился на эту профессию, а не перешел из другой. Здесь соглашусь с Илоном Маском, который сказал, что «чистые» менеджеры — не круто и гораздо лучше, когда люди сначала работают в технической не менеджерской роли
Мне профессия менеджера продукта напоминает смешанные единоборства, MMA. Там нужно уметь бить ногами и руками, бороться в стойке и партере. Спортсмены из разных видов приходят и учатся недостающим компонентам. Борцы учатся бить, боксеры — бороться и т.д.
Менеджер продукта не обязан быть крут во всех составляющих. Достаточно быть профи в паре вещей, а все остальные вещи делать «не плохо». Например, разработчики хорошо разбираются в технике, аналитике и организации труда, но им часто нужно подтянуть коммуникационные навыки.
Маркетологи по натуре своей шустрые ребята. Часто имеют ценное качество — быстро разбираться в куче вещей, не вникая глубоко в суть. Это помогает им легко входить в профессию. Их ахиллесова пята — низкий технический уровень. Исправить это возможно, просто обычно они не хотят.
UX-дизайнеры — на мой взгляд самая родственная продуктовому менеджменту профессия. Я сам перешел из нее легко и непринужденно. Но видимо я исключение из правил. Не так много юиксеров становятся продактами. А жаль.
Не продуктовым менеджерам, особенно из IT — очень легко стать продактами. По сути проджект менеджер умеет 85% того, что необходимо продакт менеджеру. Надо только перестроить мозги на новый лад и принять другие правила игры. Технически это не сложно. В реальности — не все могут.
Профессия менеджера продукта очень интересна и хорошо оплачивается. На наших курсах всего за полгода вы сможете овладеть ей и устроиться на работу в ведущие компании мира. По моему промо-коду вы получите скидку 90%. Переходи именно по моей ссылке: bit.ly/3fjf2z3
Дорогие друзья, очень приятно было провести с вами эту неделю. Спасибо за вопросы дополнения и возражения.
С теми из вас, кто подписался на мой телеграм-канал, я не прощаюсь. Будем видеться по вторникам и четвергам.
Всем чмоки в этом чате!
Я — Алексей Рытов. Менеджер продукта в Semrush и автор телеграм-канала «Притчи продуктолога». В этом мета-треде я соберу ссылки на все треды моего недельного дежурства в качестве ведущего этого коллективного твиттера.
Стратегия и тактика. Мы планируем поквартально. Три месяца — это достаточно много, чтобы сделать что-то существенное. И это достаточно мало, можно вовремя скорректировать планы. Но прежде, чем говорить о планировании квартала, я хочу прояснить вопросы стратегии и тактики.
1.1 Стратегия и тактика
twitter.com/produnderhood/…
Тема дня: Планирование квартала. Так совпало, что именно сегодня мы планируем работы на ближайшие три месяца. Расскажу об этом. Наша команда состоит из: Продукт овнер (я) UX UI 4-5. Два бэкенд разработчика (один из них тех.лид) 6-8. Три фронтенд разработчика QA
1.2 Планирование квартала
twitter.com/produnderhood/…
Мы взяли Spotify Rhythm (мы это не скрываем) и немного доработали под свои нужды. От ОКР отличается довольно сильно. twitter.com/ECalyari/statu…
1.3 О Semrush Rhythm
twitter.com/produnderhood/…
Тема дня: Спринт: планинг, груминг (PBR), стендап, ретро, демо. Уверен, для многих из вас все, что я сегодня напишу, будет звучать как прописные истины для детсадовцев. Отлично, если это так. Но для кого-то может оказаться полезным.
2.1 Встречи спринта. Груминг и планинг
twitter.com/produnderhood/…
СТЕНДАП (дэйли) — встреча на 15 минут, где каждый отвечает на вопросы: что делал, что собираюсь делать, какие есть проблемы. Проблемы не обсуждаются, а выносятся на парковку — реальную или виртуальную доску, где на стикерах записаны проблемы со стендапа.
2.2 Стендап
twitter.com/produnderhood/…
РЕТРО, ретроспектива — встреча раз в спринт, где команда может выяснить отношения и позитивно поконфликтовать. Есть много прикольных фреймворков, как проводить ретро. Но мы пользуемся самым простым: плюсы, минусы, голосование, обсуждение, решения.
2.3 Ретро
twitter.com/produnderhood/…
ДЕМО — встреча в конце спринта, где мы показываем то, что сделали в спринте. Цель — получить фидбэк от всех заинтересованных лиц. Ну и конечно же похвастаться, какие мы молодцы.
2.4 Демо
twitter.com/produnderhood/…
Тема дня: Проверка фич и статистика. Довольно частый вопрос: «Как вы проверяете фичу»? Мне кажется, что прежде всего надо проверять не каждую фичу, а продукт в целом.
3.1 О статистике в продукте
twitter.com/produnderhood/…
Итак, ответим на частый вопрос: «Как вы проверяете фичу»? Ответ: «Головой». К сожалению мне не известен универсальный алгоритм для проверки эффективности фичи. Все фичи разные, и анализировать их надо по-разному.
3.2 Проверка фичи
twitter.com/produnderhood/…
Тема дня: Плохая/хорошая команда. Плохой команду делают: непрофессионализм, инфантилизм, апатичность, лень, неправильный фокус, ссоры, боязнь конфликтов. Что-то одно у кого-то одного — уже плохо. Ниже разберем подробнее. Беру из моего личного 20-летнего опыта.
4.1 Плохая команда
twitter.com/produnderhood/…
Хорошей команду делают: профессионализм, проактивность, честность, постоянные изменения, человечность, юмор, безопасность. Разберем подробнее.
4.2 Хорошая команда
twitter.com/produnderhood/…
Тема дня: Эксперименты. В продуктовой разработке многие любят эксперименты. Они бывают разными, но в основном говорят об А/Б-экспериментах. Что лучше конвертит — большая картинка или маленькая кнопка?
5.1 Эксперименты
twitter.com/produnderhood/…
Тема дня: Технический долг. Менеджмент давит на команду разработки: «Давай новые фичи быстрее, нет времени на рефакторинг». В чем-то они правы, не будет прибыли, продукт умрет. А в чем-то неправы — однажды скорость разработки упадет до нуля, а люди уволятся.
6.1 Технический долг
twitter.com/produnderhood/…
@produnderhood 1. Только 4% вакансий упоминают технический долг. Во многих компаниях процессы настолько сосредоточены вокруг конкретного тикета что люди привыкают не высовываться и просто делать что написано
6.2 Хороший тред о техническом долге от читателя
twitter.com/SergiyOsypchuk…
Тема дня: Кто такой менеджер продукта. Мне кажется, что сейчас только ленивый не устраивает вебинары и не открывает курсы. Так что информацию вы найдете и сами. Давайте лучше порассуждаем, их каких профессий приходят в эту специальность.
7.1 Откуда берутся менеджеры продукта
twitter.com/produnderhood/…
