Лидеры продукта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ценность;

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