Дешёвая проверка решения
Что это такое
Дешёвая проверка решения начинается с самой недоделанной вещи, которая способна ответить, работает ли подход, — решение же принимают по её результату. В продуктовом исследовании артефакт часто не программный: страница-лендинг, консьерж-сервис, выполняемый вручную, прототип или изменение в уже работающем экране.
Почему это важно
Дорогая неудача получается из решения, которое в принципе не было неверным, но его перестроили прежде, чем кто-либо проверил. Консьерж-проверки и прототипы стоят дни и отвечают на тот же вопрос, что и релиз, — если вопрос задан заранее. Дисциплина защищает и от противоположной ошибки: от проверки чего-то настолько непохожего на настоящий продукт, что положительный результат ничего не значит.
Ключевые идеи
Назовите самое рискованное предположение и проверяйте только его
У решения есть несколько предположений: что людям это нужно, что они смогут этим пользоваться, что оно не нарушает юридическое ограничение, что оно по средствам. Выберите то, которое вероятнее всего неверно и дороже всего обойдётся, если это так.
Предположение повторные покупатели согласятся на хранение карты
Альтернатива они хотят избежать повторного ввода, а способ неважен
Проверка предложить запомнить данные для следующей покупки (без хранения)
-> если это конвертирует, хранение и не было сутью
Такая проверка стоит неделю и может убрать квартал работы.
Консьерж раньше автоматизации
Сделайте работу вручную для первых клиентов: если никому не нужно, чтобы это делали вручную, никому не нужна и автоматизация. Однако если нужно, ручной прогон научит вас, что именно она должна делать.
Предпочитайте поведение мнению
Клик, оплата или назначенный звонок считаются данными, а «я бы этим пользовался» — нет. Там, где единственный доступный сигнал — мнение, считайте его слабым и скажите об этом.
Определите правило решения вместе с проверкой
Пишите порог и вытекающее действие вместе: проверка без заранее согласованного решения превращается в спор о том, был ли результат хорошим.
Ограничьте время и сохраните результат в любом случае
Две недели, потом решайте: отрицательный результат, записанный как следует, избавляет следующую команду от тех же двух недель, и это более дешёвая половина обучения.
Практика
Проверьте одно предположение на этой неделе
Запишите предположение, самую дешёвую проверку, которая его опровергла бы, порог и решение — и проведите проверку.
Готово, когда: результат получен, решение принято, и оба записаны одним абзацем.
Проведите консьерж-тест
Предложите результат трём настоящим пользователям и выполните его вручную, затем запишите каждый ручной шаг, который пришлось бы автоматизировать.
Готово, когда: три пользователя получили результат, и вы можете перечислить шаги, которые должна покрыть автоматизация.
Частые ошибки
- Проверка самого лёгкого предположения — результат приятный и ничего не говорит; исправить: проверяйте самое рискованное.
- Собрано мнение вместо поведения — данные не могут обосновать решение; исправить: сделайте так, чтобы проверка требовала действия.
- Не согласовано правило решения — исход обсуждают, а не действуют по нему; исправить: запишите порог и действие до запуска.
- Проверка, непохожая на настоящую вещь — положительный результат ничего не значит; исправить: держите проверку дешёвой, но верной в том единственном измерении, которое важно.
- Отрицательные результаты выбрасывают — следующая команда повторяет те же две недели; исправить: записывайте, что проверяли и что вышло.
Что читать дальше
- Поиск проблемы, которую стоит решать (04-product-process/04-product-discovery/01-finding-a-problem-worth-solving) — оценённая проблема, на которую отвечает эта проверка.
- Продуктовое исследование (04-product-process/04-product-discovery) — трек, который закрывает эта глава.
- Lean UX (03-design-ux/37-lean-ux) — превращение результата в гипотезу очередного цикла.
- Прототипирование (03-design-ux/40-prototyping) — выбор точности прототипа для проверки.