Escaping the Build Trap, глава 18: Исследование решений

Главная мысль: прежде чем строить решение, проверьте его быстрым и дешёвым экспериментом. Цель этого этапа — узнать, а не заработать.

Marquetly: первый эксперимент

Команда Кристы нашла проблему крупнее, чем думала. Учителя тратят больше 80 часов за два месяца на монтаж видео. Некоторые переснимают видео снова и снова, лишь бы не монтировать.

Что команда хотела узнать:

• Монтаж — проблема для большинства учителей. Это уже известно.
• Неизвестно другое: если снять с учителей монтаж, они будут чаще публиковать курсы?

Как устроили эксперимент:

• Два видеомонтажёра из маркетинга помогали две недели. Их выделил VP маркетинга.
• Они могли обработать около семи курсов в неделю.
• Метрика успеха: минимум 10 курсов из обработанных опубликованы за месяц.

Что узнали:

• Учителя не знают, как выглядит хорошее видео для онлайн-курса. Команде пришлось давать советы.
• Значит, в решение нужен гайд или шаблон.
• Эксперимент не масштабируется больше чем на 14 человек за две недели. Это нормально для такого типа.
• Через три недели 12 учителей опубликовали курсы. Успех.

Команда записала, что важно в решении:

Что нужно учителю	Что сделает или сломает решение
Гайд, как снять хорошее видео	Контроль над готовым результатом
Склейка видео, слайдов, картинок, аудио, YouTube	Легко передать материалы монтажёру
Текст поверх видео	Простой язык, без технических слов
Вводный слайд

Build to learn, а не build to earn

• Компании путают два режима: строить, чтобы узнать, и строить, чтобы заработать.
• Эксперимент — это build to learn. Он проверяет гипотезу. Он должен быть коротким.
• Если гипотеза подтвердилась, эксперимент выбрасывают. Потом строят надёжное и масштабируемое решение.

Про MVP:

• Термин из книги The Lean Startup. Многие поняли его неправильно.
• Частая ошибка: «MVP — это всё, что мы выпустили в первом релизе».
• Так MVP становится способом быстрее выпустить фичу. Качество падает, а узнаём мы мало.
• Определение автора: MVP — это минимум усилий, чтобы чему-то научиться.
• Из-за путаницы автор больше не говорит «MVP». Она говорит «эксперименты с решением».

Product Kata помогает держать фокус. Она всегда спрашивает: «Что нам нужно узнать дальше?»

Закройте петлю

Эксперимент не живёт долго. Поэтому:

• Ограничьте число клиентов в эксперименте.
• Заранее решите, как вы его закончите.
• Скажите клиентам, зачем тест, когда и как он закончится и что будет дальше.

Три типа экспериментов

Тип	Как выглядит для клиента	Когда подходит	Пример из книги
Concierge	Клиент знает, что работу делают вручную	Мало пользователей, нужна тесная обратная связь	Marquetly монтирует видео; прогноз позиций SEO в Excel
Wizard of Oz	Выглядит как готовый продукт, но внутри всё вручную	Нужна обратная связь в большом масштабе	Zappos; подписки в интернет-магазине
Concept testing	Клиенту показывают идею: лендинг, макет, прототип, видео	Нужно быстро показать идею и собрать реакцию	Видео Dropbox для инвесторов

Concierge

• Нет кода. Можно начать быстро. Много обратной связи.
• Хорошо подходит для B2B. Многие такие компании начинали с ручной работы для клиентов, а потом автоматизировали.
• Пример: в SEO-компании автор месяц отправляла клиентам прогноз в Excel. Команда узнала, какими факторами клиенты хотят управлять. Потом фичу закодировали и успешно запустили.
• Минус: не масштабируется. Посчитайте, сколько людей вы можете обслужить за период.

Wizard of Oz

• Основатель Zappos сделал простой сайт. Когда приходил заказ, он сам покупал обувь в магазине и отправлял её. Так он проверил спрос без склада и инфраструктуры.
• Подписки в интернет-магазине: система доставки не умела подписки. Команда сделала копии товаров с пометкой «подписка». Поддержка вручную перезаказывала их каждый месяц.
• Через четыре месяца увидели: многие отменяют подписку на второй-третий месяц. Клиенты сказали, что хотят сами контролировать покупки.
• Новое решение: простое ежемесячное письмо-напоминание. Продажи сильно выросли. Экономия — больше $100 000 на разработке.
• Не держите такой эксперимент долго. Он выглядит настоящим, но внутри ручной труд.

Wizard of Oz можно совмещать с A/B-тестом. Но A/B-тест не нужен, если:

• направление решения ещё совсем неясно;
• трафика мало и результат не будет статистически значимым.

Concept testing

