Как расставляет квартальные приоритеты в разработке 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%).

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

История состоит в том, что один из ивестных фондов собрал фаундеров своих портфельных стартапов и менторов, и попытался их быстро проапгредить.
Темы, которые попытались покрыть:
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/

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

Аминь )

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

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

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

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

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

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

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

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

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

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

Коллега поделился неплохим обзором общих антипаттернов по тестированию. Если вы РО/РМ, который давно работает (особенно в энтерпрайз) разработке, ничего особо нового вы не увидите. С другой стороны, иногда полезно уложить все в общую картину и вспомнить основы.

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

https://habr.com/post/358178/ - RU версия
http://blog.codepipes.com/testing/software-testing-antipatterns.html - EN оригинал

Вчера я был на замечательном воркшопе от MindTheProduct в Амстердаме.
MTP организовывают самые интересные конференции и тренинги по продакт менеджменту, две самые крупные - летом в Сан-Франциско и осенью в Лондоне; очень советую.

Я напишу о контенте и выводах, а сейчас хотел поделиться одним очень простым наблюдением. Огромная польза для РО/РМ с пост-СССР пространства состоит просто в возможности в течение дня отмериваться опытом с другими продактами со всего мира, узнавать как они решают те же проблемы, над которыми ты бьешься каждый день. Это незаменимо, особенно если вы строите продукт на глобальный рынок, или как минимум стремитесь быть специалистом топ-уровня.

Продолжение следует :)
https://www.eventbrite.com/e/product-management-essentials-102-training-workshop-amsterdam-tickets-43599757047

Customer requirements are not Product Requirements.

Да, нужно слушать customer voice. Но это лишь один из источников наравне с сейлз, маркетингом, customer success, стейкхолдерами. В сумме все это может корректировать очередность выпуска фич в вашем роадмапе, но:

1. Помните о стратегии и видении; очень, очень легко потеряться в штамповке фич, которые «все юзеры хотят и ждут».
2. Продолжение п.1: не превращайте ваш продукт в франкейнштейна из меню и настроек («мы просто сделаем это опциональным»).
3. Помните, что решение о приоритетах бэклога принимает Product Owner/Manager, а не клиент. И даже не директор департамента или член совета директоров, которому кто-то позвонил.

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

Материалы с воркшопа Mind The Product. Если у вас нет времени или лишних денег посещать такого рода воркшопы (хотя стоит найти и то, и другое!), делюсь кратким гайдом с подборкой классных отобранных материалов по продакт менеджменту. Вы можете (и должны!) быть продакт менеджерами мирового уровня, а для этого нужно учиться )
Здесь нет контента самого воркшопа, выжимки по нему я напишу позже, как и обещал.

Материалы с воркшопа Mind The Product.

Не так давно я писал о том, что вопрос WHY - главное орудие РО.
https://news.1rj.ru/str/productdev/43
Вчера мы проводили второй день тренинга по agile для всей команды и отдельное внимание уделили масштабированию на примере SAFe. Что интересно, это как эти три вопроса ложатся на уровни процесса:
1. WHY: уровень бизнеса/портфолио. Зачем мы финансируем вот эту программу в нашем портфеле, какие бизнес-задачи мы хотим решить.
2. WHAT: уровень программ/бизнес-эпиков. Что мы планируем строить, какие верхнеуровневые наборы фич можем здесь сформулировать.
3. HOW: уровень фич/скрам-команд. Как именно мы реализуем вот эту юзер-стори, какие технологии выберем, как это встроится в существующий продукт.

Естественно, здесь масса нюансов - и роль продакт-менеджера, и вовлечение архитектора, и идентификация зависимостей, внедрение Program Increment Planning и т.д., но в целом Фреймворк ещё раз подчеркивает важность умения «отпускать» - децентрализовать и давать командам свободу находить лучший способ реализации.

Какие бывают продакт-менеджеры?

- Продакт-исследователь (discovery) — фокусируется на исследовании рынка, поиске голубых океанов, трендов и инсайтов. Думает, что чем больше статистических данных, тем лучше получится продукт. Плачет после первого запуска, потому что это не так.

- Продакт-писатель [требований] — оборачивается пледиком и начинает строчить тикетули в Jira. Размеру его беклога больше, чем расстояние от Земли до Альфа-Центавра. Постоянно потеет, потому что хотелок написал много, а команда может сделать только четыре.

- Продакт-проектировщик (design) — обожает стикеры и почесать языком с потенциальными пользователями или стейкхолдерами (обратный типаж — великий гений создает своё шедевр в одиночестве). Рисует невнятные каляки-маляки, которые потом с болью превращаются командой в код. Быстро теряет интерес к продукту после MVP.

- Продакт-проджект — в его речи чаще слышны burndown chart и фокус-фактор, чем cohort analysis и коэффициент доверия. Скрамовский оунер, стремится не столько приносить ценность в продукт, сколько увеличить велосити команды. Плохо понимает, какой реальный профит принесёт то, что делает командой.

