Это история не о применении новых технологий для решения проблем, о том, насколько важны решимость и сила воли. Внедрять существенные изменения в крупной корпорации всегда непросто, но это удается по-настоящему сильным менеджерам продукта.

Впоследствии Алекс ушла из BBC и сделала потрясающую карьеру в нескольких технологических и медиакомпаниях; сегодня она работает лидером продукта в Нью-Йорке.

В части II мы изучили продуктовые команды, в части III — описали, как решить, на чем они должны сосредоточиться. В части IV я объясню, как эти команды работают. Мы подробно рассмотрим методики, виды деятельности и подходы к работе, которые продуктовые команды используют для того, чтобы раз за разом исследовать новые продукты и поставлять их на рынок.

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

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

ОБЗОР

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

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

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

Я провожу с продуктовыми командами очень много времени, и мне не раз доводилось весьма настойчиво убеждать их смелее выходить на потребителей, чтобы как можно раньше получить их отзывы и комментарии о новом продукте, и уже через несколько минут призывать тех же людей ни в коем случае не нарушать собственные стандарты в отношении масштабируемого, отказоустойчивого, надежного, высокопроизводительного и безопасного софта.

Та же проблема встречается и в ином обличье. Как уже говорилось, многие команды сталкиваются с огромными трудностями из-за минимально жизнеспособного продукта (minimum viable product, MVP), потому что, с одной стороны, заинтересованы максимально быстро предложить его клиенту, чтобы получить конструктивную обратную связь и узнать то, что пока о нем неизвестно, а с другой — когда мы это делаем, людям кажется, что этот, с позволения сказать, продукт, в не слишком выгодном свете представляет наш бренд и компанию. Как же мы могли предлагать его как готовую версию?

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

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

Я всегда стараюсь использовать термин продукт исключительно для описания того, на чем можно делать бизнес. В частности, это должно быть что-то в нужной степени высокопроизводительное, подлежащее масштабированию и включающее мощный комплект автоматизированных регрессионных тестов и инструментарий для сбора аналитики. То, что уже по возможности интернационализировано и локализовано и подлежит техническому обслуживанию, а также четко согласуется с обещаниями бренда. И самое важное, это то, что команда может выпустить уверенно.

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

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

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