Управление продуктом *

Мы все пытаемся найти боль клиента и предложить ему свой продукт для решения. Но перед этим нужно провести огромную аналитическую работу, чтобы узнать, а кто же наш клиент вообще. В этой статье мы подробно рассказываем, как составить работающий портрет клиента и посчитать стоимость выхода продукта на рынок.

Две недели, четыре вебинара, десятки часов подготовки, планирования и ретроспектив,
40 улучшений и…. большие потери.

Поворотное Ретро

Итак, 28 апреля стартовала Вечерняя школа Слёрма. Вместе с нашими студентами на основе обратной связи мы создаём курс про Agile и по принципам Agile. За две недели отработали технические вопросы, внедрили более 40 улучшений, продолжили наполнять копилку полезностей, постоянно получали обратную связь от студентов. В общем, улучшались, собой и продуктом были довольны.

На Ретро после 4 вебинара пригласили студентку, чтоб от народа услышать, какие мы крутые. Обратная связь оказалась неожиданной, словно холодная вода в лицо. И много непонятных терминов, английских слов в речи спикеров. И в личный кабинет не получается зайти, и в чат в Телеграм не попала. И темы вебинаров «размазаны», непонятно, на какую целевую аудиторию рассчитаны.

Невесёлая воронка

Начался анализ. Глубокий инсайт изменил наше сознание. Дойдя до 4 вебинара – до четвёртого!!! – мы только узнали, что теряем людей. Мы забыли о цифрах, смотрели на них, но не видели. Сами судите:

Вот такая невесёлая воронка при полной уверенности, что наш курс имеет огромную ценность. Уже две недели мы даём людям сотни полезностей, рассказываем, как в кризис не утонуть, увидеть новые горизонты, поймать возможности, запастись эффективными Agile-инструментами.
Но народ-то уходит…

WTF?!!! В чём дело?!

Привет, Хабр.

Последние 3 месяца около 40% моего рабочего времени занимает общение с дизайнерами. Спасибо, но жалеть не нужно. Шучу. Нужно. Дизайнеров.

Про то, что дизайн — это не про нарисовать, а про спроектировать, мне уже показали. А о том, почему это так, нашла доступное объяснение от Кости Горского, в прошлом артдира Яндекса. Видео доступно по ссылке.

Режим самоизоляции многих вынудил работать из дома. Кому-то смена обстановки даётся легче, кому-то сложнее, а кто-то и вовсе не заметил бы разницы, но после объявления недели (а потом и месяца) «карантина» прирост постов о лайфхаках, эффективности и продуктивности в ленте существенно увеличился.

Меня зовут Михаил Трошев, я руковожу службой поисковых интерфейсов Яндекса. Наша команда много лет работает распределённо — ниже расскажу, чем это отличается, а чем схоже с «удалённо», как организовано, почему не ломается и чем может быть полезен наш опыт тем, кого резкая смена режима работы застала врасплох.

Что-то наверняка покажется вам банальным (Agile, Scrum, Kanban, DevOps — ничего себе открытия!), но это ведь как с зарядкой по утрам: все знают, что она полезна, но делать регулярно и в полную силу почему-то лень. Так вот: мы делаем. И это работает.

Привет, хабровчане! В этот внеочередной выходной день выходного месяца, хотим поделиться с вами интересной статьей, которая была переведена в преддверии старта курса «Team Lead 2.0».

---

Разработчикам нужна обратная связь, чтобы они могли совершенствовать навыки и получать новые знания. По словам редактора Inc. Magazine, Джеффа Хейдена, традиционные показатели могут быть обманчивы, поскольку они не всегда отражают четкую картину. Раньше оценка работы персонала представлялась сложной задачей, именно потому появились инструменты Git Analytics, такие как Waydev. Этот инструмент предлагает подход к разработке на основе данных, чтобы помочь вам выявить лучшее в своих сотрудниках.

Очень важно измерять правильные показатели и делать это корректно. В свою очередь, выбор показателей зависит от специфики вашего бизнеса и должностных обязанностей каждого инженера-программиста.

Мы расскажем вам об алгоритме, который поможет оценить эффективность работы программистов:

