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

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

Публикую свою колонку, вышедшую 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. Его суть — в проработке реальных историй того, как продукт выполняет ту или иную работу.

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

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

[Перевод] 12 шагов, которые должен совершить менеджер по продукту в новой компании в первые 30 дней

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

Советы из статьи на первый взгляд кажутся очевидными, однако это не так. В свое время, при переходе между разными продуктами, эти рекомендации могли бы заметно ускорить процесс моего погружения в детали и заранее «настроить» более результативную систему продуктового менеджмента. Рекомендую к прочтению всем новоиспеченным Product Managers.

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

Давайте выделим 3 основных области, в которых мы будем действовать: люди, продукт и вы сами.

Люди

1. Выясните ожидания СЕО или своего руководителя.

Скорее всего, вас наняли для того, чтобы буквально «заткнуть течь», поэтому вы ощутите на себе давление к немедленной демонстрации результатов. Обсудите с СЕО/руководителем цели, которые он ставит перед вами. Здесь важно убедиться, что у компании правильные ожидания от менеджера по продукту. Ваша главная цель на первый месяц — эффективно влиться в коллектив.

2. Запланируйте встречу тет-а-тет с каждым членом команды.

В зависимости от ее размеров, это действие может занять как несколько часов, так и все 30 дней. Тем не менее найдите на это время.

Я предпочитаю совместные прогулки. В этом явно что-то есть. Как минимум, смотреть перед собой комфортнее, чем сидеть лицом к лицу в переговорной комнате, общаясь через стол.

3. Задайте всем один и тот же вопрос: «Что я могу сделать, чтобы облегчить тебе жизнь?»

Этим вы покажете, что вы здесь для того, чтобы помогать, а не командовать. То, в какой манере люди будут отвечать вам – почти так же важно, как и что именно они будут говорить. Вы увидите, как члены команды относятся к роли PM, и что им от вас нужно.

4. Снимите груз с плеч людей.

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

Продукт

5. Запланируйте встречу с главным разработчиком, чтобы вникнуть в архитектуру продукта. Глубоко вникнуть.

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

Часто PM’ы пытаются впечатлить девелоперов своей технической подкованностью, но по моему опыту, последних куда больше впечатляют те продуктологи, которые задают много вопросов и не комплексуют говорить «Я не понимаю».

6. Не поддавайтесь желанию запрыгнуть с места в карьер и начать все менять.

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

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

7. Общайтесь с пользователями

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

8. Исправьте что-нибудь

Я верю, что PM может быть «технарем», и отличное начало – это самостоятельное исправление бага или запуск самой небольшой фичи.

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

Личное

9. Прочитайте всю документацию. Если чего-то нет, допишите.

Прочитайте всё, что можно прочитать: бизнес-требования, функциональные требования, спецификации, документацию, вики и т.п. Если найдете что-то, что еще не задокументировано или уже неактуально, исправьте это. По ходу дела обращайте внимание на то, что можно будет улучшить в будущем.

10. Поставьте себе цели по личному развитию.

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

Задайте себе вопросы:

— Что вы делаете по-настоящему хорошо и планируете продолжать делать? Получится ли это делать на новом месте? Как именно?

— В чем вам надо вырасти? Какие меры вы для этого предпримите? Как вы измерите свой прогресс?

11. Настройте свою «систему жизнеобеспечения».

Поставьте весь софт, который вам необходим. Настройте все инструменты, включите почтовые фильтры, комфортно обустройтесь на новом рабочем месте.

12. Получайте удовольствие от любимой работы!

А какие советы начинающим PM дали бы вы? Давайте обсудим в комментариях.

Источник: «12 things product managers should do in their first 30 days at a new company», Ken Norton, The Next Web.

Что такое дизайн-мышление: исчерпывающий гайд

В последнее время все те, кто так или иначе задействован в ИТ-проектах, в создании продуктов, в инновационном предпринимательстве, — слышат термин «дизайн-мышление», но мало, кто понимает, о чем идет речь.

Между тем, дизайн-мышление — это мощная методология, которая позволяет создавать новые продукты, которые решают реальные проблемы пользователей. Я тоже достаточно давно применяю принципы ДМ в своей работе над продуктам, будь-то GetLean, iPictory, Альфа-Банк или продукты моих клиентов по консалтингу.

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

Скриншот 2016-06-29 11.26.07

Посмотреть руководство