Я много говорю о метриках и об их важности. Но ещё и о том, что с метриками надо быть осторожными. Уже был отдельный пост про последствия возведения в культ только одного из показателей. Теперь давайте поговорим в целом о метриках, которые убивают продукт.

Цифры любят все: инвесторы, топ-менеджеры, команды. Но иногда именно метрики становятся оружием массового самообмана (а порой и краха всего бизнеса).

Vanity metrics

Красивые графики без пользы. Скачивания приложения, общее количество регистраций, охват в соцсетях. Легко показать инвесторам, приятно размещать в отчёте. Но если эти люди не становятся пользователями, если эти метрики не приносят денег, то это не метрики, а декорации, за которыми всё не так радужно.

В 2017 руководство Medium уволило 50 сотрудников (треть штата), отказавшись от ad-driven модели на основе просмотров и кликов, потому что она вредила качеству контента. Они закрыли офисы в NY и DC, перейдя к подписной модели.

Локальная оптимизация

Команда выжимает CTR кнопки на лендинге, но при этом стоимость привлечения клиента растёт. Продукт псевдооптимизируется кусками, а бизнес в целом — деградирует. Тактическая победа вместо стратегического роста.

В 2010x YouTube отказался от ранжирования по просмотрам/CTR и перешёл к watch time, потому что оптимизация под клики порождала кликбейт и плохой долгосрочный опыт. Отказ от старого ранжирования привёл к постоянному улучшению retention в течение следующих лет.

Игнорирование лагов

Есть метрики, которые показывают результат с задержкой. Например, churn по-настоящему проявляется лишь через месяцы. Если реагировать только на «живые» цифры — можно проспать момент, когда продукт уже пошёл ко дну.

Microsoft/Bing описывает парадоксальные результаты в онлайн‑экспериментах: изменения, дающие краткосрочный прирост запросов/дохода, ухудшали долгосрочную ценность. Вывод — нужен OEC и длинные эксперименты.

Слепота к качеству

В отчёте всё хорошо: конверсии стабильные, retention не падает. А внутри — тысячи жалоб в поддержку и негатив в соцсетях. Качественные сигналы не вошли в дашборд — значит, их как будто не существует. Но именно они убивают доверие пользователей.

В 2017 Star Wars Battlefront II (EA): монетизационные метрики «сходились», но токсичный опыт вызвал грандиозный публичный скандал. Electronic Arts в спешке отключила микротранзакции в игре.

Культ одной метрики

Повторюсь, но любой, кто верит в «сакральную метрику» (будь то DAU, NPS или LTV), подписывает себе приговор. Продукт живёт системой показателей, а не одной цифрой. Ваша драгоценная NSM без сторожевых подружек — просто карго-культ.

MoviePass гнался за числом подписчиков и «ростом», игнорируя юнит‑экономику. Итог — кассовый разрыв, обвалы, массовый отток (с 3 млн до ~225 тыс).

Средняя температура по больнице

Классическая ловушка: средний чек растёт, но на деле это два богатых клиента перекрыли отток сотен мелких. Средние значения скрывают дисбаланс. Используйте хотя бы медиану.

Blue Apron: в публичных отчётах были приличные средние показатели и выручка на пользователя, но они не спасли от болезненного IPO и провала — высокий churn съедал экономику.

Оптимизация ради отчёта

Когда команда работает не на продукт, а на красивую презентацию. Сократили cost per lead? Красавцы. И плевать, что лиды оказались дохлыми. Метрика должна быть инструментом обратной связи, а не фейерверком в презентации. Она обязана показывать реальность, даже если реальность неприятна.

Wells Fargo гналась за KPI по числу открытых счетов: миллионы фейковых аккаунтов, рекордные штрафы и многолетние регуляторные санкции — отличный пример токсичной метрики.

Чтобы метрики работали на продукт, а не против него, используйте комплексный подход:

1. Создайте сбалансированную систему метрик (DAU, LTV, churn) для полной картины бизнеса.

2. Регулярно проверяйте качественные сигналы и интегрируйте их в дашборды.

3. Проводите длинные эксперименты с OEC, чтобы уловить отложенные эффекты.

4. Используйте метрики для честной обратной связи, а не для красивых отчётов.

Кстати, забыл рассказать. Я тут статейку новую выложил на днях. Про упаковку бизнеса. Про то, что это не просто финмодель с брендбуком и красивая преза для инвесторов.

Это большая и кропотливая работа по сведению воедино всех аспектов этого самого бизнеса. Это комплект артефактов, по которым можно одинаково внятно разговаривать с клиентом, партнёром, инвестором и даже соискателем.

