Продуктовый подход

Чаще всего под «продуктовым подходом» подразумевают, что:

  • Вы решаете пользовательскую задачу, знаете что эта задача имеет смысл, она провалидирована — или это исследовательская задача и вы можете спрогнозировать желаемое изменение.
  • Вы умеете формулировать гипотезы на основе исследований или анализа данных. Исследования и анализ данных могут поступать от других подразделений, продакт-оунера или вы могли их сделать самостоятельно.
  • Вы умеете синтезировать решения или способы проверки гипотез. Гипотезы можно проверять по-разному. Не всегда для этого нужны прототипы или макеты или дизайн-система.
  • Вы умеете выбирать/приоритизировать и обосновывать предлагаемые решения. Например, используя простые модели «сложно/дорого», ICE (Impact, Confidence, Ease).
  • Вы разбираетесь в технической части работы — сотрудничаете с разработкой и учитываете их возможности и ограничения стека. Если вы придумали несколько решений и выбрали самое быстрое для проверки гипотезы вместе с разработкой — это может быть примером сотрудничества.
  • Вы знаете как будете замерять успех.
  • Вы проверили гипотезу, замерили результат, сделали выводы.
  • Вы учитесь на запусках и совершенствуете продукт, опираясь на исследования и данные.

Я чувствую как вы киваете, пока читаете все эти строки. Кажется что всё понятно и просто!

Очень рад, если это так!

Всё это вы сможете показать в описании проектов.

Всё это надо будет подтвердить фактами и показать на примерах.

Если кажется, что слишком много и сложно — не пугайтесь раньше времени!

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

Если еще не делали — есть смысл сделать на нынешней работе.


Работа над продуктом подразумевает формулирование гипотез и их проверку — либо на данных, либо на прототипах, либо через тестирование (прототипов или А/Б тесты).

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

Факт:

— 89% пользователей заходят только с мобильных устройств, поэтому мы решили отказаться от развития десктопной версии и форсировать оставшихся пользователей устанавливать приложение.

Неуклюжая попытка выдать мнение за факт:

— Мы решили что удобнее проверять на десктопе, поэтому мы начали с него.

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

Работа над продуктом сильно завязана на факты.


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

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

Если были А/Б тесты — расскажите о результатах экспериментов и каких-то важных особенностях запуска. Точно нет смысла рассказывать, что такое А/Б тесты (не тратьте время! — все знают).

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

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

Оцените разницу формулировок, про один и тот же проект:

— Я протестировал прототип на 15 пользователях и в основном были хорошие результаты!

Другой вариант:

— Я попросил 15 пользователей выполнить задание: найти причину сбоя работы программы на графике. 13 пользователей справились с задачей меньше чем за минуту, двое не нашли новый контрол и не справились. Такой же эксперимент с существующим интерфейсном на проде показал, что с заданием справились всего семеро пользователей из 15, но тоже в пределах минуты.

Какой пример лучше раскрывает результат и вызывает больше доверия?

Обе формулировки опираются на один и тот же факт — прототип проверен на 15 пользователях.

Дизайн взаимодействий