Переход от стратегии к роадмапу продукта

Готовый, блестяще реализованный продукт кажется идеальным. Мы видим только великолепное воплощение и предвкушаем лишь положительный опыт использования. Чего мы не видим, так это сколько труда вложено в этот шедевр. И сколько людей и процессов задействовано в его производстве. Это общее правило для лучших продуктов. За всеми стоит отличная команда, которая следовала роадмапу продукта — от задумки до реализации — и показала прекрасный результат[10].

Вот сколько разных людей и элементов вовлечены в любой качественный продукт: лидер и/или менеджер продукта, команда продукта (дизайнеры, инженеры, тестировщики и т. д.), компоненты, роадмап, методы, UIKit, маркетологи, рекламщики и, конечно, клиенты. Как и в кулинарии, замена любого ингредиента (члена команды) может привести к совершенно иному результату. Иногда это к лучшему, но чаще получается совершенно не то, что планировали вы и чего хотели бы пользователи. Если вы продаете шоколадные торты, а потом вдруг вместо них появятся клубничные, некоторые клиенты будут разочарованы.

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

Фокус

Сначала мы обозреваем фронт работ и сосредотачиваемся на ключевых ценностях. Для достижения результата это не просто желательно, а необходимо. Роадмап также помогает понять, что не стоит нашего внимания. Развивая кулинарные аналогии, можно сказать: «Мы печем лучшие пироги. Не печенье, не пирожные, а именно пироги».

Согласованность

Роадмап обеспечивает согласованность. Вся команда движется к единой цели. Как только роадмап обсужден, команда понимает, какова роль у каждого и к какому результату ведут усилия. На кухне мы бы сказали: «Теперь все всё знают про начинку и украшение пирога, а также про то, сколько времени займет весь процесс — от замеса до выпечки».

Приоритеты

Знать, что делать, — только полдела, вторая половина — знать когда. Приоритеты — вот ключевая составляющая эффективного роадмапа. То есть утверждение «У нас нет на это времени» следует конкретизировать: «Это не входит в список приоритетных действий на пути к успеху».

Наглядность

Возможность видеть, как команда работает и что она делает, существенно упрощает процесс. В роадмапе сразу видны потенциальные подводные камни и возможности, если работа организована в соответствии с приоритетами и значимостью. Если сейчас 15:00, а пирог должен красоваться на прилавке магазина к 10:00 следующего утра, то можно наметить этапы работы в этом промежутке времени.

Координация

Дублирование функций и несогласованность, снижающие производительность, очень нервируют. Организовать работу команды в едином ритме необходимо для создания и поддержания движущей силы. Каждый должен знать, в чем заключается его личный вклад и как он связан с работой остальных. Здесь уместно вспомнить, что «у семи нянек дитя без глазу».

Видение

Лучшие компании всегда четко представляют, куда идут. Идеальное видение описывает райскую картинку для клиентов. Ведь все это не ради вас, а ради них. Как мы уже упоминали, самая известная и, возможно, лучшая клиентоориентированная концепция была у Disney — «делать людей счастливыми». Это ясно говорит о том, чем следует заниматься ежедневно. Вы только что порадовали клиента, доставив ему вкусный и красивый пирог. Что предложить людям дальше? В оперативном плане должно быть описано, как перейти к долгосрочным отношениям с клиентом.

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

• это не план релизов — не вносите даты и графики;

• это не перечень функций и/или элементов, пользовательских историй и подлежащих выполнению задач. Для роадмапа это мелочи;

• это не обязательство, а динамичный ориентир, изменяющийся с поступлением новой информации;

• это не всеобщий документ. Поскольку мы настаиваем на маленьких, автономных и кроссфункциональных командах, сосредоточенных на конкретных задачах по продукту, то у каждой должен быть свой роадмап;

• успешный роадмап — это не диаграмма Гантта. Взаимозависимости и каскадные связи не годятся для этого уровня планирования.

Жанна Бастоу из ProdPad подводит итог: «Роадмап перестает работать, если вносить в него конкретные даты. Это означает непонимание его сути. Для меня это некий артефакт, обозначающий направление действий к воплощению видения продукта. Это документ, который отличается (должен отличаться) от плана релизов, где описывается, что именно запускается, когда и кто над этим работает. Они в равной степени значимы, но если объединять их, то получается диаграмма Гантта с датами, однако не на ближайшие один-два квартала, а гораздо шире. Я всегда подчеркиваю, что никто не знает, насколько компания расширится к декабрю, не говоря уже о темпах создания продукта».

Мэтт Уолтон, директор по продукту FutureLearn, добавляет: «Каждая команда ответственна за свой роадмап. Специалисты сами решают, как добиться поставленной цели и соответствовать критериям. Главное — это помнить, что сам по себе роадмап не имеет значения, он нужен для понимания и обсуждения рабочих процессов в команде, выявления и решения проблем. Раньше наши роадмапы были всего лишь идеальными картинками в Keynote, а теперь у каждой команды живые, динамичные, общие доски в Trello, от которых гораздо больше толку».

