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

1. Abstract – серия документальных фильмов о дизайнерах от Netflix https://www.netflix.com/title/80057883

Герои, конечно, сами по себе легендарны (Кристоф Ниманн, например, иллюстрировавший обложки The New Yorker, или Тинкер Хэтфилд, создавший Air Jordans и придумавший самозашнуровывающиеся Nike). Но боже, как же офигенно снято! Мне кажется, ни один художественный фильм не захватывал меня так, как эта документалка 🙂фактурная история, потрясающий монтаж, а главное - работы дизайнеров и их восприятие мира так органично вплетены в общую канву и в визуальный ряд, что сам фильм по сути становится произведением искусства своего героя (или даже его квинтессенцией, если хотите).

Чистый экстаз.

2. 99% Invisible – подкаст о явлениях/предметах, о которых мы не задумываемся - но которые повлияли на нашу историю и культуру.

Вот, например, эпизод про отряд художников, которые во время Второй мировой войны делали "инсталляции" из танков на передовой и создавали у противника впечатление настоящей дивизии https://99percentinvisible.org/episode/show-of-force/

Или вот - про финское правительство, которое решило применять подход дизайн-мышления в политике и запустила крутой и немножко утопический эксперимент https://99percentinvisible.org/episode/the-finnish-experiment/

Или – про то, откуда берутся эмоджи и как добавить туда свое https://99percentinvisible.org/episode/person-lotus-position/

Начинаешь думать про эти мелочи (а иногда совсем даже не мелочи) и офигеваешь от всех этих взаимосвязей, которые порой и не замечаешь 🙂

@proproduct

Расскажу немного про подход к роадмапам в Intercom.

Как выглядел роадмап на моем предыдущем месте работы? Диаграмма Ганта на квартал и на год вперед. Процесс согласования был мучительным и долгим, но в итоге через пару месяцев что-то все равно начинало съезжать – где-то разработчик заболел, где-то неправильно оценили сложность проекта, где-то во время тестирования обнаружились новые факты, и пришлось сделать еще одну итерацию. Каждый месяц мы встречались с сейлзами и с саппортами, и каждый месяц к этой встрече я правила роадмап.

И каждый раз меня терзал вопрос: каким образом мы можем оценить сроки и сложность разработки еще до ее начала? Очень часто на этом этапе мы даже не до конца понимаем проблему – что уж говорить о решении. Более того, чем дальше во времени мы планируем, тем выше вероятность, что что-то изменится – появится новый конкурент, опубликуют новый закон, у пользователей появятся новые запросы, да и сам продукт никогда не статичен и постоянно развивается.

Intercom решил проблему просто: в их роадмапе нет сроков. План пишется на квартал вперед и составляется в Google Docs, в самой простой табличке на 5 столбцов:
- над чем мы хотим работать (название инициативы)
- краткая расшифровка для тех, кто вне контекста
- почему мы хотим над этим работать
- как это соотносится с квартальными целями компании (к какой цели можно привязать)
- текущий статус.

Команда выбирает и выстраивает в порядке приоритета 5 вещей, которые хочет взять в разработку на следующие 3 месяца. Last call за продактом, который презентует и аппрувит роадмап с руководством.
Формулировки могут быть не очень конкретными: так как мы еще недостаточно исследовали проблему и не начали прорабатывать решения, в роадмапе пишется область продукта, которую мы хотим улучшить. Это может звучать как, например, "измерение качества работы службы поддержки" или "автоматическая квалификация лидов". Уже дальше, в процессе исследований, команда определит cupcake-solution https://blog.intercom.com/start-with-a-cupcake/ и поставит более точные цели на 6-недельный цикл.
По истечении квартала не все пункты могут быть затронуты; какие-то перекочуют в следующий роадмап, какие-то просто уйдут по естественным причинам.
Долгосрочная перспектива определяется стратегией на 1 и на 2 года вперед.

У такого подхода, понятно, есть и плюсы, и минусы: поделюсь своими впечатлениями через некоторое время. Как минимум, в теории он пока что звучит привлекательно :)

@proproduct

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

- "рутина" продакта: что делают продакты на ежедневной и на еженедельной основе (составление планов, общение с командой, брейншторм-сессии, анализ фидбэка от пользователей, мониторинг "здоровья продукта")
- как выглядит процесс разработки с точки зрения продакта и на каких этапах надо вмешиваться 😉

Присылайте еще и записывайтесь тут:
https://t.me/proproduct/506

Очень, очень люблю Яндекс за их вклад в обучение продуктовых ребят и развитие индустрии в целом. Мне кажется, на их бесплатных курсах можно почерпнуть гораздо больше, чем на многих платных. На канале уже выложено 5 видео-лекций, темы супер-вкусные, единственный минус – каждая по полтора часа 😱 но, конечно, было бы желание, а время найдется 🙂

https://www.youtube.com/playlist?list=PLEs8EuAPI73Bj78n7-BIW3s1we0r15yJl

Друзья, мне написали организаторы конференции Target Summit и предложили подарить нашему коммьюнити 10 билетов (а они, на минуточку, сейчас стоят по 6 тысяч). Расписание выглядит очень интересно, темы отличные, спикеры крутые (Яндекс, Twitter, Sports.ru, Viber, Aviasales, Uber - весь цвет!) – смотрите сами:

http://targetsummit.ru/#agenda-section-1

Чтобы получить билет, необязательно быть продактом – нужно выполнить несколько простых условий:

- пройти опрос по ссылке до 12 дня 19 октября. Он про продуктивность, и там всего 4 вопроса, поэтому участвовать можно всем 🙂 https://goo.gl/forms/3rrr42QCJmtwQv5I2
- вечером 19 октября я рандомно выберу 10 ответивших, а организаторы Target Summit вручат им призы.

Всем удачи!

Иииии список победителей:

Николай Атапков
Екатерина Петрова
Татьяна Васильева
Влад Дерипаско
Катя (@tekunova)
Даша Чикишева
Пирогова Вика
Наталья Чечулина
Александра Хадеко
Полина Опарина

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

Всем спасибо за участие!

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

История эта, как ни странно, про стетоскоп. Вплоть до начала 19 века у врачей практически не было возможности понять, что происходит в организме больного. Следствием этого стало то, что симптомы принимались за саму болезнь: то есть, если сейчас у человека жар, это может быть признаком десятка болезней, в те же времена болезнь была одна – жар, и лечили ее одним и тем же способом (что, конечно, далеко не всегда давало хороший результат). Но в один прекрасный день французский врач Рене Лэннек свернул в трубку свою тетрадь и приложил к груди пациента – вместо того, чтобы простучать ее пальцами, как делали раньше. Лэннек не только изобрел стетоскоп и улучшил качество диагностики: новый уровень слышимости позволил различить множество разных болезней и, соответственно, предложить новые способы лечения.

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

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

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

Неделю заметок о сборе фидбэка предлагаю считать открытой; пишите мне в личку вопросы, если есть такие ;)

@proproduct

Что я понимаю под "базовым общением с пользователями"

Дисклеймер: я пишу исключительно о своем опыте и о том, что работает/не работает для меня. Если вы успешно пользуетесь каким-то методом и делаете крутой продукт, вам не нужна эта статья 😉

Начну с того, что им не является:

- опросы типа "Как вы относитесь к X?", "Какая картинка вам нравится больше – зеленая или красная?".

Даже если вы попросите пользователя написать абзац текста (а не выбрать из несколько вариантов):

1) вы можете некорректно сформулировать вопрос и повлиять на ответ пользователя
2) вы можете выбрать неправильную последовательность вопросов, которая повлияет на ответ пользователя
3) пользователь может неправильно понять вопрос
4) пользователь может ответить коротко и не раскрыть тему до конца
5) вы можете неправильно понять ответ пользователя

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

