Меня зовут Александра Клименко. Несколько лет назад я еще работала продактом, теперь я фулл-тайм занимаюсь своим проектом skillslab.center, где мы учим осознанным коммуникациям для жизни и бизнеса. В канале @normalno_delaj я разбираю кейсы роста команд и продуктов, а также важные нюансы коммуникации для успешной работы продуктовой команды.
Эта статья про процессно-коммуникационную составляющую, не техническую. Какими техническими средствами ее поддерживать, решать вам в зависимости от вашего «ИТ-зоопарка», я описываю общие принципы.
Точка 🅰 — вы команда-фичегенератор, в которой делают задачи по плану.
Зачем вам переходить в эксперименты, писать не буду. Мы же хотим в точку 🅱, где эксперименты существуют и движут разработку вперед.
А именно:
- отдельный процесс брейншторма и формирования гипотез
- оценки этих гипотез, в том числе из внешних источников
- планирование быстрых экспериментов
Здесь я беру небольшую команду, которая сама и занимается экспериментами, и сама же делает потом core продукт. От этого уже потом можно перейти к делению growth/core команды, делить команду на несколько продуктов и т. п.👀
Сразу говорю: алгоритм не мой, я только его исполняла, но гугление не помогло найти мне источник. Поэтому если кто-то сможет мне указать автора, буду благодарна. Может я даже что-то напридумывала к первоисточнику. Итак!
Шаг 1 — Анализ исторических данных
Ничего не меняем в текущем процессе. Берем предыдущие несколько релизов и выписываем: слева фича, справа — сколько она принесла.
Это иногда непросто, но полезно понять, как оценить что-то сделанное.
🔎 Находите существующие данные, ищете как посчитать экономический эффект вашей работы за предыдущие 2-3 месяца. Грустно, если в минус работали все это время, я и такое видела — но это только доп. аргументы, чтобы ввести культуру экспериментов.
Шаг 2 — Добавляем пост-анализ в процесс
При написании ТЗ и обсуждении внедрения любого изменения вы планируете, как можно посчитать его экономический эффект после его внедрения. Например, помечаете в аналитике, что эта заявка на продукт пришла с новой кнопки или из нового сервиса. И включаете в процесс анализа запуска 📊 (или создаете процесс анализа запуска) подсчет результатов после. Понемногу делитесь результатами с командой и руководителем (тут аккуратно, см. все мои посты по тому как общаться на сложные темы по тегу #нормальные_коммуникации_нормальный_продукт )
Шаг 3 — Добавляем прогнозирование, сколько принесет фича
📈В пост-анализе начинаем сравнивать, насколько сильно не попали в прогноз, и из-за чего, чтобы каждую итерацию улучшать процесс. Учимся прогнозировать без галлюцинаций.
Шаг 4—Выбираем способ скоринга
Любой, важно чтоб было что-то про деньги 💰, ключевую метрику 🎯 и про сложность/ресурсы/сроки исполнения. По-немногу между существующими задачами начинаем выбирать с учетом этого скоринга. Продолжаем сравнивать прогноз с результатами.
На этом этапе вы уже можете потихоньку входящие запросы от руководителя/стейкхолдеров пробовать оценивать. Как подавать: "мы хотим понимать, как сделать каждую фичу так, чтобы она реально нам что-то заработала, и вот я примерно так оцениваю разработку, а вот так — сколько мы заработаем. Нам норм такую фичу брать? Какие параметры хочешь уточнить в модели?"
Шаг 5 — Эксперименты
У вас набралась история - где-то квартал например - и вы можете нормально скорить и выбирать текущие задачи. Теперь наконец подходим к экспериментам 🧪!
Когда вы видите в беклоге фичу, которая большая, сложная, потенциально вкусная, но дорогая в ресурсах — предлагаете сделать сначала эксперимент. Не начинайте со сложного, мой первый эксперимент был отправленным по сегменту вручную письмом с заявкой на новый продукт, которую заполнило ровно 6 человек. Мы ушли подумать и вышли с новым продуктовым УТП, хорошо заработали.
Шаг 6 — Показываем пользу
Итак, на этом этапе вы структурировали работу своей команды. Вместо "мы сделали Х фич" вы уже пришли к "мы сделали Х экспериментов, чтобы найти как заработать Y рублей". Осталось разобраться, как быть со входящими запросами.
В процессе внедрения вы могли заметить, что ваши благие намерения не помешают окружающим (стейкхолдерам, СЕО и т.п.) периодически пробовать сломать ваш процесс, спуская сверху что-то срочное и обязательное.
Чтобы обеспечить вам и команде больше веса в процессе принятия таких решений, можно постараться формализовать все вышеописанное:
- написать инструкции
- сделать форму для предложения идей
- прописать чёткий алгоритм приоритезации поступающих идей aka всё, что не от CEO - в долгий ящик
Это не значит, что вы больше не будете вообще получать бесящих запросов или сможете их не выполнять, потому что есть процесс. Однако, влияние рандомных запросов на ваш беклог уменьшится, если удастся договориться обо всём не только на словах, но и на бумаге.
Теперь ваша задача — работать со стейкхолдерами, помогая им приносить и формулировать запрос так, чтобы добиваться общей цели — бизнес-эффекта от внедрения. Если вы пришли к этому через описанные мной шаги, у вас будет, чем аргументировать.
А уж дальше — я утверждала и продолжаю утверждать, что умение работать с давлением, переговоры и умение решать конфликты — важнейшие навыки продакта, аналитика, проджекта и любого другого ответственного за процессы и коммуникацию в команде. Удачи вам в этом!
Поделитесь в комментариях, как вы справляетесь с потоком задач и фантазий стейкхолдеров и слушают ли они ваши аргументы и цифры?
И заглядывайте в канал @normalno_delaj, чтобы читать больше о продуктах, коммуникациях, и как развивать ваш бизнес и команду.