Следовательно, лучший роадмап — артефакт стратегической коммуникации, описывающий общую картину и пути к воплощению концепции продукта. «Отсутствие оперативного плана часто приводит к тому, что делается больше, но хуже», — считает Энтони Аккарди, технический директор Rue La La. Кто будет пользоваться роадмапом после его составления? В общем-то, все: дизайнеры, разработчики, сотрудники отдела продаж и маркетинга, руководство, потребители, партнеры и клиентская поддержка.

ИЗУЧЕНИЕ ПРОБЛЕМ ПОЛЬЗОВАТЕЛЯ

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

Очень эффективно разделение роадмапа на темы. Как подчеркивает инженер пользовательского интерфейса Джаред Спул, «темы ведут к решению проблем, а не к разработке компонентов», что мгновенно приводит к пониманию вещей, самых важных для клиента. Если проблемы пользователя для вас приоритетны, то для начала следует в них разобраться.

К тому же это упрощает роадмап (поскольку в одну проблему иногда входит много функций), а также и процесс обозначения приоритетов, так как отбор проходит только то, что имеет отношение к проблемам пользователя.

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

ПРИОРИТЕТЫ ЦЕЛЕЙ И СТРАТЕГИЧЕСКИХ ДЕЙСТВИЙ

«Часто, придумав хорошую идею, люди приступают к ней со стороны предложения, — считает Райан Сингер, менеджер продукта в Basecamp. — Они ищут повод создать то, что им хочется, а следовало бы поглубже вникнуть в продукт и подойти со стороны спроса: подходящее ли сейчас время? Почему это важно? Что имеет значение прямо сейчас?»

Обозначение приоритетов мы подробно обсудим в другой части книги, но, поскольку оно неотъемлемо от составления оперативного плана, коснемся этого вопроса и здесь. Давайте начнем с того, как не следует расставлять приоритеты целей и действий. Знать, какие критерии не использовать, так же важно.

На интуитивную оценку генерального директора ориентироваться не стоит. Он, конечно, человек неглупый, и у него бывают гениальные идеи, но любое субъективное мнение всегда покоится на личных предубеждениях. Аналогичным образом и запросы отдела продаж или технической поддержки на предложения пользователей следует проверять на состоятельность и соответствие общей клиентской базе. Вмешиваться в рабочий процесс каждый раз, как только один-единственный пользователь заявит, что нужно что-то добавить, неконструктивно. На мнения аналитиков также не рекомендуем полностью полагаться: в своих предположениях они руководствуются историческими и среднестатистическими данными, поэтому поостерегитесь предсказывать с их помощью будущее узкого сегмента рынка. Безусловно, всё это ценные источники, но не в отрыве от остальных. Это ни в коем случае не истина в последней инстанции.

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

• ценность;

• выполнимость;

• удобство использования.

Ценность и удобство использования являются ключевыми для клиентоориентированного обозначения приоритетов. Принесет ли эта идея (продукт, функция) пользу клиенту? И в достаточной ли степени, чтобы иметь ценность для бизнеса? Нравится ли клиенту пользоваться продуктами? Разумеется, вопрос следует отделить от технической (и деловой) стороны — выполнимости. Можно ли создать продукт с наименьшими затратами? Каковы издержки на обслуживание и поддержку? Поставить одну идею выше другой возможно, лишь имея перед глазами общую картину.

УПРАВЛЕНИЕ НЕИЗВЕСТНОСТЬЮ

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

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

«Мы в команде предпочитаем форму пари. Если выдвигать идею с формулировкой «спорим, что, если сделать Х, получится Y», то проще поделиться соображениями, чем предлагать формальную гипотезу. Ошибаться, конечно, неприятно, но ничего страшного. К тому же пари разряжает атмосферу, способствует творчеству и обмену идеями. И это привычнее, чем гипотеза, а значит, и уверенный шаг к культуре, поощряющей эксперименты», — рассказывает консультант по управлению продуктом Кейт Лето.

Низкие ставки

При оптимизации существующего, зрелого продукта лучший способ собрать данные в пользу предположений — это проверка ставок через a/b или мультивариантное тестирование. Такой подход на основе данных нейтрализует любые споры и отклонения демонстрацией действий реальных пользователей или потребителей при столкновении с новыми возможностями. При наличии доступных сегодня платформ и инструментов для тестирования не делать это даже странно. И команду инженеров придется привлечь всего один раз — для установки библиотек тестирования!

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

Высокие ставки

Для высоких ставок на новую линейку продуктов (или совершенно новые компоненты) мультивариантное тестирование не годится. В этих случаях большинство лидеров продукта возвращаются к подходу «минимального жизнеспособного продукта» (МVP). Его впервые предложил Эрик Рис в книге «Бизнес с нуля», но сам термин используется так часто, что утратил первоначальное значение.

«MVP иногда ошибочно применяют к первой реализации зачаточного продукта. И в результате этот подход вместо быстрого теста предстает очень сложным и недостаточно качественным», — утверждает Рик Хигэм, старший менеджер продукта в Skyscanner.

Вместо этого следует сделать выводы и поставить акцент на тестировании рискованных допущений. «Тест рискованных допущений[11] — исчерпывающий тест, — продолжает Хигэм. — Для проверки любой неопределенности не нужны лишние телодвижения. Никто не ждет идеального кода или дизайна. И преждевременного воплощения продукта не произойдет».