Почитайте вот эту статью, например, про то, как легко "сместить" восприятие пользователя http://www.npr.org/2016/11/06/500678100/the-art-of-the-vote-who-designs-the-ballots-we-cast. Ну или кейс из моей практики: мы хотели посчитать NPS и спрашивали у пользователей по шкале от 0 до 10, насколько они готовы порекомендовать продукт. Группа А видела просто шкалу; в ней средний результат был 7.5. В группе Б на шкале уже стоял преселект на отметке 6. Средний результат – 8.9.

- customer development

Product development answers the question “When (and what) can they buy?”
Customer development answers the question “Will they buy it?”
(из книги Cindy Alvarez)

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

Во-первых, вам очень повезло, что аудитория вашего продукта потенциально такая широкая, что вам подойдет первый же прохожий.
Во-вторых, вы застаете людей врасплох. Это значит, что ваше время общения будет сильно ограничено (и до истинных проблем вы не успеете докопаться), да и откровенность респондентов тоже (вот честно, будете ли вы вываливать всю подноготную на, пусть и обаятельного, незнакомца?).
В-третьих, что самое главное, вы тестируете не сам продукт, а его маркетинговую часть (в частности, позиционирование и ценообразование). Если вы классный сейлз, то продадите любую идею. Но лично для меня показатель качества не ответ на вопрос "купят ли?" (сколько людей покупает кучу треша, который им совершенно не нужен; да и достигается увеличение этой метрики во многом не через улучшение качества продукта), а "будут ли регулярно пользоваться" (ну и платить, если уж на то пошло).
В общем, я использую этот метод примерно так же, как 5 seconds test, – могут ли люди, никогда не видевшие продукт, за короткое время четко понять его value proposition. Но это точно не относится к регулярному общению.

- сложные usability исследования, для подготовки которых требуются человекоресурсы, деньги и время

Этнографические исследования, diary studies, UX исследования в лаборатории и так далее – все то, что вы будете делать, скорее, ad hoc, чем на регулярной основе, потому что это дорого и долго. Вот здесь хороший чеклист для определения хорошего исследования https://www.userfocus.co.uk/pdf/researchquestions.pdf

Какие же тогда критерии для базового общения с пользователем?
- случается регулярно
- может быть организовано кем угодно в команде (PMом, дизайнером, разработчиком)
- основано на поведении пользователя
- ну да, и продукт уже существует. Когда вы на стадии прототипа, это другой тип исследований 😉

@proproduct

Примеры:
- разбор и ответы на тикеты в саппорте. В Intercom с ними работает весь R&D и особенно PMы
- сбор фидбэка после запуска беты/фичи
- разговор с пользователем, который делает что-то в вашем продукте не так, как другие пользователи.

Завтра расскажу, зачем мы это все делаем и как это влияет на разработку 🙂

@proproduct

Зачем нужно общаться с пользователем

Дисклеймер: я пишу исключительно о своем опыте и о том, что работает/не работает для меня. Если вы успешно пользуетесь каким-то методом и делаете крутой продукт, вам не нужна эта статья 😉

Я работаю в b2b SaaS компании; это накладывает определенные ограничения на количественные исследования: если в b2c спокойно можно катать эксперименты хоть каждую неделю, в b2b, где продукт интегрирован в рабочий процесс и используется регулярно, за подобные фортеля вам надают по шапке. Поэтому общение с пользователями критично важно для разработки.

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

Уже лучше, если у вас в команде (или на аутсорсе) есть исследователь; но, как мы уже говорили, подобные тесты требуют больших ресурсных затрат и потому проводятся не так часто (раз в месяц уже хороший показатель). Как следствие, теряется связь с пользователем, "чутье", которое позволяет продакту принимать решения. Если держать постоянный контакт, то, на самом деле, и масштабные юзабилити тестирования будут требоваться не так часто.

Расскажу чуть подробнее про то, что я делаю на регулярной основе:

