В части II мы изучили продуктовые команды, в части III — описали, как решить, на чем они должны сосредоточиться. В части IV я объясню, как эти команды работают. Мы подробно рассмотрим методики, виды деятельности и подходы к работе, которые продуктовые команды используют для того, чтобы раз за разом исследовать новые продукты и поставлять их на рынок.
Надеюсь, вы очень скоро поймете, что тут не существует единственно верного, универсального процесса. Скорее это комбинация правильно подобранных методик, правильных установок и культуры. Кроме того, обращаю ваше внимание, что основной акцент делается на методиках исследования продукта, ведь мы с вами говорим прежде всего о менеджерах по продукту, а это основная сфера их ответственности.
Итак, продакт-менеджеру нужно посвящать много времени работе с продуктовой командой, ключевыми заинтересованными сторонами и клиентами, занимаясь поиском решений, которые полюбят потребители и которые принесут пользу его компании. Имейте, однако, в виду, что менеджер продукта и дизайнер продукта также должны быть всегда готовы ответить на вопросы инженеров-программистов, возникающие еще на этапе поставки продукта на рынок, что обычно занимает от получаса до часа в день.
Исследование продукта
Большинство компаний — разработчиков ПО занимаются решением довольно трудных задач, что обычно заканчивается созданием сложных систем, которые делают эти решения возможными. Большинство команд сталкиваются при этом с двумя весьма серьезными трудностями. Во-первых, им нужно до мельчайших деталей выяснить, каким должно быть решение проблемы потребителя. Сюда входит все — от уверенности в том, что в нем нуждается довольно большое количество клиентов (спрос), до выработки решения, выгодного и для потребителей, и для бизнеса. А еще нужно гарантировать — и это еще сложнее, — что предложен унифицированный способ, полезный для многих клиентов, а не специализированное решение для узкого круга пользователей. А для этого просто необходимо иметь возможность протестировать огромное число разных идей, причем максимально быстро и недорого.
Во-вторых, нужно гарантировать, что предлагаемая разработка надежная и масштабируемая и что потребители могут рассчитывать на ее долгосрочную ценность. Ваша команда должна выпускать версии программного продукта уверенно. Хотя стопроцентной уверенности в этом плане никогда не бывает, не следует делать релиз, молясь об успехе. Иными словами, нужно уметь быстро учиться и собирать полезные сведения, но предлагать новые версии продукта всегда надо с уверенностью.
Многие из вас вполне резонно решат, что эти две сложные цели противоречат друг другу. Мы спешим предложить что-то новое, чтобы узнать, что работает, а что нет, но при этом не хотим выпускать на рынок то, что еще не готово для прайм-тайм, рискуя нанести ущерб потребителям и собственному бренду.
Я провожу с продуктовыми командами очень много времени, и мне не раз доводилось весьма настойчиво убеждать их смелее выходить на потребителей, чтобы как можно раньше получить их отзывы и комментарии о новом продукте, и уже через несколько минут призывать тех же людей ни в коем случае не нарушать собственные стандарты в отношении масштабируемого, отказоустойчивого, надежного, высокопроизводительного и безопасного софта.
Та же проблема встречается и в ином обличье. Как уже говорилось, многие команды сталкиваются с огромными трудностями из-за минимально жизнеспособного продукта (minimum viable product, MVP), потому что, с одной стороны, заинтересованы максимально быстро предложить его клиенту, чтобы получить конструктивную обратную связь и узнать то, что пока о нем неизвестно, а с другой — когда мы это делаем, людям кажется, что этот, с позволения сказать, продукт, в не слишком выгодном свете представляет наш бренд и компанию. Как же мы могли предлагать его как готовую версию?
В этой части я расскажу, как сильным командам удается одновременно достигать обеих целей — быстро учиться и приобретать нужные знания на этапе исследования продукта и поставлять на рынок надежные, качественные готовые версии в соответствующий период.
В целом, по моему опыту, большинство продуктовых команд гораздо лучше понимают, как выполнить вторую задачу, то есть поставить надежный софт, чем как достичь первой цели — быстро провести нужные эксперименты и исследование продукта. Отличным примером продвинутой методики поставки продукта, который я часто наблюдаю в командах, понимающих огромную важность небольших постепенных изменений сложной системы, может послужить непрерывное развертывание софта. Отчасти путаницу тут порождает размытость смысла, который мы вкладываем, называя что-то «продуктом» или говоря о «качестве уровня продукта» или о «продукте для коммерческого распространения».
Я всегда стараюсь использовать термин продукт исключительно для описания того, на чем можно делать бизнес. В частности, это должно быть что-то в нужной степени высокопроизводительное, подлежащее масштабированию и включающее мощный комплект автоматизированных регрессионных тестов и инструментарий для сбора аналитики. То, что уже по возможности интернационализировано и локализовано и подлежит техническому обслуживанию, а также четко согласуется с обещаниями бренда. И самое важное, это то, что команда может выпустить уверенно.
Все это, безусловно, очень нелегко. На поиск уходит большая часть рабочего времени разработчиков. Поэтому мы изо всех сил стараемся сделать так, чтобы наши усилия не были тщетными. Проводить всю эту работу, когда менеджер продукта не уверен в том, что клиент хочет или нуждается именно в таком решении — верный рецепт грядущего провала и напрасных трат. Таким образом, благодаря исследованию продукта мы убеждаемся, что время и силы инженеров, создающих продукт производственного качества, не будут потрачены впустую. Вот почему на этом этапе применяется так много всевозможных методик и инструментов.
У нас есть методики для более глубокого изучения пользователей и клиентов, для проверки идей и замыслов продукта, как с качественной, так и с количественной точки зрения. И, по сути, применение большинства из них не предполагает трат времени инженерно-технического персонала — что очень важно, поскольку нам известно, как много усилий нужно приложить на этапе поставки для создания софта, готового к производству.
Секрет эффективного исследования продукта в значительной мере заключается в том, чтобы получить доступ к потребителям, не пытаясь протолкнуть быстрые эксперименты на уровень производства. Если вы работаете в недавно созданном стартапе и у вас пока нет клиентов, к вам это, конечно, не относится. Скорее всего, вам еще рано работать над программным продуктом производственного качества. Но большинство компаний имеют реальных клиентов и доход, и этот вопрос не может их не беспокоить. Далее мы подробно поговорим о методиках, которые позволяют крупным корпорациям быстро, правильно и ответственно экспериментировать.
И главное, если вы хотите с помощью исследований выявлять отличные продукты, чрезвычайно важно построить работу так, чтобы ваши идеи как можно раньше и чаще попадали в руки реальных пользователей и клиентов. А если вы хотите поставлять отличные продукты на рынок, то для их разработки вам придется использовать передовые методики и стараться никогда не навязывать свое мнение инженерам-программистам.
Глава 33. Принципы исследования продукта
Главная цель исследования продукта заключается в устранении следующих рисков:
• Купит ли (нашу идею) покупатель, решит ли он (ее) использовать? (Риск ценности.)
• Сможет ли пользователь понять, как это работает? (Риск юзабилити.)
• Можем ли мы это разработать? (Риск технической реализуемости.)
• Принесет ли это решение пользу нашему бизнесу? (Риск бизнес-жизнеспособности.)
Мнения продакт-менеджера обо всех этих рисках, безусловно, недостаточно — нужно собрать доказательства.
Наш подход к исследованию продукта базируется на принципах, которые четко определяют, как мы должны работать. Если вы их понимаете, то не только знаете, как эффективно действовать сегодня, но и как без особых усилий внедрять новые методики по мере их возникновения в будущем. Итак, вот эти принципы:
1. Мы не должны рассчитывать на то, что потребители (или руководство, или заинтересованные стороны) подскажут нам, над чем следует работать.
Потребители вообще не знают, что возможно создать, а если говорить о высокотехнологичных продуктах, то никому из нас до конца не известно, чего мы действительно хотим, до тех пор, пока мы не увидим это своими глазами. Конечно, это не значит, что клиенты или руководство обязательно ошибутся, просто наша задача — гарантировать предлагаемым решением устранение фундаментальной, базовой проблемы. Наверное, это главное в разработке современных технологических продуктов. Так уж сложилось, что в большинстве случаев с инновациями в нашей индустрии изначально потребители понятия не имели, что обожаемый ими продукт может быть создан. И со временем эта тенденция только укрепляется.
2. Главное — обеспечить реальную ценность продукта.
Конечно, сложно соблюсти все принципы, но сложнее всего предложить такую ценность, чтобы потребители решили купить и использовать наш продукт. Компания способна выживать некоторое время, имея проблемы, связанные с юзабилити или даже с производительностью продукта, но без базовой ценности у нее на самом деле нет ничего. Вот почему львиная доля времени и усилий на этапе исследования продукта уходит на подтверждение ценности данной идеи.
3. Какой бы сложной и важной задачей ни была собственно разработка продукта, обычно для его успеха куда сложнее и важнее предложить эффективный механизм взаимодействия с пользователем.
В каждой продуктовой команде есть инженеры-программисты, но не у всех имеются необходимые навыки в области дизайна продукта. И даже когда они есть, используются ли они именно так, как нам нужно?
4. Функциональность, дизайн и технологии неразрывно связаны.
В старой, каскадной модели разработки продуктов рынок определял функциональность (или технические требования) продукта, которая, в свою очередь, определяла его дизайн, а тот — способ реализации. Сегодня мы знаем, что технологии определяют (и делают возможной) функциональность в той же мере, как это действует и в обратном направлении. И нам известно, что технологии определяют (и делают возможным) дизайн. А дизайн — (и делает возможной) функциональность. Чтобы увидеть многочисленные примеры всего перечисленного, достаточно взглянуть на свой телефон. В нем функциональность, дизайн и технологии тесно переплетены. Кстати, это и есть главная причина того, почему мы должны изо всех сил стараться построить работу так, чтобы менеджер продукта, дизайнер продукта и главный инженер трудились плечом к плечу в прямом смысле слова.
5. Мы с самого начала ожидаем, что многие наши идеи и замыслы не сработают, а чтобы довести до ума остальные, потребуется несколько итераций.
Как сказал Марк Андриссен, «самое главное — понимать, какая информация вам недоступна». Конечно же, нельзя заранее знать, какие идеи будут приняты потребителями, а какие нет. Поэтому мы должны изначально подходить к исследованию продукта с настроем на то, что многие, если не большинство наших идей и замыслов, ни к чему не приведут. Чаще всего это случается из-за недостаточной ценности, но иногда и дизайн слишком сложен; или выясняется, что разработка займет слишком много времени; или возникают проблемы правового характера, скажем, с конфиденциальностью. Нам нужно быть готовыми к тому, что при необходимости придется попытаться решить фундаментальную проблему другими способами.
6. Мы непременно должны проверить свои идеи на реальных пользователях и клиентах.
Вера в то, что мы способны предвидеть реакцию потребителей, — весьма распространенная ловушка при разработке новых продуктов; она может быть основана на изучении клиентов или собственном опыте. Как бы там ни было, сегодня мы точно знаем, что всегда надо проверять жизнеспособность своих идей на реальных пользователях (потребителях). И делать это прежде, чем вы начнете тратить время и средства на создание продукта.
7. Наша цель на этапе исследования продукта — как можно быстрее и дешевле подтвердить правильность своих идей.
На этом этапе во главу угла ставится скорость. «Быстродействие» позволяет протестировать много идей, а в отношении наиболее многообещающих испытать несколько подходов. Существует множество типов идей, замыслов, типов продуктов и разные риски (ценности, юзабилити, реализуемости и бизнес-жизнеспособности), которые необходимо устранить. Поэтому у нас так много методик для различных ситуаций.
8. Подтверждать реализуемость идей нужно на этапе исследования, а не позже.
Если инженеры-программисты впервые узнали об идее при планировании спринта, считайте, что вы потерпели неудачу. Мы должны гарантировать выполнимость до того, как решим создавать продукт, а не после, поскольку это не только сокращает малоэффективные затраты времени. Как показывает опыт, если как можно раньше узнать мнение технаря, то, во-первых, это будет способствовать поиску более успешного решения, а во-вторых, очень важно для совместного обучения людей.
9. Подтверждать бизнес-жизнеспособность идей нужно на этапе исследования, а не позже.
Прежде чем тратить время и деньги на создание продукта, крайне важно убедиться, что решение, над которым мы работаем, обеспечивает потребности нашего бизнеса. При оценке бизнес-жизнеспособности идеи о продукте следует учесть финансовые моменты, соображения отделов маркетинга (насчет бренда и способов вывода нового продукта на рынок) и продаж, юридические требования и вопросы бизнес-развития, а также мнение высшего руководства. Ничто так не ослабляет моральный дух сотрудников и подрывает веру в профессионализм продакт-менеджера, как ситуация, когда продукт готов, но вдруг обнаруживается, что менеджер, оказывается, не разбирается в важнейших вопросах бизнеса.
10. Важнейшая грань исследования — совместное обучение.
Если вы хотите иметь команду «миссионеров», а не «наемников», все ее члены должны вместе учиться и получать новую информацию; вместе видеть проблемы клиента и наблюдать за тем, как одни идеи терпят крах, а другие отлично воплощаются в жизнь. Тогда все люди будут понимать общий контекст, в котором их работа имеет значение, и знать, что именно они должны делать.
Итак, это были принципы исследования продукта, а все остальное зависит от их соблюдения.
В общем главная цель исследования продукта состоит в устранении потенциальных рисков, связанных с его ценностью, юзабилити, выполнимостью и бизнес-жизнеспособностью, но в некоторых случаях компания сталкивается с еще одним серьезным риском — этическим.
При обсуждении столь деликатной темы я очень не хочу, чтобы мои слова прозвучали так, будто я вас поучаю или снисходительно наставляю на путь истинный, но я всегда призываю продуктовые команды, с которыми работаю, ответить на еще один важный вопрос: а следует ли нам это создавать?
Вы можете думать, что этический аспект возникает только тогда, когда речь идет о чем-то незаконном, но в подавляющем большинстве случаев это вовсе не правовая проблема. Суть в том, что нам необязательно непременно что-то делать просто потому, что для этого имеется необходимая технология, даже если бы это способствовало достижению какой-то цели нашего бизнеса. Чаще всего навыки в области развития технологий и дизайна позволяют найти решение, соответствующее нашим бизнес-целям (например, в деловых отношениях, росте или монетизации), но оно нередко создает негативный побочный эффект, наносящий ущерб пользователям или окружающей среде. Поэтому я призываю продуктовые команды всегда учитывать этические последствия своих замыслов. Если заметен значительный риск подобного рода, подумайте, нельзя ли найти альтернативные варианты, которые позволят решить эту же проблему, но без негативных последствий.
И последнее, но очень важное замечание в связи с отношением менеджмента к проблемам этики. Вам совершенно необходимо максимально глубоко познать свой бизнес, особенно в плане того, как ваша компания зарабатывает. Менеджер обязан подходить к обсуждению любых тем с позиций здравого смысла и проявлять чуткость в вопросах этического характера. Ваша роль — не жесткий контроль в компании, а выявление проблем и предложение потенциальных решений.
Большинство продуктовых команд считают итерацию видом деятельности, относящимся к этапу поставки продукта на рынок. Если вы делаете релизы еженедельно, считается, что вы работаете с недельными итерациями. Но у нас есть также концепция итерации на этапе исследования продукта. Мы условно определяем ее как проверку минимум одной новой идеи или подхода. Конечно же, замыслы и идеи бывают разными по форме, размеру и степени риска, но цель исследования продукта состоит в том, чтобы протестировать их намного быстрее и дешевле, чем на этапе поставки продукта.
Чтобы вы лучше понимали, чего стоит ожидать, скажу, что команды, компетентные в применении современных методик исследования продукта, могут использовать в рамках тестирования порядка 10–20 итераций в неделю. Вам может показаться, что это очень много, но скоро вы убедитесь, что благодаря современным методикам исследования продукта работать так не очень сложно.
Обратите внимание и на то, что многие итерации никогда не пойдут дальше вас, вашего дизайнера и главного инженера. При создании прототипа нередко обнаруживаются проблемы, которые заставляют вас передумать. Тут действует эмпирическое правило: итерация на этапе исследования продукта должна забирать по крайней мере на порядок меньше времени и усилий, чем итерация на этапе поставки.
Глава 34. Методики исследования продукта: обзор
Не существует идеальной систематики методик для исследования продукта: все они полезны и эффективны в различных ситуациях. Так что далее ключевые методики этой группы я представляю вашему вниманию в порядке, который считаю наиболее целесообразным.
Методики для формулирования задач помогают быстро определить, какие фундаментальные проблемы необходимо решить команде в ходе исследования продукта. Если нам предлагается потенциальное решение, надо уточнить базовую проблему, выявить риски и подумать, на чем стоит сосредоточить усилия. А еще нужно убедиться в том, что мы понимаем, как наша работа согласуется с деятельностью других команд компании.
Несколько методик могут быть полезны в течение всего процесса исследования продукта: они помогают определить наиболее трудные задачи и спланировать, как мы будем подходить к их решению. Обсудим это далее.
Генерировать идеи можно по-разному, но некоторые их источники лучше других, поскольку потенциально позволяют удерживать фокус внимания на наиболее важных проблемах и задачах. Методики выработки идей призваны обеспечить продуктовую команду набором многообещающих решений, нацеленных на решение проблем, над которыми она в настоящий момент работает.
Прототип поистине незаменимый инструмент для исследования продуктов. Далее мы обсудим четыре основных вида прототипов и опишем, в каких ситуациях лучше использовать каждый из них.
Первостепенная цель исследования продукта — максимально быстрая проверка и тестирование имеющихся идей. На этом этапе мы, по сути, пытаемся отделить перспективные идеи от сомнительных.
В книге перспективная идея продукта определяется как идея, решающая фундаментальную проблему таким образом, чтобы потребители ее покупали; ведущая к созданию продукта, которым будет легко пользоваться; для реализации которой у команды есть время, навыки и технологии, притом что ее воплощение в жизнь принесет пользу бизнесу в разных его аспектах.
Важно помнить, что многие идеи не настолько рискованные, как мы считаем. Они могут быть четкими или же рискованными только в одном аспекте — скажем, юридический отдел беспокоят возможные трудности, касающиеся конфиденциальности будущего продукта. Однако иногда нам приходится решать более серьезные проблемы, и мы сталкиваемся со значительными рисками в большинстве или даже во всех возможных областях.
Таким образом, к исследованию продукта надо подходить так: мы обязаны проверять и подтверждать правоту только тех идей, которые действительно нужно подтвердить, и использовать для этого методику, наиболее подходящую в той или иной ситуации.
Методики этой группы предназначены для инженеров-программистов; с их помощью они работают над областями, вызывающими беспокойство. Скажем, тестируемое решение потребовало применения технологии, в использовании которой у команды нет опыта, или были выявлены серьезные трудности в связи с масштабированием или производительностью, или придется оценивать компоненты от сторонних компаний.
Эти методы предназначены для дизайнеров продуктов; с их помощью они работают над проблемными областями. Многие продукты включают сложные рабочие процессы, и дизайнерам нужно убедиться, что они понятны пользователю и что потенциальные источники путаницы идентифицированы и упреждены.
Значительная часть времени на этапе исследования продукта уходит на подтверждение либо улучшение его воспринимаемой ценности. Для разработки нового продукта нам нужны гарантии, что клиенты будут покупать его по цене, которую мы назначим, и откажутся ради него от любого другого, которым пользуются сейчас. При улучшении существующего продукта — например, предложении новой фичи или дизайна, — который потребитель уже купил, нам необходимо убедиться, что люди предпочтут использовать новую опцию или дизайн, а не старые.
К сожалению, недостаточно предложить удобные в использовании продукт или решение, которое полюбят потребители, а разработчики смогут создать. Продукт должен быть выгодным и полезным для бизнеса и поддерживать жизнеспособность компании. Это означает, что мы можем позволить себе затраты на его создание и все требуемые для этого поставки, равно как затраты на его маркетинг и продажи. И это должно быть нечто, что наш торговый персонал сможет продать. Кроме того, решение должно устраивать партнеров по развитию бизнеса, подходить коллегам-юристам и согласовываться с обещанием бренда нашей компании. Методики для тестирования бизнес-жизнеспособности используются для проверки правильности решения с точки зрения всех этих рисков.
Если в вашей организации решено сменить привычный способ на новый, которым, по вашему мнению, нужно работать завтра, в этом вам поможет набор проверенных методик.
Как видите, нам нужен довольно широкий спектр методик, как количественных, так и качественных. Одни предназначены для сбора фактов (или по крайней мере статистически значимых результатов), другие — для получения доказательств. И все они призваны помогать нам быстро учиться и приобретать нужные знания.
Для полной ясности добавлю, что я делюсь методиками, которыми, на мой взгляд, необходимо владеть любой современной продуктовой команде. Примерно за два года вы, скорее всего, примените каждую из них хотя бы несколько раз. Безусловно, сегодня существует немало других эффективных методик, подходящих для конкретных типов продуктов или ситуаций, и постоянно появляются новые. Но без тех, что описываю я, вам не обойтись.