Как получить людей, когда компания никого не нанимает

Заморозка найма давно стала обычным состоянием во многих компаниях: работайте с теми, кто есть. Для запуска новой инициативы это может стать препятствием — но в такой ситуации работает расчет.
Это третья часть серии о финансовых метриках для продакта. В первой разбирали, что влияет на ожидания стейкхолдеров от менеджера проукта. Во второй — как связывать продуктовые метрики с выручкой.

🔍 Кейс inDrive

Команде сказали: никого не нанимаем, развивайте продукт силами текущей команды. При этом рынок такси жесткий, во многих странах сильные конкуренты. Чтобы удерживать и наращивать долю, нужны были разработчики, продакты и другие специалисты.

Первая попытка объяснить, зачем они нужны, звучала на продуктовом языке: «вырастим метрику на 10%». Ее никто не понял.

Тогда показали два плана: с текущими ресурсами и с дополнительными. Для второго посчитали, сколько людей нужно (в издержках), какие фичи они сделают и сколько выручки это принесёт.
Разговор с руководством сразу изменился, потому что оно думает именно в таких категориях: вкладываем X, получаем Y. В итоге ставки одобрили.

Как говорить с руководством о ресурсах

✔️ Переводите результаты в деньги с учетом фазы развития и типа компании.
Фраза «вырастили метрику X» ничего не говорит человеку, который не погружен в продукт. Выручка, расходы и прибыль понятны всем. В резюме это тоже работает.

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

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

Навык работы с бизнес-метриками в продуктовой практике окупается и лично. Чем выше позиция, тем большая часть вознаграждения приходится на LTI (Long-Term Incentive) — долгосрочное вознаграждение сотрудника. Одна из популярных форм такого вознаграждения — опционы, а они напрямую зависят от того, как компания зарабатывает. Менеджер продукта, который умеет связывать свою работу с выручкой, влияет и на собственный доход.

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

По мотивам доклада «Финансовые метрики для продакт-менеджеров: как поженить продукт и деньги» Никиты Лебедева на ProductSense’25

Видео в бесплатном доступе в Академии ProductSense
➡️ Смотреть видео →

@productsense

Что будет, если проверять продуктовое решение только после запуска ❓

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

Если на этапе выбора решение не проверяли, после запуска обычно всплывает одна из проблем:

➡️ Непонятно, чего добились. В задаче было записано действие, например «сделать онбординг», а не результат, которого ждали от пользователей. Онбординг сделали, задачу закрыли — но стало ли кому-то лучше, сказать нельзя.

➡️ Фича работает, а проблема осталась. Решение опиралось на предположение о причине проблемы, которое никто не проверил. Причина оказалась другой, и сделанное ее не затрагивает.

➡️ Нечем объяснить выбор. Задача пришла от бизнеса или руководителя уже с готовым решением, и другие варианты не рассматривали. Когда результат слабый, непонятно, было ли это решение лучшим из возможных или просто первым.

➡️ Результат трактуют кто как хочет. О метриках и сроках оценки договорились уже после запуска. Если метрика выросла, фичу считают успешной. Если не изменилась, говорят, что нужно больше времени. Если одна метрика выросла, а другая упала, итог определяет тот, чей голос в обсуждении весит больше.

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

Как проверять решение еще на этапе выбора — разберем на бесплатном вебинаре.

Вебинар «Вы приняли продуктовое решение. Как понять, что оно — правильное?»

📌 2 ноября (пн), 19:00 мск
Бесплатно в Академии ProductSense

В программе:
— Путь от цели до метрик по шагам
— Разбор реального кейса в прямом эфире
— Ответы на вопросы

Спикеры
— Иван Меркурьев, Senior Product Manager, Яндекс.
Автор телеграм-канала Ordinary PM
— Анастасия Бабинцева, Product Manager, LifetimeHealth.
Редактор канала Product Mindset

⭐️ Участники получат шаблон принятия решений и карту навыков менеджера продукта.

⏩ Зарегистрироваться

@productsense

🔔 Вебинар о проверке продуктовых решений уже сегодня 👆🏻

Регистрируйтесь, если еще не успели, и пересылайте коллегам.

Встречаемся в 19:00 мск онлайн в Академии ProductSense 🙌🏻

Проблема в сотруднике или в системе? Как руководителю реагировать на ошибки команды

Когда возникает проблемная ситуация: ошибка на проде, срыв срока, провал воронки после релиза, — у команды есть три пути:
1 — найти виноватого;
2 — признать ответственным руководителя;
3 — пойти разбираться во внутренних правилах и процессах.

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

11 ноября об этом поговорят на панельной дискуссии «Решай проблему, а не человека» в Школе менеджмента «Стратоплан». 

Участвуют: 
🔵 Юра Агеев, основатель ProductSense
🔵 Глеб Михеев, ex CPO платформы агентов в  B2C, «Сбер»
Ведет дискуссию Александр Орлов. 

О чем будут говорить:

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

❓ Косяк сотрудника — это косяк руководителя? Где заканчивается ответственность человека и начинается ответственность того, кто ставил задачу и следил за ней.

❓ Контроль или микроменеджмент. Как держать руку на пульсе и при этом не душить команду. Где проходит граница.

❓ Карьера. Почему то, как человек приносит плохие новости, влияет на то, как его оценивают для повышения.

Участники могут прийти со своими вопросами и кейсами: спикеры разберут их в прямом эфире.

📌 11 ноября, 19:00–20:00 GMT+3, онлайн

Дискуссия входит в «Чёрный курс менеджмента» — бесплатный онлайн-курс Школы менеджмента «Стратоплан» по мотивам «Чёрной книги менеджера».