Наблюдал тут пару недель назад итересную картину (публикую с разрешения владельца компании).

Позвали меня поглядеть на проектные процессы. Почему-то слаженная когда-то система стала разваливаться с ростом команды. Вроде, и проджект есть, и процессы рабочие, и команда неплохая. Но вместе какая-то херня получается.

Надо было понять, где проёб, и разделаться с ним. Обычно такая охота занимает от двух недель до месяца: нужно погрузиться в специфику, пообщаться с командой, изучить инструментарий и тп. Однако в этот раз не понадобилось и пяти дней.

Оказалось, что «проблема» лишь в том, что все пользуются разными инструментами: дизайнеры фигмой, аналитики конфлюенсом, разработчики гитлабом. Когда команда была небольшой, это не создавало трудностей: всё решалось на дейликлах. Дизайнеры без проблем ориентировались в небольшом тогда конфлюенсе, аналитики легко шастали по макетам.

Но с увеличением команды это стало неудобно: тьма изменений, которые стало сложно отслеживать даже с трекером. Классика.

Можно было бы начать перестраивать процессы, если бы планировалось продолжать найм. Но команду не собирались больше расширять, и мы нашли более простое и дешёвое решение.

Бот в телеге, сообщающий обо всех изменениях и тегающий ответственных. Три дня: день на проектирование и базу, два — на интеграции с фигмой, конфлюенсом, трекером и гитлабом. Всё.

Грядёт время нового стрима:

14.10 (вторник) в 20:00 МСК

На этот раз хочу предложить вам парочку старых и несколько новых тем на выбор:

1. Вредный MVP. Типичные ошибки, урезанный опыт, влезание в долги, гипотезы и самообман, прототипы, месть рынка.

2. Фейковые инновации. Псевдо-ценности и псевдо-ИИ, новые обёртки старого, плагиат, разрушение культуры.

3. Роадмап и деньги. Метрики вместо чекбоксов, outcome вместо feature, бюджет вместо инженерии, польза вместо дат.

4. Пожаротушение. Огонь как часть системы, буфер хаоса, отличие пожаров от хотелок, роль документации и коммуникации, контролируемое горение и пост-мортем.

5. Стейкхолдеры и двойные сигналы. Поле противоречий, карта стейкхолдеров, единый язык отделов, протокол решений, синхронизация и ясность вместо консенсуса.

Шарьте, нашему кандидату нужно больше голосов! (опрос ниже)

Давайте поговорим о приоритизации.

Но не о всяких MoSCoW, USM, RICE/ICE и подобных. И даже не о сэйфовском WSJF. Давайте поговорим о подходе, который учитывает вероятности и риски. И который можно с лёгкостью адаптировать под конкретно ваши проектные и продуктовые реалии.

Речь о PoD x Probability x Reversibility, где:

PoD (Pain over Difficulty) — боль на единицу усилий. Чем больнее пользователю или бизнесу и проще исправить — тем выше приоритет. Это фильтр во имя здравого смысла: если у тебя в продукте очевидная дыра, которую можно закрыть за день, тупо ждать квартального планирования.

Probability — вероятность эффекта. Насколько мы уверены, что это вообще сработает. Уверенность эта берётся не из домыслов и фантазий, а из данных, интервью, экспериментов. Иногда «большая идея» с нулевой валидацией выглядит мощно, но шанс попасть в цель у неё меньше, чем у простого фикса, снимающего боль прямо здесь и сейчас.

Reversibility — обратимость. Можно ли откатить решение, если окажется, что мы сделали какую-то хрень. Чем выше обратимость — тем выше приоритет: безопаснее ошибаться быстро, чем бояться двигаться вообще (привет, Lean). Рисковать становится проще.

Возьмём какой-нибудь простейший до карикатурности пример. Новый онбординг. Дизайнеры считают, что он снизит порог входа и повысит конверсию. Считаем:

Pain — низкий (никто не страдал от старого онбординга).

Difficulty — высокий (много времени на отрисовку и разработку).

Probability — низкая (никаких данных, только гипотеза).

Reversibility — нулевая (онбординг встроен глубоко в код).

Какой, в итоге, приоритет был бы у фичи? Самый низкий, полагаю. А значит, можно эти же ресурсы потратить на что-то более весомое.

В общем-то, всё (ну почти).

В чём же главный плюс подхода, помимо учёта обратимости? Да в том, что его можно миксовать с чем угодно. Не хватает одного только PoD? Добавьте количество затрагиваемых пользователей и уверенность в оценке из RICE. Нужно как-то визуализировать результат таких упражнений? Кидайте его в MoSCoW. Адаптируйте.

