Евгений Паршин написал о 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