Павел Педенко — один из самых известных продакт-менеджеров Украины. Он возглавлял департамент разработки веб-проектов «1+1 Media», работал над сервисом Setapp в компании MacPaw, организовал самый большой хакатон в Европе Global Hack Weekend.
Сейчас развивает приложение для начинающих рэперов Raply, а также создает две конференции — Growth Marketing Stage и Product Management Stage.
На ивенте Bottleneck Night в InnoHub Павел рассказал, как и зачем формировать эмпатию в продуктовых компаниях. Записали самое интересное.
Зачем нужна эмпатия
Понимание важности эмпатии в продуктовых командах ко мне пришло во время работы над сервисом Setapp в MacPaw.
Однажды на утреннем scrum-совещании участник проекта сказал: «Ребята, я не знаю, что там написано в бэклоге, но сперва мне нужно пофиксить проблему, о которой написали в закрытой юзерской Facebook-группе».
В этот момент я понял: наконец-то продакт-менеджмент перестал быть только моей обязанностью — он стал обязанностью всей команды. Я понял, что команде не все равно, чем она занимается, и ребята искренне хотят помогать пользователям. Это и называется эмпатией.
Когда люди видят смысл в своей работе, они:
Хотят помочь, а не просто «закрыть таск». Поэтому не расценивают работу как ежедневную рутину.
Уверены в том, что строят. Продуктовые команды, которые занимаются инновационными продуктами с большим уровнем неопределенности, не уверены в своем деле.
Люди могут не верить продакт-менеджеру или фаундеру, но делать свою работу, потому что в офисе есть вкусные печеньки.
Однако если они видят проблему юзера и хотят ее решить, их уверенность растет.
Имеют общую цель. Команде важно понимать, ради чего она работает и что в итоге хочет получить. Так растет мотивация.
Чем команда с развитой эмпатией отличается от обычной
Разница — в отношении к работе. В командах, которые не сопереживают пользователю, часто можно услышать фразы в стиле «Проджект опять принес неинтересную задачу».
Если бы у них была развита эмпатия, это звучало бы как «Эта задача критична для юзера Х, поэтому мы должны ее решить».
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
Еще одно популярное выражение — «Кто вообще этим будет пользоваться?». Если сотрудники вовлечены в процесс, они бы отвечали примерно так: «На интервью пользователь Х попросил, чтобы мы решили эту проблему».
Интервью — один из самых популярных инструментов пользовательских исследований.
Кейс: как искали аудиторию Raply
Что делать, если у вас маленькая команда и вы не особо понимаете, куда двигаться? Решите, для кого вы создаете продукт и пообщайтесь с этими людьми. Нельзя строить эмпатию к тому, кого не видел.
На примере приложения для рэперов Raply расскажу, как это делали мы.
В Китае сейчас очень развита хип-хоп тусовка. Поэтому мы с моим другом решили создать приложение для китайских рэперов. Чтобы найти и лучше узнать наших пользователей, в прошлом году мы отправились в город Шэньчжэнь.
С какими проблемами мы столкнулись? Мы не понимали, чем сейчас живет хип-хоп культура. К тому же, не знали китайского, а на английском там практически никто не говорит.
Это усложняло поиск потенциальных пользователей.
Что мы сделали? Определились с рынком — поняли, что в целом нам нужны люди, которые пробовали читать рэп. После разбили аудиторию на сегменты:
- люди, которые хотя бы раз за последний год были на хип-хоп концерте
- люди, которые покупают атрибутику рэперов
- люди, которые слушают рэп-музыку на стриминговых сервисах.
Потом оценили, какой из этих сегментов легче всего найти. Начали фокусироваться на людях, которые ходят на хип-хоп концерты.
Спрашивали у знакомых китайцев, есть ли у них такие знакомые. Шаг за шагом нас начали представлять людям, которые связаны с этой тусовкой.
В итоге мы нашли ребят, которые пишут рэп. С помощью переводчика провели с ними интервью и дали протестировать прототип. Как оказалось, важно, чтобы в приложении был базовый auto tune, который выравнивает звучание.
Ранее нам никто не говорил об этом на интервью — удалось узнать только во время тестирования.
Если вы не знаете, для кого создаете продукт, скорее всего, вы делаете то, что никому не нужно.
Кейс: как в Индии запускали Uber
Жители Индии пользуются смартфонами старых моделей. Поэтому когда там запустился Uber, приложение банально не открывалось.
К тому же, местные по-другому взаимодействуют с сервисами такси. Они говорят, где находятся на уровне меток: «Я стою возле магазина Х» или «Я на рынке возле продавца кукурузы».
Продуктовая команда Uber до последнего отказывалась верить в это. Потом они сами приехали на улицы Мумбаи и убедились лично.
Это мотивировало запустить адаптированное приложение для Индии без карты на первом экране.
Эта история еще раз доказывает, что продуктовая команда должна видеть своего пользователя и понимать его проблемы. Тогда она действительно сможет ему помочь.
Благодаря такому подходу Uber сделал еще несколько успешных кейсов. Например, в Индии запустили оплату наличкой, а в Украине сделали возможным вызывать такси по телефону.
Последний эксперимент — один из самых успешных, сейчас его масштабируют на другие страны.
Два важных вывода
1. Если вы создаете продукт, то понимать пользователя — ваша обязанность. В команде нет отдельного человека, который должен этим заниматься. Это общая задача.
2. Потребности пользователя развиваются также, как и ваш продукт. Если вы создали успешный продукт, это не значит, что он всегда будет таким.
Исследования пользователей никогда не должны заканчиваться — постоянно коммуницируйте со своей аудиторией.
Хотите получать дайджест статей?