- анализ запросов в поддержку. В Intercom вообще есть традиция делать Customer Support Day и идти на день работать в саппорт. Но здесь речь не совсем про то, чтобы отвечать на вопросы пользователей (хотя это тоже супер полезно).

Мы используем Idiomatic – тулзу, которая позволяет группировать запросы по темам, и проводить базовый анализ: например, на этой неделе возросло количество жалоб на фичу x, но стали меньше писать про фичу z.

Также у наших саппортов есть система тегов непосредственно в Intercom, чтобы продактам было легче категоризировать запросы; плюс, если пользователь просит новую фичу, саппорты просят подробнее рассказать про use case.

Я стараюсь каждую неделю "нырять" в самую "громкую" группу: беседую (либо прямо в нашем же чате, либо по телефону) с пользователями, чтобы докопаться до проблемы. Все инсайты я заношу в ProductBoard как центральное место для сбора фидбэка: меня покорило расширение для браузера (выделяю кусок чата, нажимаю кнопку, отправляю фидбэк с комментарием - огненно!) и привязка фидбэка к фичам. Дизайнеры/разработчики, которые в данный момент работают над реализацией, могут посмотреть на пользовательские кейсы; если же фича новая, эта информация затем помогает в приоритезации и подготовке роадмапа на следующий квартал.

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

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

Еще нельзя забывать, что запросы в поддержку – это все же vocal minority. Не поддавайтесь на провокации и обязательно валидируйте гипотезы количественно ;)

@proproduct

- фидбэк на бету/новую фичу. Нам опять повезло: мы активно используем для этого собственный продукт – к примеру, тегируем кастомеров в эксперименте и затем отправляем им сообщения с "разогревающим" вопросом (что-то простое, вроде – вот наша фича, так она работает, что думаете). Сообщение должно быть максимально короткое и простое, чтобы пользователь захотел черкануть хоть строчку, а там уже продакт может подхватить разговор и договориться о созвоне. Пользователю хорошо, потому что мы рассказали ему о новой функциональности (еще круче, если он о ней когда-то просил, и тут вдруг мы ;); нам хорошо, потому что есть предлог еще раз пообщаться с людьми, – сплошной win-win. Для нас это важно еще и потому, что наши два принципа ship to learn и start small, think big предполагают несколько итераций – и как раз фидбэк помогает понять, какой шаг должен быть следующим.

Что важно: делать это по горячим следам – зарелизили, собрали фидбэк.
Дальше, если что-то по цифрам не сходится, пошли собирать фидбэк еще раз.
(но это, конечно, неприменимо к фичам, где требуется долгий период адаптации/обучения).

- "в режиме чтения" (а не общения): разговоры потенциальных пользователей с сейлзами. Вот тут как раз много можно узнать о конкурентах, о их текущих проблемах, о киллер-фичах, которые могут повлиять на решение о покупке. Это работает для b2b; для b2c должно быть регулярное полномасштабное исследование на уровне компании (а не только разработки): у нас оно информирует стратегию или запуски новых продуктов (как раз, например, Live Chat for Sales, над которым я работаю).

Если подвести итог :)
Регулярное общение с пользователем очень важно, но о трёх вещах нельзя забывать:

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

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

- Любой качественный фидбэк должен быть затем валидирован на данных.

Завтра будет трансляция о работе продакта (можно задать как раз вопросы про общение с пользователями, если на что-то еще не ответила) https://t.me/proproduct/509

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

@proproduct

В чатике между тем опять всплыла прекрасная статья про Goals-Signals-Metrics https://library.gv.com/how-to-choose-the-right-ux-metrics-for-your-product-5f46359ab5be - может, стоит перевести ее уже (и немного дополнить)? 😉

Хотите ли вольный перевод?
anonymous poll

Да – 504
👍👍👍👍👍👍👍 70%

Нет, почитаю на английском – 217
👍👍👍 30%

