Евгений Паршин написал о Riskiest Assumption Test (RAT).

— Это быстрая проверка идей, провал которых может похоронить весь продукт целиком;
— Для проверки идеи не обязательно нужен MVP. Проверить спрос можно с помощью лендинга с рассказом о продукте и формой заявки;
— Надо 1) выделить рискованные гипотезы — предположения, из-за которых с высокой вероятностью продукт не выживет, 2) оценить степень их значимости, 3) протестировать самые опасные;
— С помощью RAT можно проверить спрос, ценность продукта для пользователя, юнит-экономику и правильность выбранного сегмента;
— Найти рискованные гипотезы можно через исследования, брейнштормы, самостоятельные рассуждения. Например, можно посмотреть на Lean Canvas и спросить себя: что может пойти не так, что мы ошибочно приняли за истину?
— Каждую гипотезу можно оценить по способности похоронить продукт, количеству ресурсов, необходимых для проверки гипотезы, сложности тестирования, времени проверки.

#product #research

Михаил Наер и Иван Звягин написали о понимании задачи.

— Это документ, с помощью которого дизайнеры и стейкхолдеры могут сформировать единое представление о задаче;
— Его надо составлять на старте большого проекта (добавление каналов в банковское приложение) или отдельной задачи в рамках такого проекта (проектирование первого касания с каналами), то есть когда результатом будет изменение метрик;
— Документ помогает попасть в потребности клиентов и бизнеса, найти более сильное решение, замерить его эффективность, не брать задачи, которые решаются другими фичами;
— В большом проекте самостоятельно подготовить понимание задачи нереально, это надо делать на установочной встрече с дизайнерами и стейкхолдерами всех связанных продуктов;
— Документ состоит из вводных, миссии (как фича поможет пользователям), цели (какую пользу принесёт компании и почему), аудитории, критериев успеха;
— Бывают задачи без цели (социальные, некоммерческие проекты) или миссии (добавление согласий с юридическими документами), но лучше попытаться их найти;
— Описание аудитории отвечает на вопрос, кто наши пользователи и сколько их (и стоит ли задачу вообще делать);
— Критерии успеха помогают запланировать необходимые замеры и понять, решена ли задача. Они всегда направлены на миссию или цель;
— Что мы будем считать успехом? Есть ли бенчмарк? Что хотим не сломать? Что если результат не соответствует ожиданиям?

Смотрите также лекцию Ильи Бирмана о понимании задачи. #product

Иван Кунцевич написал, на какие вопросы надо ответить перед выполнением дизайн-задачи.

— Почему появилась эта задача? Возможно, у проблемы, которую хотят таким образом решить, есть решения попроще;
— Есть ли текущее решение, почему оно не работает? Если в продукте есть похожая функциональность, можно её адаптировать. Не придётся придумывать всё с нуля, решение будет знакомо пользователям;
— Как сейчас пользователи решают проблему? Возможно, есть сложившиеся паттерны (вне вашего продукта), которых стоит придерживаться;
— Какова цель бизнеса, на какие метрики он хочет повлиять? Понимая это, проще выбирать из нескольких решений, можно а/б-тестом сравнить их влияние на целевые метрики;
— Какую ценность получит пользователь? Чем больше пользовательских целей получится учесть, тем более качественным, функциональным и привлекательным получится продукт;
— Что ждём от финального результата? Если не отслеживать влияние конкретного решения на метрики, нельзя сделать вывод о его успешности. Если метрики с каким-то изменением упадут, будет сложно понять причину и откатиться назад.

#product

Егор Грохотов написал о быстрой проверке гипотез.

