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