👥 721 people voted so far.

Друзья, вот ссылки на те тулзы, которые я упомянула во вчерашнем посте; это не внутренние интеркомовские тулзы 😉

https://idiomatic.io/
https://www.productboard.com/

Всем участникам трансляции:
- ссылка на трансляцию придет примерно за час до начала
- после окончания трансляции по той же ссылке будет доступна запись

Примерный план нашей беседы тут 😉
https://t.me/proproduct/509

К слову, друзья: у нас в Intercom много открытых вакансий (в том числе, джуниорских) – если мы с вами успешно работали вместе, напишите мне в личку, я с радостью вас порекомендую!

Офисы в Дублине, Лондоне, Санфране; команда супер крутая, продукт огонь; хороший пакет и много плюшек 🙂
Часть вакансий здесь: https://www.intercom.com/careers

Сегодня этому каналу ровно год. Когда я его начинала, и подумать не могла, до чего это все дорастёт :)) тогда казалось - вау, тысяча человек, как много! А сейчас нас больше 8 тысяч, и даже это не кажется пределом.

В последнее время я пишу не так часто, как хотелось бы, каюсь. Но и терять в качестве не хочется; зачем делиться ссылками, которые добавят в покет и никогда не прочитают, или писать бесполезные статейки в духе «Капитан Очевидность»? На каждую заметку я трачу по паре часов: проверяю несколько источников, стараюсь переговорить с экспертами, режу текст, чтобы не было воды (хотя порой все равно получается полотно 🙈).

Спасибо вам, что читаете; спасибо, что подкидываете классные вопросы и пишете добрые слова - это очень мотивирует, особенно когда после долгого рабочего дня садишься писать статью :) отдельное спасибо ребятам, которые с момента основания поддерживали и помогали с развитием канала. Вы крутые! 💪

Stay tuned & keep questioning! 🔥🎮

Кстати, друзья: 26 декабря я наконец-то окажусь в Москве и буду рада организовать митап/встречу/лекцию - в прошлый раз, кажется, классно получилось 😉 пишите мне в личку, если есть идеи-предложения по теме или площадке!

Как выбрать правильные метрики для продукта

Какое-то время назад все активно начали делиться вот этой статьей от UX-исследователя в Google Ventures про то, как выбрать правильные UX метрики для продукта https://library.gv.com/how-to-choose-the-right-ux-metrics-for-your-product-5f46359ab5be. Статья крутая, но после практического использования возникают вопросы :) буду публиковать по кусочкам вольный перевод (в кавычках) и мои комментарии.

"В процессе дизайна можно полагаться на пользовательские данные и на результаты экспериментов. Это то, что сейчас называется data-driven design, но я предпочитаю термин data-informed design – "рулит" все еще дизайнер, а не данные.
Чтобы это работало на практике, надо смотреть на правильные метрики. Базовые цифры по трафику (количество просмотров страницы или количество уникальных пользователей, к примеру) легко отслеживать; они дают неплохое понимание, как поживает ваш сайт; но часто они совершенно бесполезны для оценки UX-изменений. Все потому, что они слишком общие и напрямую не отражают качество продукта или цели проекта – на их основе сложно понять, что делать дальше.
Я работаю UX-исследователем в Google, и мы разработали несколько полезных фреймворков для определения и выбора метрик, отражающих:
- качество user experience (HEART)
- цели вашего продукта или проекта (Цели-Сигналы-Метрики)".

Во-первых, да, data-informed. INFORMED by data, not driven.
Сначала стратегия и цели, затем метрики. Сначала гипотеза и, опять же, цели, затем эксперимент. Накручивать циферки только ради циферок можно очень долго и очень успешно, только продукт от этого лучше не станет.