• Скорее генеративный, чем оценочный. Помогает понять, чего хочет пользователь.
• Чтобы сделать его оценочным, нужен чёткий критерий «прошёл / не прошёл». Автор называет это ask: обязательство, деньги, время. На лендинге ask — это email.
• Dropbox не мог объяснить инвесторам свою идею синхронизации файлов. Команда смонтировала видео, как продукт будет работать. Инвесторы поняли идею, и Dropbox получил финансирование.

Когда тяжёлые эксперименты не нужны

• Эксперименты нужны при высокой неопределённости и большом риске.
• Пример: команда нашла, что на экране нет нужной кнопки. Она хотела A/B-тест. Автор сказала: проблема и решение известны, просто сделайте. Но потом измерьте эффект.
• Средний случай — прототипы. Они не требуют кода и проверяют конкретный сценарий.
• Риск прототипов: красивые экраны для проблемы, которую вы ещё не поняли. Сначала исследуйте проблему.

Эксперименты в сложных отраслях

«У нас так нельзя» — неверно. Лендинг и Wizard of Oz подходят не всем, но учиться можно везде.

• Космический шаттл строят годами. Но тест панелей на жаростойкость — это тоже эксперимент.
• GiveVision делала очки для незрячих людей. Программу ставил сторонний производитель. Цикл — около шести месяцев, обновить потом нельзя.
• Сначала команда наблюдала за пользователями. Приоритеты: читать надписи (например, номер автобуса), информацию о питании, деньги, цвета.
• Потом поставила программу на Android-телефон. Телефон крепили к «очкам» с 3D-принтера. Пользователи носили их целый день и давали обратную связь.
• Так команда снизила риск без месяцев производства.

Внутренние продукты

• Автор вела внутренние инструменты в интернет-магазине. Сначала она считала, что дизайн там не важен.
• Через год к ней стояли очереди: люди не могли сами загрузить товары.
• Начальник сказал: если люди не могут пользоваться инструментом, это ваша проблема, а не их.
• Она начала работать как с внешними пользователями: формулировать проблемы, исследовать, делать concierge, concept testing, прототипы.
• Результат: сотрудники довольны, текучка ниже, нанимать надо меньше.

Выбор решения в Marquetly

Карен, VP of product, выбирает между тремя вариантами: build, partner или buy.

Вариант	Суть
Сервис	Нанять видеомонтажёров
Своё ПО	Написать редактор видео самим
Купить технологию	Встроить готовый простой редактор в платформу

• Третий вариант лучше по марже. Риск: учителя могут не справиться сами.
• Карен нашла подходящий редактор у компании из Будапешта.
• Второй эксперимент: 40 учителей, 30 минут обучения и гайд. Дальше сами.
• Итог: 30 из 40 опубликовали курс за месяц. Ниже, чем в concierge, но намного выше обычных 25%.
• Данные из Product Kata стали основой бизнес-кейса для руководства.

Ключевые термины

Термин	Значение
build to learn	Строим, чтобы проверить гипотезу. Результат потом выбрасываем
build to earn	Строим надёжный продукт для заработка
MVP	По автору: минимум усилий, чтобы узнать что-то важное
Concierge	Ручная работа для клиента. Клиент это знает
Wizard of Oz	Продукт выглядит настоящим, но внутри работают люди
Concept testing	Показ идеи: лендинг, макет, прототип, видео
Ask	Что пользователь должен дать (email, деньги, время), чтобы тест считался пройденным
Close the loop	Заранее спланировать и объяснить клиентам конец эксперимента
Build, partner, buy	Выбор: сделать самим, найти партнёра или купить

Что это значит на практике

• Concierge для данных. Перед тем как строить пайплайн и дашборд, соберите отчёт вручную в SQL или в таблице для 2-3 пользователей. Посмотрите, какие поля и разрезы им реально нужны.
• Wizard of Oz для витрины. Новую метрику можно сначала считать скриптом раз в неделю и отдавать в знакомом интерфейсе. Если ей пользуются, тогда делайте incremental-модель в dbt и оркестрацию.
• Выбросьте эксперимент. Ручной скрипт или временная таблица не должны стать продом. Запишите, когда эксперимент закончится и кто его выключит.
• Не тестируйте очевидное. Если в дашборде сломан фильтр, просто почините. Но потом проверьте, что число вопросов в чат поддержки упало.
• Внутренние пользователи — это клиенты. Если аналитики постоянно просят вас «выгрузить данные», это проблема вашего продукта данных, а не их.
• Build или buy. Перед тем как писать свой коннектор или каталог данных, проверьте готовые инструменты. Но сначала проверьте, что пользователи смогут ими пользоваться.

Вопросы для самопроверки

1. Чем build to learn отличается от build to earn? Почему автор перестала использовать слово MVP?
2. Чем concierge отличается от Wizard of Oz? Когда выбрать каждый?
3. В каких двух случаях A/B-тест не подходит?
4. Как GiveVision проверила решение, если производство очков занимало около шести месяцев?

Предыдущая: 17. Исследование проблемы. Следующая: 19. Разработка и оптимизация.