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

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

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

Как начать делать Customer Development

Кратенькое видео по Customer Development от Ивана Замесина из Яндекса: https://youtu.be/_4r4E8--SAU
(можно смотреть первые 18 минут)

Саммари по видео ниже.

Кастдев не делаешь, потому что:
1. Комфортно находиться в своей ситуации, сидеть и пилить продукт тихонько. Никто не критикует, все спокойно.
2. Нужно общаться с незнакомыми людьми и это напряжно.
3. Можно пропустить и по шапке от начальства не получишь (в отличие если дизайн не дашь вовремя на аппрув).
4. Нет пока еще культуры что это мастхэв часть процесса

Как начать делать:
1. Почувствовать, что это очень хорошо - быстро проверил идею и гипотезу, и сразу больше уверенности что то что ты выпустишь через полгода, будет хорошим. Но здесь позитивный фидбек далеко, отложен. Это не мотивирует.
2. Сказать руководителю: “Мне нужно делать интервью на каждом этапе, пинай меня если я не буду этого делать”. Он будет пинать и это стимул.
3. Прийти к состоянию, что это быстро и прикольно. Тогда нет барьеров.

Как разговаривать с людьми:
1. Прочесть Mom’s Test (тоже советую мастхэв, особенно если вы пилите стартап, или собираетесь - отнеситесь к ней ОЧЕНЬ серьезно).
2. Непринужденный разговор. Иметь в голове сценарий, и подстраивать его под собеседника, но не допрашивать и не “анкетировать”.
3. Просить инвестиции, совета, пиар и т.д. Просто фидбек “все круто” без инвестиций с его стороны (в любом виде) это ничего не значит. Например: “напиши прямо сейчас в ФБ что тебе понравилась вот такая игра”.
4. Тупо постоянно приглашать юзера каждый день в офис, и у любого есть возможность с ним поговорить (без адженды). Это стимулирует не упустить возможность.
5. Как можно раньше идти в поля (вначале вы достанете всех ближних и коллег, и они начнут морозиться, и вам таки придется идти в поля).
6. Делать интервью в соцсетях и мессенджерах. Это тоже снижает барьер и морально легче, чем вживую, тем более знакомиться с настоящими незнакомыми людьми.


Итог: Даже очень плохой кастдев лучше чем никакого. Не бойтесь своих юзеров!

Кто-то из знакомых написал, что вводит у себя OKR, и я вспомнил что как-то делал краткое саммари методики для всех, кто заинтересован в Objectives & Key Results

Objectives and Key Results  - методология постановки целей от Google, которая учитывает острую потребность гармонизировать потребности/стратегию организации и личные цели/амбиции каждого сотрудника.

Этот тот случай, когда, казалось бы, неподъемная задача по синхронизации фокуса и направления усилий всей компании делается через ОЧЕНЬ простую методологию, с понятными шагами и критериями оценки.

5-минутный обзор 80-минутного воркшопа  - ниже по ссылке. Автор воркшопа для портфельных компаний Гугла - бывший продакт-менеджер blogger.com (третий по траффику бизнес Google), а сейчас - партнер в GV (Google Ventures).

Также в русскоязычном саммари видео есть ссылки на дополнительные ресурсы по теме, включая внутренюю методичку Google для новых сотрудников, и, собственно, оригинал видео для фанатов.

https://medium.com/@mishanestor/objectives-and-key-results-методология-постановки-целей-от-google-aa3cba5e763b

О важности опыта в бизнесе, продажах и маркетинге для продакт-менеджмента