Во-вторых, да, на "базовые метрики" смотреть бесполезно. Ну поверьте, нет такой волшебной пилюли, которая работала бы для всех. Безусловно, у вашего продукта могут трекаться такие же метрики, как и других продуктов: те же DAU, Retention, ARPU и прочие. Но вот вопрос, какие из них будут для вас более важны, а какие – менее. Условно говоря, приложение, которое отправляет сигнал sos в ближайшую службу спасения, вряд ли будет смотреть на Retention.

В-третьих, какая-то повальная путаница с тем, что считать метриками продукта, что – метриками проекта, а где вообще продакт маркетинг затесался. По сути все просто: вот у нас есть продукт, которым можно как-то пользоваться. То, что происходит до начала использования, относится к продакт-маркетингу; то, что происходит во время, к продукту. Проект (~фича) – это гипотеза внутри продукта; соответственно, на высоком уровне успех проекта определяется метриками продукта, но также имеет и собственные "технические" метрики, которые позволят понять, все ли работает хорошо, не сломалось ли чего.
И есть еще отдельная группа метрик для исследований (время выполнения заданий или как раз Task Success, о которой говорится в статье), которые позволяют сделать количественные выводы для usability тестов. Ну это так, для общей картины ;)

Возвращаясь к моей любимой медицинской аналогии:
- представьте, что вы пришли на прием ко врачу. А он такой померял у вас температуру, взял анализ крови, отправил на узи, а потом говорит – ну да, температура у вас низковата, давайте я вам таблетки пропишу.
- а потом оказалось, что просто градусник сломался, а у вас и не болело ничего.
- или болело колено, а вас лечат от низкой температуры - потому что ниже среднего по больнице, и вообще: сказали, что у всех надо мерять температуру, значит, надо мерять!

TL;DR
- начинайте с вопросов, на которые хотите ответить, а не с данных. Данные нужны для информирования решений, а не для их принятия.
- не ищите one metrics to rule them all (одну ключевую метрику). Нету одного стандартного сета метрик на всех, потому что разные продукты решают разные проблемы и преследуют разные цели. Начинайте с целей и проблем, а затем уже продумывайте, какие цифры могли бы подсказать вам ответ/направление.

@proproduct

Ну что, поехали разбираться дальше 🙂

"Помогая гугловым командам с UX метриками, мы заметили, что наши предложения обычно попадают в какую-то из 5 категорий:

H - Happiness (Счастье). Измеряет отношение пользователя, часто через опросы. Примеры метрик: удовлетворение, воспринимаемая легкость использования и NPS".

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

Я пользуюсь Spotify каждый день. Я счастливый пользователь? На мой взгляд, это такой же странный вопрос, как – вот вы пользуетесь молотком, вы счастливый пользователь молотка? Эмоции – это про бренд, про историю (которой, к слову, занимается маркетинг); продукт – про решение задачи, про ценность. Пользователи могут питать какие-то чувства к Яндексу или к Гуглу, но не к поисковому движку как таковому – тут у них сугубо рациональный подход.

Опять же, если мы разрабатываем фичу (это метрики проекта, упомянули их в предыдущем посте), то должны думать о метриках продукта – и тут тот же NPS, к примеру, совершенно бесполезен: замерить таким способом влияние отдельно взятой фичи практически невозможно.

Другое дело, если мы спросим: а извлекает ли юзер какую-то пользу из нашего продукта? Концепт ценности (vs счастья) также отлично подходит и для приоритезации новых фич.

Как определить ценность? Идите от обратного: спросите себя - если мы представим идеального пользователя, который получает максимальную пользу от продукта, что он сделал/делает?

Если это Spotify, возможно, он слушает музыку > n минут в день.
Если это Uber, возможно, он делает n-ное количество поездок за определенный период.
Если это Slack, воможно, он пригласил n коллег в чат.

По сути, это называется "активация": первый момент во время использования продукта, когда пользователь извлекает ценность. Важно, что пользователь вполне может и не осознать этот момент 😉

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

@proproduct

Meanwhile напомню перед выходными, что куча материалов из этого канала лежит на Medium 😉

https://medium.com/@buldakova