7-го мая в 19:00 по Москве приглашаем всех присоединиться к митапу по продуктовой аналитике. Обсудим все самое важное: работу с данными, инсайты, подходы к исследованиям и поговорим о роли продуктового аналитика в команде. Мероприятие пройдет полностью на английском языке.

Салют, хабровчане. В мае OTUS запускает онлайн-практикум по Customer Development, в связи с этим мы поговорили с преподавателем практикума — Сергеем Колосковым.



Меня зовут Сергей Колосков. Я продакт-менеджер в Ozon, руководитель программ в Otus и автор telegram-канала Fresh Product Manager. Сегодня я расскажу о вещах, которые понял о CustDev за весь свой опыт.

Кастдев (от англ. Customer development, сокращенно custdev) — это процесс извлечения инсайтов от юзеров для генерации, валидации и приоритизации идей развития продукта с помощью интервью и качественных исследований. Сначала выявляется проблема, потом разрабатывается продукт, а не наоборот. Через кастдев пропустить можно любую гипотезу, но нужно точно знать, что есть полезные и бесполезные вопросы и ответы, что не нужно продавать на кастдев, а сегмент выбирать нужный и, желательно, его любить.

Продолжаем нашу подборку интересных материалов (первая часть тут). На этот раз один образовательный курс Техносферы, две передачи из ток-шоу для айтишников «Oh, my code» и анонс нового сезона.

Из опытного продакта получился бы неплохой игрок в покер. Ведь ему приходится выстраивать стратегию, с помощью которой продукт будет улучшаться для пользователей, а доходы компании — расти. Но как понять, какую стратегию выбирать? Делимся своими наработками в этой статье :)

Перевод статьи подготовлен в преддверии старта курса «Agile Project Manager в IT».

---

Когда я только начинал свою карьеру, программное обеспечение поставлялось в коробках. Если для вас это звучит странно, знайте, что, когда я был ребенком, мой отец приносил домой перфокарты, на которых программы записывались в 1970-х. У такого программного обеспечения было конечное состояние. Через 20 лет с того момента это уже казалось нелепым. Сегодня же мы создаем системы, которые можно совершенствовать бесконечно. Отсюда возникает вопрос: «Когда работа заканчивается?» — и на этот вопрос сложно дать ответ. Мы ищем ответ на этот вопрос, потому что он поможет нам дать ответ на другие, еще более важные вопросы. Получит команда свою премию или ее отчитают? Будет ли команда заниматься чем-то новым? Получит ли стейкхолдер свою выгоду?

Команды разработчиков, которые используют Scrum (или любую другую вариацию методологии Agile), имеют четкое представление о том, когда заканчивается разработка. Часто под этим подразумевается «набор минимальных критериев, которыми должен обладать продукт/услуга для удовлетворения потребностей бизнеса». В результате все сводится к списку функций, который утверждается стейкхолдером (или product owner’ом) и на момент завершения проекта должен быть полностью выполнен. Разработчики зовут это «работает, как было задумано».

Планируете внедрение ПО Atlassian (Jira, Confluence)? Не хотите допустить жестоких ошибок в проектировании, которые потом придётся решать в последний момент?


Тогда вам сюда — рассматриваем внедрение Atlassian Jira + Confluence в корпорации с учётом различных технических аспектов.

На Хабр Карьере есть специальный раздел с обучающими программами на разных платформах. Среди них мы отобрали самые внятные и полезные бесплатные курсы — на время изоляции и вообще. Ориентировались на содержание, количество выпускников и репутацию школ. 31 курс на любой вкус: от продвижения в Инстаграме до венчурных инвестиций.

В преддверии старта практического онлайн-курса «Product manager» состоялся открытый урок с Сергеем Колосковым, продакт-менеджером Ozon. Участники научились находить метрики роста и строить аналитику вокруг них, а также считать и сводить unit-экономику. В этой статье мы приводим расшифровку занятия и полезные схемы и примеры из презентации.

---

Расскажу на примере Timepad (сервиса для организаторов ивентов), который зарабатывает комиссии с продаж билетов и апсейле. Вместо некоторых цифр, которые нельзя найти с помощью внешних источников, будут X, Y и Z, как-никак NDA :)