Да, метод, как и все остальные, далёк от идеала. Подвержен субъективным оценкам (если лень искать данные). Фокус на обратимости может «сбивать прицел» в крупных проектах с низкой долей неопределённости и высокой инертностью. Подход отчасти перекликается с аджайловским Value/Effort. Но это всё нюансы, которые легко решаются подгонкой подхода под ваши реалии.

ПС: Вот ссылка на цикл об этом

Хорошие новости. У меня скоро освобождаются 2 слота под менторство. Формат простой: от одного до трёх часов в неделю, с активным общением между. Поработаем над какой-то конкретной задачей или составим индивидуальный учебный план и будем ему следовать (общая доска, домашние задания, все дела).

Немного о моём опыте:

Я начинал в нулевых как разработчик, потом ушёл в дизайн и аналитику, теперь менеджерю и продюсирую всякое. Семь лет управлял и помогал управлять стартапами, потом покорял корпоративные эдельвейсы (VISA, Альфа, Сбер, Лукойл, ВК, Атом etc). С 2017 года активно преподаю в ВУЗах, веду корпоративное обучение. Подробнее о моих умениях в закрепе канала.

Что я могу дать в рамках менторства:

1. Всё, что связано с управлением. Продуктом, проектом, командой, метриками, финансами, рисками, ожиданиями и всем, что ведёт к успешному запуску.

2. Харды: продуктовый дизайн, аналитика, разработка, архитектура. Помогу подтянуть неподтянутое или усилить сильное.

3. Помощь в карьерном росте: как горизонтальном, так и вертикальном. Могу помочь с победой в политических баталиях, построить правильные отношения с коллегами и руководством, подтянуть уровень до новой позиции или подготовить к переходу в другую компанию.

4. Подтягивание софтов в их классическом понимании. Коммуникации, ответственность, ведение дискуссий, работа с манипуляциями и всё такое.

5. Настройка процессов. От внедрения методологий до перевода бухгалтерии на ЭДО. Разработка, адаптация, борьба с саботажами и прочие прелести.

6. Вообще всё, что на стыке дизайна, технологий, бизнеса и аналитики.

И да, это менторство за деньги. О том, почему я перестал менторить бесплатно, можете почитать в прикреплённом к этому посту сообщении.

Пишите мне или @mashavanassi, созвонимся, обсудим детали.

И у нас победитель. С небольшим отрывом вперёд вышел «Вредный MVP», за ним следом «Стейкхолдеры и двойные сигналы». Это будут темы следующих 2х стримов.

Остальные темы пойдут либо в посты здесь, в канале, либо в статьи на сайте.

Не переключайтесь.

Проблемы белых. Зовут выступать на конференцию, в анкете нужно указать компанию, в которой работаю. А я не работаю ни в какой компании. С двумя сотрудничаю, но не настолько плотно, чтобы писать их названия на бейдже. Что делать?

Спойлер следующего стрима.

Уже скоро: во вторник (14.10) в 20:00 МСК.

Лет 10 назад один из моих клиентов спросил, почему нельзя писать код сразу без багов. Я тогда выдал ему очень красочную аналогию, и она сработала. Впоследствии я ещё не раз к ней прибегал и, чаще всего, успешно.

Дублирую для новых подписчиков, пользуйтесь:

Уже много лет я не работаю на фрилансе, но до этого долго и успешно практиковал удалённую разработку и проектирование. И иногда клиенты задавали презабавный в своей наивности вопрос: «А сразу без багов писать нельзя?» или «А нельзя сразу сделать так, чтобы юзеры не отваливались?».

Так вот, хочу ответить всем своим будущим и бывшим клиентам и партнёрам: «Нет, нельзя. Меньше — можно, вообще без — нельзя.»

Запомните одну простую штуку. Создание серьёзного программного продукта — это не только производственный процесс. Это исследование. Вот вы знаете, как положить асфальт. И когда вам говорят, что нужно покрыть 5 квадратных кэмэ дороги, вы быстренько считаете расход, технику, амортизацию, логистику – и выдаете сроки и сумму. А теперь замените в предыдущем предложении слово «дороги» на «стены». Чуете? Никто, ни один дебил до вас, не клал асфальт на пять километров стены. По отдельности – все понятно. Вот асфальт, он простой. Вот каток, он тоже несложный. Вот сорок рабочих, они умеют укладывать простой асфальт несложным катком. А вот стена, и о ней вы тоже знаете практически всё. Но вместе — какая-то поебень получается.

И пусть мы представим, что асфальт на этой стене оправдан. Всё равно, эти сорок профи изведут вам гору асфальта, прежде чем поймут, как его класть. Вот переведённый асфальт — это и есть баги и минусы в воронке.

Допустим, теперь вы умный. Вы позовете мастера по нестандартным дорожным покрытиям. Он не умеет класть асфальт, как сорок трудяг, но он способен мыслить нестандартно и знает всё о силе трения. И даже он изведет вам некоторое количество асфальта в процессе поиска решения. Меньше, чем сорок строителей, но он и денег отдельных за свою работу возьмёт.

А всё потому, что никто до вас не использовал стандартные штуковины таким замысловатым способом.

Баги будут, и некоторые юзеры рухнут в Аид, потому что идеального проектирования и маркетинга не существует — нужен анализ реальных данных. И вообще, занимайтесь своим асфальтом, если вы не готовы к этому.

У меня всё. И да, все аналогии лживы.

Стрим ровно через сутки, 14.10 в 20:00 МСК. Поговорим про то, почему запуск MVP может навредить продукту/бизнесу и что делать, чтобы этого избежать.

Основные темы:

1. Термины, отличия от прототипа и типы потенциального вреда.
2. Типичные ошибки запуска.
3. Радикальный минимализм и чем он может обернуться.
4. Реакция рынка и последствия плохого MVP.
5. Продуктовый, технический и дизайн-долг.
6. Чем чреват запуск без продуманных гипотез.
7. Почему нужно ограничивать риск, а не продукт.
8. Метрики и практические советы.

Записи не будет (я писал уже, почему так). Презентации, скорее всего, тоже (расскажу на стриме о причине).

Шарьте, наверняка кому-то будет интересно.

Начало через 10 минут: https://telemost.yandex.ru/j/2742891779

Готовлю третью статью про информационную архитектуру, в связи с чем немного обновил на сайте первые две части цикла (раз и два).

Дальше буду рассказывать про информационные сущности. Именно там рождаются таблицы, свойства и связи, которые потом превращаются в интерфейсы, поиск и навигацию. Как отличить сущность от элемента интерфейса, как описывать свойства без каши и что делать, если у вас «арбуз — и ягода, и фрукт».

Не переключайтесь.

Начал писать третью статью про сущности в информационной архитектуре — и, как обычно, немного увлёкся. Пришлось разбивать на две части: одна получилась больше про теорию, в другой будут практические материалы.

Но даже с учётом разбивки первая вышла солидным лонгридом: в ней о том, что такое сущности (и чем они точно не являются), какие у них бывают свойства, связи, что такое фасеты, таксономии, противоречивые классификации и ещё тьма всего.

В общем, налетайте.

На неделе будут «сущности vol.2»

Нифига ни на две, а очень даже на три. Теоретическая часть работы над сущностями опубликована, а практической будет посвящено две отдельных статьи: одна про базу (этапы создания, RFC, паттерны моделирования), вторая про навигацию и поиск, ошибки и антипаттерны, чек-листы и шаблоны.

Это, видимо, никогда не закончится.

А у меня снова хорошие новости. На следующей неделе я заканчиваю работу с одним из клиентов. Бизнес упакован, процессы налажены, команда довольна. Осталась пара формальностей со структурой документации и её поддержкой, дело пяти дней.

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

Я умею в методологии и процессы, документацию, архитектуру, продуктовый дизайн с аналитикой, в обучение команды. Опыт в этой нашей айтишке 20+ лет, больше 10 из которых — в управлении и обучении. Подробнее о моих умениях в закрепе канала. О том, кто я такой и почему это всё себе позволяю — на сайте.

Если у вас есть интересные продукты/проекты и задачи, пишите @mashavanassi или мне @sherer_pro.

Готова вторая часть про информационные сущности (и она же четвёртая во всём цикле про информационную архитектуру).

Я честно старался в одну статью уместить все этапы создания, но получилось только первые пять. И так вышел лонгрид, а никто не любит лонгриды.

Здесь можно почитать про подготовку и декомпозицию, классификацию данных, выявление самих сущностей и их связей.

Про два последних (и самых главных) этапа будет в следующей статье, уже совсем скоро.

Я обещал, что не буду задерживаться со следующей частью цикла? Ловите.

Третья статья про сущности в информационной архитектуре, теперь про их свойства и способы фиксации.

Пока с IA приторможу, накопилось много другого материала.

Вы не просили, а я всё равно сделал:

(Pain ÷ Difficulty) × Probability × Reversibility

Первая статья в цикле про PoDPR — метод приоритизации, который учитывает не только важность проблемы/задачи и сложность реализации, но и вероятность «попадания», риски и обратимость решения. Что это за подход, как он может улучшить существующие методологии и как сделать его расширяемым под конкретно ваши реалии.

В следующей статье будет про то, как считать PoDPR без манипуляций и вкусовщины.