В этот четверг приглашаем вас на митап, посвящённый продуктам, которые лидируют представители Ozon, Авито, Skyeng.

В программе:

— Ozon доставляет: как посылка попадает к вам в руки? (Игорь Мелех, Ozon).

— Делать или не делать: приоритизация по-взрослому (Аня Подображных, Авито).

— Как провести 24 эксперимента на 100 тыс. пользователей за месяц и не умереть (Роман Михайлов, Skyeng).

— Q&A-сессия.

Подробнее о докладах и продуктовой культуре в Ozon читайте внутри.

7 декабря в 19:00 поговорим о разработке digital-продукта на разных этапах и уровнях: от управленческих задач и распределения фокусов по командам, работы с метриками эффективности, до запуска конкретного предложения и дизайна.

1. Инструментарий — техника, tooling, технические процессы, CI/CD и прочие штуки — авто-всё, всё как код и т.д.
2. Культура — это как отдельным разработчикам прийти всем вместе к «мир, дружба, жвачка».

Я больше 10 лет работаю с / в / для agile в сфере web-разработки. Из них больше всего пришлось иметь дело с самым популярным agile фреймворком — scrum (по данным VersionOne). Хочу поделиться с вами накопленными наблюдениями и выводами.

Начну с метафоры, так как иногда приходилось видеть внедрение scrum по такому сценарию:

• До scrum: «разработка» как младенец — она целеустремленна, но не умеет нормально ходить, а очень хочет научиться, чтобы добираться до цели.
• Внедрение: приходит учитель (scrum тренинги, курсы, agile coach и т.п.) и показывает, как ходить. Малыш счастлив, он двигается шагами! Топ-топ-топ. У нас спринты — мы ходим!
• После внедрения: терпеливые стейкхолдеры говорят: «Окей, погнали к цели», на что получают «не давите на команду, мы ходим!». Разработка выписывает интересные траектории и получает удовольствие от процесса, но цель забыта.
• Scrum-но: дальше пилюля правды от бизнеса, scrum «мутирует» и позволяет бизнесу получать какой-никакой продукт от разработки. И, к сожалению, формально ставится галочка «мы работаем по scrum», а реальный потенциал команды разработки так и не раскрыт, да и кругом говорят «scrum ненастоящий».

Все как в жизни.

Предыстория

В классических методологиях роли владельца продукта не было. Впервые роль владельца продукта появилась в Scrum фреймворке. До этого ближайшей по смыслу ролью была роль менеджера проекта в методологии PMI PMBoK. Роль менеджера проекта содержала в себе ряд противоречий и конфликтов интересов:

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

Решая эти проблему, создатели Scrum:

1. Разделили роль менеджера проекта на две: Scrum мастер, которые заботится о команде, этакая строгая, но любящая нянька, и владелец продукта.
2. Сделали так, что ответственность владельца продукта не заканчивается на завершении разработки, а продолжается в период коммерческой эксплуатации.
3. Решили, что в компетенции владельца продукта входят: маркетинг, продажи, знания бизнеса и предметной области.

Ежемесячный дайджест новостей российского продуктового сообщества.

В этом выпуске отчеты про жизнь продуктологов и маркетологов за рубежом The State of Product Leadership 2019 и The 2019 State of Marketing. Множество материалов по Growth Teams. Старт набора в весеннюю программу стартапов от Russol и в бесплатную школу product owner-ов от Додо Пицца.

Все материалы Product Mindset, отчет PM Trands & Benchmarks, квартальный отчет по мобильному рынку, конкурс стартапов от Visa на 11 млн рублей.