- Продакт-роадмеппер — прохвост, рисующий дороги-карты с датами. Когда выпуск фичи не попадает в дату, находится тысяча причин, почему его сбалансировано-построенный роадмеп правильный, а другие — нет. Любит говорить о том, как текущее корыто превратится в космический корабль. Не очень понимает, когда это все же наступит.

- Продакт-продажник — любит костюмы и очки с деревянными дужками. Ездит по пресейлам, продавая клиентам ожидания. Для команды использует только два приоритета: СРОЧНО и ВНЕЗАПНО. Уверен, что продукт должен делать деньги, а не ценность. Внедряет всё, что просят крупные и не очень клиенты, лишь бы их удержать.

- Продакт-маркетинг — умеет пользоваться Яндекс.Метрикой и скакалкой. Меряет конверсию продукта во всё, что угодно. Подготавливает рассылки, рекламу и флаеры. Любит писать фельетоны про «уникальный продукт» и «новое качество жизни». Сидит в твиттере и фейсбуке через телеграм на iwatch.

- Продакт-аналитик данных — знает, как считать когорты при помощи куба и сводных таблиц. Различает среднее от медианы. Слышал про моду и статистическую значимость. Любит навешивать цели на всё, что попадется под руку. Когда говорит и показывает графики с сияющими глазами, никто ничего не понимает, но все кивают. Впадает в аналитический паралич чуть менее, чем постоянно.

- Продакт-руководитель — любит водить руками в стороны, создавая муссоны. Ничего не умеет делать, кроме «синхронизировать» других для разработки продукта. Илита, кормящая своим продуктовым молоком личинок продактов. В резюме пишет, что делает в год по сто продуктов. Не человек — конвейер!

- Продакт-евангелист — спит в поездах за деньги компании. Когда бодрствует, говорит ртом в толпу на разных вписках. Вместо обоев дома клеит бейджики с конференций. Придумывает фичи, пока вещает. Забывает, что они еще не реализованы. Уверен, что его компания лидер рынка. Знает, куда этот рынок придет через 20 лет. Не знает, что выдаст команда через неделю.

- Продакт-блоггер — пишет обо всякой херне. Устраивает конкурсы. Каждое второе предложение начинает со фразы «Меня часто спрашивают…».

(Каждый может узнать себя в те или иные моменты 🙂 Источник: http://sergeytikhomirov.ru/vvedenie-v-produktovyj-menedzhment/)

Мой друг и тоже продакт Паша Педенко из MacPaw отправился в рабочий кругосветный трип (СФ, Гонконг и Шанхай это лишь некоторые из его остановок) и обещал попутно делиться увиденным и услышанным, в частности с Mind the Product (самая крупная конференция по продакт-менеджменту)🚀🚀🚀

Не могу держать это в себе, будем вместе следить, тем более многие из вас тоже знают Пашу:

https://news.1rj.ru/str/PavloIsOnTheRoad

Сегодня ровно неделя, как у нас начался первый двухмесячный Release Train - синхронный для всех команд инкремент, который планируется в рамках SAFe методологии. SAFe - это один из способов масштабировать agile/scrum, позволяющий управлять разработкой в условиях множества команд, получая прогнозируемый инкремент и даже попадание в майлстуны роадмапа.
https://www.scaledagileframework.com/why-safe/

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

Типичное расписание:
1. Первый час:
- Кик-офф по общей концепции мероприятия от хэд оф инжиниринг
- Вводная от продакт-менеджера по роадмапу и целям
- Краткие (5 мин) оверьвью от каждого РО по их планам.
- Лид архитектор по изменениям в архитектуру на этот период.
- Наставление по процессам и лучшим практикам.

2. Два часа команды работают каждый в своей локации, перенося уже запланированные эпики на общий борд с индикацией блокеров от других команд.

3. Краткая презентация результатов ИЛИ синк между скрам-мастерами в случае, если команды хорошо разогнались и вы видите, что грешно останавливать это (в нашем случае было именно так).

4. Еще несколько часов для финализации планирования по всем 4 спринтам внутри периода. Переговоры между командами у программной доски, финализация договоренностей, устранение блокеров.

5. Презентация с участием всех команд и приглашенных стейкхолдеров (маркетинг, саппорт и тп).

В итоге - разложенный по спринтам эклог с учетом всех командных зависимостей, майлстунами доставки недостающих требований и дизайна, релиз-план, критические точки для контроля прогресса по роадмапу.

Пока нравится 🙂

Был сегодня на продуктовом митапе. Со сцены слышал:
- как вы валидируете гипотезы в своих продуктах?
- ну просто запускаем фичу в прод и смотрим что получится.
Задумался 😭😭

О стейкхолдер-менеджменте.

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

Неожиданно, эта запись немного о другом :)

Когда вы работаете в не очень большой компании, особенно на ранней стадии продукта в стартапе, вы оказываетесь в ситуации, когда 90% веса сиейкхолдеров оказывается на вашем фаундере/СЕО.

Здесь есть три основных модели поведения.

1. Bad PO. Неопытный человек просто смиряется с тем, что этот пиздец никогда не закончится, записывает противоречивые требования под диктовку, кое-как их реализует, не особо мотивируя команду (зачем, если завтра все поменяется?), и так влачит своё существование от ЗП к ЗП с перерывами на фейсбук и плейстейшн.