Но прежде ключевая информация для понимания: Product Management воздействуют на показатели через разработку, а Product Marketing (а я продуктовый маркетолог) — через коммуникации с пользователями.

Шаг 1: составить пирамиду метрик

В прошлом, когда я был молодым менеджером продукта, один из моих руководителей в корне изменил мою карьеру. Шел второй год моей работы в Airbnb. Я справлялся со своими обязанностями, но не более. Мой новый руководитель Влад Локтев обратил внимание, что завершение проекта, который я вел, откладывалось на недели. Он не был удивлен, помог вернуть проект в нужное русло и завершить его. Но я знал, что на очередной аттестации мне припомнят эту ошибку. Когда пришло время, я действительно получил далеко не блестящие оценки. Влад обозначил мои точки роста, в том числе рекомендовал сфокусироваться на коммуникациях, направленных на контроль статусов задач, и их жесткой приоритизации. После этого разговора я мог бы выйти подавленным. Но вместо этого, наоборот, я почувствовал небывалый эмоциональный подъем и желание действовать – мне стало ясно, что нужно делать.

В этой статье я перескажу свой опыт создания, развёртывания и продажи API на специализированном маркетплейсе. Мне не пришлось делать вебсайт или придумывать, как внедрить решение для обработки платежей – я просто написал код и развернул API.

Чтобы создать стартап, нужна команда, и каждый в этой команде должен быть мастером на все руки – программистом, маркетологом, продавцом. К тому же, это долгий и трудный путь, так что шансы на успех невелики. Но для запуска собственного проекта стартап – не обязательное условие. Я убежден, что можно сбывать продукты, не занимаясь ничем, кроме бэкенда.

За последний год я придумал план выпуска собственного продукта, который не предполагает работы с аудиторией и/или обработки платежей. Вся процедура состоит из трех шагов:

Привет, меня зовут Михаил Правдин, я руковожу UX-лабораторией Авито. Хочу рассказать, чем занимается моя команда, какие методы есть в её арсенале, и как наша работа позволяет достигать бизнес-целей.

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

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

Мы в Badoo не доверяем ощущениям, зато верим цифрам. Суммарно у наших сервисов больше 500 миллионов пользователей, и свой фреймворк для тестирования мы написали довольно давно. За шесть лет через него прошло 2962 теста, и A/B-тестирование доказало свою важность, надёжность и результативность.



Но в этой статье я расскажу не о том, как работает наша система. На это не хватит одной статьи. Кроме того, многие вещи специфичны для нашей компании и не подойдут другим. Сегодня я расскажу об эволюции наших представлений об A/B-тестах: на какие грабли мы наступали в процессе и как проверяли корректность работы тестов. Это статья для тех, кто ещё не начал тестировать, но думает об этом, а также для тех, кто не уверен в своей системе тестов.

С каждым годом культура разработки растет, появляются новые инструменты для обеспечения качества кода и новые идеи, как эти инструменты использовать. Мы уже писали про устройство статического анализа, про то, на какие аспекты анализаторов нужно обращать внимание, и, наконец, про то, как с организационной точки зрения можно построить процесс на основе статического анализа.

Отталкиваясь от вопросов, с которыми мы часто сталкиваемся, мы описали весь процесс внедрения сканера кода в процесс безопасной разработки. Сегодня речь пойдет о том, как выбрать подходящий вам анализатор.

Но как же так, есть же книга DevOps Handbook, самый авторитетный источник. В ней есть целый раздел, посвященный мифам о DevOps, зачем писать статью? Ну, дело в том, что, на мой взгляд, эта книжка не только объясняет методологию, но и местами её продаёт.

И раздел о мифах в ней — он такой, и содержит мифы, которые хотелось бы опровергнуть авторам, а не те, которые популярны в реальности. Тут же я постарался описать мифы, которые циркулируют в реальном мире, и с которыми мне приходилось сталкиваться, объясняя методологию своим слушателям.

1. DevOps к вам применим

Нет, DevOps подходит не всем. Этот миф идёт первым потому что некоторые отцы-основатели сами его исподволь продвигают.