Архив метки: product management

Тихий скетчинг

Одним из самых неожиданных профессиональных открытий 2017-го года для меня стала техника «Тихого скетчинга» для решения продуктовых задач. Сначала я подсмотрел ее на конференции Mind The Product London во время одного из воркшопов, а затем нашел ее упоминание в книге SPRINT от Google Ventures.

Работа Product Manager подразумевает постоянную генерацию решений. Когда выявлена проблема целевой аудитории, и перед будущим продуктом (либо его частью) поставлена цель, наступает время придумать такую реализацию, которая эту проблему для пользователя успешно решит.

Как обычно происходит процесс создания решений? Поработав на продуктовых позициях в самых разных компаниях: от микро-стартапов до колоссального размера корпораций, я обратил внимание, что чаще всего команды используют один из двух подходов. Читать далее

Зачем нужна продуктовая работа?

Те, кто занимается созданием каких-либо продуктов, постоянно натыкаются на массу примеров, зачем делать User Research, зачем заниматься Customer Development’ом, зачем прибегать к Jobs To Be Done и т.п.

Честно, большинство этих примеров всегда выглядит немного притянутыми за уши. Ну вот не можешь ты при чтении отделаться от мысли, что как-то все немного картонно. Возьмем классическое: «пользователь говорит, что хочет увеличить конверсию чекаута на 20%. Чего он хочет на самом деле? Выполнить план 4-го квартала. А если еще копнуть? Получить выше премию. А если еще? Съездить в отпуск на новый год.» И тут авторы предлагают нам подумать над этой глубокой мотивацией пользователя и поработать с ней. Убедительно? Вряд ли.

Я тоже часто сталкиваюсь с необходимостью объяснить глубоко не посвященным людям, что такое Product Management, и всегда иллюстрирую свой рассказ примерами из собственных продуктов.

И вот, наконец, у меня появился крутой, сочный, жирный кейс от очень известной и любимой всеми компаниями. Встречайте: выключение Wi-Fi в iOS 11. Все айфоноюзеры уже заценили новый Control Center? Конечно.

Знаете, в чем конкретно тут пример отличной реализации заповедей UX? В одной единственной кнопке, точнее в сути ее работы

Чего хотят пользователи от операционной системы? — Отключить Wi-Fi. Окей, в iOS с первых версий такая возможность была, но в последней версии инженеры Apple механизм работы этой кнопки изменили. Теперь она не отрубает Wi-Fi модуль как раньше, а отключает устройство от конкретной сети. При этом, когда вы уйдете с работы домой, то к домашней сети ваш телефон подключится автоматически, без необходимости двигать тумблер включения Wi-Fi.

Чувствуете?

На самом деле, мы с вами хотим не «отключить Wi-FI», а «Отключиться от сети, к которой автоматически подключился телефон, и нас это бесит, потому что она требует авторизации или просто очень медленная». Нам пофигу на Wi-Fi модуль! Мы в интернете хотим продолжить сидеть.

Можно ли такое выявить без общения с пользователями?  Маловероятно. Это не только хороший пример правильной продуктовой работы, но еще и прекрасная иллюстрация того, почему те же Job Stories, придуманные в Intercom, работают лучше, чем классические User Stories.

Если US для описанной ситуации звучала бы так: «Я, как пользователь iOS 11, хочу отключать и включать Wi-Fi», то JS, в свою очередь, звучала бы гораздо подробнее: «Когда я заметил, что телефон подключился к нежелательной Wi-Fi сети, которая медленно работает или требует авторизации, я хочу быстро отключиться от нее, чтобы продолжить начатое действие, которое было прервано плохим соединением».

Вот так. Казалось бы, мелочь, а какой крутой UX. Для этого и нужно общаться с клиентами, понимать, что ими движет, и учитывать это в развитии продуктов.

А какие вы знаете примеры крутой продуктовой работы?

P.S. По мотивам моего поста Иван Замесин, ex Product в Яндексе и Chatfuel, написал подробный разбор, что в этом решении хорошо, и что плохо: перейти в пост Ивана в фейсбуке.

Не путайте хороший дизайн с хорошим продуктом

Публикую свою колонку, вышедшую 18 августа на сайте FutureBanking.ru

Как часто мы смотрим на дизайн приложения и говорим: “Какой крутой продукт у ребят!”. Или видим, как кто-то сделал заметный редизайн устаревшего интерфейса, и сразу нам кажется, что “классные ребята, молодцы, хорошо всё делают”. Ловили себя на таком?