2. Good PO. Опытный человек знает, что никто ничего не знает до того, как это протестировано/запущено, и вступает в неравный, но очень красочный бой с фаундером (иногда очень скоротечный). Вся команда запасается попкорном и начинает ходить на ранее скучные встречи, поскольку пиздец набирает фееричного размаха. В ход идут метрики против интуиции, юзер-тестинг против быстрого запуска говно-мвп в прод, необходимость закрытия техдолга против нагромождения новых киллер-фич, реализация своего роадмапа против копирования функционала новопоявившегося конкурента. Если такой РО/РМ обладает ещё и какими-то софт-скиллами типа грамотных переговоров или способности идти на здоровые компромиссы (сегодня я тебе, завтра ты мне), то у него даже может что-то получиться.

3. Great PO. Иногда человек оказывается в ситуации, когда его фаундер очевидно и объективно один из лучших экспертов в мире в своём домене (with proven track record, как говорится). И иногда нужно вовремя заметить своё горячее желание всю эту «дилетантскую» вакханалию остановить и вместо этого остановить себя. Никто не знает, как будет правильно, и вы в том числе. И тогда, в духе better done than perfect, ваша задача просто включить режим самурая и постараться максимально грамотно и быстро воплотить вижн своего фаундера вместо потери времени на бесполезные сражения. Не забивая на метрики, не спустив рукава, а именно максимально грамотно и идеально. Сделать из этого лучшую версию того, что можно сделать. И уже в процессе, имея первые shitty mvp в проде, имея живые данные, аргументировать, улучшать, и делать это вместе против рынка, а не друг против друга. Таков путь продакта-самурая 😂🥋⚔️

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

P.S. Подставьте вместо слов «фаундер» слова «совет директоров», «хэд оф продакт» и тд, все остаётся валидно.

"Если продакт не отвечает за деньги, то он не продакт, а проджект (т.е. просто отвечает за сроки доставки фич).

Деньги это валидация ценности. Пользователь сталкивается с продуктом, и он платит за велью или нет (это показатель того, есть ли велью у продукта). Не очень точная, но очень честная.

Чем больше ценности ты даешь, тем лучше конверсия, тем выше ARPU”.

Недавно Аня в @proproduct опубликовала интересное интервью с Ильей Красинским, сильно советую посмотреть: https://youtu.be/w_TJSWxY5vw
Если нет времени - ниже в вольной форме еще несколько заметок и цитат:

У людей нет метрик, у них есть сценарии. За последние три тысячи лет они не сильно поменялись. Они что-то ищут, появляется триггер, который запускает какой-то сценарий, который они хотят выполнить.

У нас нет контроля над кошельком клиента. Мы работаем над продуктовыми метриками. Мы не работаем с теми, кто купил. Мы больше работаем над теми людьми, кто НЕ купил - чтоб они купили. Пытаемся влиять на их поведение косвенно, чтоб в итоге купили.

“Помнишь, как появились в Яндексе продакты? Было много проджектов, потом вдруг стало модным быть продактом. Потому сначала все стали продакт овнерами, это пришло из скрима, а потом на линкедине поменяли себе это на продакт менеджеров. Теперь ты продакт менеджер, будешь отвечать за сроки, говорили они”.

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

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

Если ты работаешь через проверку гипотез, ты 50% времени тратишь на то чтоб родить годную для проверки боем гипотезу, а команда тем временем имеет время закрыть техдолг. Потом ты приходишь и говоришь “давайте вот это сделаем, это все равно конечно придется переделывать потом, но мы по крайней мере сделаем это дешево. И мы не пилим весь наш архипелаг, и если не сработало - выкинули”.

Задавать себе вопрос: Где точки роста в этой компании?

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

Churn rate - метрика не actionable. Ты на нее смотришь и плачешь.

Аналитика головного мозга. “Как-то я сидел высчитывал кривую эластичности спроса. Провел кучу тестов, нашел математически правильные цифры. Через три месяца пришел собственник и сказал: давай повысим цены в два раза. Я ему час читал лекцию о том, как это нельзя делать, но потом сдался. Мы повысили цены в два раза, и увеличили доход в два раза. Теперь я сторонник дешевых экспериментов. Разведка боем”.

Важно, чтоб команды параллельно занимались и кратным ростом (основные фичи, точки роста), и локальными оптимизациями (напр, команда маркетинга тюнит регистрацию).

Точки роста обожают смещаться в зону некомпетентности команды.

Дашборды показывают цифры, которые ты и так знаешь, а проблемы скапливаются в тех цифрах, о которых ты не подозреваешь.

Ты не можешь три метрики считать, а две не считать. Тебе нужна целостная система метрик, чтоб ставить диагностику.

Людям нравятся красивые штучки в UI, которые ничего на самом деле не стоят в разработке - картинка, простая анимация. "Я стараюсь в каждую итерацию одну такую штучку добавлять”.

С какого-то момента больше нельзя учиться по книгам, потому что для тебя книги еще не написаны. Чтобы развиваться дальше, можно преподавать самому, заниматься консалтингом, работать с сильными людьми. Так тренироваться.