1. Продакт, который не продавал, не занимался биздевом, на худой конец не делал свой стартап или более-менее успешный пэт-проект, наверное все же проджект. В лучшем случае он скрам-РО, умеющий хорошо работать с командами и даже непрямое лидерство, но этот пробел в бизнесе очень сложно восполнить.
2. Продукт - это не набор запиленных фич, а ценность, которую покупают. Как вы продуктом “уговариваете” юзеров купить (в любом виде, например хорошо ритейниться) ваш продукт?
3. Если нет опыта в маркетинге, будет очень сложно координироваться с продакт-маркетингом. Маркетинг это не просто налив трафа, который может жить плюс-минус отдельно от продакт-девеломента (хотя в части форм регистраций, главной, навигации, онбординга пересечение все равно огромное). Весь контент, что в постах и на баннерах, что в PR -статьях и на вашем блоге, - это не отдельные вещи, это все может решать ваши продуктовые задачи.
4. Задача продукта - успешный продукт, простите за банальность. Успешный продукт - это хорошие метрики, позволяющие поднимать деньги у VC, монетизироваться косвенно за счет рекламы или данных, или же прямая конверсия в платящих пользователей (клиентов если вы В2В, без разницы). И на эти метрики и конверсии влияет не только UI/UX, над которым мы с вами трудимся.
5. Некоторые думают, что вот там маркетинг, сейлзы и саппорт, все это от меня не зависит, я буду с командой воплощать роадмап. Но это не продакт-менджмент. Это обычная проектная деятельность, просто такая катастрофа в слоу-моу для продуктовой компании. Фича в проде - done, отлично. Взялись за следующую, ведь дедлайны, релизы, наседают со всех сторон. На самом деле - что с ней дальше, как она повлияла на метрики, как она была запущена, как оттренированы сейлзы, какие материалы вы подготовили для саппорта, что с вашими FAQ, какой контент готовят (или не готовит:) ) ваши райтеры в маркетинге или медиа и тд - это ваша прямая обязанность. Не делать, но давать инпуты и следить за результатами, в т.ч. качественным содержанием.
6. Коллега недавно напомнил о классическом описании РО, там есть фраза о том, что “потому что все остальным пофиг”. Продакт должен помнить, откуда его профессия вообще появилась (хинт: появилась она в P&G d 1931 году, покорила FMCG поначалу, и сейчас известна под названием бренд-менеджер - человек которого беспокоит все, от упаковки и биллбордов до отношений с властями и регуляторами (кому интересна история: https://www.mindtheproduct.com/2015/10/history-evolution-product-management/).
7. Любая надежда, что все ваши любовно сделанные фичи будут идеально донесены и проданы без вашего вмешательства - опасная иллюзия.

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

Что делать, если вам (пока еще) не повезло.

1. Если вы в В2В - ездить на пре-сейлы и переговоры, присоединяться к звонкам, работать с customer success (“а вот это наш продакт-менеджер, который и делает наш замечательный продукт; он будет очень рад ответить на ваши вопросы… Эй, куда это ты побежал?..”)
2. Тренировать support / customer success / аккаунтов - вы узнаете много чего интересного, плюс научитесь отвечать на неудобные вопросы.
3. Пойти поучиться digital-маркетингу, желательно вживую и с живыми преподавателями-практиками (внимательно читайте биографии, наличие длинного списка преподавания и менторства в акселераторах и хакатонах не значит, что человеки имеют реальный опыт бизнеса). Это стоит вашего времени.
4. Имея хоть какое-то теоретическое понимание (кроме курсов можно много-много читать о том, как строятся воронки продаж в В2В (чем отличаются хантеры от фармеров? что такое MQL?), что такое growth marketing/hacking в стартапах, как работает контент-маркетинг/инбаунд и т.д.), приходите к вашим коллегам из других департаментов и предлагайте свое тело в помощь или же попытайтесь вместе проработать как вы запустите следующую фичу, или же измените подход к продажам продукта с вот этим новым долгожданным функционалом.
5. Банальные, но действенные способы - свой маленький проект (даже если это принесет вам 100 уе, даже если это не софт а простой e-commerce на шопифай/тильде) или же вписаться кому-то помогать с их бизнесом/идеей (поверьте вокруг масса желающих вцепиться своими щупальцами в ваш мозг).
6. Экстрим-вариант - поменять вашу более-менее понятную прибыльную компанию со стабильными ЗП и корп политиками и прыгнуть в чужой стартап продактом на этапе когда там до 20 чел и только прилетел seed (ну чтоб вам хоть было на чем учиться).
7. Супер-экстрим-вариант: зажмуриться и прыгнуть в свой стартап. Пара-тройка лет, половина седых волос, и вы уже знаете что почем в этом мире 🙂 Если вас не затянет предпринимательство (если затянет - значит, вы маньяк, потому что супер-хорошо на этом этапе у вас еще не будет), то вы придете кому-то приносить пользу, имея намного больше опыта во всех аспектах функционирования продуктовой софтверной компании.

Это, конечно, очень все кратко, можно неделями говорить о каждом пункте, но идея должна быть понятна 🙂

Ну и если вы вдруг имеете опыт во всем вышеперечисленном, но не работаете продактом - стоит об этом задуматься 😉 Но это другая история, с другими проблемами и вызовами.