Работа Product Manager подразумевает постоянную генерацию решений. Когда выявлена проблема целевой аудитории, и перед будущим продуктом (либо его частью) поставлена цель, наступает время придумать такую реализацию, которая эту проблему для пользователя успешно решит.
Как обычно происходит процесс создания решений? Поработав на продуктовых позициях в самых разных компаниях: от микро-стартапов до колоссального размера корпораций, я обратил внимание, что чаще всего команды используют один из двух подходов.
1.Коллективное обсуждение. Участники собираются в переговорке, кто-то один выходит к маркерной доске, и начинается обсуждение:
— А что бы мы хотели сделать?
— Я предлагаю, чтобы пользователь точно мог логиниться через соцсети!
— Обязательно нужно спрашивать телефон!
— Давайте сделаем классные анимации!
Такие встречи могут продолжаться часами. На выходе обычно получается лишь небольшая часть из запланированного.
Частый сценарий: 2/3 встречи уходят на обсуждение 25% задуманного. Затем все понимают, что прошло много времени, и ничего не сделано, и «экспрессом» пробегают оставшиеся кейсы, глубоко в них не погружаясь.
Такой подход не эффективен, потому что, во-первых, получается неравномерная глубина проработки задачи (от начала встречи к концу), и во-вторых, он отнимает уйму времени.
Кроме того, низкая эффективность мозговых штурмов и групповых совещаний доказана научно. Еще в 1958 году ученые из Йельского университета провели серию экспериментов, которая показала, что количество и качество идей, достигнутых путем «брейншторма», ниже, чем если бы люди думали по-одиночке.
2.Делегирование. Задача отдается дизайнеру, который сразу отрисовывает ее в UI, основываясь на тех данных, которые у него есть.
Далее PO принимает работу, «полностью доверяя профессионалу», и задача уходит в разработку.
Такой подход занимает меньше времени, но по-прежнему лишен глубины проработки. Продуктовые задачи должен решать не дизайнер, а эксперт по UX, в роли которого иногда может выступать как продакт, так и группа, включающая в себя продакта, исследователя, дизайнеров и аналитиков.
Тихий скетчинг
Это удивительное по своей простоте и логичности решение, которое позволит сэкономить массу времени на бессмысленных спорах, не потеряв при этом глубины и качества.
Суть метода в том, чтобы объяснив команде задачу, попросить всех потратить 5-10 минут на скетчинг — простые наброски будущего решения на бумагу.
Процесс проходит циклически в 1-2 круга.
Шаг 1. 7-15 мин. Объяснить команде цель и задачи, которые решаются продуктом.
Это самый важный этап, т.к. от него зависит то, насколько придуманные решения будут «приземлены об реальность».
На встрече обязательно должен быть человек, который возьмет на себя роль фасилитатора. Он должен простыми и понятными терминами рассказать, какую проблему мы решаем, и зачем. Если у него есть данные пользовательских исследований, то не будет лишним потратить 10 минут на их демонстрацию.
После рассказа команда задаст уточняющие вопросы, и через 15 минут от начала встречи у всех присутствующих появится единый вижн того, зачем затеян этот процесс.
Шаг 2. 5-10 мин. Скетчинг.
Каждый член команды берет листок бумаги (не меньше А4) и маркеры, и начинает набрасывать свой вариант решения. Скетчинг происходит в полной тишине. Любые вопросы, которые возникают, можно будет задать позже. Сейчас все работают, основываясь только на полученной перед этим информации и собственном опыте.
Разумеется, для того, чтобы сделать скетч, не нужно быть дизайнером. Это простейшие элементы интерфейса, нарисованные на бумаги настолько подробно, насколько это позволяет сделать ограничение в 10 минут.
Скетчем может быть как один экран интерфейса сайта/приложения, так и их последовательность. Здесь нет никаких рамок, наоборот — чем менее будет ограничен участник, тем более креативные решения можно будет получить на выходе.
Через 10 минут у каждого члена команды будет лежать несколько листочков бумаги с его вариантом решения.
Шаг 3. 5-10 мин. Презентации.
Каждый должен в течение не более, чем 2 мин, рассказать о концепции своего решения: в чем его основа, почему он выбрал те или иные элементы, почему пришел именно к такой последовательности действий.
После рассказа участники могут в течение еще 1-2 минут позадавать вопросы. Важно: это не критика или обсуждение, это лишь наводящие вопросы, чтобы все смогли лучше понять замысел автора решения.
После того как все участники рассказали о своих решениях, проводится еще один раунд скетчинга.
Шаг 4. 5-10 мин. Скетчинг (раунд 2).
Все повторяется, только теперь участники уже видели предложения коллег, подчерпнули здравые мысли и усовершенствуют свои варианты. Кто-то может сделать полностью новый вариант — это не страшно.
Шаг 5. 5-10 мин. Презентации (раунд 2).
То же самое, что и в прошлый раз. Теперь время на каждую презентацию ограничено 60 сек. Опять никаких обсуждений, только вопросы на понимание.
Шаг 6. 7-10 минут.
Выработка единой концепции. Фасилитатор, стоя у доски, рисует целевой вариант решения, который основан на всех состоявшихся обсуждениях. Как правило, этот этап проходит быстро и без долгих дискуссий, т.к. все вопросы уже были сняты перед этим.
Члены команды могут активно комментировать — это только помогает процессу.
Спустя всего 1-2 часа команды есть хорошо проработанный UX будущего решения. В нем учтены мнения и опыт нескольких профессионалов.
Если предмет встречи — крупный кусок функционала или полностью новый продукт, то я обычно убираю 2-й раунд скетчинга и презентаций. Так удается за 2 часа проработать 3-4 больших самостоятельных части продукта.
Шаги 8,9… Прототипирование и тестирование.
Что делать дальше с получившимися скетчами, знает каждый продуктолог. В своей практике чаще всего я передаю скетчи дизайнеру, чтобы он собрал из них кликабельный прототип.
Впоследствии он будет протестирован на клиентах, чтобы выявить самые явные UX-ошибки. Затем, после устранения ошибок можно переходить к UI, новым тестам, и, наконец, передаче в разработку.
Таким образом, за одну встречу длиной в 1-2 часа можно глубоко проработать решение проблемы пользователя, не скатываясь в балаган и споры, и повышая качество результата.
Подход «тихого скетчинга» можно использовать в любых продуктовых задачах, и не только в ИТ-продуктах. Команда GV консультирует десятки портфельных компаний, которые создают в том числе роботов, кофейни, магазины и т.п. И везде применяет одну и ту же методологию — SPRINT, частью которого является скетчинг.
Я лично заметил существенный скачок в скорости и качестве проработки продуктовых гипотез после того, как стал использовать этот метод в своих проектах.
А как вы генерите решения?
P.S. Авторы SPRINT называют методологию «Working alone together» и рекомендуют тратить на скетчинг несколько часов. Это приемлемо в рамках работы по SPRINT, но для повседневных продуктовых задач подходит вариант с короткими итерациями, о котором я рассказал выше.