Product owner - это сочный, мощный чувак, который поднимет баблишко твоего нищего проекта

твой лучший Product owner - это я! 

Евгений Коврижин 

 

- Product Owner уже 13 лет

 

- Лучшие в мире Soft Skills

 

- Кандидат экономических наук

 

- Адекватный

 

- Более 500 проведенных экспериментов на баблишко

SEO текст про 5 направлений работы Product Owner. Я устал его писать.

Ты гадкий утенок, хочешь стать прекрасным IT-лебедем с ежегодным кратным ростом LTV? Познай слабость своей парадигмы мышления. Представь, digital контора едет на пляж в двухъярусном золотом автобусе. Сотрудники хотят успеть занять топовые места, но лузеры ползут слишком медленно. Тут мимо проносится спорткар, внутри безбашенная молодежь. Эти ребята доберутся до цели первыми, по-любому! WHY?! Пассажиры автобуса вроде как умнее, денег у них больше, связи круче, почему тогда ситуация help? Да дело в том, что водитель спорткара - product owner, владеющий искусством зарабатывать деньги, баблишко, money. Если бы владельцы автобуса допетрили хоть немного поучиться таким вещам, то круто бы ускорились, а еще увидели другой пляж в противоположном направлении, о котором мало кто знает. Причем больше, чище и гораздо ближе.

Product owner and аналитика

«Цыплят по осени считают»

Что такое аналитика? Нужно ли вообще product owner в ней разбираться? Скажем так, отдельный специалист аналитик умеет гораздо больше, такая профессия. Популярно мнение, будто аналитики – занудные data driven ребята, перебирающие сводные таблицы ексель, постоянно бубнящие фразы типа «Ну однозначно тут ничего утверждать нельзя». Но от этой работы зависит успех проекта. Конечно, если ты настолько крут, что ты и прошаренный аналитик, и PO в одном лице, то тебя бы с руками и ногами оторвать в крупный брендовый проект, но вряд ли ты такой. Так что постарайся найти крутого аналитика, построй с ним любовь и вместе вы будете четко тащить LTV.

 

У Нормального product owner развито продуктовое видение проекта - он чует одним местом, где деньги лежат. Однако, если ты не знаешь базовых аналитических вещей, то взаимодействие внутри команды будут напоминать общение слепого с глухим. Пойди и погугли, что такое меры центральной тенденции, изменчивости (мода, среднее арифметическое, медиана, дисперсия). Почитай умных людей, зачем нужны A/B тесты, какие условия обязательны для полноценного сплит-тестирования. Заодно можно глубже изучить тему достоверности и случайных событий. Грамотный product owner знает, что перед едой рекомендуют мыть руки, а перед запуском эксперимента – считать sample size. Но если ты совсем ленивый  или просто не догоняешь, напиши мне в телеге.

 

Профессиональный продакт мыслит категориями когорт. Зачем нужен когортный анализ? Ты узнаешь это после проведения серии экспериментов и построения НЕвалидных выводов по ним. Поэтому лучше изучить тему заранее, чтобы потом не облажаться перед коллегами. Ну и куда же мы без основ гугл аналитики (каналы, источники, события, сегменты, пути по сайту).

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

Product owner and пиратские метрики

«И швец, и жнец, и на дуде игрец»

Жизнь product owner становится веселее, как только выясняется, что для поиска клада расчехляют пиратские метрики или AAARRRR воронку. Раньше PO копал одну яму, надеясь отыскать баблишко, а теперь понимает, вокруг поле непаханое. Куда ни пойди, везде рост LTV. Теперь остается сделать из воронки трубу, расширив узкие места.

 

Верхнеуровневый этап воронки «Информирование» – первый шаг взаимодействия с пользователями. Product owner надрывно кричит: «Мы существуем!». Можно при этом раздавать буклетики, вешать хайповый баннер или запилить четкий сайт, оптимизированный под поисковые запросы.

 

