Это вторая из двух статей про бэклог. В первой я разбирал, почему бэклог это не план, а коллегиальный документ, в котором лоббируют свои интересы все, кроме пользователя, хотя платит за продукт именно он. Диагноз был поставлен. В этой статье сконцентрируемся на лечении.
Меня зовут Александр Козуб, я двадцать лет в финтехе, последние несколько из них CPO. В симптомах вижу систему, об этом и пишу.
Главный вопрос, на котором мы остановились, звучит так. Допустим, я согласен, и в бэклоге голосуют все, кроме плательщика, и надо вернуть его голос. Но как это сделать, если у меня недостаточно власти отклонить задачу CEO, переспорить маркетинг или отклонить инициативу разработки? Я же не могу запретить им хотеть.
Запретить не можете, но управлять потоком, не запрещая, можете и, более того, должны.
Проблема вместо задачи
В продолжении прошлой темы буду развивать тему фокусирования на проблемах вместо решений и замены бэклога задач на бэклог проблем пользователей. Начну с того, чем бэклог проблем отличается от бэклога задач не на словах, а в работе.
Бэклог задач это отранжированная очередь предложения: список того, что мы собираемся сделать. Бэклог проблем это не очередь, а скорее дашборд спроса: список незакрытых проблем пользователя и того, насколько каждая из них закрыта. Задачи в нем тоже есть, но они вторичны, они привязаны к проблеме как варианты ее закрытия, а не как самостоятельные единицы, за которые идет голосование.
Разница не косметическая: когда верхнеуровневая единица это задача, спор идет о том, чью задачу взять следующей, и выигрывает тот, у кого больше веса. Когда верхнеуровневая единица это проблема, спор смещается на то, какая проблема острее для пользователя, а это уже вопрос не про вес автора, а про факты о спросе. Вы меняете предмет голосования, и тем самым меняете распределение голосов, меняется и решающий голос.
Перевод решения в проблему
В первой статье я писал, что все любят придумывать решения и влюбляются именно в свои. CEO приходит не с проблемой, а с готовой кнопкой. Маркетинг приходит не с проблемой, а с механикой. Разработка приходит не с проблемой, а с архитектурным или технологическим заходом. Решение это собственность автора, и пока разговор идет на территории решений, это борьба за авторство, в которой у продакта обычно далеко не самое весомое слово.
Единственная операция, которая выводит из этой борьбы, это перевод решения обратно в проблему.
Кто-то приносит вам решение. Вы не отвергаете его и не принимаете, вы задаете один вопрос: какую проблему пользователя оно закрывает. И дальше вместе с автором восстанавливаете спрос, который стоит за его предложением. Иногда проблема находится, и тогда решение встает в дашборд как один из вариантов ее закрытия, рядом с другими, и его можно честно сравнивать. Иногда проблема не находится вовсе, и это самый ценный исход: становится видно, что предложение закрывало не спрос пользователя, а чей-то внутренний интерес.
Почему это работает там, где не работает прямой отказ. Потому что проблема ничья, у нее нет конкретного автора. Переводя решение в проблему, вы забираете предмет спора у человека с эго и отдаете его тому, у кого эго нет, пользователю. Вы не говорите автору «твое решение плохое», это атака на собственность. Вы говорите «давай посмотрим, у кого есть спрос», и это уже не про него.
Готовность выбросить
Здесь я обязан сделать признание, иначе статья была бы лицемерной.
Я сам регулярно нарушал собственное правило. Я заходил через решение, а не через проблему: приносил на стол конкретный продуктовый ход, минуя аккуратный разбор спроса. И не считаю, что был неправ.
Потому что решение решению рознь, и вся разница в одном, в собственности.
Есть решение-как-эго: автор им владеет, защищает, не может отпустить. Это и есть та конфликтная территория, ради которой мы все это затеяли.
И есть решение-как-провокация: вы бросаете решение на стол не чтобы его внедрить, а чтобы расширить рамку, показать команде, что поле решений шире, чем им кажется. В первой своей роли я бы назвал это симптомом сужения рамки, во второй сильным ходом. В прошлых статьях я уже писал, что иногда продукт двигает не следующая гипотеза, а дерзкое сильное решение. Так что противоречия тут нет.
Критерий, который отделяет одно от другого, ровно один и он проверяемый: готовность выбросить, готовность отказаться от собственного решения. Если вы можете отпустить свое решение без боли в ту секунду, как оно отыграло свою роль, вы пользовались им как инструментом. Если отпустить больно, вы им владеете, и тогда оно вас политизирует ровно так же, как политизирует любого автора.
Поэтому в потоке я смотрю не на то, что перед нами: проблема или решение, смотрю на то, держится ли автор за свое решение или готов его отдать. Стейкхолдер, запертый в своем решении, выбросить не может, и его надо аккуратно тащить на территорию проблемы. Тот, кто бросил решение как провокацию, отдаст его сам.
Куда складывать проблемы
У перевода в плоскость мышления и обсуждения проблем есть подвох. Если просто свалить все проблемы в один список, получится новая куча, не лучше прежней: проблемы тоже неоднородны, и сравнивать их в лоб так же бессмысленно, как сравнивать технический долг с планом продаж.
Проблема про то, что продукт вообще не нужен в новой ситуации, и проблема про то, что кнопка нажимается на третий раз, это проблемы разного слоя. Одна про потребность, другая про работу в контексте, третья про мотивацию, четвертая про цену и усилие. Их нельзя класть на одни весы, не указав слой.
Как раскладывать проблемы по слоям ценности, у меня есть отдельная статья про систему продуктовых осей, не буду пересказывать ее здесь. Важно одно: бэклог проблем это операционный слой, а система координат ценности это то, на чем он стоит. Без координат дашборд проблем превращается в свалку, просто более модную, чем свалка задач.
Метод и власть
Теперь самое неудобное, и именно ради этого стоило писать вторую статью отдельно.
Перевод решения в проблему требует, чтобы собеседник на это пошел. А он идет не всегда, так как это требует от него осознанности и готовности расстаться со своим решением, а от вас высоких коммуникативных навыков, чтобы провести этот перевод, не унизив автора. И если у автора есть власть, он почти всегда предпочтет остаться на удобной ему территории, территории решений, а не идти туда, куда вы его тащите. Затащить CEO в разбор спроса, когда он пришел с готовой кнопкой и отсутствием времени на обсуждение, удается редко или практически невозможно.
Отсюда вывод, который я считаю главным в обеих статьях: бэклог проблем не выигрывается полномочиями. Он выигрывается способностью переводить чужие решения обратно в спрос. Потолок этого метода это ваш коммуникативный вес, а не ваша должность.
Это плохая новость для тех, кто ждал рычага, и хорошая для всех остальных. Вы не можете запретить CEO его кнопку. Но вы можете раз за разом, на каждом груминге, на каждом ревью, возвращать разговор к спросу, пока даже самый властный участник не начнет говорить о проблеме пользователя, а не о своем интерфейсном решении. Это власть не приказа, а переформулирования. Она медленная, она требует навыка, и она единственная, которая работает без полномочий и потому масштабируется.
Где это не работает
Первое. Я строил бэклог проблем в своей практике, мы делали с командой несколько подходов, получился кое-какой результат. Но идеальным назвать его не поворачивается язык. Конфликтов на пути было много, и часть из них так и не удалось разрешить. Значит, я даю вам метод и логику, а не доказательство вида «примените и получите столько-то». Такого доказательства у меня пока нет. Да и обстоятельства у всех разные.
Второе. Метод упирается в коммуникативный вес продакта, и это не равномерно распределенный ресурс. Сильному переговорщику он дает много, слабому почти ничего. Я не делаю вид, что это формула, которая сработает у каждого одинаково.
Третье, и я уже обжигался на этом. Не превращайте перевод в проблемы в новый заградительный барьер. В первой статье я рассказывал, как кастомная модель скоринга у нас выродилась в оборону и испортила бренд продуктовой команды. С проблемами та же ловушка: если вы используете «а какую проблему это закрывает» не чтобы понять спрос, а чтобы отбиться, заинтересованные считают это мгновенно, и вы снова токсичный продакт, который прячется за умными словами. Разница между инструментом и щитом не в технике, а в намерении, и она видна со стороны.
Финал
Вернемся к вопросу, с которого начали. Как вернуть за стол того, кто платит, если власти навязать его волю у вас нет.
Ответ не в полномочиях и не в инструменте. Он в одной повторяемой операции: брать каждое решение, которое лоббируют в ваш бэклог, и спокойно переводить его обратно в спрос, проверяя автора на готовность отпустить свое, а проблему раскладывая по слоям ценности. Делать это ровно столько раз, на сколько хватает вашего коммуникативного веса. Не выиграть один спор, а сместить язык, на котором в команде вообще обсуждают приоритеты.
Пользователь так и не сядет за ваш стол сам. У него нет голоса в вашей оргструктуре. Единственный его представитель в комнате это вы, и не потому что у вас есть полномочия, а потому что вы единственный, кто готов говорить от его имени, переводя чужие решения в его проблемы.
Пока все чинят симптомы, я разбираю системы, которые их создают. Безрезультатный бэклог это симптом. Система это документ, в котором лоббируют все, кроме плательщика. А лечение не в том, чтобы дать продакту власть, которой у него нет, а в том, чтобы он научился возвращать в этот документ единственный голос, который нельзя купить лоббированием, голос того, кто платит.