Приоритизация — основной практический инструмент менеджера по продукту. Ее цель — помочь менеджеру направить ресурсы команды на развитие продукта и достичь главных целей, избежав локальной оптимизации. Процесс приоритезации часто называют просто «фокусировка».
Чтобы определить, какая деятельность оказывает самое положительное влияние на достижение цели, и поместить эти задачи в начало списка приоритетов, вам потребуется модель действительности. Упрощенное представление о том, что вы делаете, обладающее предсказательной силой. Для этого можно пользоваться фреймворками.
Фреймворк — это заготовка модели. Лекало для схематического представление реальности. С его помощью менеджеры по продукту принимают конкретные решения:
Распространено мнение, что есть «правильные», «каноничные» способы пользоваться фреймворками. Я его не разделяю. Я считаю, что каждый директор по продукту должен иметь модель, подходящую именно для его продукта. А для этого он ее должен уметь выбрать, настроить или целиком изменить под свой контекст.
Я убежден, что единственным критерием выбора модели является ее влияние на качество реально принимаемых решений. На практике это означает помещение в фокус внимания тех или иных свойств системы и предсказательная сила модели. Т.е. соответствие между состояниями предсказанными моделью и реально произошедшими событиями.
Команда разработчиков может и должна адаптировать любой инструмент под свои конкретные задачи и деятельность. Ваша система расстановки приоритетов станет эффективней, если будет индивидуальной.
Большинство фреймворков приоритизации имеют несколько жесткий характер и часто опираются на численные данные. При этом сами по себе фреймворки ни как не отвечают за полноту и достоверность данных, которые вы в них используете. Они служат инструментом визуализации, давая представление о текущем состоянии дел. Не думайте, что цифры, которые вам показывает модель, примут решения за вас. Это приближенное представление, которое с какой-то грубостью показывает картину. Решения принимают люди. Полагайтесь на рациональное мышление, комбинируйте цифры со своими экспертными знаниями и принимайте взвешенные решения. Таблица с цифрами — лишь основа для вашего выбора.
Этот принцип я подсмотрел у Канемана, в книге «Думай медленно, решай быстро». В 1955 году он, будучи лейтенантом израильской армии, столкнулся с проблемой создания эффективной системы отбора солдат для боевых частей, вдохновившись книгой Paul Meehl «Клиническое против статистического предсказания». Существующие неструктурированные интервью были полностью бесполезными для предсказания успеха кандидатов, поэтому Канеман разработал гибридный подход: сначала интервьюеры оценивали кандидатов по шести конкретным характеристикам (ответственность, общительность, «мужская гордость» и др.), а затем, после завершения структурированной части, закрывали глаза и давали общую интуитивную оценку. Результаты превзошли ожидания: «Большой сюрприз заключался в том, что интуитивная оценка в конце была столь же точной, как среднее значение шести оценок, и добавляла новое содержание», — рассказывал Канеман десятилетия спустя. Этот эксперимент лег в основу его главного принципа приоритизации: «Разбейте проблему на части, оцените аспекты независимо, и только потом используйте интуицию» — подход, который доказал, что сочетание структурированного анализа с экспертной интуицией эффективнее каждого метода в отдельности, при условии правильной последовательности применения (Episode 022: Deciding, Fast and Slow with Dr. Daniel Kahneman, Alliance for Decision Education, 2024).
Если вам нужно приоритизировать список любых кандидатов, то хорошая практика — сначала понять, что для вас делает участников этого соревнования более или менее ценными, то есть разработать свою систему метрик. Взвесить этих кандидатов в этой системе метрик. А потом, собрав факты, принять решение, исходя из экспертной позиции и глядя на числа. А фреймворки просто помогают отобрать эти критерии и организовать их в наглядный вид.
1. Проверьте, что вы правда можете осуществлять какую-то стратегию для своего продукта.
Есть такая стратегическая триада: субъект, объект и намерение субъекта по отношению к объекту.
Может показаться капитанством, но я все-таки рекомендую пройти простую самопроверку, прежде чем заниматься приоритизацией. Если любого из стратегических элементов триады нет, то мы практически не имеем шансов на то, что усилия по приоритизации приведут к чему-то, кроме потери времени и усилий.
2. Определите цель вашего продукта.
Приоритеты определяются целью. Без цели любые сравнения, качественные прилагательные вроде «лучше», «эффективнее», «быстрее» не имеют практического смысла. А усилия по определению приоритетов будут бесполезными. Поэтому, прежде чем работать с этой главой, убедитесь, что вы понимаете вашу цель. Простыми словами — вы правда понимаете, чего хотите добиться. Если цели еще нет, то приоритизацией заниматься рано.
Чтобы определить цель, есть другие подходы, которые нужно рассматривать отдельно от этой главы. Приоритизация помогает оперировать задачами внутри целей.
3. Уточните цель в терминах изменения поведения людей.
В конечном итоге любой продукт эффективен постольку, поскольку он обещает улучшения поведения людей. Если ваши действия не приводят к заметным изменениям в поведении какой-то группы людей, то в конечном счете они бессмысленны, потому что не изменяют экономику продукта и его влияние на мир.
Итак, у вас должен быть менеджер, который понимает и разделяет свою цель, может описать ее в терминах изменения поведения людей и имеет полномочия применить ее к продукту. Если все в порядке, двигаемся дальше.
В следующей части я расскажу про популярные фреймворки. На выходе они все дают одно и то же — ответ на вопрос, какие дела в каком порядке делать. Но хочу еще раз уточнить: не нужно воспринимать эти подходы как канонические — это то, с чего можно начать, чтобы потом разработать свой собственный подход.
Бэклог — это линейный список заданий, которые команда продукта выполняет в течение какого-то периода. Линейный, потому что сверху этого списка находятся более важные задачи, которые нужно сделать раньше.
Определить порядок действий можно с помощью матрицы Эйзенхауэра. Она состоит из четырех ячеек:
У этого квадрата достаточно простая проблема: срочное неважное убивает несрочное важное. Важные дела делаются только тогда, когда они становятся срочными.
Что делать с остальными двумя квадрантами и так понятно:
А вот как балансировать срочные (имеющие дедлайн и адвокатов, которые требуют срочности) и важные (обладающие наибольшим влиянием на приближение к цели, но пока не подгорающие) — 80% заморочек любой приоритизации. Если ничего специально не предпринимать, вы естественным образом сфокусируетесь на «Срочно/Важно». А это приведет к систематическому недоинвестированию в квадрант «Важно/Не срочно».
Философия лин-стартапа предлагает простой подход: пока система еще маленькая, пока у вас нет процессов и вы не рискуете ничем, кроме будущего своего стартапа и сидовых инвестиций, вы можете позволитьсебе не делать очень многого. Иными словами — делайте больше важного, перестаньте делать срочное. Примите потери и сфокусируйтесь на росте.
Выбор сводится к тому, чтобы распределить приоритет между важными делами.
Но чем взрослее будет компания, чем больше будет создано, найдено, запущено в эксплуатацию, чем больше у вас будет людей, лидирующих отдельные фрагменты процесса, чем больше клиентов и партнеров — тем больше будет возникать рисков, обязательств и проблем, конкурирующих за ресурс с важными проблемами.
Чем большим вы рискуете, тем сложнее выбирать.
Вопрос: как заниматься важными задачами вовремя? Делегировать неважное срочное другим. Производительность продуктовой команды всегда лимитирована фокусом внимания его лидеров. Поэтому постарайтесь сделать так, чтобы люди, способные своими действиями и мышлением ускорить работу, не тратили мышление на то, что не приведет к быстрому приближению к крупной цели. Другими словами — все, кроме того, что имеет наибольшее влияние на рост продукта, надо так или иначе аутсорсить: вспомогательным службам (если вы корпорация), внешним компаниям, отдельным людям, нанятым, чтобы разгрузить лидеров. Не важен способ, важен эффект: лидеры перестают заниматься срочными не важными задачами.
Я понимаю, что это просто сказать, но сложно сделать. Поэтому вся остальная глава про то, как понять, что самое важное, и как управлять фокусом внимания так, чтобы у важных кандидатов в дела было больше шансов на внимание команды.
По большому счету, все остальные фреймворки, о которых я буду рассказывать, — это способы балансировать этот перекос.
Термин «узкое горло» — это часть методологии ТОС (теория ограничений систем) Элияху Голдратта. Это автор «Цели» — одной из самых ценных книг по бизнесу, на мой взгляд. Также на эту тему есть «Теория ограничений Голдратта» Уильяма Детмера — сборник всех моделей Голдратта в виде схем и методичек.
Во-первых, ТОС — это система оптимизации потока. Подход применим, если мы можем представить бизнес как трубу, по которой течет поток ценности. Голдратт называет это «проходом». Это может быть поток денег, или товаров, или клиентов — чего угодно. Важно, чтобы это была характерная единица, которой удобно описывать состояние бизнеса.
Самая распространенная универсальная единица измерения потока — деньги, в них можно измерить вообще все. Поэтому стоит уметь выражать поток в деньгах, точнее, в проходе денег через систему: какое количество денег система способна через себя пропустить в единицу времени. То есть это деньги не в статике, а в динамике.
Во-вторых, у потока обязательно есть участок, который лимитирует его производительность — то есть определяет, сколько «воды» проходит через самую узкую часть трубы, и, следовательно, через всю систему. Голдратт называет это узким горлышком. Потому что, какой бы ни был диаметр трубы в разных частях, через систему пройдет столько воды, сколько просачивается через самую узкую трубу.
ТОС хорошо показывает, на чем стоит сфокусироваться сейчас, чтобы максимизировать рост. Если мы прикладываем усилия, чтобы расшить узкое место, то вся система чувствует эффект.
А если мы будем прилагать усилия в любом другом месте — то отвлечем ресурсы от самого важного. И если это место выше узкого звена, то еще и увеличим на него нагрузку и усугубим проблему. Это называется заниматься локальной оптимизацией — пытаться улучшить не ту часть системы, которая сейчас лимитирует ее производительность. И это реальный вред.
С точки зрения Голдратта, заниматься приоритизацией значит:
После этого самой узкой трубой станет другая, и нужно будет перенести усилия в другую часть системы.
Хорошая практика, на мой взгляд — скользящий график двух частей команды:
Так все всегда знают, что делать дальше.
Но все равно фокус внимания всех членов команды в каждый момент времени должен быть направлен на текущее узкое горлышко, потому что не всегда гипотезы о том, как его расшить, срабатывают с первого раза.
Чем больше влияния на узкое горлышко оказывает инициатива, тем больший приоритет получает эта задача.
В моей табличке две колонки. Первая — производительность системы. Здесь мы перечисляем места с ограниченной пропускной способностью. А вторая — поток, который идет через систему. Это сколько у нас здесь в реальности есть сейчас клиентов.
В строчках— шаги доставки ценности. Их удобно перечислять с конца — когда ценность доставлена. Например: клиент доволен и рекомендует наш товар следующему. Перед этим, очевидно, он использует наш товар или услугу. До этого оплачивает товар. А еще раньше принимает решение об оплате. И так далее до момента первый встречи с нашим предложением. Это обобщенная для большинства кейсов последовательность.
Табличку можно заполнять с любого места — с того, про которое мы что-нибудь знаем.
У текущего состояния системы есть вопрос: сколько условных попугаев, которые текут через систему, мы способны обслужить?
Если мы ведем через систему клиента, то наш вопрос: при каком количестве клиентов, которые будут пытаться использовать наш товар, мы перестанем справляться?
Если мы говорим о физическом товаре типа пылесосов, то считаем не сколько клиентов используют или не используют пылесосы — потому это не напрягает ресурсы нашей системы, а сколько пылесосов мы можем произвести в единицу времени. Потому что наша система лимитирована в этом месте.
Иногда ограничение может быть в том, сколько оплат мы можем принять в единицу времени. Например, наш менеджер способен продавать двум клиентам в день, это 40 клиентов в месяц. Пока у нас один менеджер, мы физически не сможем продать больше, чем 40 клиентам. Эта проблема неактуальная для сайта — там мы можем продавать какому угодно количеству клиентов.
В начале я говорил, что вся система приоритизации летит в топку, если мы потеряли связь с целью. И вот ТОС фактически говорит то же самое, просто в более строгой формулировке.
Когда у нас есть какой-то KPI, и нам сказали, что наша задача оптимизировать любую метрику, какую бы метрику мы ни выбрали, попытка ее оптимизации неминуемо приведет нас к локальной оптимизации. Поэтому, кстати, за метрики вредно премировать.
Нужно оптимизировать узкое горлышко и смотреть на ту метрику, которая в этот момент показывает, что мы прикладываем усилия в нужном месте.
Если вы работаете продактом в зрелом продукте, и вы не CPO, а кто-нибудь помладше, то, скорее всего, вы занимаетесь не всем продуктом целиком, а каким-то его фрагментом. Условно говоря, вы продакт фичи или метрики. Как не свалиться в локальную оптимизацию при таком подходе?
Допустим, вы работаете в образовательном стартапе и ваша задача увеличивать вторую конверсию — то есть делать так, чтобы клиент, который оплатил первый период курсов, оплатил второй.
Для начала нужно восстановить связь с целью:
Одна из самый отрезвляющих и важных мыслей Голдратта такая: когда вы направляете усилия не на узкое горлышко, вы не просто не помогаете. Вы вредите. И дело не только в том, что вы отвлекаете ресурс внимания лидеров команды. Помните квадрат Эйзенхауэра? Локальная оптимизация — источник срочных, но неважных задач. Это приводит к тому, что производительность узкого горла снижается. Детали читайте в книге «Цель».
На мой взгляд, это проблема больших систем. Но обеспечить производительность всей системы — не задача отдельного продакта. Это главная задача CPO сделать так, чтобы в каждый момент времени все члены команды были сфокусированы на том, чтобы максимизировать поток.
Как я говорил, ТОС применим, если можно посмотреть на систему как на цепочку доставки ценности. Думаю, если вы не можете выразить вашу систему как поток ценности, скорее всего, у нее плохая организационная архитектура. Поэтому дальше я сделаю лирическое отступление и расскажу про то, что считаю хорошей архитектурой — с помощью метафоры деревьев.
Представьте, что ваш продукт — это дерево. Пользователи видят то, что над землей: интерфейсы, клиентские процессы, товар, рекламу. Это ствол и ветки. И это главная ценность, которую создает продукт.
Под землей — ваш бэк-офис: внутренние процессы сотрудников — производственные, юридические, финансовые. У каждого бизнеса это свое, и оно здоровенное. Это корни — клиенты их не видят.
Теперь посмотрим, какие бывают деревья.
У сосны ярко выражен ствол — видно, что у нее есть центральная ось, вокруг которой все выстроено. Это пример хорошей архитектуры
Смешной момент. Представьте, что дерево — это ось времени. Тогда оно одновременно растет вверх и вниз, как корни и крона, а в точке касания земли — старт развития продукта, нулевая точка. Это время взаимодействия с рынком: чем более взрослый продукт, тем он выше вырастает и глубже зарывается.
Пока сосна растет, она очень стройная, у нее всегда есть понятное стремление в одну вверх, где у нее крона. Сосна говорит: «Я знаю, на каком рынке присутствую, у меня есть основание, понятно, вокруг чего я выросла, и теперь я могу выбросить густую крону».
Все самое главное сосна отдает клиентам. У нее стройная концепция и на самом деле не очень глубокая корневая система. Поэтому сосны легко выкорчёвываются и быстро растут.
Пример такой архитектуры — поисковая машина. Она отвечает посетителям на вопросы. У нее выраженный главный экран, на котором пользователь получает свою главную ценность — аннотированный список ссылок на сайты. Чем эта выдача более релевантна запросу, тем поисковая машина лучше, а всё остальное типа Яндекс Маркет, Google Фото, Карты — это уже дополнительные ветви, которые вырастают позже и опираются на ствол.
Еще один пример понятного ствола — приложение для вызова такси. Оно перевозит пассажира из одной точки в другую, подавая машину быстро и предсказуемо. Для пассажиров — это самый быстрый способ получить частную машину по справедливой предсказуемой цене, а для водителей — способ получить клиентопоток.
Понятно, что когда приложение такси становится большим, как Uber и Яндекс Такси, оно может сказать: «Теперь я суперапп, у меня есть доставка, премиум машинки, машинки с сиденьем для детей и мини-игры в сторис». Но это ветки. Все равно понятно, какой кейс главный и через какой процесс течет главная ценность.
В общем, сосна молодец — будьте как сосна.
У елки тоже есть один ствол, но у нее много боковых веток, которые растут сразу снизу. Глядя на елку, мы не видим ствола, но четко определяем, где он находится.
Тут в моей метафоре есть допущение: в жизни сосна не превращается в елку со временем. А в продукте, если у вас была выраженная ось, по которой вы растете, то потом у вас по всему стволу возникают ветки — потому что, где бы ни был поток ценности, вы хотите его расширить.
Например, когда-то айпод стал первым стриминговым сервисом в физической форме. Это было устройство, чтобы слушать музыку с доступом к стору. То есть айпод — это сосна. А айфон сразу строился вокруг стора, и у стора сразу было множество программ. У него даже был слоган: «Для этого есть приложение». Поэтому айфон — елка.
У дуба все сложно: как корова шла — так дорогу проложили. Не очень понятно, какой был замысел изначально, в какую сторону хотел расти дуб. Иногда его ветки такие здоровенные, что кажутся отдельными деревьями.
Пример дуба — бизнес большой холдинговой компании. В ней есть разные огромные процессы, они все имеют свою автоматизацию, в некоторых местах они очень тесно сопряжены, а в некоторых совершенно отдельные.
И это еще сложнее, чем сосна, потому что не очень понятно, попадает ли новое ответвление в концепцию продукта и сможем ли мы представить все это как процесс, в который, с одной стороны, мы загружаем сырье, а с другой — получаем деньги и оно течет одной большой рекой. Но жизнеспособные дубы бывают.
Это самая распространенная архитектура, потому что для куста не нужен концепт, его легко проектировать: все растет как попало, нужно просто что-то делать. Захотели — выросли. Ветка сломалась — ну и фиг с ней, у нас таких полно.
Что у кустов плохо? У них нет фокуса, они не бывают сильно большие, ими сложно захватить рынок, и у них не очень долгое время жизни. Зато не надо страдать над концепцией.
Грибы хуже кустов. Это любимый жанр для попилки бюджета: клиенты видят маленькую пипку сверху, все остальное под землей и очень разветвленное. Клиентского взаимодействия нет, ценность не особенно течет. Грибы вырастают, когда или с самого начала не хотели ничего делать и была цель взять деньги за размер грибницы, или хотели сделать сосну, но фокус был под землей, а не над ней. Не будьте как грибы.
— Можно ли вырастить сосну на месте грибов?
Конечно, можно, только не надо думать, что корни грибов — это корни сосны. Надо просто вместо грибов посадить сосну. Возможно, кто-то и умеет выращивать стройную концепцию из процессов, которые строились под другую задачу. Но это не я. Если переделывать что-то старое, в лучшем случае получим куст. А вероятнее, и наружу, в рынок, не вылезем.
— Как распознать хорошую архитектуру?
На мой взгляд, хорошая архитектура имеет стержневой процесс. Если мы его не видим, если мы структуру не можем показать как поток ценности — скорее всего, наша архитектура не самая лучшая.
Жизнеспособная и живучая архитектура имеет выраженный ствол, а ствол в данном случае — это главный поток доставки ценности.
ТОС был бы лучшим фреймворком, если бы мы продолжали работать со счетными единицами доставки ценности на всем пути ее создания и доставки. К сожалению, умственный труд имеет принципиально другую природу. Как говорит Мэт Гюнтер: "TOC's focus on throughput creates playing faster moves in chess" В отличие от производственной линии, где узкое место обычно физическое и стабильное (например, конкретный станок), в разработке цифрового продукта ограничением чаще становятся знания, коммуникация или неопределенность требований — факторы, которые часто нельзя "расшить" простым увеличением пропускной способности или измерить простым инструментом. Поверхностное применение TOC может привести к оптимизации количества выполненных задач в ущерб их качеству. В общем — TOC классный, но применить его эффективно достаточно трудно.
Так что давайте рассмотрим что-нибудь попроще.
RICE — второй по распространенности фреймворк. Эта аббревиатура расшифровывается как Reach, Impact, Confidence и Effort, то есть охват, влияние, уверенность и затраты.
RICE построен на примерно такой идее: «Давайте найдем низко висящие плоды и сначала съедим вкусное и легко собираемое, а когда это кончится, займемся нажористым, но трудно приготовляемым или быстро убегающим в лес».
На все это тоже нужно смотреть как на систему, через которую течет поток каких-то попугаев: сделок, клиентов, денег, холдингов, айфонов.
RICE говорит: «Давайте займемся теми инициативами, которые на один потраченный ресурс приносят больший эффект». Это главная его мысль.
Эффект — это ценность, которую вы для себя выбрали: деньги, клиенты, сделки. А за потраченный ресурс я предпочитаю брать время самого дефицитного ресурса. Например, если у нас самый дефицитный ресурс — тимлид, давайте все номинировать в часах тимлида. Если это отдел продаж, давайте считать командо-дни отдела продаж. Если это календарное время, давайте номинировать все в нем. А если у вас почти не осталось денег и вы на всем экономите — в рублях.
В начале я говорил про Канемана и его метод отбора офицеров. В нашем случае кандидаты — это гипотезы или куски функциональности, на которые мы собираемся тратить усилия. Нам нужно придумать некоторую систему параметров, взвесить кандидатов в этих параметрах и, глядя на результаты, принять решения. И вот RICE — это конкретная пачка этих параметров. Этот фреймворк позволяет приоритизировать гипотезы, визуализируя нашу интуицию — очень быстро и очень грубо.
Берем какой-нибудь сервис, например, корпоративный сайт. Мы хотим сделать из него поток клиентов. Для этого нам нужно создать куски функциональности, которые нам помогут. Обращаемся к RICE.
1. Выдвигаем гипотезы, что можно сделать, чтобы у нас было больше клиентов:
В работе над реальным продуктом этих идей обычно десятки или сотни, а может, и тысячи. Мы ограничимся тремя для примера.
2. Номинируем параметры RICE.
У нас есть:
Нам нужно их как-то оценить. Натурные показатели собирать сложно, потому что обычно инициатив очень много. Вы или будете высасывать цифры из пальца, или уработаетесь. Поэтому стоит сделать два подхода: сначала оценить параметры в условных баллах, отсеять нерабочие идеи и только потом перейти к натурным показателям кандидатов в дела, вошедших в топ списка.
Возьмем шкалу от 1 до 5. 5 баллов в охвате — это самый большой поток того, что течет через нашу систему. Пусть в нашем случае это будут целевые клиенты. 5 баллов во влиянии значит, что, если мы воздействуем на поток клиентов в этом месте, он кратно увеличится. А 1 балл значит, что влияния нет или оно отрицательное. В уверенности все тоже просто — насколько мы уверены в том, что эта инициатива повлияет: 5 — полностью уверены, ведь у нас уже так было, а 1 — мы не пробовали и не знаем. Затраты отличаются тем, что здесь чем меньше, тем лучше. 5 — это самые большие затраты, которые мы готовы понести в рамках этой инициативы. Допустим, это квартальная прибыль. А 1 — это минимальные необходимые вложения, например, когда инициативу можно внедрить за день.
Все баллы — относительные. Это взвешивание интуиции и ничего больше. Просто, прежде чем применять RICE, договоритесь, что значат крайние и средние значения каждой из шкал — чтобы дальше можно было правильно интерпретировать результаты оценки экспертов.
4. Взвешиваем параметры для каждой гипотезы.
Рассмотрим на примере охвата. Первая гипотеза — «Добавим на сайт больше кейсов». Кейсы будут находиться где-то внутри сайта, то есть не все клиенты, которые пройдут через нашу маркетинговую систему, их увидят. Значит, это не может быть максимум и мы не можем поставить 5. Но мы надежно знаем, что кейсы регулярно приносят поисковый трафик — там есть поток. Поэтому можно поставить 3.
Вторая гипотеза — «Купим больше трафика». Так мы точно повзаимодействуем с большим количеством клиентов. Но много ли будет целевых? Ставим 4.
Третья гипотеза — «Внедрим реферальную программу». Чтобы дать оценку, нужно понять, сколько сейчас через реферальную программу течет клиентов. Если мы этого не знаем, то не можем поставить высокую оценку, но у нас есть уверенность, что кто-то точно придет. Ставим 2.
Дальше таким же образом оцениваем параметры для остальных гипотез.
Это был первый подход к RICE в стиле скрам-покер: убедились, что поняли, про что говорим, собрали мнение присутствующих — визуализировали интуицию. Легко заметить, что RICE оставляет гигантское поле для ошибок и волюнтаризма. Поэтому так мы просто договариваемся, какие из гипотез мы опишем детальней: залезем в систему аналитики, поговорим с клиентами, получим бенчмарки с рынка и вытащим конкретные цифры. Когда мы посчитаем все в натурных показателях, то увидим, какой прирост клиентов обещает дать каждая из гипотез.
Есть еще похожая идея ICE — здесь немного другой набор слов: Impact (влияние), Confidence (уверенность), Ease (трудозатраты). Вы можете сделать вашу мутацию параметров. Но от этого подход не станет более точным, он просто станет более специфическим для вашей задачи.
RICE, или ICE, или ваша вариация визуализирует самые низко висящие плоды. Но принимать решения должна не таблица с цифрами, а вы сами.
Он врет. Если развернется подковерная война на сцене RICE, то туши свет, бросай гранату — будет очень плохо. Потому что это очень грубая методика. Пользоваться ею можно, только если вы можете себе не врать. И он тем сильнее врет, чем более разнородные инициативы вы взвешиваете.
Тяжело приоритизирует дорогие задачи. RICE нужен ровно для того, чтобы найти низко висящие плоды, а не чтобы выстроить продуктовую стратегию. Если пользоваться только RICEом, сосна не вырастет — получатся кусты.
Провоцирует на локальную оптимизацию. Потому что низко висящие плоды могут быть в очень разных частях системы.
RICE может проверить самые ранние гипотезы, когда у вас еще нет понимания рыночного сегмента. Тогда через RICE текут респонденты или инсайты. И это способ нагенерировать больше инсайтов, из которых вы потом сможете сделать ствол. Но он за вас ствол не сделает.
Для ствола нужен TOC — он помогает вырастить сосну. А RICE помогает найти инициативы, которые малым количеством усилий окажут большое влияние. Но это не средство стратегического планирования и не средство управления кратным ростом.
Я бы сказал, что самое лучшее для применения RICE — управление приоритетами команды поддержки. Именно той части команды, которая берет на себя «усилия по поддержанию штанов», чтобы команда роста не отвлекалась. Вот для нее это идеальное средство, которое говорит, в какой части хозяйства надо сегодня сделать уборку.
В проверке гипотез есть такая заморочка. Одни считают, что сначала нужно найти рынок и убедиться, что мы действуем в растущей нише, а потом уже придумывать, на чем здесь заработать. А другие говорят, нужно сначала убедиться, что мы в принципе умеем доставлять ценность, а потом уже придумывать, кому ее продать. Самая рискованная гипотеза — один из способов выбрать путь.
Обычно мы считаем рисками плохие события. Но вообще-то, особенно в рамках самой рискованной гипотезы, — это любые вероятные события. Не только плохие, но и хорошие.
Есть гипотеза, которая может воплотиться с какой-то вероятностью, и это как-то повлияет на цель — не обязательно негативно. Разбирать бэклог нужно, начиная с самой влиятельной гипотезы.
В управлении рисками стоимость риска — это вероятность риска, помноженная на влияние риска на достижение цели. А самая рискованная гипотеза помогает находить из этого произведения наиболее ценные гипотезы и приоритизировать бэклог от влияния на цель.
Риски номинируются в целях того, чем мы заняты — системы, которую мы стратегируем. В нашем случае в целях продукта. Единицы, в которых мы измеряем влияние риска, — это «одна цель». Вот есть какой-то риск. Если он сработает, мы потеряем какой-то процент цели: целевой рынок станет меньше, или сократится доход, или еще что-нибудь.
Этот метод может работать как численный только в случаях, когда есть поток событий, а не единичный риск. Например, нельзя оценить в цифрах, может ли конкурент, который сейчас оперирует на другом рынке, диверсифицироваться в нашу сторону. У нас нет базы для экстраполяции. А если мы занимаемся скорингом страховых случаев, то мы можем посчитать наступление страхового случая и его цену.
1. Строим таблицу, в которой перечисляем основные моменты бизнеса, например:
Набор номинаций может быть разным — в зависимости от вашего бизнеса.
2. Для каждого квадратика находим список факторов, которые в наибольшей степени влияют на бизнес. Для примера возьмем VR-райды, которые мы делаем в JetStyle.
Начинаем строить предположения:
3. Спрашиваем себя про каждое предположение, а что если оно не верно, насколько сильно это повлияет на нашу цель.
Если это не коммерческий директор, а кто-то другой, то мы просто его найдем и сменим таргет. А если они в принципе не заинтересованы в монетизации потока, то это имеет очень сильное влияние, потому что тогда они не купят ценность, которую мы предлагаем. В первом случае — это часть цели, а во втором — вся наша цель. Т. е. один целый пункт риска.
4. Когда мы выявили фактор с большим влиянием, нужно понять его вероятность. Для этого нужно заняться ресечем.
5. Так в каждой из шести номинаций появится свой победитель — самая влиятельная гипотеза. И теперь нужно выявить среди них абсолютных чемпионов. Находим гипотезу, подтверждение которой сильнее повлияет на бизнес, и ставим ее первой в бэклоге.
Самая рискованная гипотеза позволяет вспомнить основные моменты бизнеса. Таблица — пример, вам стоит сделать свою, посмотрев на то, какие основные процессы и этапы есть в вашем бизнесе.
Quality Function Deployment переводится как структурирование (развертывание) функции качества. QFD был разработан в конце 1960-х на верфях Mitsubishi в Кобе профессорами Акао и Мизуно. BuzzClanITU Online Toyota популяризировала метод после успешного внедрения. Метод помогает ответить на вопрос, какие технические характеристики должен иметь продукт, чтобы это было именно то, что нужно клиенту.
В классическом подходе есть список хотелок клиентов и список фич, которые можно внедрить, — и с помощью специальных обозначений мы оцениваем, насколько каждая фича повлияет на воплощение конкретной хотелки.
Это такая очень хитрая мутация RICE: мы понимаем, насколько фича способна создать целевые качества продукта, сравниваем с трудоемкостью и взаимовлиянием с другими фичами и получаем приоритет.
Классическая версия метода, на мой вкус, переусложнена и сфокусирована не совсем на том, что волнует продакта. Я пользуюсь самодельной мутацией.
1. Собираем проблемы, про которые нам говорили клиенты. Например, мы — сайт авиакомпании. И боли наших клиентов — «Я не знаю, куда поехать в отпуск», «Мне сложно вписаться в рабочий график», «Я боюсь опоздать на рейс».
2. Указываем частотность — сколько раз нам говорили про каждую проблему.
Здесь нужно провести исследование и указать реальную частотность, которая справедлива для выбранной клиентской группы, иначе все результаты будут на глаз.
3. Нормализуем частотность, чтобы в сумме была единица, и получаем вес каждой боли. Здесь единица — это 100%, поэтому каждая боль записывается как какой-то процент вклада.
4. Переформулируем боль в ценность с помощью инверсии:
5. Смотрим, как эти ценности доставляют конкуренты. Допустим, у них есть табло, поиск рейсов, СМС-напоминание о регистрации, схема выбора места в салоне и проч. Важен не просто набор фич, а конкретные особенности реализации.
6. Оцениваем, насколько фичи конкурентов решают проблемы клиентов. Для этого используем легенду:
Важная особенность метода: мы не ставим промежуточных значений. Если мы можем сказать, что некоторое свойство само способно решить проблему клиента, то ставим 9. А если ему нужны какие-то дополнительные условия, то, каким бы важным оно нам ни казалось, ставим 3, а не 5 или 6.
7. Умножаем нашу оценку на вес, который определили для каждой боли в пункте 3. Результат говорит о том, насколько полезно заниматься конкретным делом для решения конкретной проблемы.
8. Суммируем столбик с удельной ценностью и получаем то, насколько эта фича в общем влияет на доставку ценностей нашего продукта.
9. Осталось сравнить удельную ценность каждой фичи с тем, сколько и чего мы потратим, чтобы ее создать. Например, сколько времени и усилий.
В результате фреймворк приоритезирует боли клиентов и показывает, какая какая фича принесет больше всего ценности с учетом этого приоритета. С нее и нужно начинать.
Важный момент: когда мы поставили какой-то фиче девятку, мы не просто дали ей приоритет, но и обозначили требования к ней. То есть для решения проблемы выбора подходящего рейса нужно сделать не просто любой поиск рейсов, а такой, в котором удобно букировать командировки. Все, что связано с экспериментальной проверкой, с установкой требований, с кейсами, мы берем из связки: мы делаем эту фичу, чтобы создать эту ценность, которая решит эту проблему.
На ранних стадиях проектирования продукта QFD помогает понять, какие проблемы нужно решить, напридумывать фич для их решения и выбрать, вокруг каких строить продукт — т. е. выбрать ствол продукта.
К зрелым продуктам QFD тоже применяется: вы просто говорите со своими пользователями, и у вас появляется километровый список проблем и фич, которые могут их решить. QFD отлично поможет понять, что делать в первую очередь.
На ранних этапах это гипотеза существования бизнеса, а на этапах поздних — это гипотезы о том, что на твой бизнес повлияет в будущем.
Главная опасность QFD в том, что если продакт склонен скатываться в фичеризм (т.е. мышление о функциях продукта, а не поведении людей), то такая система даст ему способ подогнать цифры под любимые фичи. QFD делался с прямо противоположной целью — приоритезировать ценности, и находить пути их достижения. Но им легко злоупотребить.
Я рассказал про пять разных фреймворков, которые на основании каких-то метрик помогают приоритизировать. Но давайте не забывать, что метрика — это не самоцель деятельности. Любую метрику можно применить не по назначению. Смысл деятельности в достижении целей бизнеса, а метрики просто индикаторы того, насколько мы к ним приближаемся.
В конечном итоге любая приоритизация сводится к тому, что вы быстрее двигаетесь к цели. Чем яснее вы понимаете вашу цель и чем быстрее к ней двигаетесь, тем лучше.
Если сколько угодно «правильно» применить фреймворки, но потерять связь с целью, все будет зря. А если ясно видеть связь с целью и двигаться к ней быстро, не пользуясь фреймворками, а делая все по-своему — все будет хорошо. Если только вы не ошиблись в постановке цели.
На графике по горизонтали есть стадия зрелости продукта: от идеи до группы продуктов — большого бизнеса, который стабильно приносит деньги. Между ними есть этапы: первые продажи, найден маркет-фит, устойчивый рост, дойная корова.
А по вертикали — воронка продаж AAARRR: Awareness (оповещение), Acquisition (покупка), Activation (активация), Retention (возвращение), Referral (виральность), Revenue (маржинальность). В каждый момент времени в каком-то месте будут как-то выстроены цели, которые что-то будут значить вот в этой всей истории.
Кажется, что все основные цели продукта находятся где-то в этих квадрантах.
В разное время может болеть разное, например: про нас никто не знает, у нас низкая конверсия в покупки, клиенты покупают, но не пользуются, клиенты пользуются, но им не нравится, клиентам нравится, но у нас слишком много удельных затрат.
Заниматься одновременно всем невозможно. Все равно в каждый момент времени есть самое узкое горлышко. Найти его можно с помощью ТОС.
Юнит-экономика — это экономическая форма записи того же самого. В TOC мы оптимизируем поток, на который можно смотреть по-разному. Но один из самых удобных разрезов — жизненный цикл пользователя, выраженный во влиянии на деньги.
Обобщенный сценарий для e-commerce такой:
Юнит-экономика отвечает на вопрос, что мы масштабируем: доход или убыток.
Если при работе с воронками неожиданно вылезает ступенька, это юнит-экономика говорит, что мы наливаем воду в дырявое ведро, потому что пытаемся продавать услугу, которая не устраивает клиентов. Пока мы это не починим, мы всегда будем терять деньги. Вывод: сначала надо разобраться с доставкой ценности, а уже потом вкладывать усилия во все остальное.
Юнит-экономика — это экономическая модель, которая показывает, как себя ведут пользователи, в экономических терминах и в каком месте сценария есть самые острые проблемы.
Что это значит для приоритезации? Вы сравниваете все гипотезы, предполагая, на какую часть юнит-экономики повлияет инициатива, и выбираете те, которые дают больше влияния на gross profit.
До этого мы говорили о том, как оптимизировать поток доставки ценности — это касается логики продукта. Есть бэклог толково описанных задач, которые мы отранжировали по важности — берем и делаем задачу сверху списка.
Такой подход максимизирует шанс на то, что мы будем заниматься важной задачей раньше, но он не отвечает на такие вопросы: а когда будет сделан весь продукт целиком? а мы успеем запуститься до старта сезона? а сколько это будет стоить? а как мы измерим качество продукта и вообще, какого качества мы хотим добиться?
Тут возникают практики управления приоритетами, которые идут не от логики продукта, а от логики проекта.
Проект — это когда мы пытаемся достичь описанного в первоначальной постановке результата, уложившись в границы, данные нам в терминах качества, сроков, функционального портрета и стоимости.
Думаю, что когда-нибудь это докажут как теорему, но пока это лемма, и она звучит так: если вы до начала разработки продукта фиксируете его функциональный протрет, сроки и критерии качества, то вы можете получить пользу от эксплуатации написанного софта только в том случае, если вы воспроизводите уже работающий к этому моменту в идентичных условиях софт.
Ну и, бывают ситуации, в которых логику проектного менеджмента нельзя игнорировать. Например, если вы работаете в бюджетной организации. Тогда приходится мириться с какими-то рамками.
У меня есть эвристика: если из четырех факторов — скорость, стоимость, функциональный портрет и качество, данное в терминах поведения пользователя — мы зафиксировали требованиями больше, чем два — то все плохо. Мы оставили себе слишком мало свободы. У менеджера нет инструментов управления. Если что-нибудь пойдет не так, мы не сможем среагировать и провалим проект. А у нас что-то точно пойдет не так, ведь мы строим новый инновационный бизнес, и неопределенность велика.
Если гвоздями прибит только функциональный протрет
Тогда большой вопрос: продукт ли мы делаем. Вероятно, мы далеко не первые на рынке и создаем 916-й ларек с шаурмой, который будет таким же, как 915-й.
У нас может быть гипотеза о том, как конкретный набор функций может изменить поведение пользователей. Но, если мы еще не реализовывали этот набор функций и не наблюдали, что это поведение случалось, то мы не знаем наверняка, каким будет функциональный портрет, пока не пронаблюдаем, как им пользуется клиент в сценарии доставки ценности.
Если вы считаете, что знаете, какая функциональность сработает, значит, вы либо пророк, либо занимаетесь не инновацией. Но чаще всего — у вас просто галлюцинация. Функциональный портрет в инновационном бизнесе не стоит фиксировать.
Качество — это не «сделайте хорошо, нет, превосходно». Это конкретная особенность, какое-то конкретно качество. Описать качество на старте можно, только если вы этот рынок уже хорошо знаете. Например, вы работаете на рынке расходников и знаете, что retention — ваша основная метрика. Или вы работаете на рынке образования и знаете, что ваша главная метрика — доходимость, то есть процент клиентов, которые закончат учиться. Если это так, то именно это качество становится вашим приоритетом. Значит, у вас будет серия экспериментов, направленных на улучшение качества. Но, скорее всего, такое понимание рыночной ниши у вас будет не на старте, а в середине или только когда вы уже найдете связь с рынком.
Это хороший случай, потому что в этих рамках не зафиксирован функциональный портрет. Мы можем воспользоваться методом критического пути и определить, что нужно сделать сейчас, чтобы получить лучший перформанс, пока не кончились инвестиции и срок.
Постарайтесь самой короткой дорогой идти к первой выгоде, которая дана либо в терминах денег, либо в терминах обратной связи от использования. Переприоритизируйте то, что вам выдали, так, чтобы сначала делать то, что видимым образом изменит клиентские или внутренние процессы.
Если вы не можете построить работу так, чтобы видеть, как меняются процессы, то вы занимаетесь не продуктовой историей, и эта книга не для вас. Про то, как заниматься проектами, читайте у Скотта Беркуна — он молодец.
Критический путь — это длинный список задач, которые обязательно нужно делать последовательно. Если вы затягиваете сроки выполнения одной задачи — затягиваются сроки всего проекта.
Когда вы идентифицируете такой список, важно попробовать его хакнуть — оспорить, действительно ли нужно делать столько шагов. В этом случае стоит приоритизироваться от блокеров. Блокер — это то, без чего сценарий не выполняется вообще.
Важно выкинуть из критического пути все, кроме блокеров, выкатить продукт во взаимодействие с клиентами в самом аскетическом состоянии, и получить станок для тестирования гипотез. И уже после этого вернуться к оптимизации потока и доделать остальное, чтобы улучшить метрики и придти к цели.
Но это будет уже не проектный менеджмент, а продуктовый.
Когда вы уже что-то запустили, вам надо это развивать, но хочется запустить следующую крупную фичу, у вас появляется второй поток разработки. Первый занят поддержкой и развитием того, что вы уже построили. Второй — проверкой новых гипотез. Хорошая практика: сколько потоков разработки — столько команд. Команда поддержки приоритизирует баги и хотелки, а команда развития пилит новые гипотезы.
Если команда одна, все приоритизируется в едином потоке. Кроме одного исключения — критических багов. Если на проде есть критический баг, то каждое его столкновение с клиентом приводит к потере денег. Например, ошибка в транзакции. Критический баг имеет вытесняющий приоритет. Если он случился, все бросаем — чиним его. Критический значит, прямо сейчас наш бизнес быстро теряет деньги из-за ошибки на проде.
Есть такое правило: нельзя, чтобы редкие кейсы дискриминировали магистральные, важные основному потоку клиентов. Меньшинство не должно навязывать изменения в поведении большинству. Когда вы делаете лучше частному случаю, проверьте, что вы не делаете хуже основным пользователям. А лучше на этапе приоритизации спросите себя, откуда вы вообще взяли, что это важно. RICE вам в помощь. Помните, что в нем могут быть и отрицательные значения.
Когда бизнес дожил до момента «найден маркет-фит», нужно начинать выделять время на уборку. Если заниматься только магистральными сценариями и критическими багами, то через некоторое время все начинает порастать мхом: интерфейс теряет актуальность, показатели возвратности падают. Задачи, которые просто улучшают пользовательский опыт, тоже нужно делать.
1. Мы придумали и описали идею.
2. Приоритизировали — поняли, когда ею займется.
Многие думают, что, когда мы говорим о приоритете, то имеем в виду приоритет разработки. И что самые медленные ребята в цепочке — это программисты, и их вечно всем не хватает. Это неправда.
Мы приоритизируем не написание софта, а изменение поведения целевого человека: внешнего или внутренного пользователя. Поэтому в приоритизации фичи нужно учитывать не только то, что ее напишут программисты, а то, что все, кто будет сталкиваться с этой фичей в работе — например, производственники, продажники, юристы, маркетологи — поняли, что им нужно сделать, чтобы изменения, которые вы собираетесь внедрить, были внедрены. И сделали это. И увидели, как изменилось поведение пользователей.
Очень часто оказывается, что самый дефицитный ресурс совсем не программист, а, например, продакт.
3. Создали и протестировали альфа-версию на тестовой группе.
4. Создали и протестировали бета-версию на неограниченном количестве неподготовленных пользователей.
5. Добились доставки ценности. Кастдеверы посмотрели, как работает фича в продакшене, проанализировали пользовательский опыт и поняли, что все работает.
6. Унесли в поддержку, которая теперь займется бэклогом фичи, чтобы она перформила лучше, и будет править баги.
Если у нас есть ясная система целей и метрик и мы не занялись локальной оптимизацией, то все в целом понятно. Надо проанализировать, какие мероприятия требуют мало усилий и сильно влияют на скорость приближения к цели, и заняться ими. То есть сорвать низко висящие плоды, влияющие на узкое горло. Но есть два сложных случая.
Есть такие фичи, внедрение которых совершенно точно улучшит жизнь пользователя, но не факт, что вашей экономики от этого тоже будет хорошо. Часто бывает наоборот: жизнь пользователя становится лучше за ваш счет, а у вас локально, с точки зрения кэшфлоу, все становится хуже.
Вы можете думать, что благодарные пользователи будут возвращаться, поэтому в бизнесе все станет лучше за счет retention. В целом это очень верная позиция. Иногда говорят, что самая главная метрика бизнеса — это повторные продажи, или лояльность пользователя. Поэтому иметь целью создание ценности — хорошо. Хотя в моменте это может означать, что вы тратите усилия на то, что принесет деньги потом, а не сейчас. Чтобы это понимать, нужно иметь метрики клиентского счастья.
Но дальше наступает вопрос: а откуда мы знаем, что этот набор метрик правильный, если мы в будущем еще не были? Как нам убедиться, что, создав счастье для людей, мы правда заработаем. Честно сказать, у меня нет другого ответа, кроме как верить в такой исход. И тут мы подходим ко второй проблеме, с которой не справляется приоритизация — как сформировать видение, которому стоит верить?
Допустим, в рамках вашего вижена, чтобы изменить поведение людей, нужно создать что-то радикальное: долгое, дорогое, требующее R&D и серии экспериментов. Вообще не похожее на низко висящие плоды, но сулящее революцию.
Например, вы хотите применить искусственный интеллект для извлечения данных о состоянии складских остатков, чтобы любой снабженец всегда знал не только ассортимент каждого предприятия на рынке, но и наличие, и цену.
Как это сделать? Никто не знает. Но это произведет фурор на рынке. Поэтому вы планируете инвестировать в поиск способа, пока не убьетесь.
С одной стороны, методики, о которых я говорил — и TOC, и RICE, и самая рискованная гипотеза — могут говорить, что это хороший сценарий. И приз настолько гигантский, что вы можете позволить закопать сюда много инвестиций.
Но тут вы столкнетесь с реальной проблемой, для решения которой у меня на самом деле нет инструмента. Проблема такая: как понять, точно ли это глубокое хорошее видение. Вдруг это бред нашего босса, и мы занимаемся ерундой?
Все мы много раз видели людей, которые думают, что они визионеры, а он дураки. Придумали фигню, закопали в нее годы, а потом оказалось, что она не работает. Но у некоторых из нас есть опыт, когда мы бросили свою идею, решив, что у нее не может быть успеха, а потом другие ребята сделали на том же месте своего единорога.
Приоритизация не поможет вам ответить на этот вопрос. Она поможет сделать шаги, которые приближают целевую картинку, но не застрахует от ставки не на то, в глобальном смысле.
Можно просто не заниматься глубоким виженом — это хороший способ не потерять деньги. Но тогда, скорее всего, и рынок по-крупному изменить не получится.
Если же вы все-таки решили делать крупную ставку, то есть один верный симптом. Визионер — это человек, видению которого по какой-то причине можно верить. Поэтому у него точно должна быть экспертиза в той предметной области, которой он занимается. И должны быть люди, которые в эту картину верят. Если это не так — то почти 100% ничего хорошего не выйдет.
В этой статье мы разобрали несколько заготовок моделей приоритизации. Но еще раз хочу сказать — не пытайтесь относиться к ним как к канону, делайте все под свою задачу. Вам нужна ваша собственная модель, которая хороша постольку, поскольку ускоряет движение вашего продукта к вашей цели и обладает предсказательной силой. Если фреймворк не помогает движению к цели — забудьте и выкиньте. Дело не во фреймворке, а в движении.
