Архив недели
Понедельник
О чем поговорим на этой неделе (18-24):
День 1: Юзер интервью - с чего начатьДень 2: Аналитика - куда смотреть и что проверятьДень 3: Приоритизация
День 4: Создание роадмапы
День 5: MVP с нуля или в рамках готового продукта
День 6: Мульти-культи команды
День 7: Мотивация
В двух словах о себе: начала с Продакт менеджмента в продуктовой компании, перешла в Проджекты в аутсорсе, там же попробовала роль Бизнес Аналитика. Остановила выбор на Продукте. Около 2х лет назад переехала в Берлин, где работаю Продакт менеджером в компании Blacklane.
День 1. Представьте, что у вас 1й день в роли Продукта в новом Стартапе. Вы тестите продукт, изучаете данные и аудиторию. На этом этапе вы понимаете, что о юзерах известно мало, и вам нужно собрать больше информации.
Вариантов это сделать предостаточно: юзер интервью, фокус группы, опросники и т.д. Но с чего начать?
Для начала нужно понять на каком этапе находится ваш продукт. Стандартные этапы для стартапа:
- problem/need fit - выясняем актуальность проблемы, которую решаем;
- market fit - выясняем ценность на рынке предложенного продукта;
- scale - продукт активно наращивает аудиторию.
Детали отлично описаны в книге Running lean, автор Ash Maurya
Кстати, на каком этапе находится ваша компания?
На этапе “problem/need fit“ мы практикуем Problem interview. Никаких фокус групп или опросников.
Как вариант можно запостить проблему на Лендинг странице, как блог пост или как пробную Google/Facebook рекламу. C тайтлом в стиле “How do you handle challenges with ride hailing today?“
Аудиторию можно так же искать на Craiglist, в Facebook группах, Twitter, Pinterest, Amazon Mechnical turk (платно).
В процессе Problem interview важно понять:
- Какую проблемы ты решаешь?
- Кто/что составляет конкуренцию (текущие альтернативы)
- У кого встречаются эти проблемы (сегмент)
Типичный скрипт Problem interview:
- Собрать данные о юзере
- Описать контекст проблемы
- Собрать мнение аудитории
- Понять насколько серьезная проблема
Описать контекст проблемы можно по методу "Jobs to be done", когда ты пытаешься понять какие действия/задачи юзер пытается решить. Статься об этом: jobs-to-be-done.com/jobs-to-be-don…
На этапе “market fit” мы практикуем Solution interview.
- Как мы будем привлекать первых пользователей?
- Какой набор функционала необходим?
- Готовы ли пользователи платить на решение?
- Какую цену они готовы платить?
Типичный скрипт Solution interview имеет следующий скрипт:
- Собрать данные о юзере
- Описать контекст проблемы
- Предложить попробовать решение
- Понять готов ли юзер заплатить за решение
Если компания планирует начать релиз продукта в конкретной локации либо для конкретного сегмента, то здесь помогут фокус группы. Facebook, Linkedin, Twitter удобный для поиска аудитории. С ними можно работать в формате опросников.
Когда продукт доходит до этапа Scale или давно не стартап, тут уже все методы хороши. Те же опросы (customer satisfaction, survey), юзабилити тесты для выделения пользовательских привычек, под-сегментов, вторичных проблем.
Например для Twitter, аудиторию можно поделить на Influencers, Updaters, Sharers, Catch-ups. Для каждого из этих сегментов набор функционала будет сильно отличаться.
Поэтому тут важно сегментировать аудиторию и смотреть за тем как используется продукт. Для этого можно попробовать Discovery interview, где ты задаешь открытые вопросы и собираешь информацию по каждому сегменту.
Советую книгу Hooked: How To Build Habit-Forming Products, автор Nil Eyal, где описан подход к тому как выявлять привычки и создавать продукты, которые вызывают зависимость.
Как происходит организация интервью. Для начала мы формируем цели, скрипт, вознаграждение и готовим имелй рассылку либо звоним юзерам. Примерно 10% соглашаются на интверью (зависит от аудитории и отрасли).
Для брони времени пользуемся Calendly. Юзер может выбрать подходящее время из доступных вариантов, и событие автоматически создается в календаре. Так же можно настроить напоминалку.
Интервью проводят обычно 2 человека: один задает вопросы, второй делает заметки. Так легче сфокусироваться.
В конце мы предлагает ваучер на пользование нашим сервисом либо Amazon gift cards.
При каждом новом интервью мы опрашиваем разных пользователей, чтоб не привязываться одной и той же аудитории.
В среднем, времени хватает на 2-3 интервью по 10 человек в год. БОльшая часть времени уходит на обработку и презентацию результатов интервью.
Вот результат презентации с после проведения Discovery interview: docs.google.com/presentation/d…
Вторник
День 2. Многие компании пытаются удержать фокус и сформировать одну метрику, которая приносит основную ценность рынку - Northern star metic. Например:
Airbnb: Nights Booked
YouTube - Minutes watched
Помимо этого компания обычно формирует квартальные цели OKRs (felipecastro.com/en/okr/what-is…) со своим списком ключевых результатов KPIs (key performance indicators).
Важно упомянуть что разница между KPI и метриками, в том что первый указывает ключевой бизнес результат (топ метрика), а второй меряет подзадачи, которые в конечном итоге приведут к KPI.
Пример KPI: Средние продажи на пользователя выросли на 100% (c 2х до 4х). Метрикой может быть - объем продаж, кол-во пользователей.
Для того чтобы связать Northern star и KPI можно декомпозировать оба показателя и найти точки соприкосновения. На этой метрике и стоит фокусироваться. На эту тему отличная статья: linkedin.com/pulse/three-tr….
Про то как декомпозировать показатели или ключевые результаты на метрики отлично отписано с примерами компанией Optimizely: help.optimizely.com/Ideate_and_Hyp…
Кстати про Optimizely, мы используем сервис для A/B тестов на сайте. Удобно то, что ты сам можешь создать тест и добавить верстку с помощью их snippet без помощи инженеров.
У нас в компании Продакты используют несколько источников анализа данных:
- Redash + Реплику баз данных;
- Mixpanel;
- Firebase;
- Google analytics;
- Tabelau.
Ниже распишу каждый из пунктов.
Redash.io - удобный и бесплатный интерфейс, к которому можно легко подключить несколько дата сорсов и добавить визуализацию. Он удобен еще тем, что можно настроить обновление данных каждые 5 минут.
Mixpanel - используем для анализа данных мобильного приложения. Тула очень мощная и позволяет анализировать A/B тесты, строить воронки, считать retention, а так же строить прогнозы. Цена зависит от количества датапоинтов, которые трекам.
Firebase - используем для запуска A/B тестов в мобильных приложения (remote config). А так же используем как вспомогательную тулу для анализа данных. Firebase дешевле выходит чем Mixpanel, но визуализации мало.
Google analytics - используем для анализа данных с сайта, строим воронки, изучаем просмотры страниц и трафик.
Tableau - использует BI для визуализации всех выше пересиленных источников данных и A/B тестов. Мне лично тяжело работать с Tableua, так как изменить либо добавить новый дата сорс это большая проблема. В результате сам кастомные репорты не построишь.
Добавлю еще, что просто изучаю данные напрямую с базы данных: проверяю свои гипотезы, ищу закономерности. SQL очень помогает + бесплатная тула Jupyter Notebook для импорта данных (удобно, если нужен доступ к нескольким базам данных).
Теперь поговорим о A/B тестах. До запуска любого теста нужно определить метрики и указать ивенты, которые нужно будет трекать в процессе эксперимента.
Важно определить основную Primary metric и вторичную Secondary metric. Типичная ошибка - мерять например конверсию как primary, даже если между вашим экспериментом и конверсией юзеру нужно пройти 5 страниц.
Например вы изменили кнопку "добавить в корзину" и хотите понять влияние на конверсию. Основная метрика - клики на кнопку, а вторичная - конверсия. Если вдруг кликов больше, а конверсия без изменений. Тогда стоит посмотреть что происходит после добавления в корзину.
Далее важно дождаться момента, когда данные станут статистически значимыми. Для этого можно например использовать: abtestguide.com/calc/
Часто слышу вопросы на тему стоит ли вообще тестировать дизайн. Тут все зависит от изменений. Если в кнопке поменяли цвет с голубого на синий - это одно, а если изменили положение и сделали красной - другой разговор.
Если изменение слишком малы, но все равно есть опасения - лучше накопить дюжину таких мелочей и запустить одним тестом.
Интересная практика еще есть для тестирование Landing или Home page лейаутов. Когда проводится сразу A/B/C/D тест (трафика конечно должно хватить).
Отличная статья на эту тему: help.optimizely.com/Ideate_and_Hyp…
Среда
День 3. Нам часто приходится принимать быстрые решения. За 5 мин нужно ответить на: "Что там с моей фичей? Когда делаем?"
Вот мой вариант приоритизации:
На какой % юзеров повлияет.
Есть ли бизнес кейс.
Указан ли ожидаемый эффект.
Есть ли привязка к квартальным целям.
Если первых 3х пунктов нет - запрос сразу отпадает со словами “Иди дорабатывай”.
Квартальные цели, как правило, быстро меняются. Но иногда, четкие приоритеты компании не пропустят никаких дополнительных задач.
Если все пункты покрыты - стоит добавить в беклог и оценить работу. Дополнительно (вдруг есть время) можно проверить есть ли запросы, где сроки влияют на эффект (cost of delay). Актуально для сезонного бизнеса.
После оценки ряда задач можно провести RICE (reach, impact, confidence and effort) или Cost / impact анализ.
RICE скоринг intercom.com/blog/rice-simp… - изобретение компании Intercom. Достаточно прост в использовании и не требует точных, сложных расчетов. Одна инициатива оценивается относительно другой.
Какие методы приоритизации вы используете?
По опроснику на 2м месте Cost / impact. Добавлю, что такой анализ можно провести, только если задачи связаны с одной темой. Например после юзер интервью был составлен список идей по решению конкретной проблемы. Если темы разные impact сложно сравнивать.
Для приоритизации сториз для Grooming, создала отдельную доску в jira. Тикеты попадают в “Ready for grooming” после Tech research, UX, In design.
Часто бывает, что после скоринга задач, UX и дизайн меняют очередность. Поэтому перед планингом пользуюсь Ready for dev столбцом и расставляю задачи по приоритетам. Далее эти задачи подтягиваются в топе беклога на основной борде.
Make or Buy - как сделать выбор? Пара советов на что обратить внимание:
- Функционал является ядром продукта либо доп. плюшкой?
- Сколько будет стоить поддержка (часы/люди в месяц/год)?
- Есть ли на рынке хотя бы несколько провайдеров с хорошей репутацией и приемлемой ценой?
Недавно решали подобный кейс - хотели добавить чат функционал между водителем и пассажирами. Функционал был не основным, так как они могли общаться по смс и звонкам. Разворачивать и поддерживать свой собственный чат было дорого. Выбор чат сервисов было неплохой, но цены кусались.
По итогу выбрали Chatkit от Pusher со средней ценовой политикой. В процессе разработки натыкались на недоработки со стороны сервиса. А позже Pusher свернул проект 🤯. Другие сервисы оказались непомерно дорогими либо с нулевой репутацией. По итогу, пришлось отложить задачу.
Советоваться и спрашивать мнение команды важно и нужно постоянно. Хорошая практика - брать кого-то из команды с собой на стейкхолдер миттинги и вовлекать в обсуждения на ранней стадии.
После каждого A/B теста делиться с командой результатами и доходчиво объяснять чего добились.
Организовывать Deep drive сессии со своей и другими командами и делиться общей картиной по продукту. Это позволит иметь больше информации для принятия верных решений.
Как НЕ стоит приоритизировать:
“Я так чувствую” - CEO не понравился дизайн? Хочется угодить CEO, но круче привязать это к чему-то более глобальному из того что планируется.
По запросам сейлзов и саппорта - человеческий фактор играет большую роль. Был у меня случай, когда у юзера было проблема с выбором маршрута на карте, о нем говорил весь саппорт отдел. Оказалось это был 1 пользователь, который убедил весь отдел что это проблема каждого юзера.
Сейчас у нас есть Intercom саппорт чат, где могу отфильтровать количество юзеров и чатов по ключевым словам.
По ROI - достаточно ли ценности приносит функционал чтобы доплатить за него? Это можно проверить в процессе юзер интервью либо через Propensity модель: associationanalytics.com/2016/08/22/pro…
Четверг
День 4. Что такое по-вашему роадмапа?
Из списка лучше всего подходит стратегический план: у вас есть цель - KPI, стратегия - инициативы, тактика - задачи в рамках инициатив
У нас в компании все пользуются Confluence, где темы или инициативы с кратким описанием и метриками уже расставлены в порядке приоритетов. Хотя Эксель файлик тоже норм :) @borovikov
Плюс в Confluence есть плагин, где можно легко добавить визуализацию по срокам
Процесс утверждения роадмапы начинается с обсуждения с другими Пмами, так как часто инициативы тесно связаны. Это помогает понять что вообще реально.
Далее проводится презентация и сбор фидбеков от стейкхолдеров.
Так как роадмапа составлена на основе регулярной работы со стейкхолдерами и приоритезации, то неожиданностей не должно возникнуть.
Если все же выплывают новые задачи, то слишком поздно - “нет”. Отличная статья на эту тему: intercom.com/blog/product-s…
В конечном итоге команда решает какие инициативы мы сможем потянуть в квартале, а какие нет.
Для принятия решения обычно смотрим техническую роадмапу и зависимости.
У нас в компании инфа по инициативам всех команд доступна в главном зале на борде: Now, Next, Later
Пользуемся тегами Now, Next, Later в джире, чтоб просто было отслеживать прогресс и обновлять борду в офисе (практика Foursquare) medium.com/@noah_weiss/no…
Проводим общие еженедельные стендапы и делимся последними апдейтами на борде.
Роадмапа имеет свойство быстро меняться: резко новая важная задача, поменялись цели компании, на одну из инициатив нужно больше времени и т.п.
Тут мы просто ведем Decision log в Confluence и напротив инициативы ставим blocked, cancelled и комментах причины
Ну и важно держать в курсе все вовлеченных стейкхолдеров
Делюсь книгой на тему: Product Roadmaps Relaunched: How to Set Direction While Embracing Uncertainty (описано детально как делать, собирать инпуты и мониторить роадмапу )
Пятница
День 5. Задача MVP - проверить нужен ли ваш продукт рынку с его набором ценностей. Чтобы ответить на этот вопрос, есть пара подходов (описал Eric Ries - Lean startup).
Concierge - помогает генерировать идеи вокруг ценности продукта. Например есть идея умного механизма подборки книг, валидация проходит так: юзер заполняет опросник и далее кто-то идет в местный магазин и готовит список книг. Софт отсутствует.
Wizard of Oz MVP - тут понятней какое решение нужно, поэтому создается иллюзия готового продукта. Например сайт по продаже обуви - кто-то делает заказ онлайн и далее человек идет магазин и покупает обувь за него. Софт присутствует.
Sales MVP - помогает понять какую цену готов заплатить потребитель в обмен на ценность.
Если коммерческий продукт нельзя продать, значит ценность не велика.
На практике редко приходится работать с продуктом с нуля. Плюс, обычно, он не настолько уникален, чтоб перебить конкуренцию одной фичей. Поэтому накручивается не мало функционала.
В таких случаях пользуюсь Use case диаграммами, чтобы определить участников и что они должны делать.
Далее детализирую процессы на BPMN диаграммах: businessstudio.ru/wiki/docs/curr…
Далее проводится Vertical slicing workshop, где определяем границы MVP по принципу "Walking skeleton" medium.com/theagilemanage…
Типичные вопросы для Vertical slicing workshop:
- Принадлежит ли функционал к основному юзер флоу?
- Может ли юзер решить проблему без этого действия/функционала?
- Добавляет ли этот функционал конкурентное преимущество?
Для уже раскрученных продуктов со своим уровнем ожиданий от пользователей, строим доп сервисы, фичи на базе принципа SLP (simple lovable product). Функционал и интерфейс максимально просты в использовании.
Хороший пример такого продукта тот же Slack, WhatsApp. Первые версии были достаточно многофункциональными, по понятными и простыми в использовании.
Когда продукт, сервис или функционал прошел стадию MVP и занял свою нишу на рынке, далее стоит определиться с подходом: Refinement or Exploration
Приносят ли Local maxium и Continuous refinements больше ценности, чем Global maximum и другие возможные варианты развития продукта/сервиса.
Помогут ответить на вопрос:
данные + фидбеки юзеров
готовность компании тратиться на exploration
концепция "кегелбан" или bowling alley (Geoffrey Moore).
Сразу книга по теме Geoffrey Moore “Crossing the Chasm”, где он описывает принцип bowling alley + статья: ignitionframework.com/crossing-the-c…
Суть в том, что ты анализируешь как разный набор функционала можешь привлечь абсолютно новый сегмент пользователей.
Uber eats, Amazon prime video - отличные тому примеры.
Суббота
День 6. Один из главных принципов работы в мультикультурной среде - “inclusiveness”:
- Коммуникация открытая;
- Каждый может выражать свое согласие/несогласие без осуждения, и рассчитывать на объективность;
- Успех делится со всей командой, конкретный вклад каждого не важен.
Google яркий тому пример: diversity.google
Принцип “inclusiveness” может быть затратен для компании, так как решение “приклеить или прибить” занимает больше времени. Но, со временем этим можно научиться управлять.
Важно знать свою команду, мотивы и заранее готовить и выносить варианты решений на обсуждение. Логичные и понятные аргументы помог ускорить процесс, и культурные различия не будут помехой.
Еженедельные 1-on-1 с участниками команды, Тим Лидами служат возможностью дать/получить конструктивный фидек, понять настроения и восприятие работы и команды.
Кроме этого, раз в месяц проводится 360 фидбек, когда вся команда за одним столом по очереди дают фидбек о своих коллегах по принципу: что хорошо, что улучшить.
Чтобы наладить работу в мультинациональной команде, стоит обратить внимание на следующие аспекты: фидбек, лидерство, доверие, конфликты.
Фидбек - некоторые культуры (в основном всточноевропейские) предпочитают прямой фидбек, тогда как других это пугает. Поэтому тут нужно аккуратно похвалить, а потом немного поругать. Как говорят немцы: Durch die blume sagen (говорить через цветы).
Лидерство - вырисовывается ли в команде иерархия либо все предпочитают уравниловку.
Если есть иерархия, то Продакт может прислушиваться к мнению конкретного человека в команде, так как ему доверяет вся команда.
А вот если уравниловка, то лучше организовать мини миттинг либо спросить в общем чате для сбора мнений по теме.
Доверие - на чем строится доверие: на том, как люди работают вместе или больше на том как хорошо они друг друга знают. Обычно и то и то, но чего-то всегда больше.
Если работа на первом месте, что важно наладить шаринг знаниями внутри команды, менторшип.
Вот примерно так описывает фокус в работе Erin Meyer в своей книге The Culture Map
Конфликты - решаются ли внутри команды либо их просто избегают. Если избегают, важно инициировать решение самому. Поднять тему на 1-on-1.
Пара советов по организации эффективных миттингов:
- Повестка дня;
- Инвайты в календаре;
- Работа с аудиторией (обратная связь с участниками);
- Заметки в течение митинга с последующими мейлом с итогами.
В рамках командных миттингов можно пробовать ротацию в проведении planning, grooming, sprint retro. Так каждый из участников будет вовлекаться в процесс.
Для более проактивных участников можно выделять отдельную роль: фасилитация, контроль, тайминг миттинга. Так они не заберут на себя все внимание, а наоборот будут давать инициативу другим.
Коммуникациями в команде и конфликтами проще управлять и решать с позиции High-Context и Low-Context культур.
Так в high-context культурах конфликты имеют личный характер и требуют моментально разрешения, в то время как в low-context культурах они относятся больше к ситуациям, фактам. Статья на тему: online.pointpark.edu/business/cultu…
Воскресенье
День 7. Удержание людей и помощь в профессиональном росте - что может сделать Продакт менеджер?
Если вам известны факты о зарплатных ожиданиях, вовлеченности в работу, настроении человека - не стоит ждать очередного этапа сбора фидбеков, а стоит инициировать обсуждение с Руководством самому.
Кто как не Продакт знает свою команду лучше всех. Поэтому знать Competency matrix, Personal growth plan по каждому участнику не помешает. В этом могут помочь Team Leads.
Сompetency matix должна иметь четкие критерии перехода с одного уровня на другой. Если к кому-то из участников есть предвзятое отношение, стоит вмешаться.
Так был случай когда один из инженеров по мнению всей команды заслуживал позицию Senior, но Engineering lead имел дополнительные ожидания по soft skills. Это все конечно нигде не было задокументировано.
Пришлось вмешаться и подписать “Джентельменское соглашение” , где Продакт выступал 3й стороной в Плане по переходу на следующий уровень со четкими критериями.
Далее проводились регулярные апдейты по документу. В результате все пункты были выполнены и справедливость восторжествовала.
Способы мотивации команды:
- Показывать ценность команды и вклад в дела компании;
- Обмениваться идеями, мнениями;
- Давать развитие новым идеям;
- Праздновать успех;
- Поддерживать командный дух;
Далее приведу примеры.
Раз в месяц проводим “Townhall”, где презентуем для всей компании одну или несколько инициатив. Продакты описывает проблему, знакомят аудиторию с данными. Далее участники команды показывают демо. После проводится сессия вопросов/ответов. Это позволяет создать awareness.
Для персонального развития один раз в неделю проводим Personal improvement day, где каждый из участников выбирает интересующую тему, которая будет полезна для компании, и работает над ней.
По новым идеям, 2 раза в год проводим Hakathon, в котором участвует вся компания. Создается борда с идеями, и далее каждый для себя выбирает подходящую. Выделяется 4 дня на реализацию. После проводится презентации. Некоторые идеи могут быть выбраны для дальнейшей имплементации.
Успех и достижения команды обычно празднуются на уровне команд. Но есть возможность на еженедельном ивенте Blackfix, где компания делиться основными новостями и достижениями, добавить и презентовать достижения по конкретной теме.
Совместные тим ивенты, организация mob programming сессий за пределами офиса - все это укрепляет командный дух и позволяет наладить социальные контакты.
Круто когда людям интересно и они хотят работать с вами. А что делать когда мотивация на нуле?
Для начала - понять как дела с доверияем, затем предлагать подходящие инициативы.
Ваша команда должна доверять вам, для этого достаточно быть честным, признавать свои ошибки, проявлять понимание к проблемам других, ну и быть профессионалом.
По инициативам - не всем подходит одинаковый формат. Кому-то нравится участвовать в greenfield проэктах, кому-то интересно поработать в cross-team инициативах, кому-то хочется создать open-source проэкт на базе своей работы.
Это не значит, что вам стоит забыть о приоритетах и идти на поводу. Но помочь найти занятие по душе внутри компании позволит вам заработать доверие. Шансы, что человек захочет работать только с вами после такого велики.
Пару советов на тему личной мотивации:
- Не привязываться эмоционально к проблемам. А если уже привязалась, найти резко хобби.
- Почитать книгу о мотивации. Например: Obstacle is the Way: The Timeless Art of Turning Trials into Triumph by Ryan Holiday.
Пару советов на тему личной мотивации: - Не привязываться эмоционально к проблемам. А если уже привязалась, найти резко хобби. - Почитать книгу о мотивации. Например: Obstacle is the Way: The Timeless Art of Turning Trials into Triumph by Ryan Holiday.
Интересные треды за неделю:
День 1: twitter.com/produnderhood/…
День 2: twitter.com/produnderhood/…
День 3: twitter.com/produnderhood/…
День 4: twitter.com/produnderhood/…
День 5: twitter.com/produnderhood/…
День 6: twitter.com/produnderhood/…
День 7: twitter.com/produnderhood/…
Ну вот и все на этой неделе. Всем спасибо, надеюсь узнали для себя что-то новое. Cкоро выпущу статейку на тему MVP, так что follow me: medium.com/@svetlana.blaz…
Ну и буду рада фидбеками.
![Product strategy best practices [with examples]](https://blog.intercomassets.com/blog/wp-content/uploads/2018/10/cropped-cropped-site-icon-2-192x192.png){kind=icon}
![Product strategy best practices [with examples]](https://blog.intercomassets.com/blog/wp-content/uploads/2016/07/Product_Strategy_Means_Saying_No_Related_V2.png)
![RICE Prioritization Framework for Product Managers [+Examples]](https://blog.intercomassets.com/blog/wp-content/uploads/2018/01/RICE_Simple_Prioritization.jpg.optimal.jpg)
