Как отстроены продуктовые процессы в компаниях
Avito
- dual track: discovery и delivery Весь процесс продуктовой разработки от идеи до выкатки в продакшн идёт двумя параллельными потоками — discovery и delivery.
- Discovery — это проработка инициативы, качественные и количественные исследования, валидация проблем и решений. Этим процессом занимается дискавери-команда. В неё входят менеджер продукта, тимлид разработки, аналитик, bizdev-проджект-менеджер, дизайнер и UX-исследователь.
- После того как идея проработана, проведены все необходимые исследования, выбрана фокусная проблема и оптимальное решение, задача уезжает в команду разработки — деливери. В команду деливери входят бэкенд-, фронтенд-, QA- и mobile-инженеры, менеджер продукта и тимлид разработки. Это не какие-то отдельные люди, а те же продакт и тимлид, что и в дискавери-команде.
- Верхнеуровнево продакт отвечает за результат по продукту, драйвит продуктовые изменения и подключает экспертов из разных функций для достижения результата. Более детально, что делает менеджер продукта:
- Отвечает на вопросы: кто пользователи, зачем им твой продукт, какие у них потребности.
- Постоянно отслеживает метрики успеха и здоровья продукта.
- Генерирует, собирает и приоритезирует гипотезы улучшения продукта.
- Вместе с командой проверяет гипотезы, итогом которых становится лучшее понимание продукта или конкретные улучшения.
- Формирует бэклог продукта на основе качественных и количественных данных.
- Прорабатывает спеки и истории для продуктовых улучшений.
- Ставит продуктовые задачи команде и объясняет продуктовую логику: зачем, почему, для кого.
- Презентует результаты на командных мероприятиях.
- Проактивно обеспечивает прозрачность целей и результатов для стейкхолдеров.
- Учитывает интересы других юнитов и подразделений, видит картину целиком.
- Страхует тимлида в вопросах управления командой разработки: мониторит проблемы и предлагает решения.
- Все команды Авито работают над своими продуктами по единым фреймворкам и процессам, при этом нет принудиловки: команды сами могут оптимизировать инструменты и процессы, если им так удобнее.
Working Backwards
Пришло из Амазона(собственно СРО оттуда же)
Scaling Lean
Самая первая стадия — New Opportunities Discovery. На ней как раз прорабатывается новая идея и пишется PR и FAQ. Здесь не нужно делать сложные качественные и количественные исследования, разрабатывать прототип и так далее.
Суть подхода в том, чтобы превратить разработку продуктов из трубы в воронку: на каждом из этапов более слабые идеи отсеиваются, и компания может сфокусироваться на наиболее важных ставках. Именно поэтому на первой стадии не стоит инвестировать слишком много ресурсов в проработку.
По итогам стадии назначается Gate 1 — встреча, на которой собираются СРО, CTO, другие руководители и стейкхолдеры, которые могут быть связаны с реализацией идеи. Все читают PR и FAQ, а потом менеджер продукта отвечает на вопросы. Если все важные вопросы покрыты, и в идее видят потенциал, продукт получает зелёный свет и переходит на следующую стадию.
Stage 2 посвящен Product Discovery. Здесь уже важно подтвердить свои гипотезы через качественные и количественные исследования. На этом этапе продакты проводят CustDev, делают fake door, UX-исследования, опросы. Можно собрать простой прототип и посмотреть, как с ним будут взаимодействовать пользователи. На этом этапе данных уже больше, поэтому можно построить трекшн-модель. Это модель роста продукта, в которую мы закладываем некоторые допущения и прогнозы по росту метрик в зависимости от продуктовых изменений, которые будем делать на следующих этапах.
По итогам второй стадии проводится Gate 2, на котором обсуждается уже обновлённый PR, FAQ и трекшн-модель. Если результаты Product Discovery успешны, и мы видим потенциал в дальнейшей проработке продукта, то можно переходить на этап Product Delivery.
На третьем этапе появляются Minimum Lovable Product (MLP) и пользователи. Здесь мы уже можем посмотреть на реальных метриках, насколько наши прогнозы оправдались. По итогам проводится Gate 3, где принимается решение о запуске. Здесь как раз пригодится PR, который мы писали до этого: с минимальными доработками документ превращается в реальный пресс-релиз, на основе которого СМИ будут писать о нашем продукте.
Дальнейшие гейты проводятся для того, чтобы проконтролировать, как продукт идёт по трекшну и есть ли отклонения в модели, чтобы при необходимости принять меры. Отклонения могут быть в обе стороны.
Objectives and Key Results
Защищённые на гейтах продукты попадают на планирование и входят в состав OKR.
Планирование OKR происходит раз в квартал. В нашем юните для приоритизации мы используем ICE (Impact, Confidence, Ease).
- Impact мы теперь оцениваем не экспертно, а по специальной шкале, которая помогает оценивать вклад задачи в Revenue и Customer Experience. Важностью каждого из параметров можно управлять через вес. Например, если в каком-то из кварталов мы хотим сделать фокус на Customer Experience, то можем повысить его вес относительно Revenue.
- Confidence стандартно оцениваем по уровню проработки задачи: если она на стадии идеи, Confidence будет 1, если уже есть количественные подтверждения, например зелёный A/B-тест, то это 10.
- Ease оцениваем по сложности реализации: берём в расчёт не только сложность разработки, но и трудозатраты в дискавери. Отдельно оцениваем необходимые работы на стороне всех функций: продакта, аналитика, UX-исследователя и дизайнера.
В результате мы получаем приоритизированный бэклог и список Objectives & Key Results на квартал. Потом начинаются стандартные SCRUM-процессы. Мы используем стандартный набор встреч: PBR, планирование спринта, ретро и sprint review.
В конца каждого спринта мы получаем инкременты в продакшене и оцениваем, как они помогают нам продвигаться в достижении OKR. Если что-то западает, это обсуждается на ретро и вносятся изменения в планирование следующих спринтов и общего роадмапа на квартал.
Double Diamond
После планирования и приоритизации, когда бэклог и список OKR сформированы, мы приступаем непосредственно к продуктовый работе. Здесь мы используем модель Double Diamond.
А что у вас со сроками и time to market, если вы постоянно пишете документы, защищаете гейты, что-то исследуете и ставите OKR?
Обычно результаты каких-то работ бывают двух типов: output и outcome. Output — это непосредственный результат выполнения действий или активностей. Например, новая фича. Outcome — эффект от выполненных действий. Обычно он появляется не сразу после их выполнения и даже может быть эффектом от нескольких outputs. Если ещё проще, output — это то, что сделали, а outcome — это то, что за счёт этого достигли.
Если мы осознано замедляем аутпуты продуктовыми процессами, то фокусироваться нужно на том, чтобы за счёт этих процессов увеличить ауткамы. Здесь легко впасть в крайность, когда процессы дискавери делаются ради процессов: проводится больше исследований, чем требовалось, при этом сроки замедляются настолько, что продукт уже никому не нужен. Чтобы не впадать в неё, нужно понимать, что ценность работы менеджера продукта — это конечный результат, а не то количество фреймворков и методов исследований, которое он знает и применяет.