На этапе «Привлечение» происходит идентификация пользователя. Главный смысл – забрать контакт, будущую точку взаимодействия (почта, телефон, запомнить внешность). Подумайте, почему online-сервисы настойчиво просят подписаться на пуш-уведомления? Там работает этот надоедливый product owner!

 

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

 

Этап «Доход» поднимает вопрос «Где деньги, Зин?». Это любимая пиратская метрика у product owner. Ответ лежит в сумме LTV + CAC. Когда пользователь за сто лет жизни приносит больше, чем на него потратили – радость, в противном случае – печаль. Вот ряд примеров, какие модели можно здесь использовать: триал, подписка, одноразовые платежи, контракт, баннеры, почасовая оплата, контекстная реклама, фримиум, донаты, % от сделки, ретаргетинг, показы видео, кредит, арбитраж трафика, патенты, лицензии, аукцион, венчур, шантаж).

 

«Ретеншн» – показатель возвращаемости когорты, которая впервые совершила целевое действие. Топовые среди аналитиков – «rolling retention» (характеризует сам факт возвращения), «classic retention» (характеризует частоту возвращения). Допустим, вы директор магазина «у дома». Здесь лучше учитывать «classic retention», потому что на доход магазина влияет частота возвращения когорты. Показатель rolling retention 100% становится непрактичным, если вчерашние посетители вернутся только через год. Другое дело – рынок торговли коттеджами, где клиенты возвращаются максимум три раза за 50 лет.

 

Некоторые удачливые стартапы становились востребованными, а затем продавались (американцам) за миллионы долларов благодаря «виральности». Тайный смысл этого явления - сколько новых людей приведут других новых людей. Получается относительно-бесплатное привлечение трафика. Возникает вопрос, способен ли неопытный product owner поднять коэффициент виральности. Классическая ситуация - один новый человек приводит X новых людей, где X составляет 0,00000… Как только коэффициент становится больше 1, слухи о проекте, словно коронавирус, быстро заполоняют планету. Реализовать трудно, но достижимо.

 

Какие бы пиратские метрики не шатал product owner, придется генерировать гипотезы. Продуктовая гипотеза – обоснованное рискованное предположение, которое можно проверить с помощью эксперимента. Популярное определение - «предположение, которое надо доказать». Подобная урезанная интерпретация скрывает смысл процесса. Если громко заявить команде «Ребята, есть классная тема!», то это не гипотеза. Но стоит только дополнить: «Конкуренты зарелизили мощное решение!», появляется обоснование. Рискованность тоже упоминается не зря, ведь нерискованные предположения нет смысла проверять, тратить ресурсы (например, «ударю себя молотком, будет больно»). Проверка гипотезы экспериментом тоже обязательна. Скажем, нельзя протестировать предположение «Если ребенок будет ходить в эту конкретную школу, то знаний там получит больше». Еще не научились параллельно проверять две судьбы ребенка.

 

Product owner and процесс

«Дорога даже в ухабах лучше бездорожья»

Наверное, даже юный product owner слышал об agile, scrum, kanban. Эту тему уже давно обсосали сотни авторов. Изучив литературу, придет внезапный вывод: "пора браться за ум". Учитывай самую популярную ошибку, когда проекты внедряют скрам ради скрама или канбан ради канбана. Чтобы эти методики работали, надо без фальши проникнуться философией agile. Когда тут крутой agile, а там ругается «начальник», не соглашаясь менять план проекта под новые рыночные условия, то ситуация слабо напоминает agile.

 

Проще обстоят дела относительно подготовки user-story, критериев приемки и готовности. Тут каждый product owner сам себе эксперт, подгоняет шаблоны под персональные цели. В IT-мире практикуется принцип написания "INVEST". Согласно методике, user-story делают независимой, обсуждаемой, ценностной для заказчика, оцениваемой, маленькой, тестируемой. Эти рекомендации разработаны опытными людьми, поэтому стоит к ним прислушаться, хуже не будет.

 

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

