В маленькой команде почти любая ошибка сначала выглядит как полезная работа.
Вы выпускаете функции, чините воронку, отвечаете пользователям, собираете аналитику. Каждый отдельный шаг кажется разумным. Только через несколько месяцев становится видно, что вся эта скорость вела немного не туда.
У меня ушло несколько лет, чтобы научиться замечать такие решения раньше. Не всегда до запуска, иногда хотя бы через неделю, а не через квартал. Ниже семь принципов, которыми я сейчас проверяю продуктовые ходы. Они выросли из работы над Viralmaxing, нашей аналитикой для контентных команд, и из моих повторяющихся ошибок.
Начну с одной из них.
Тестовый период, который привёл не тех людей
В первой версии Viralmaxing была прямая оплата. Пользователи говорили, что продукт дорогой и его нельзя даже попробовать. Возражение звучало логично, поэтому мы добавили тестовый период на семь дней, а позже сократили его до трёх.
Верх воронки сразу вырос. Регистраций стало больше, денег в моменте тоже стало немного больше. Казалось, мы убрали очевидное трение.
Через несколько месяцев картина стала хуже. В продукт заходило много людей с низким намерением. Им было нормально потыкать сервис и уйти. Нам от них был нужен честный и подробный ответ о ценности продукта. Эти две задачи не совпадали.
Мы тратили время на разговоры с людьми, которые ещё не успели полюбить продукт и не были заинтересованы помогать нам его улучшать. С ними всё было нормально. Это мы плохо настроили фильтр и приняли объём входа за качество сигнала.
В одном недельном разборе пять из шести оплат прошли в обход trial. Данные уже показывали, что отсутствие тестового периода не было главным барьером для мотивированных покупателей. Но мы слишком долго смотрели на регистрации и слишком мало на активацию, оплату, возврат и качество обратной связи.
Эта история хорошо показывает разницу между результатом первого и второго порядка.
Первый порядок выглядел так:
Уберём оплату на входе, получим больше пользователей.
Второй порядок оказался длиннее:
Получим больше регистраций, снизим среднее намерение, увеличим поддержку, загрязним обратную связь и замедлим обучение команды.
После этого я перестал оценивать решение только по ближайшему эффекту.
Что я называю сильным решением
Сильное решение даёт рычаг. Я вкладываю один, получаю десять. Оно увеличивает результат или убирает целый класс будущей работы. Иногда делает и то и другое.
Это мой практический вариант принципа Парето. Я не пытаюсь механически найти двадцать процентов задач в таблице. Я ищу ход, после которого десять следующих решений станут проще или вообще исчезнут.
Сильный ход меняет систему, в которой вы будете делать следующие ходы.
Хороший процесс не гарантирует удачного исхода. Плохое решение иногда случайно приносит деньги, а хорошее иногда заканчивается провалом. Если судить только по результату, мозг быстро обучается суевериям. Это явление известно как ошибка результата.
Поэтому я разделяю качество процесса и итог. Итог станет известен позже. Процесс можно проверить сейчас. Какой результат мы хотим? Какие факты у нас есть? Что считаем вероятным? Какой новый факт заставит нас передумать?
Теперь к самим принципам.
1. Сначала спросите, что можно остановить
Решение обычно понимают как выбор следующего действия. Какую функцию сделать, какой канал запустить, кого нанять. Для маленькой команды полезнее сначала спросить, что можно перестать делать.
На старте Viralmaxing мы увидели новый сервис на рынке и решили, что нам нужен похожий функционал. Решение казалось безопасным. Если это делает другой продукт, значит спрос уже доказан.
Функция действительно привела пользователей. Проблема была в том, что мы не собирались строить для них веб‑продукт. Приходили блогеры и соло‑авторы с небольшими личными задачами. Мы целились в команды, которые управляют трафиком и сетками аккаунтов, но начали размывать продукт под всех сразу.
Сильным решением оказалось остановить разработку. Мы убрали функцию из маркетинга и сфокусировали веб‑продукт на аналитике для команд. Сценарий для соло‑креаторов оставили в мобильном приложении. Два контекста перестали тянуть один продукт в разные стороны.
Один отказ очистил позиционирование, маркетинг, бэклог и разговоры с пользователями. Новая функция добавила бы ещё решений. Удаление убрало десятки.
У любого добавления есть альтернативная стоимость. Неделя на новую функцию означает неделю без улучшения того, что уже мешает нужному клиенту.
Перед новой работой я заканчиваю предложение:
Если я выбираю это, я не делаю…
Если закончить его невозможно, цена решения ещё не названа.
2. Требуйте внешнего ответа
Моя автоматическая реакция на неопределённость долго была простой. Пойти и сделать ещё что‑нибудь. Лучше всего написать код, собрать систему или переложить планирование в Obsidian.
Код я умею писать хорошо, а продвигаться хуже. Поэтому я интуитивно выбирал работу, в которой чувствовал себя сильнее. Она давала движение и чувство контроля, но не всегда давала ответ рынка.
В одном разборе полугодия я насчитал восемнадцать смен направления. В каждый отдельный момент я был занят. В сумме я слишком часто начинал новый ход раньше, чем рынок успевал ответить на предыдущий.
Теперь я задаю себе прямой вопрос:
Это действие даст внешний сигнал или только улучшит моё чувство контроля?
Внешний сигнал нельзя получить наведением порядка внутри собственной системы. Другой человек оплатил, вернулся, отказался, внедрил или порекомендовал. Пять разговоров с нужными людьми часто меняют продукт сильнее, чем две недели разработки, потому что после них у команды появляется новый факт.
Это не спор с кодом, аналитикой или планированием. Они полезны, когда сокращают путь до внешнего ответа. Проблема начинается, когда инструмент подменяет сам контакт.
3. Ищите узкое место до поиска рычага
Словом «рычаг» легко оправдать любую автоматизацию. Можно в десять раз ускорить работу, которая сейчас не ограничивает результат. Команда просто начнёт быстрее производить запас ненужного.
Я хорошо знаю состояние, когда открыто шесть или семь фронтов. На каждом есть небольшой прогресс, но ни один не доходит до внешнего сигнала. Проблема здесь не в скорости отдельных задач. Узкое место находится между начатой работой и контактом с реальностью.
Поэтому перед новым проектом или каналом я задаю два вопроса:
Что я перестану делать ради этого?
Если сделать только это, что изменится во всех остальных задачах?
Первый вопрос показывает цену. Второй показывает рычаг. Если ответы указывают в разные места, решение ещё не готово.
Сейчас у меня есть грубое ограничение. Один активный способ дойти до результата, остальные идеи ждут. Ограничение раздражает, зато не даёт перепутать количество начатой работы с движением.
4. Измеряйте качество сигнала, а не размер входа
История с trial научила меня смотреть на метрики как на цепочку, а не как на набор красивых чисел.
Метрика | Что она показывает | Чего она не доказывает |
|---|---|---|
Регистрация | Человек преодолел вход | Что у него есть сильное намерение |
Активация | Он дошёл до первого результата | Что результат достаточно ценен для оплаты |
Оплата | Человек согласился заплатить | Что он останется и внедрит продукт |
Возврат | Продукт снова понадобился | Что пользователь относится к нашему целевому сегменту |
Рекомендация | Пользователь рискует своей репутацией | Что тот же механизм сработает для всех сегментов |
Широкая воронка полезна, только если система умеет отделять сильный сигнал от шума.
Сам сигнал тоже нужно читать с учётом стимулов. Бесплатный пользователь решает одну задачу, платящий клиент другую, продуктовая команда третью. Даже честный совет меняется в зависимости от того, за что человек получает награду или наказание. Это происходит и без сознательной лжи, что видно в исследованиях конфликта интересов у советчиков.
Поэтому я спрашиваю, какой результат нужен человеку, который даёт совет. Пользователь может просить гибкость ради редкого личного случая. Команда может защищать функцию, потому что потратила на неё месяц. Алгоритм может награждать просмотры, хотя бизнесу нужны покупки от узкого сегмента.
Для контента логика та же. Миллион случайных просмотров и десять тысяч просмотров от людей с нужной проблемой являются разными результатами. Если заранее не выбрать нужный, метрика примет решение за вас.
5. Обратимые решения проверяйте быстро
Сложное решение редко становится простым после ещё одного часа анализа. Обычно данных мало, будущее зависит от других людей, а выбирать всё равно нужно.
Скорость должна зависеть не от уверенности, а от цены ошибки и возможности откатиться. В письме Amazon акционерам обратимые решения сравнивают с двусторонними дверями, а трудно обратимые с односторонними.
Первые стоит принимать быстрее и проверять действием. Вторым нужен больший запас данных. Частая ошибка маленькой команды состоит в том, чтобы неделями обсуждать обратимый тест или за вечер принять решение, которое меняет весь продукт.
Вместо вопроса «я уверен?» я использую три других:
Какой исход я считаю самым вероятным?
Какой дешёвый внешний ответ уменьшит неопределённость?
Какой факт заставит меня передумать?
Не нужна точность до процента. Достаточно назвать основной, хороший и плохой сценарии, а потом дать им грубые вероятности. Разговор, предпродажа, ручной прототип или маленький запуск обычно полезнее ещё одной внутренней презентации.
Вероятности не превращают нас в пророков. Они сохраняют след мысли. Через месяц можно увидеть, где мы недооценили риск, переоценили спрос и какие данные изменили прогноз.
6. Назначайте условие пересмотра до запуска
Самая опасная гипотеза незаметно становится частью самооценки. После этого новые данные уже не обновляют решение, а воспринимаются как нападение.
До запуска я записываю наблюдаемый факт и дату пересмотра. Не «посмотрим по ощущениям», а «если к этой дате не происходит это, меняем ход».
Перед важным запуском помогает premortem, который описал психолог Гэри Кляйн. Команда представляет, что план уже провалился, и независимо выписывает причины. Человеку больше не нужно спорить с общим оптимизмом. Ему поручили объяснить неудачу.
Для личного решения хватает десяти минут. Я пишу:
Прошло три месяца. Решение оказалось плохим. Почему?
Потом выбираю две причины с самым большим сочетанием вероятности и ущерба. Для каждой назначаю ранний сигнал и действие.
Если бы мы так разобрали trial заранее, один из сценариев звучал бы просто. Число регистраций растёт, а доля мотивированных пользователей падает. Ранним сигналом стала бы активация и качество обратной связи, а не верхняя часть воронки. У теста появился бы срок, порог и условие остановки до запуска.
Спор через месяц шёл бы не о том, кто был прав. Мы бы проверяли, наступил ли заранее названный факт.
7. Защищайте решение от ежедневного шума
Полноценного журнала решений у меня нет. Есть Obsidian и довольно скучная схема планирования. Сначала квартал, потом месяц, неделя и день. Во время работы я не хочу каждый час заново обсуждать направление.
Вечером я выписываю пять приоритетных действий на следующее утро. Это не первые пять дел из длинного списка. Это действия с самым высоким рычагом на сегодня. Если они сделаны, день уже успешный. Остальное можно не успеть.
Раньше список разрастался до десяти пунктов. Я его не заканчивал и к вечеру чувствовал, что снова сделал мало. Пять приоритетов работают лучше. Они сдерживают мой перфекционизм и не дают мелким задачам переписать решение, принятое на уровне недели.
Получается простая последовательность:
Квартал задаёт одну ставку.
Месяц выбирает результат.
Неделя находит узкое место.
День получает несколько действий, которые двигают именно его.
План нужен не для количества сделанного. Он защищает сильное решение от ежедневного шума и даёт рычагу время накопиться.
Навык делает следующую попытку точнее. Инструмент удешевляет следующую операцию. Аудитория увеличивает отдачу следующей публикации. Пол Грэм называет такие эффекты суперлинейной отдачей. Я использую более приземлённую проверку. Сильный ход должен повторяться дешевле или делать следующую попытку сильнее.
Короткий чек‑лист
Перед решением, которое может съесть больше недели, я отвечаю на семь вопросов:
Что можно остановить до начала новой работы?
Какой внешний ответ должно вызвать решение?
Где находится настоящее узкое место?
От какой лучшей альтернативы я отказываюсь?
Что произойдёт сразу, а что вслед за этим?
Решение обратимо и где предел теста?
Какой факт и в какую дату заставит меня передумать?
Если ответы помещаются в несколько абзацев, этого достаточно. Если запись превращается в отдельный проект, я, скорее всего, снова строю систему вместо решения.
Эти принципы не делают решения безопасными. Они повышают шанс, что ошибка будет дешёвой, сигнал чистым, а следующий ход понятным. Для маленькой команды это уже много.
Чем быстрее мы движемся, тем нужнее простые теоретические рамки. Без них легко принять скорость за направление, регистрации за спрос, функцию за продукт и занятость за рычаг. Я несколько лет учился замечать эту разницу. Надеюсь, у вас уйдёт меньше.