10–12 ноября — три вечера про жёсткий менеджмент без сахарной ваты:
- основы твёрдого управления;
- как понять, кто тянет команду вниз;
- мастер-класс по увольнению;
- разбор резюме.

Участие бесплатное, нужно только подписаться на каналы. Есть платный вариант: без подписок и с бонусным курсом.

👉🏻 Зарегистрироваться

@productsense

11.11 в Академии ProductSense будет кое-что особенное

Что именно, расскажем в среду.
Пока можем сказать одно: стоит отметить в календаре 11:11 по Москве 👆

За последние месяцы Академия сильно выросла:

🔵больше 3000 материалов: записи ProductSense, PeopleSense и других событий
🔵вся видеотека Epic Growth переехала к нам: записи конференций, микрокурсы и остальной контент
🔵больше 50 микрокурсов, чтобы разобраться в теме за вечер и сразу применить
🔵новые эфиры и вебинары каждый месяц, а их записи остаются в Академии

Если ещё не знакомы с Академией или давно туда не заглядывали, у вас есть два дня, чтобы освежить впечатления. 468 материалов открыты бесплатно, нужна только регистрация. Всё о платформе собрано в закрепе 👆🏻

➡️Открыть Академию

Как выбрать способ проверки гипотезы
И что почитать на эту тему

Проверка гипотезы нужна, чтобы снизить неопределённость перед решением. Но метод часто выбирают по привычке: в одной команде всё проверяют A/B-тестами, в другой — интервью. В итоге проверка может занимать месяц и отвечать не на тот вопрос, который стоял за гипотезой. Или не отвечать ни на какой.

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

Шаг 1. Поймите, что именно вы хотите проверить

Предположения в продуктовых гипотезах обычно касаются одного из четырёх аспектов:
🔵 Ценность: будут ли люди это покупать или этим пользоваться.
🔵 Удобство: разберутся ли они, как этим пользоваться.
🔵 Реализуемость: сможет ли команда это сделать с имеющимися временными ресурсами, навыками и технологиями.
🔵 Жизнеспособность: сработает ли это для бизнеса: продаж, маркетинга, финансов, юридических ограничений.

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

Если за идеей стоит несколько предположений, разбейте её на отдельные гипотезы: так проще понять, что именно подтвердилось. Некоторые способы, например интервью или опрос, позволяют проверить несколько гипотез сразу. A/B-тест обычно строят вокруг одной гипотезы.

Шаг 2. Учтите ограничения

Одно и то же предположение можно проверить разными способами, и выбор между ними зависит от четырёх ограничений:
🔵 Трафик: хватит ли людей, которые увидят изменение, чтобы получить надёжный ответ
🔵 Время: когда нужно принять решение
🔵 Цена ошибки: что вы потеряете, если решение не сработает
🔵 Обратимость: можно ли всё вернуть за день

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

Шаг 3. Выберите метод под риск

1️⃣ Ценность → сначала проблема, потом спрос

Есть ли проблема
Проведите интервью о прошлом опыте: спрашивайте «Расскажите, как вы делали это в последний раз», а не «Было бы вам удобно, если…». И посмотрите, что у вас уже есть: обращения в поддержку, отзывы, аналитику. Опрос «Нужна ли вам такая функция?» здесь не поможет: люди отвечают вежливо, а не честно.

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

Будет ли польза на деле
Идея может нравиться людям, но это ещё не значит, что решение справится с их задачей. Чтобы это проверить, не обязательно сразу писать код: какое-то время команда может делать работу будущего продукта вручную. В подходе «консьерж» пользователь знает, что с ним работают люди. В подходе Wizard of Oz он видит обычный интерфейс и не знает, что за ним работают люди. Если люди пользуются ручной версией и возвращаются, польза есть и решение стоит автоматизировать.

2️⃣ Удобство → юзабилити-тест прототипа

Даже нужное решение не взлетит, если люди не понимают, как им пользоваться.

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

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

3️⃣ Реализуемость → технический прототип

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

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

4️⃣ Жизнеспособность → деньги и ограничения бизнеса

Решение может нравиться людям и при этом не окупаться.

Поэтому отдельно проверьте, готовы ли люди платить. Проверяйте это деньгами, а не кликами: предзаказ или лендинг с разными ценами покажут больше, чем нажатия на кнопку. Чем дороже обойдётся ошибка, тем ближе к реальной оплате должна быть проверка.

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

Отдельно: влияние на метрику → A/B, если хватает трафика

A/B-тест показывает не то, нужно ли решение людям, а насколько сильно оно сдвигает метрику. Поэтому запускать его имеет смысл, когда ценность уже подтверждена.

Перед стартом посчитайте, сколько людей нужно для теста. Если столько людей вы будете набирать дольше, чем можете ждать с решением, A/B вам не подойдёт. В таком случае можно выбрать метрику, которая ближе к изменению и реагирует быстрее: например, клики вместо выручки.

❗️ Когда эксперимент не нужен
Если изменение дешёвое, обратимое и не бьёт по деньгам, можно выкатить его и следить за метриками. Проверка, которая стоит дороже возможной ошибки, лишняя.

Что почитать
Марти Каган, «Вдохновлённые»: классика продакт-менеджмента, в том числе про четыре типа предположений и технический прототип
Дэвид Блэнд, Алекс Остервальдер, «Тестирование бизнес-идей»: каталог способов проверки с оценкой цены, сроков и надёжности результата
Роб Фитцпатрик, «Спроси маму»: как спрашивать, чтобы не врали из вежливости
Консьерж или Wizard of Oz: в чём разница
Почему для юзабилити-теста хватает 5 человек, Nielsen Norman Group
Калькулятор выборки для A/B Эвана Миллера

@productsense