Сильные команды планируют побочки, слабые предпочитают о них не думать и избегать

Летом я проходила большой чекап и теперь горжусь тем, что после прошлогоднего чекапа дисциплинированно занялась здоровьем. Сейчас у меня состояние здоровья на 9/10, год назад я бы его оценила на 5/10. Юхууу😎

Так вот прохождение врачей меня привело меня к разгону мысли про побочки.

Врач редко обещает лечение сложных заболеваний «вообще без последствий», и вы сами знаете, какими бывают по длине инструкции в таблетках🥲 В русском языке есть даже присказка: одно лечим, другое калечим (удивляюсь, как поговорки находятся на любую идею))

В бизнесе применима та же логика, но мы редко себе в ней признаемся.

По сути мы тоже «лечим» в бизнесе то, что в итоге должно улучшить общее «здоровье» компании — прибыль, окупаемость, удержание. Но каждое решение что-то может задеть: кто-то решит уйти, NPS просядет, саппорт утонет в тикетах. По сути это и есть «побочки» — их важно предвидеть и заранее зафиксировать, после какого порога ухудшений бьем тревогу.

Как это применить на практике? Вот вам план:

1. Ставим диагноз и фиксируем endpoint (критерий успеха)

Не «оптимизируем воронку», а «у нас высокая стоимость привлечения клиента, окупаемость 7 недель, хотим сократить до 4»

2. Оформляем «информированные согласия» внутри команды

Важно честно объяснить внутри, что и сколько будет болеть (четкая коммуникация тут как анальгетик для команды🙂). Например, «Заменяем отдел продаж на AI-сейлзов. Готовы 2 недели видеть −5 п.п. в конверсии в продажу, пока нейросеть обучается, если это через 4 недели ускорит возврат инвестиций в 1.75 раз»

3. Сравниваем пользу и вред одной линейкой

Врачи считают NNT (Number Needed to Treat) — сколько пациентов нужно лечить, чтобы один выздоровел. И NNH (Number Needed to Harm) — сколько нужно лечить, чтобы у одного появилась серьёзная побочка.

Если NNT = NNH — лекарство бесполезно (помогает одному и вредит одному). Если NNT < NNH (например, лечим 200, а побочка у 1 на 1000) — лекарство норм. Чем меньше NNT и чем больше NNH — тем лучше решение.

Пример в бизнесе:
- Выкатываем новый онбординг на 1000 клиентов
- 30 клиентов начинают тратить в 2x больше (желаемый исход) → NNT = 1 000/30 ≈ 33
- 4 клиента уходят из-за багов (негативный исход) → NNH = 1 000/4 = 250

Итого на каждые 33 затронутых получаем 1 пользователя с желаемым аплифтом, а ушедший от нас пользователь случается раз на 250.

4. Берем второе мнение до и делаем разборы без охоты на ведьм после

До крупного запуска с рисками — позвать экспертную команду (в медицине это red team), которая поищет уязвимости в плане. После запуска — разбор (в медицине это Morbidity & Mortality): чему научились, что меняем. Главный принцип: не ищем козлов отпущения, фокус на рефлексии вокруг того, что узнали.

———

Иииинтерактив:
🥂 - ставьте, если и так в командах всегда заранее фиксировали, какие побочки готовы терпеть при изменениях и тестах
❤️ - если не фиксировали, но планируете теперь
😁 - если это все фигня какая-то, и проблемки нужно решать по ходу дела