Иногда приходится смириться с тем, что надо сделать. Вот как этот сценарий описывает Брюер: «Надо — и точка. Приходится с головой погрузиться в работу и выполнить ее. А уже потом решать, как все объединить и как что между собой соотносится». Мы не рекомендуем соглашаться на все требования, но нам импонирует, что в результате обсуждение поворачивает в новое русло. От структуры команды и используемых процессов зависит, как построить разговор. Идеальной схемы обсуждения приоритетов нет, но обязательно надо делать это почаще, и без политики. Рассказывает Роуз Грабовски, бывший директор по управлению продуктом Invaluable: «Это смесь долгосрочного анализа и командной работы над получением обратной связи по инициативам в текущих спринтах, рассмотрения багов и попыток установить связь между выявленными проблемами. Каждый день переключаешься с высокого уровня на мелочи. Уж таковы особенности нашей сферы».

Баланс приоритетов и противоречия

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

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

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

В такой схеме лидер продукта разносит задачи по приоритетам и приступает к выбору. Цель Брюера состоит в том, чтобы выяснить, над чем команда хочет работать, и сказать: «Так, всего мы, скорее всего, не успеем, но как построить систему “на вырост”? И все ли согласны, по крайней мере на этот момент, с учетом имеющихся данных, что мы хотим расти именно в этом направлении? Да? Отлично. Тогда поехали».

Углубление в приоритеты

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

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

Перейти на страницу:

Похожие книги