— В Авито разработку и развитие продуктов делят на стадии. Каждая завершается гейтом — встречей, где команда презентует и защищает свой прогресс перед руководителями направлений;
— Проверяют гипотезы на стадиях New Opportunities Discovery (этап исследования) и Product Discovery (этапы проверки спроса и ручной проверки). Цель — попытаться убить продукт на самой ранней стадии;
— Быстрее и эффективнее всего проверять самые рискованные гипотезы;
— Изучайте рынок в том числе через экспертов. Пара интервью с экспертами поможет быстро разобраться, как устроена интересующая вас сфера;
— Если этап исследования подтверждает потенциал идеи, при проверке спроса можно оценить продукт по верхнеуровневой воронке и нащупать каналы продвижения. Например, можно посчитать конверсию лендинга;
— Ручная проверка — сопровождение нескольких клиентов по всем этапам взаимодействия от заявки до целевого действия, чтобы выявить проблемы. Продукт при этом может быть собран на коленке;
— Подключайте юристов и бухгалтеров пораньше, чтобы собрать соответствующие ограничения и не тратить время на правки продукта потом;
— Скорость сборки прототипов новых услуг увеличивает заранее подготовленная инфраструктура: CRM, телефония, чаты, отдельный счёт в банке.

#product #research #process

Иван Вендров написал о тирании маржинального пользователя.

— Часто продуктовые компании заинтересованы в привлечении большого количества пользователей, в том числе и тех, кому продукт малополезен;
— Потому что их можно монетизировать за счёт рекламы. Или потому что нужен сетевой эффект;
— Такие компании смотрят на DAU. С одной стороны, продукт с высоким DAU — продукт, которым многие хотят пользоваться;
— С другой, компания фокусируется на пользователях, которые могут этот показатель увеличить (маржинальные, следующие пользователи, которых надо привлечь);
— Как сформулировал Киря в комментариях: компании забивают на опыт тех, кого уже привлекли, чтобы привлечь ещё, и оптимизируют продукт под следующих, кого предстоит привлечь;
— Если не привлечь внимания такого пользователя яркой картинкой или интригующим заголовком, он легко переключается обратно на ТикТок;
— Нетолерантен к сложности интерфейса, использует только большой палец, которым можно скролить. Добавление настроек ленты или кнопки «Показывать меньше такого» под контентом приводит его в гнев, так как занимает место яркого интригующего контента;
— Маржинальный пользователь — не всегда конкретный человек, иногда это состояние разума, и все когда-то бывали в таком состоянии;
— Популярные цифровые продукты часто спроектированы так, чтобы этим пользоваться. И продукты, которые становятся популярными, меняются в этом направлении.

In English. #product

Евгений Трифонов написал о feature creep.

— Это процесс излишнего добавления фич, когда получается переусложнённый продукт с кучей малозначимых возможностей, которые только путают людей;
— Философия UNIX: пусть каждая программа хорошо выполняет одну задачу. Для выполнения новой задачи начинайте с нуля, а не усложняйте старые программы добавлением новых фич;
— Причины feature creep: 1) Считается, что добавлять — хорошо; 2) Негативный эффект не заметен сразу, а накапливается со временем; 3) Новые фичи проще продать начальству; 4) Люди, работающие над продуктом, хорошо его знают, меню для них выглядит понятным, а функции — нужными; 5) Обычно пользователи просят добавить фич, а не убрать; 6) Новые фичи проще продать аудитории;
— Чтобы что-то с этим сделать, надо сначала признать существование проблемы и начать о ней говорить;
— Регулярно спрашивайте себя, не хрень ли я делаю;
— Осознайте, что количество фич, которые можно впихнуть в продукт — тоже ограниченный ресурс. Не надо им бездумно расшвыриваться;
— Проверяйте, как продукт выглядит для нового пользователя. Смотрите, как он его использует, чтобы сломать своё «проклятие знания»;
— Измеряйте, какими фичами насколько активно пользуются;
— Задумывайтесь, если бы фича была платной, стал бы кто-то платить за неё;
— Если продукт используют более чем для одной задачи, точно ли это должен быть один продукт, а не несколько разных;
— Важно уметь говорить «нет». Многим проще что-то добавить в продукт, чем объяснить, почему этого делать не надо.

#product

Кэлвин Френч-Оуэн написал о категориях пользователей и учёте их потребностей при планировании продукта.

— Продукт должен быть удобным покупателю, быть удобным пользователю не обязательно. Можно ориентироваться на практиков (покупатели и пользователи в одном лице) и руководителей (покупатели и отчасти пользователи);
— Продавать практикам помогает эстетика и хороший UX. Возможность совместного использования ускоряет распространение знания о продукте между специалистами;
— Руководителям важнее всего отчётность: насколько эффективно работают подчинённые, есть ли проблемы;
— Также им важна стандартизация. Когда все работают одинаково, повышается безопасность, можно экономить на масштабах. Нужна настройка ролей и доступов с учётом корпоративной иерархии, сложная модель данных, позволяющая настроить продукт под требования конкретного покупателя;
— Узнайте, что нужно тому, кто принимает решение о покупке. Продаёте начальникам отделов? Насколько им важен отполированный интерфейс для обычных специалистов?
— Если продукт покупают руководители, вкладывайтесь в отчётность, интеграции с почтой и Слаком, ежемесячные сводки;
— Если практики — в инвайты, вход через волшебные ссылки и G Suite, самообслуживание, автоматический биллинг, объединение пользователей. Устраните все барьеры при регистрации.

In English. #product

Марина Суслова написала о репозитории клиентских проблем и его реализации в Jira.

— Всё началось с желания создать CJM, чтобы понять, где есть слабые места и куда направить ресурсы. Такая карта в Миро быстро потеряла бы актуальность;
— Репозиторий включает все клиентские проблемы, известные из исследований и других источников: обращений, жалоб, общения с консультантами, обратной связи;
— Когда результаты исследований хранятся отдельно, новое исследование как будто отменяет предыдущее. А так все знания в одном месте;
— Чтобы избежать дублирования, новые проблемы попадают в лист ожидания, из которого их разбирают дежурные;
— У каждой проблемы есть критичность и частота возникновения, которые определяют её вес и помогают приоритизировать задачи;
— Также есть ответственный за решение, который указывает статус, решение, ссылку на задачу или эпик в Jira (её добавление переводит проблему в статус In progress, а её завершение — в статус Done);
— Репозиторий используют для стратегического планирования, наполнения беклога, отслеживания прогресса;
— В 2023 году появился облачный Jira Product Discovery, который решает ту же задачу, но репозиторий можно вести и в обычной Джире, чтобы избежать дублирования работы по актуализации статусов;
— Приоритизацию упрощают поля Impact, Effort и Score;
— Для группировки и построения разных дашбордов могут пригодиться поля: шаг клиента; тип проблемы (Need, Problem, Resolution); источник знания (исследование, обращение и так далее); категория пользователей; канал, где проблема возникает.

#problem #product #research

Евгений Бондковски написал об отличии дизайна, ориентированного на продукт (product-centric) и ориентированного на пользователей (user-centric).

— Product-centric подход смещает фокус с пользователя на баланс между потребностями пользователей и бизнеса и возможностями разработки;
— Продуктовый дизайнер учитывает задачи бизнеса и потребности пользователей (которые обычно конфликтуют) и предлагает дизайн-решения, которые легче всего реализовать (нужен постоянный диалог с разработчиками и вовлечение их на ранних этапах проектирования);
— Подходящее решение не всегда получается найти сразу. Можно использовать итеративный подход с постоянным сбором обратной связи и доработкой. Чаще всего в продуктовом дизайне надо не создавать продукт с нуля, а дорабатывать то, что уже есть;
— Например, поступила задача: добавить возможность оставить чаевые курьеру. Исследование показало, что 1% пользователей хочет оставлять чаевые, а 21% не любит этого делать. Если ориентироваться на пользователей, чаевые стоит разместить за второстепенной кнопкой на экране успеха, чтобы возможность была, но не мозолила глаза;
— Но в чаевых заинтересован бизнес: они повышают доход курьеров, которые не уходят к конкурентам (и даже переходят от конкурентов к нам). Значит, выбор размера чаевых стоит разместить на экране успеха;
— Обратная связь после тестового запуска показала, что функцией пользуются, но пользователи стали менее довольными: не нравится навязчивость, что просят заплатить ещё, непонятно, сколько из этой суммы получит курьер. Это можно итеративно улучшить;
— Учёт технических ограничений: варианты суммы чаевых вычислялись в процентах от заказа. Но разработать проще, если варианты будут фиксированными и заранее вычисленными из размера среднего чека.

#thinking #product