Скорее всего, да. Это нормальная реакция, ведь основу наших впечатлений от любого UX составляет визуальный дизайн. Не может ведь красивый продукт работать плохо. Или может?

Сам по себе дизайн в отрыве от контекста не должен служить свидетельством успешности и качества продукта. Можно ли назвать UI сайта Booking.com выдающимся? А amazon.com? Вряд ли. И это колоссального размера бизнесы, с мощнейшей R&D-экспертизой, с огромным UX-штатом специалистов.

Что такое, вообще, хороший продукт? У меня есть свое определение, которого я придерживаюсь. После взаимодействия с великолепным продуктом вам хочется воскликнуть: “Блин, как же это было удобно и круто!”, и достигается этот эффект точечным решением специфических проблем конкретного пользователя на протяжении всего процесса его взаимодействия с продуктом.

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

Сейчас в продвинутом бизнесе явно наблюдается тренд на продуктово-ориентированные команды. Компании набирают новоиспеченыных владельцев продукта и просят их “сделать красиво”. Ребята изо всех сил стараются стать заметными.

Как прослыть хорошим продактом? Провести редизайн ради редизайна. Это очень распространенная ошибка: “Кажется, наше приложение выглядит несовременно, надо сделать полный редизайн!”. Я сам допускал такие промахи в своей практике.

Вряд ли скажу что-то новое, но это суровая правда: когда мы что-либо меняем в продукте, надо идти от проблем пользователей. Устаревший дизайн действительно может быть решением, но для этого он должен быть, что называется, Data Advised (следующий уровень после привычного Data Driven, но это тема отдельной колонки).

Видим, что пользователи отваливаются на экране? Возможно, им что-то непонятно? Заметили, что приложение “распухло” от функций, и дальше сложно сохранять его цельность и логику навигации внутри? Проверяем, мешает ли это пользователям, и если да, задумываемся об обновлении UI, — но не красоты ради, а преследуя конкретные цели: увеличение конверсии, снижение времени, проведенного на определенных шагах воронки, увеличение Retention Rate и т.д.

Иногда достаточно следовать актуальным гайдлайнам iOS/Android/Windows, чтобы сделать функциональный и современный дизайн. Большой штат UI-специалистов работает над мобильными ОС, определяя критерии современности за вас. Можно не изобретать велосипед, и просто соответствовать требованиям гайдлайнов.  

Каждый продуктолог должен запомнить: красивый продукт — не обязательно значит хороший. Ответить на вопрос о качестве могут только пользователи. Не подменяйте их мнение своим. Тестируйте все гипотезы, слушайте клиентов и не делайте редизайн ради редизайна — и тогда вам удастся спроектировать по-настоящему великолепный пользовательский опыт, который будет эффективно решать проблемы ваших пользователей.

А те, в свою очередь, отблагодарят вас лояльностью.

Правда про кастдев, дизайн-мышление, UX research

Я в ИТ-бизнесе с 2007 года. Последние 5 лет изо всех утюгов индустрии можно слышать про важность Customer Development, дизайн-мышления, customer dicovery, UX research и [подставьте свое]. Каждый эксперт настаивает на конкретной методологии и позиционирует ее как панацею от всех продуктовых бед и провалов в бизнесе.

Есть у меня на этот счет одна мысль.

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

По большому счету не важно, будете вы изучать ваших клиентов в строгом соответствии с методологией Design Thinking, или начнете неистово приглашать их на глубинные полуторачасовые интервью в в офис. Важно, что вы в принципе общаетесь с вашей ЦА. 

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

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

Если у вас в команде есть люди, отвечающие за продукт, отправьте их общаться с целеввой аудиторией. Не важно, как именно, не важно, насколько строго они будут соблюдать правила — всё это наживное. Важен сам факт общения. Сделайте это, и изменения не заставят себя ждать.

Три вида продактов

Если вы видите хороший продукт, будьте уверены, что в его главе стоит один из этих 3-х типов людей:

  1. Гений. У человека просто талант. Необъяснимый. Чутье, интуиция, видение. Встречается очень редко.
  2. Профессиональный продуктолог. Самый очевидный сценарий. Человек владеет профессиональной методологией — значит, может с максимальной вероятностью сделать хороший продукт. Практически безотносительно предметной области.
  3. Типичный представитель целевой аудитории продукта. Самый часто встречающийся в России тип владельцев успешных бизнесов. Иногда путается с Гением, однако таковым не является. Секрет такого продакта прост: он сам глубоко погружен в предметную область, сам является представителем типичной (важно, что не меньшинства, а именно типичной) ЦА и оттого очень хорошо понимает проблемы клиентов.

