Войти в систему
Войти с помощью соц. сетей:
Главная цель исследования продукта заключается в устранении следующих рисков:
Мнения продакт-менеджера обо всех этих рисках, безусловно, недостаточно — нужно собрать доказательства.
Наш подход к исследованию продукта базируется на принципах, которые четко определяют, как мы должны работать. Если вы их понимаете, то не только знаете, как эффективно действовать сегодня, но и как без особых усилий внедрять новые методики по мере их возникновения в будущем. Итак, вот эти принципы:
Потребители вообще не знают, что возможно создать, а если говорить о высокотехнологичных продуктах, то никому из нас до конца не известно, чего мы действительно хотим, до тех пор, пока мы не увидим это своими глазами. Конечно, это не значит, что клиенты или руководство обязательно ошибутся, просто наша задача — гарантировать предлагаемым решением устранение фундаментальной, базовой проблемы. Наверное, это главное в разработке современных технологических продуктов. Так уж сложилось, что в большинстве случаев с инновациями в нашей индустрии изначально потребители понятия не имели, что обожаемый ими продукт может быть создан. И со временем эта тенденция только укрепляется.
Конечно, сложно соблюсти все принципы, но сложнее всего предложить такую ценность, чтобы потребители решили купить и использовать наш продукт. Компания способна выживать некоторое время, имея проблемы, связанные с юзабилити или даже с производительностью продукта, но без базовой ценности у нее на самом деле нет ничего. Вот почему львиная доля времени и усилий на этапе исследования продукта уходит на подтверждение ценности данной идеи.
В каждой продуктовой команде есть инженеры-программисты, но не у всех имеются необходимые навыки в области дизайна продукта. И даже когда они есть, используются ли они именно так, как нам нужно?
В старой, каскадной модели разработки продуктов рынок определял функциональность (или технические требования) продукта, которая, в свою очередь, определяла его дизайн, а тот — способ реализации. Сегодня мы знаем, что технологии определяют (и делают возможной) функциональность в той же мере, как это действует и в обратном направлении. И нам известно, что технологии определяют (и делают возможным) дизайн. А дизайн — (и делает возможной) функциональность. Чтобы увидеть многочисленные примеры всего перечисленного, достаточно взглянуть на свой телефон. В нем функциональность, дизайн и технологии тесно переплетены. Кстати, это и есть главная причина того, почему мы должны изо всех сил стараться построить работу так, чтобы менеджер продукта, дизайнер продукта и главный инженер трудились плечом к плечу в прямом смысле слова.
Как сказал Марк Андриссен, «самое главное — понимать, какая информация вам недоступна». Конечно же, нельзя заранее знать, какие идеи будут приняты потребителями, а какие нет. Поэтому мы должны изначально подходить к исследованию продукта с настроем на то, что многие, если не большинство наших идей и замыслов, ни к чему не приведут. Чаще всего это случается из-за недостаточной ценности, но иногда и дизайн слишком сложен; или выясняется, что разработка займет слишком много времени; или возникают проблемы правового характера, скажем, с конфиденциальностью. Нам нужно быть готовыми к тому, что при необходимости придется попытаться решить фундаментальную проблему другими способами.
Вера в то, что мы способны предвидеть реакцию потребителей, — весьма распространенная ловушка при разработке новых продуктов; она может быть основана на изучении клиентов или собственном опыте. Как бы там ни было, сегодня мы точно знаем, что всегда надо проверять жизнеспособность своих идей на реальных пользователях (потребителях). И делать это прежде, чем вы начнете тратить время и средства на создание продукта.
На этом этапе во главу угла ставится скорость. «Быстродействие» позволяет протестировать много идей, а в отношении наиболее многообещающих испытать несколько подходов. Существует множество типов идей, замыслов, типов продуктов и разные риски (ценности, юзабилити, реализуемости и бизнес-жизнеспособности), которые необходимо устранить. Поэтому у нас так много методик для различных ситуаций.
Если инженеры-программисты впервые узнали об идее при планировании спринта, считайте, что вы потерпели неудачу. Мы должны гарантировать выполнимость до того, как решим создавать продукт, а не после, поскольку это не только сокращает малоэффективные затраты времени. Как показывает опыт, если как можно раньше узнать мнение технаря, то, во-первых, это будет способствовать поиску более успешного решения, а во-вторых, очень важно для совместного обучения людей.
Прежде чем тратить время и деньги на создание продукта, крайне важно убедиться, что решение, над которым мы работаем, обеспечивает потребности нашего бизнеса. При оценке бизнес-жизнеспособности идеи о продукте следует учесть финансовые моменты, соображения отделов маркетинга (насчет бренда и способов вывода нового продукта на рынок) и продаж, юридические требования и вопросы бизнес-развития, а также мнение высшего руководства. Ничто так не ослабляет моральный дух сотрудников и подрывает веру в профессионализм продакт-менеджера, как ситуация, когда продукт готов, но вдруг обнаруживается, что менеджер, оказывается, не разбирается в важнейших вопросах бизнеса.
Если вы хотите иметь команду «миссионеров», а не «наемников», все ее члены должны вместе учиться и получать новую информацию; вместе видеть проблемы клиента и наблюдать за тем, как одни идеи терпят крах, а другие отлично воплощаются в жизнь. Тогда все люди будут понимать общий контекст, в котором их работа имеет значение, и знать, что именно они должны делать.
Итак, это были принципы исследования продукта, а все остальное зависит от их соблюдения.
Этика: следует ли нам это создавать?
В общем главная цель исследования продукта состоит в устранении потенциальных рисков, связанных с его ценностью, юзабилити, выполнимостью и бизнес-жизнеспособностью, но в некоторых случаях компания сталкивается с еще одним серьезным риском — этическим.
При обсуждении столь деликатной темы я очень не хочу, чтобы мои слова прозвучали так, будто я вас поучаю или снисходительно наставляю на путь истинный, но я всегда призываю продуктовые команды, с которыми работаю, ответить на еще один важный вопрос: а следует ли нам это создавать?
Вы можете думать, что этический аспект возникает только тогда, когда речь идет о чем-то незаконном, но в подавляющем большинстве случаев это вовсе не правовая проблема. Суть в том, что нам необязательно непременно что-то делать просто потому, что для этого имеется необходимая технология, даже если бы это способствовало достижению какой-то цели нашего бизнеса. Чаще всего навыки в области развития технологий и дизайна позволяют найти решение, соответствующее нашим бизнес-целям (например, в деловых отношениях, росте или монетизации), но оно нередко создает негативный побочный эффект, наносящий ущерб пользователям или окружающей среде. Поэтому я призываю продуктовые команды всегда учитывать этические последствия своих замыслов. Если заметен значительный риск подобного рода, подумайте, нельзя ли найти альтернативные варианты, которые позволят решить эту же проблему, но без негативных последствий.
И последнее, но очень важное замечание в связи с отношением менеджмента к проблемам этики. Вам совершенно необходимо максимально глубоко познать свой бизнес, особенно в плане того, как ваша компания зарабатывает. Менеджер обязан подходить к обсуждению любых тем с позиций здравого смысла и проявлять чуткость в вопросах этического характера. Ваша роль — не жесткий контроль в компании, а выявление проблем и предложение потенциальных решений.
Итерации на этапе исследования продукта
Большинство продуктовых команд считают итерацию видом деятельности, относящимся к этапу поставки продукта на рынок. Если вы делаете релизы еженедельно, считается, что вы работаете с недельными итерациями. Но у нас есть также концепция итерации на этапе исследования продукта. Мы условно определяем ее как проверку минимум одной новой идеи или подхода. Конечно же, замыслы и идеи бывают разными по форме, размеру и степени риска, но цель исследования продукта состоит в том, чтобы протестировать их намного быстрее и дешевле, чем на этапе поставки продукта.
Чтобы вы лучше понимали, чего стоит ожидать, скажу, что команды, компетентные в применении современных методик исследования продукта, могут использовать в рамках тестирования порядка 10–20 итераций в неделю. Вам может показаться, что это очень много, но скоро вы убедитесь, что благодаря современным методикам исследования продукта работать так не очень сложно.
Обратите внимание и на то, что многие итерации никогда не пойдут дальше вас, вашего дизайнера и главного инженера. При создании прототипа нередко обнаруживаются проблемы, которые заставляют вас передумать. Тут действует эмпирическое правило: итерация на этапе исследования продукта должна забирать по крайней мере на порядок меньше времени и усилий, чем итерация на этапе поставки.
Войти с помощью соц. сетей: