(смогут ли пользователи понять, как это работает), риске реализуемости (осуществимости) (смогут ли инженеры создать то, что нужно, с учетом времени, навыков и технологий, имеющихся в распоряжении) и риске бизнес-жизнеспособности (будет ли это решение полезным для разных аспектов бизнеса: продаж, маркетинга, финансов, юридических вопросов и так далее).
2. Продукты определяются и разрабатываются совместно, в сотрудничестве, а не последовательно. Наилучшие команды вышли за рамки старой модели, в которой менеджер продукта выясняет и определяет технические условия, дизайнер-проектировщик разрабатывает решение, обеспечивающее их выполнение, а затем инженеры-программисты осуществляют их на практике — и каждому приходится считаться с ограничениями и учитывать решения тех, кто шел в этом процессе до них. В сильных командах все трудятся плечом к плечу, обмениваясь идеями и во всем помогая друг другу, чтобы придумать технологические решения, которые полюбят потребители и которые принесут реальную выгоду бизнесу.
3. И наконец, главное — решить проблему, а не имплементировать новые функции. Как мы уже говорили, традиционные дорожные карты продуктов нацелены прежде всего на процесс, но сильные команды знают, что их цель — не только и не столько внедрение того или иного решения. Они обязаны гарантировать, что оно позволит устранить фундаментальную проблему. Иными словами, они нацелены на реальные бизнес-результаты.
Как вы скоро убедитесь, книга посвящена именно этим трем принципам.
Глава 8. Ключевые идеи
В этой книге я часто ссылаюсь на понятия, которые можно считать фундаментом современной работы над продуктом. И мне хотелось бы кратко объяснить их, прежде чем продолжать обсуждение.
Термин продукт я использую в довольно широком смысле. Помните, я сразу акцентировал ваше внимание на том, что в книге речь идет исключительно о высокотехнологичных продуктах? Но в общем я имею в виду всеобъемлющее, максимально комплексное определение этого понятия.
Понятие продукта, безусловно, включает функциональность — функции и характеристики. Но сюда относятся и технологии, которые делают эту функциональность возможной. А еще дизайн пользовательского интерфейса, который представляет эту функциональность визуально. И то, как мы ее монетизируем. И то, как привлекаем и приобретаем пользователей и клиентов. А еще оно может включать опыт взаимодействия в реальном мире, что порой необходимо для обеспечения ценности продукта.
Если вы разрабатываете сайты для e-commerce, то ваш продукт включает в себя опыт выполнения и возврата заказа. В общем продукт такой компании представляет собой все, кроме реального, фактического товара, который продается. Аналогично продуктом медиакомпании будет все, кроме предлагаемого потребителям контента.
Суть в том, что определение продукта должно быть всеобъемлющим и комплексным. Не думайте, что наша задача — просто внедрять новые функции.
Я уже говорил, что большинство компаний по-прежнему используют по сути каскадный процесс и что в лучших современных командах вы ничего похожего не увидите.
Позже мы рассмотрим процесс разработки продукта подробнее, а сейчас я изложу вам общую концепцию.
Все продуктовые команды занимаются двумя основными видами деятельности: во-первых, определяют (изобретают, придумывают, находят путем исследований) продукт, который будут создавать; во-вторых, выводят его на рынок (выпускают, разрабатывают и представляют). Исследование продукта (или новых дополнительных возможностей, так называемых фич) и его поставка на рынок — два основных вида деятельности кросс-функциональной продуктовой команды — обычно ведутся непрерывно и параллельно.
Осмыслить и визуализировать это можно несколькими способами, но, по сути, все довольно просто. Главное — все в команде всегда должны работать параллельно, стараясь определить, какой продукт нужно создать; над этим в основном изо дня в день работают менеджер продукта и дизайнер, в то время как инженеры-программисты трудятся над реализацией замысла и созданием готового программного продукта.
Рис. 8.1. Непрерывный процесс исследования продукта и его поставки на рынок
Как вы скоро увидите, в реальности все немного сложнее. Например, технари тоже ежедневно помогают выяснять, над каким продуктом следует работать (и, надо признать, многие лучшие инновации рождаются благодаря их участию, так что недооценивать их вклад ни в коем случае не стоит), а менеджер продукта и дизайнер ежедневно помогают инженерам создавать фактический продукт (в основном уточняя необходимые характеристики и функции). Но в целом все сводится к этим двум видам деятельности.
Эта концепция связана с понятием тесного сотрудничества в управлении продуктом, проектирования пользовательского интерфейса и инженерной разработки. На этапе исследования мы сокращаем разные формы риска, прежде чем будет написана хоть одна строка кода.
Цель исследования — как можно быстрее отделить хорошие идеи от плохих и получить в результате проверенный бэклог продукта (журнал задач, которые необходимо выполнить команде). В частности, это означает, что мы получили ответы на четыре главных вопроса:
1. Будет ли пользователь это покупать (или использовать)?
2. Сможет ли он понять, как это использовать?
3. Смогут ли инженеры это построить?
4. Станут ли заинтересованные стороны это поддерживать?
Этап исследования включает в себя проведение серии очень быстрых экспериментов с использованием прототипов, а не самих продуктов, чтобы получилось быстро и недорого. Сейчас я только скажу, что существует несколько видов прототипов для разных рисков и ситуаций, но на создание каждого из них требуется как минимум на порядок меньше времени и усилий, чем на создание готового продукта.
Чтобы понять ожидания пользователей, сильные команды обычно еженедельно тестируют множество идей продуктов — от десяти до двадцати и более.
Хочу еще раз подчеркнуть, что в экспериментах обычно применяются прототипы. Прототипы — это не то, что абсолютно и полностью «созрело», и точно не то, что компания будет пытаться продавать и за что готова встать горой. Но они невероятно полезны, потому что с их помощью можно очень многое узнать, причем быстро и дешево.
Цель использования прототипов и проведения экспериментов на этапе исследования — быстрый поиск некоторых доказательств того, что это действительно стоит создавать и что мы, следовательно, могли бы предложить потребителям. Для этого должен быть удовлетворен ряд условий касательно масштабируемости, производительности, надежности, устойчивости к сбоям и ошибкам, безопасности, конфиденциальности, интернационализации и локализации; продукт обязан работать так, как рекламировалось.
Цель этапа поставки — создание и выпуск готовых программных продуктов (или фич), то есть того, что вы сможете продать и на чем компания заработает деньги и репутацию.
Тот факт, что мы потратили время и силы на создание работающего продукта, еще не означает, что кто-то захочет его купить. Вот почему в мире продуктов мы всегда стремимся достичь важнейшего соответствия «продукт — рынок». Речь идет о минимально жизнеспособном продукте, обеспечивающем потребности целевого рынка. Заслугу популяризации этой исключительно важной концепции (соответствие продукта ожиданиям рынка) приписывают Марку Андриссену; это центральная концепция всей книги.
Для большей ясности скажу, что для актуальных продуктов достижение такого соответствия — это всегда результат этапа поставки. Действия на этапе исследования помогают нам определить продукт, но фактическая работа, необходимая для его создания, тестирования и вывода на рынок, выполняется на этапе поставки.
И наконец, последнее важное понятие — видение продукта. Это долгосрочная цель для того или иного продукта, обычно поставленная на срок от двух до десяти лет. Это и то, как мы намерены реализовывать свою миссию как продуктовая компания.
Итак, мы используем прототипы для проведения быстрых экспериментов на этапе исследования, а затем поставки, создаем и выводим продукт или новую функцию на рынок в надежде достичь соответствия «продукт — рынок», что является ключевым шагом на пути к реализации видения продукта компанией.
Кстати, если суть какого-либо из этих понятий вам пока не полностью ясна, не стоит беспокоиться. Я знаю, что сейчас у вас в голове, скорее всего, вертится куча вопросов, но все станет ясно, когда мы глубже погрузимся в каждую тему. Кроме того, немного здорового скептицизма еще никому не повредило: «Да разве такое возможно — проводить по пятнадцать экспериментов в неделю?»
Я предупреждал вас, что успешные продуктовые команды работают иначе, чем большинство конкурентов — пусть это послужит вам первым указанием на то, как сильно отличаются их подходы.
Минимально жизнеспособный продукт (minimum viable product, MVP)[4] — одна из самых важных концепций в нашей отрасли, предложенная много лет назад. Термин придумал Фрэнк Робинсон (в 2001 году), а я писал об этой концепции в первом издании книги (в 2008 году). Но заслуга ее популяризации принадлежит Эрику Рису, в частности его работе The Lean Startup[5]