Для продакт-менеджера умение приоритизировать не просто полезный навык — это основа успеха в профессии. Поэтому неудивительно, что вокруг него развелось невероятное количество различных фреймворков и методов.
Давайте вспомним, как это обычно выглядит:
- Все идеи и фичереквесты сваливаются в бэклог. Некоторые особо упоротые персонажи даже пишут брифы к каждому таску, но в какой-то момент сдаются, так как за скоростью роста бэклога угнаться невозможно;
- Затем все это копируется в эксельку (или же используется шаблон для скоринга в таск трекере). Продакт и компания (обычно техлид, но в особых случаях и вся команда) собираются и начинают скорить по некоторым критериям из фреймворка. Возьмем, к примеру, RICE (Reach — Impact — Confidence — Effort), для оценки трудозатрат (Effort) обычно привлекаются разработчики. Если разработчики джуны, процесс идет относительно быстро. Если постарше, то мучительно медленно: на этапе брифа или идеи у всех очень разное представление о решении и о том, как его воплощать в жизнь, поэтому дискуссия затягивается и порой вообще уходит в сторону;
- Все это веселье повторяется с завидной регулярностью, потому что новые идеи прибывают, старые теряют актуальность или, наоборот, становятся более важными.
Обычно в какой-то момент всем это надоедает и табличка в эксельке начинает зиять пустыми столбцами.
Если у вас не так — вы большие молодцы. Но поверьте, во многих компаниях процесс построен именно таким образом: продакт тратит львиную долю времени на менеджмент бэклога и его приоритизацию.
Почему все это в корне неправильно? Не читайте дальше, задумайтесь на минутку — давайте для наглядности возьмем такой (супер упрощенный) пример.
Допустим, я ученый, и моя цель — устроиться на работу в престижный университет. Какое из следующих трех действий будет иметь наибольший эффект для достижения моей цели:
- Провести исследование и опубликовать результаты в научном журнале;
- Начать ходить в спортзал;
- Смотреть сериалы по вечерам.
Несмотря на то, что спортзал может дать хороший результат для нашей жизни в целом, а сериалы наиболее просты в выполнении, непосредственно к цели нас продвинет только первая опция.
Давайте теперь переложим это на наши продуктовые реалии. Предположим, мы делаем новый Netflix, и у нас есть три фичи в бэклоге:
- Добавить блок «Рекомендуемые фильмы»;
- Сделать возможность родительского контроля;
- Добавить возможность создавать списки фильмов.
Что будем делать? У первого, вроде, наиболее широкая аудитория, третье проще всего сделать — второе исключаем, получается?
А теперь давайте снова вспомним про цель — какую фичу вы возьмете в работу, если ваша цель:
- увеличить среднее время просмотра;
- выйти на рынок детских продуктов;
- совершить прорыв в machine learning.
Кажется, понятно, что в первом случае мы сравнивали яблоки с апельсинами. Если продакт начинает приоритизировать фичи — это четкий звоночек, что у продукта нет стратегии.
Как происходит приоритизация здорового человека:
- Анализ рынка, определение основных рисков и возможностей. На основе этого создается стратегия продукта (анализ, безусловно, подразумевает общение с пользователями — существующими или потенциальными).
- Анализ текущего состояния продукта, основных проблем и блокеров.
- На основе п.1 и п.2 команда определяет цели. Повторюсь, цели — это не фичи; это некоторая точка, в которую мы хотим прийти за счет изменения продукта. Здесь очень большую роль играет продуктовое чутье, умение предугадать, что может стать катализатором роста.
- Обычно если первые три пункта сделаны хорошо, то дальше не составляет труда определить основные гипотезы.
- Понять, какое минимальное решение позволит нам проверить гипотезу. Оценка фич «по размеру» не имеет никакого смысла по двум причинам:
- Если маленькая фича не продвинет нас к цели, а большая продвинет, имеет смысл вкладываться в большую: ее в итоге все равно придется делать, а маленькая только отвлечет нас по пути.
- Сравнение из первого пункта «большая-маленькая» работает только для сравнения порядка: понятно, что поменять цвет кнопки намного проще, чем добавить блок «Рекомендуемые фильмы». Саму же фичу можно (и нужно) резать до тех пор, пока не получится ровно тот кусок, который проверяет гипотезу. Например, для блока «Рекомендуемые фильмы» не обязательно писать рекомендательную систему с нуля, если мы хотим проверить, как люди относятся к рекомендациям в принципе: для этого подойдут и ручные редакторские подборки.
Стандарт — делать первые два пункта раз в полгода; третий пункт — раз в квартал. Но все индивидуально, смотрите, что лучше ложится на модель вашего продукта.
Первые два пункта самые затратные по времени, но это того стоит: затем все следующие шаги очень логично и просто ложатся в общую канву.
Не будьте менеджерами бэклога, будьте менеджерами продукта.
А что делать, если пришел на работу в компанию, где как раз менеджерят бэклог (а не продукт) и скорят фичи (а не проблемы)? У меня есть офигенно простой и эффективный метод на этот случай – я называю его «один, два, три».
- 0. Побуду кэпом и проговорю лишний раз на всякий случай: почему нельзя приходить и все менять? Потому что у вас еще нет кредита доверия команды, + у вас нет глубокого понимания контекста, чтобы предложить лучшее решение. Нужен запас времени, чтобы все это приобрести, но не останавливать же разработку на то время, пока вы разбираетесь в ситуации? Поэтому делаем следующее:
- 1. Берем все фичи из бэклога, загоняем в один столбик в эксельке. Никаких описаний и дополнительных оценок в столбике быть не должно.
- 2. Берем в охапку двух, максимум трех человек в команде, у которых наибольший контекст и понимание продукта, – может быть техлид, ваш непосредственный менеджер, бывший продакт, исследователь и тд.
- 3. Каждому даем отдельный список из п.1 и просим раскидать все фичи по трем бакетам:
- 1 – то, что мы должны делать прямо сейчас, у нас есть подтверждения, что это важно; 100% уверенность, что мы должны заниматься именно этим, а не чем-то другим
- 2 – пока нет данных, но наша интуиция говорит, что это важно и должно быть сделано
- 3 — все остальное.
- 4. Вы мерджите столбики: по моему опыту, если вы пришли к правильным людям, у вас будут расхождения всего в паре пунктов, большинство оценок (особенно для группы 1) будет совпадать.
- 5. Делаем встречу на всех задействованных ранее людей, приходим к консенсусу по расхождениям, получаем два столбика: название фичи + циферка. Добавляем еще один, с обозначением общей темы или проблемы (вам желательно подготовить их заранее). Раскидываем все фичи по темам. В идеале в группе 1 темы не должны повторяться: если есть дупликаты, выбираете только одну фичу, вторую переносите в категорию 2.
- 6. Вуаля! Группа 1 – это ваш план на ближайшее время; то есть, вы спокойно можете делать execution и параллельно думать над стратегией. Группа 2 – это ваша подсказка от команды: с этих тем/проблем вы можете начинать исследование и дальше копать глубже. В группе 3 часто оказывается всякий треш, но порой это интересная отправная точка, чтобы пообщаться с командой и понять, откуда эти идеи пришли.
На все про все – 3-4 часа работы максимум.