Вот так.

Лучшие материалы по управлению продуктом 2016

Компания Alpha опубликовала очередной дайджест со ссылками на лучшие по их версии материалы по теме управления продуктом за 2016 год. Здесь посты, которые я нашел наиболее интересными и отложил себе на «прочитать позже». Пост обновляется комментариями по итогам прочтения.

As a product manager, what do you spend most of your typical work time on?

По итогам прочтения: очень много ставших клише «В 6 я встаю, а к 8 уже сделал половину рабочих дел за день, и вообще весь мой день космически систематизирован».

How to Pick Winning Product Features

What Do I Do At Work All Day?

По итогам прочтения: вполне реальная рутина, приметил для себя количество времени, которое автор уделяет личным встречам.

Decision Making for PMs

What You Can Do to Simplify Your Products

Why Talking to Customers is the Most Important Thing a Product Manager Can Do

How A Modern Product Team Should Work

Building Products

Product Management for the Enterprise

A Trello template for your Product Backlog

3 Mobile Product Lessons From Uber

Behind Every Great Product

After running 2,000 experiments for Fortune 500 product teams, here’s what we learned

Интуиция против статистики: как расставить приоритеты по внедрению новых функций

Вышла моя статья на VC.RU о том, как определять приоритеты продуктовой разработки так, чтобы это было прозрачно, честно и эффективно. 

Перейти к статье на vc.ru

О пользе usability-тестирования

Давайте посмотрим на экран «Контакты» в Skype для Mac.

У меня недавно возникла проблема. Я не знал, как добавить новую группу контактов. Это очень странное ощущение: ты видишь, что группы уже есть (значит ранее ты их уже добавлял), но как добавить новую, совершенно не понимаешь.

Как бы вы добавляли группу? Я подсветил на скриншоте те элементы, которые вроде как могли бы логично вести к такому действию:

Попробуем по очереди.

  1. Кликнем правой кнопкой рядом с имеющимися группами. Не работает(
  2. Поищем в файловом меню, во всех его пунктах. Нет(
  3. Нажмем правой кнопкой на контакт. Нет, там только «Add to List…», но нужного Create new list нет…
  4. Нажмем на кнопку с плюсиком. Не то(
  5. Выйдем на домашний экран. Ничего подобного там нет(

Я совершал 3 подхода к этой задаче. Два раза забивал. В третий раз в отчаянии решил потратить побольше времени, но не гуглить, а разобраться самому.

И я разобрался.

Знаете, где сидел нужный контрол? В модальном окне «Add to List…»

Но почему там? В вашем распоряжении огромный Retina-дисплей Мака. Почему не предусмотреть контрол не в двух кликах, а в одном?

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

Как не повторять ошибок Skype?

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

Именно в такие моменты обычно волшебным образом проявляются многие UI-баги, которые доставляют так много боли пользователям. Когда своими глазами видишь, как пользователь тупит и не может найти нужную кнопку там, где по твоему мнению, это было сделать так просто, вы знаете, действует отрезвляюще. Особенно на UX-guys, которые этот интерфейс спроектировали.

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

Где найти больше информации?

The Guide to Usability Testing

How to Conduct Usability Testing from Start to Finish

 

Управление продуктом: как работать с обратной связью

Это не моя статья, это перевод. Ссылка на источник в конце.

Процесс сбора ценного и своевременного фидбека от клиентов требует времени. Шан Таунсенд, директор по исследованиям Intercom, рассказывает о том, как научиться понимать пользовательские отзывы. В этой статье она объясняет, как распознать и проанализировать те виды отзывов, которые принесут наибольшую пользу вашему бизнесу.

1. Определите, к какой категории пользователей относится автор отзыва

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

Разработка продуктов при помощи Job Stories

Это не моя статья, а перевод. Ссылка на источник в конце материала. 

Раньше, когда между пользователями и разработчиками зияла пропасть, моделирование персон и создание пользовательских историй давало результат. Теперь все иначе.

Эта статья Алана Клемента, евангелиста Jobs to be Done, о том, как команда разработчиков проектировала страницу профиля в приложении, используя метод Job Stories. Его суть — в проработке реальных историй того, как продукт выполняет ту или иную работу.

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

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