Product owner and построение продукта

«Курочка по зернышку клюет, а сыта бывает»

Product owner - это чувак, который часто говорит «Нет» и должен постоянно задавать себе вопрос «Чтобы что?». Главный момент перед началом работы – докопаться до сути, зачем начинать работу. А вдруг необходимые материалы для проверки гипотезы уже найдены или возможен альтернативный способ тестирования. Например, захотелось парню делать планку 20 минут каждый день для якобы бодрого настроения. Но стоит только провести касдев, как сразу выяснится, он мечтает понравиться конкретной девушке. Тогда возникает альтернативный путь, подарить цветы и пригласить в кино. Такой подход займет гораздо меньше сил, а результат тот же. Но это не точно…

 

Прошаренный product owner регулярно использует слово «MVP». Так проверяются риски:

  • Первичное построение воронки, анализ спроса и предложения. А как выглядит наша воронка?
  • Проверка гипотезы минимальными костами. Не надо пилить фичи! Предположим, дать объявление на авито, можно ли тогда проверить гипотезу «мои услуги кому-то нужны»?
  • Обязательная сегментация. Да, воронка лендинга показала, конверсия в оставление контакта составила 5%, а хочется 35%. Погодите-ка… У пенсионеров показатель 50%! 
  • Перспективы масштабирования, потолок дохода. Классно, MVP демонстрирует ожидаемый результат. Вот только бизнес из этого сделать сложно, там трафика мало.
  • Потенциал сходимости экономики. Так, конверсия составила 5%, а надо 35%. Если улучшить конверсию рекламного объявления на 100 процентов, лить теплый трафик, а также поколдовать над лендингом, то максимум получится 60%. Стоит ли этим заниматься – вопрос.

Цикличность процесса проверки гипотез или HADI-цикл тоже формирует скорость роста. Product owner генерит обоснованные предположения из выводов предыдущей гипотезы. Скорость движения к цели связана со скоростью обнаружения новых знаний, а не только с методами ускорения конкретного теста. Поэтому product owner старается пускать вперед те эксперименты, которые принесут больше полезной информации. И денег.

 

Куда начинать двигаться, когда в беклоге 100500 гипотез? Если проект страдает «бутылочным горлышком» (лимитированное число программистов), то надо такое слабое место защищать. Иными словами, нужна приоритезация по методам ICE, RICE или Кано. Тут важно помнить, при одинаковом ROI этих гипотез приоритет теряет значение.

 

Некоторые product owner свято верят в силу скоринга. Допустим, после группового синка появились гипотезы на 10, 20,40, 60, 70, 80 условных единиц. Кажется, что первой по приоритету зайдет задача с оценкой 80. Но такая градация призвана разделить группы крутых, средних, слабых задач. С какой начать, 70 или 80, решает только product owner.

Product owner and монетизация

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

 

Забравшись на середину горы, ты мечтаешь о золотой вершине. Внезапно замечаеншь соседнюю вершину, там золота гораздо больше. Теперь обязательно спускаться вниз и лезть на соседнюю гору?

 

Эти вопросы анализирует product owner, руководствуясь unit-экономикой, препарированием составных частей дохода бизнеса. Удивительно, но некоторые проекты годами бьются над монетизацией, пытаясь увеличить доход на 10, 20 или даже 40%. Правильный подход к наращиванию капитала открывает перспективы кратного роста.

 

Часть product owner утверждает, по началу развития проекта рост уверенный, потому что понятно, куда развиваться. Со временем темпы снижаются. Логично, ведь заканчиваются очевидные гипотезы. Но это заблуждение. Такие ограничения возникают из-за отсутствия знаний. Применив Growth Hacking, яснее начинаешь понимать узкость предыдущего метода работы.

«Деньги счет любят»