В конце концов они достигнут предела, после чего наступит закат (спад). Распознать этот момент и действовать в соответствии с ним может оказаться непростой задачей, поскольку даже сокращающиеся потоки доходов трудно перекрыть.
В основе поддержания и оптимизации устоявшегося продукта лежат одни и те же механизмы. Существуют фиксированные расходы и те, которые зависят от масштаба. Есть также регулярные и нерегулярные источники дохода. Когда эти действия более отлажены, они в основном направлены на поддержание работы хорошо смазанной машины, устранение препятствий для потока доходов и удовлетворение стабильной базы пользователей.
Согласно знаменитой «дилемме инноватора» Клэя Кристенсена, существует долгосрочный риск самонадеянности старого игрока на рынке.
Это дилемма говорит о том, что старые игроки не терпят неудач с инновациями не потому, что они слабые, мягкотелые или пресыщенные, а из-за того, что удобный, зарекомендовавший себя продукт действительно не может себе позволить инновации.
Риск для существующего потока доходов просто слишком велик. Это создает возможности, которыми в конечном итоге пользуются новички, что приводит к третьему – и заключительному – этапу жизненного цикла продукта.
Всему когда-нибудь приходит конец, и цифровые программные продукты (а также потоки доходов и прибыль, которые они могут генерировать) в конечном счете тоже подчиняются этому правилу. Возможно, это не самое любимое дело менеджера продукта – следить за закатом изжившего себя продукта и выводом его из эксплуатации, но эта конечная стадия потребует от него аналогичных профессиональных навыков.
Не верите мне? Вот что вам нужно для вывода продукта из эксплуатации:
• определить закономерности снижения прибыли по сравнению с убытками и принять трудные решения о том, где и когда сокращать убытки;
• свернуть обязательства, откалибровать ожидания, сохранить безопасность, конфиденциальность и выполнить другие юридические требования;
• в конечном итоге полностью снять продукт с учета в бизнесе.
Как вы видите, это зеркальное отражение навыков, в первую очередь необходимых для создания успешных продуктов.
Какие могут быть деньги без клиентов или транзакций?
Проще говорить о получении денег от транзакций, которые совершаются либо клиентом в месте продажи, либо корпоративным клиентом посредством банковского перевода, но работа по управлению продуктом вне коммерческой среды по-прежнему использует ту же жизненную силу, что и коммерческое предприятие, – деньги.
У правительства, некоммерческих и других организаций, не связанных с продажами/бизнесом, – у всех есть счета, которые нужно оплачивать.
Деньги – это кровеносная система материального мира. В некоммерческой организации доноры и члены предоставляют ресурсы, даже если доходов как таковых нет.
Правительству, как и компаниям, разработка программного обеспечения с новыми функциями или исправление старых ошибок обходится дорого.
Денежная часть работы никогда не исчезает, поэтому нет смысла уклоняться от нее.
Как только вы, находясь в роли менеджера продукта, увидите, как деньги текут под поверхностью почти каждого усилия, вы осознаете, что, по сути, это такой же материал для создания чего-то нового, как и строчки кода или пиксели на экране.
ДЕНЬ ИЗ ЖИЗНИ ПМ В СФЕРЕ ФИНАНСОВЫХ ТЕХНОЛОГИЙ
Майкл Карри, руководитель отдела продуктов в 100x Group, международном стартапе в области криптовалюты (финансовых технологий)
– Как у вас начинается рабочий день?
– Проверяю Slack и электронную почту.
– Как вы проводите раннее утро?
– Пью кофе и планирую день по календарю.
– Как вы проводите бóльшую часть утра?
– Выполняю как можно больше работы индивидуального исполнителя, пока не начнутся встречи.
– Чем заканчивается утро?
– Встречи продолжаются.
– Когда вы делаете перерыв на обед?
– В 12 часов дня.
– Что вы делаете в первую очередь после обеда?
– Иногда снова пью кофе. Готовлюсь около часа к вечерней встрече, когда в Азии наступит утро.
– Как вы справляетесь с авралом или незапланированной работой?
– Непосредственно и активно участвую. Я помогаю нескольким отделам планировать задачи по инциденту и выполнять их.
– Как вы проводите бóльшую часть дня?
– Еще несколько встреч, затем работа с документацией и подведение итогов.
– Что вы делаете в конце рабочего дня?
– Ужин в кругу семьи. Помогаю дочери с домашним заданием. Укладываю спать малыша.
– Вы работаете по вечерам?
– Да, часто.
Ключевые идеи
• Бизнес и доходы – это основные обязанности в управлении продуктом.
• Если вы создали ценный продукт, то вы сможете найти бизнес-модель для его поддержания.
• Пробовать несколько моделей получения дохода – это нормально.
• Не бойтесь отказываться от модели получения дохода, которая не работает.
• Прикладывая разного уровня усилия, можно поддерживать несколько источников дохода.
• Безубыточность – это поворотный момент для любого продукта, после которого его дорожная карта временно становится бесконечной.
• Финансовые затраты и оттоки определяют возможности продукта на каждой стадии его жизненного цикла: создания, поддержания и заката.
• Даже если вы не создаете продаваемые продукты, деньги являются одним из материалов, с которыми работает менеджер продукта.
Глава 9Здоровое напряжение в сотрудничестве продукта и UX
Принято считать, что UX-специалисты и менеджеры продукта имеют много общих забот и используют в работе смежные компетенции, что ведет к непрерывной борьбе за точное определение зоны ответственности каждого. Сколько есть команд, столько существует способов разделить между собой работу, но часто все они сводятся к вариациям этой формулы:
• менеджер по продукту отвечает за «что»;
• UX-дизайнер отвечает за «как».
Итак, проблема решена, не так ли? Такая короткая глава, да?
Однако даже если мы договоримся о том, какие именно обязанности относятся к «что», а какие – к «как», то как именно вы будете реализовывать это на практике? Над чем вы работаете отдельно, над чем – непосредственно вместе, как вы координируете свои действия и за кем остается последнее слово, когда вы сотрудничаете?
Перекрытие и расхождения
Если вы помните гистограмму «Управление продуктом и UX» из главы 3 «Переносимые UX-навыки», то вы знаете, что есть несколько навыков в середине спектра, которые вполне оправданно могут использовать UX-эксперт и ПМ, в зависимости от команды и контекста (рис. 9.1).
Гистограмма – это сознательная попытка избежать вездесущих диаграмм Венна, обычно используемых для отображения перекрытия и сложности, а также для подсчета очков. Однако такая форма может создать восприятие ярко выраженного линейного порядка или последовательности этих навыков, в то время как в реальности их отношения гораздо более размыты.
Рис. 9.1. Навыки и соотносящиеся с ними задачи, находящиеся примерно в середине списка, могут достаться как UX-специалисту, так и продукту, в зависимости от команды
Итак, потенциальные области пересечения помогает проиллюстрировать диаграмма Венна, в которую вписаны и расчерчены некоторые из этих навыков (рис. 9.2).
Рис. 9.2. Выборка навыков специалиста по продукту/UX, грубо отсортированных по практикам, наиболее соответствующим для их задач
Общие с коллегами способности и навыки – это хорошая вещь, и по своей сути она не вызывает проблем, но на практике может возникнуть двусмысленность в понимании того, кто за что ответственен и за кем остается последнее слово. Это может привести к конфликту, недопониманию и, что важно, получению плохого пользовательского опыта.
Конфликты могут возникать из-за простой несогласованности действий или по более неприятным причинам. Определенно есть люди, все еще мыслящие категориями «территории» и отталкивающие нового человека любой другой команды или образа мысли, которого они воспримут как посягающего на их «район». Этот менталитет уличных банд не подходит для сотрудничества, но раз уж он существует, вам нужно знать о нем, если у вас есть хоть какое-то стремление создать отличное ПО с имеющейся у вас командой.
Помимо прямых споров о том, кто владеет конкретным проектом, артефактом или рабочим продуктом, есть также большой риск дублирования, если специалисты по продукту и UX вразнобой преследуют свои индивидуальные цели.
Каждый проводит исследование, каждый определяет концепции и модели, каждый составляет спецификации и другие артефакты проектирования, которые пытаются решить очень похожие задачи немного разными способами, что потенциально ведет ко всевозможным проблемам, включая следующие:
• неопределенность на этапе разработки и поставки;
• циклы, впустую потраченные для прояснения различий, которые вообще не надо было создавать;
• бесконечное перепрыгивание между двумя фреймами в зацикленном перетягивании каната, которое заканчивается только тогда, когда кто-то выше по цепочке замечает паралич команды.
Где вы проводите черту?
Когда-то я опубликовал в своей сети вопрос, который звучал обманчиво просто: «Где вы проводите черту между продуктами и UX?»
Оставляя контакты для связи в группе «Всё зависит от обстоятельств», я, возможно, не должен был удивляться тому, как много людей попытались отвергнуть основную идею вопроса, спрашивая, существует ли такая черта в принципе (или должна ли существовать).
Большинство людей подчеркивали серую область совпадений, которая вполне объяснима, указывая, что именно в ней заключены все нюансы. Они отвечали так: