Kitobni o'qish: «Управление продуктом. Российская практика»

Часть I. Зоны влияния продакт-менеджера, продуктовый подход и создание продуктовых команд

Глава 1. Подходы к управлению продуктом

Что труднее всего на свете видеть своими глазами? То, что лежит перед ними.

Иоганн Вольфганг фон Гете

ПЕРЕОСМЫСЛЕНИЕ РАБОТЫ: ОТ ФАБРИКИ ФУНКЦИЙ К ОБНАРУЖЕНИЮ ВОЗМОЖНОСТЕЙ

Шестнадцать лет назад я работала в компании, которая занималась внедрением программного обеспечения. В какой-то момент у акционеров возникло желание создать стартап и сделать облачный Service Desk. Я играла роль бизнес-аналитика. У меня были диплом по направлению «информационные системы и сети» одного из ведущих вузов страны, опыт написания множества технических заданий и оценки требований.

В то время никто еще не слышал про продакт-менеджеров, такой роли просто не было. Я, как бизнес-аналитик, должна была переводить видение заказчиков в требования для разработчиков. Как вы думаете, что мы тогда делали? Наверное, вы уже догадались: «пилили фичи». И мы даже не осознавали, что нам нужно заняться тестированием бизнес-модели продукта и первыми продажами.

Прошлый опыт определяет, как мы принимаем решения, наши действия и предпочтения. Как-то Абрахам Маслоу сказал: «Если единственный инструмент, который вы имеете, – молоток, то заманчиво рассматривать все как гвозди». Люди могут по умолчанию использовать знакомые им методы, которые срабатывали в прошлом. Нам постоянно казалось, что продукт еще не готов; в итоге полтора года мы работали на фабрике функций без обратной связи от рынка, мыслей о модели продаж и монетизации. Главное ограничение роста всегда смещается в зону некомпетентности команды – «слепую зону», в которой команде не хватает экспертизы.

Это было начало 2000-х, и в свое оправдание могу сказать, что тогда опыта работы в стартапе почти ни у кого не имелось. В 1990-е мы стали свидетелями быстрого расширения технологических компаний, однако в 2001 году в США лопнул «пузырь доткомов» ровно потому, что старые методы больше не работали. Закрылось огромное количество интернет-стартапов, которые не смогли оправдать ожидания инвесторов и обеспечить соответствие продукта рынку. Это простимулировало появление новых подходов к управлению продуктом: Agile (гибкую разработку программного обеспечения) и Lean Startup (бережливый стартап).

Однако обо всем по порядку. Вы можете спросить: «Если не проводить исследования рынка, то как понять, какой продукт нужно делать?» На этот счет есть две теории.

Одна заключается в том, что идея – озарение предпринимателя, а сами бизнесмены – такой особенный класс людей, которые обладают даром предвидения. Часто приводят высказывание Стива Джобса: «Очень трудно создавать продукт для конкретных людей. Чаще всего люди сами не знают, чего хотят, пока ты не покажешь им это. Вот почему я никогда не полагаюсь на исследования рынка. Наша задача – прочесть то, чего еще нет на странице». Конечно, Джобс был визионером, готовым рисковать, но было ли это свойство даром свыше или следствием его характера и прошлого опыта?

Мне очень нравится речь Стива Джобса перед выпускниками Стэнфорда, в которой он поделился еще одной важной мыслью.

Нельзя соединить временные точки заранее; увидеть связь между ними возможно, лишь оглядываясь назад. Надо просто верить, что точки как-то соединятся в будущем. Ничего из того, что я тогда узнал, казалось бы, не могло иметь никаких практических последствий для моей жизни. Но десять лет спустя, когда мы создавали первый компьютер «макинтош», все это мне пригодилось. Мы заложили всю изученную мной премудрость в нашу машину. Это был первый компьютер, владеющий каллиграфией. Если бы я не наткнулся на тот курс в колледже, у «мака» никогда бы не было множества разных типов шрифтов. И поскольку Windows в этом отношении просто копирует «макинтош», возможно, что ничего этого не было бы ни на одном персональном компьютере. Итак, нельзя соединить временные точки заранее; увидеть связь между ними возможно, лишь оглядываясь назад. Надо просто верить, что точки как-то соединятся в будущем.

Эта цитата наводит меня на мысль, которая была описана в концепции экономиста Израэля Кирцнера об обнаружении ошибочно нераспознанных возможностей в его книге «Конкуренция и предпринимательство»². По сути, идея Кирцнера вращается вокруг предпринимательской функции выявления возможности получения прибыли, которая обусловлена асимметрией информации на рынке. Согласно ему, предприниматели, благодаря своей бдительности и дальновидности, могут распознать возможности получения прибыли, которые другие упустили из виду или недооценили. Поэтому часто бизнесмены начинают стартапы с осознания и глубокого понимания проблемы, с которой сталкиваются лично: они – эксперты в предметной области. Я много раз была свидетелем тому, как какое-то стоящее предложение возникало у экспертов из-за объединения старых знаний в новые комбинации, то есть благодаря умению создавать новые взаимосвязи.

У Питера Тиля, соучредителя PayPal, в книге «От нуля к единице. Как создать стартап, который изменит будущее» есть интересная глава о секретах, которую он открывает словами: «Каждая из самых известных и знакомых сегодня идей когда-то была неизвестной и неожиданной. Лучшие предприниматели знают: в основе любого великого бизнеса лежит секрет, скрытый от внешнего мира».

Например, всем известный продукт Miro, который сейчас обслуживает 99 % компаний из списка Fortune 100 и имеет более 50 млн пользователей, начался в 2011 году с идеи Андрея Хусида и Олега Шардина³ перенести интерактивную доску в браузер для «визуального сотрудничества». На эту идею их натолкнула работа в креативном агентстве. Они поняли, что люди могут общаться визуально и этот способ во многих случаях лучше закрывает задачу совместного творчества по сравнению с обычным обменом сообщениями. Картинка стоит тысячи слов – такова была первоначальная идея Miro. Однако ей потребовалось четыре года, чтобы достичь соответствия продукта рынку после разработки первой версии решения.

Могу сказать, что знание ошибочно нераспознанных возможностей, которые и становятся «секретом», отличается от простой идеи продукта или галлюцинации основателя. Это первое, что нужно понимать, когда вам приводят статистику провала стартапов (девять из десяти «умирают» и закрываются). Ключевое слово тут – «возможность»: возможность создать жизнеспособную масштабируемую бизнес-модель.

Теперь представим, что вы не основатель, а работаете в продуктовой команде, не общаетесь с клиентами, не пользователь своего продукта или не имеете опыта в своей предметной области. Какова вероятность обнаружения и реализации вами стоящей возможности?

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

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

ИЗМЕНЕНИЕ ПОДХОДОВ: КАК МЫ ВНЕДРЯЛИ AGILE И SCRUM

Вернемся к нашему стартапу. Итак, как можно описать «пиление фич»?

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

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

Процесс работы в описанной мной компании показан на рис. 1.1.

Рис. 1.1. Процесс разработки продукта, пример

В то время многие еще применяли водопадную модель с длинными циклами разработки. Ключевым ограничением была низкая скорость разработки и вывода готового продукта на рынок (time to market). Быстро что-то изменить было не только сложно, но и дорого. Водопадная модель подходит для ситуаций с очень предсказуемыми требованиями или долгосрочными горизонтами планирования, однако для проекта с меняющимися требованиями нужны более гибкие подходы. Надо отдать должное: во всех командах, в которых я работала, мы шли в ногу со временем от водопада навстречу Agile.

В 2001 году появился «Agile-манифест»⁴. Этот подход базируется на четырех ключевых ценностях, которые помогают компаниям стать гибкими.

1. Люди и их взаимодействие важнее, чем рабочие процессы и инструменты.

2. Функционирующий продукт важнее, чем регламенты, написание инструкций, задания.

3. Сотрудничество с заказчиком важнее, чем просто подписание договора.

4. Адаптивность и оперативная реакция важнее, чем слепое следование плану.

Agile подразумевает итеративный процесс, в котором сначала создается базовое решение, которое затем со временем расширяется. Допустим, вы хотите сделать сайт для электронной торговли. В Agile вы не будете тратить месяцы на создание ресурса, вместо этого вы разработаете базовую первую версию – MVP (Minimum Viable Product – минимально жизнеспособный продукт). Возможно, просто страницу, чтобы начать продавать. Затем вы итеративно будете ее усовершенствовать, добавляя все больше разделов и функций. Эти итеративные улучшения называются инкрементами или потенциально готовыми к поставке приращениями продукта (PSPI, Potentially Shippable Product Increment) – ценностью, предоставляемой клиенту через элементы бэклога продукта, которые были выполнены во время спринта.

Agile-манифест на самом деле не описывает выполнение работы, то есть сам процесс. Когда компании решают использовать эти принципы, они должны выбрать его самостоятельно. Можно расценивать Agile как зонтик, под которым находятся процессные фреймворки, соответствующие его принципам и ценностям: Scrum, Kanban, LeSS, SAFe и др. Большинство технологических компаний не следуют ни одному из них буквально, а используют гибридные подходы, ориентированные на практические результаты, в виде набора практик (рис. 1.2).

Рис. 1.2. Agile как образ мышления и набор практик⁵

Мне нравится визуализация Ахмеда Сидки – основателя Международного Agile-консорциума, который изобразил континуум от образа мышления, ценностей Agile-манифеста к принципам и практикам.

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

Большинство продуктовых команд работает по Scrum или в гибридном подходе Scrum + Kanban. Основным артефактом для работы становится бэклог продукта – список всех желаемых работ, обычно в виде пользовательских историй (user story), отсортированных в порядке приоритета. Он развивается по мере появления новых требований (или идей в нашем случае). В начале каждого спринта происходит планирование, в результате которого пользовательские истории переносятся из бэклога продукта в бэклог спринта с оценкой объема работ. Затем команда встречается на ежедневном стендапе, где делится ходом работы. В конце спринта проводится его ретроспектива.

Самый популярный фреймворк на данный момент – Scrum Кена Швабера и Джеффа Сазерленда. В его основе лежит идея работы короткими циклами – спринтами, в которых принимают участие и бизнес, и ИТ.

Спринты – регулярные ограниченные промежутки времени, в течение которых Scrum-команда выполняет заданный объем работы. Средняя продолжительность – 2–4 недели. По итогам команда обязуется создать новую версию продукта с приростом ценности для клиента (функционала) – инкрементом. Спринты выпускаются в определенные даты. Все это приводит к упорядочиванию работы ИТ. Поскольку вы действуете итеративно и попутно создаете продукты, вы можете предоставить больше гибкости своим конечным пользователям и клиентам и вовлечь их в процесс разработки и тестирования.

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

Формат пользовательской истории выглядит следующим образом: «Как [тип пользователя]; я хочу [некая цель]; так, чтобы [некая причина]». Рассмотрим все пункты подробнее.

• Как [тип пользователя]. В этом разделе указывается, кто пользователь. Это помогает лучше понять его точку зрения и потребности.

• Я хочу [некая цель]. Эта часть описывает, чего пользователь хочет достичь или какую функцию желает видеть в продукте. Она должна быть ясной и краткой, фокусироваться на желаемой функциональности, без подробностей реализации.

• Так, чтобы [некая причина]. Тут объясняется причина цели пользователя. Так мы обеспечиваем контекст и помогаем команде понять основную мотивацию, которая может иметь решающее значение для определения приоритетов и принятия решений.

Например, для сайта интернет-магазина пользовательская история может быть такой.

ПОЛЬЗОВАТЕЛЬСКАЯ ИСТОРИЯ: ОНЛАЙН-МАГАЗИН

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

Критерии приемки

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

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

• Информация о ценах, включая базовую, любые применимые скидки, рекламные акции или пакетные предложения, должна отображаться на видном месте рядом с описанием продукта.

• Пользователи должны иметь возможность просматривать совокупные рейтинги и читать подробные отзывы тех, кто купил продукт. Система отзывов должна поддерживать материалы, отправленные проверенными пользователями, обеспечивая достоверность и подлинность.

• Клиенты должны иметь возможность фильтровать и сортировать отзывы по релевантности, дате, рейтингу или конкретным критериям.

Пользовательская история дополняется макетом интерфейса и нефункциональными требованиями к производительности, безопасности, отказоустойчивости (если применимо). Пользовательские истории могут быть сгруппированы в эпики, которые, в свою очередь, объединены в инициативы, а инициативы в темы.

Владелец продукта (Product Owner) – это ключевая роль в Scrum, отвечающая за максимизацию ценности продукта, создаваемого командой разработки. Он определяет приоритеты в бэклоге, собирает оценки трудозатрат, взаимодействует с заинтересованными сторонами для определения и удовлетворения их требований.

Все команды помешаны на планировании. Это неудивительно, ведь точные оценки позволяют прогнозировать сроки и бюджет проекта, на которые «коммитятся» владельцы продуктов. Сколько раз я участвовала во встречах, где все спрашивали: «Когда вы реализуете эту фичу?» Коммуникация статуса и сроков крайне важна, ведь по ней оценивается работа команды в фабрике функций.

Для каждой истории (либо в условных единицах – Story Points, либо в человеко-часах) выставляется оценка, которую дают разработчики. Поинты обозначают уровень сложности или трудоемкости реализации элементов бэклога продукта (пользовательской истории): один поинт – простую задачу, два – сложнее и т. д., однако для того, чтобы начать их использовать, необходим накопленный командой опыт разработки. Часто на этом этапе важно дробить истории, чтобы получить более точные оценки.

Для лучшего понимания нужно рассмотреть концепцию скорости работы (velocity). В конце каждого спринта команда суммирует оценки усилий, связанные с пользовательскими историями, которые были завершены за время спринта. Эта сумма называется скоростью: это количество поинтов, которое команда реализует за спринт. Таким образом, в начале вы как бы предполагаете или оцениваете, сколько поинтов вы можете набрать за спринт, но после пары спринтов вы сможете усреднить количество поинтов, а затем сделать вывод, что в среднем ваша команда может, например, набрать 15 поинтов за спринт. Это и есть скорость работы.

Для составления бэклога спринта команда берет пользовательские истории из бэклога продукта и обязуется доставить их за спринт. Это самый нижний уровень, на котором команды устанавливают приоритеты. В релиз (выпуск функциональности для пользователей) обычно попадают истории нескольких спринтов. Календарный план релизов представляет собой дорожную карту, которая часто выглядит как диаграмма Ганта с датами релизов.

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

Рис. 1.3. Пример Burndown Chart

Если скорость команды начинает падать, значит, она неправильно оценивает свои истории: берет на себя слишком много работы или кто-то заставляет ее это делать. Но если команда неожиданно обнаруживает, что у нее появляется много свободного времени, значит, ей следует сделать переоценку своих трудозатрат. Важный инструмент для налаживания темпа и прогнозирования скорости разработки – диаграмма сгорания задач, или Burndown Сhart.

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

Один из популярных вопросов на собеседованиях: «Что делать, если команда отстает от графика?» Это головная боль владельца продукта и менеджера проекта. Тут можно вспомнить известный треугольник ограничений проекта, также называемый тройным ограничением, железным треугольником (рис. 1.4).

Рис. 1.4. Треугольник ограничений

Вот три основных ограничения (изменение одного из них обычно влияет на два других).

• Объем работ: определяет, что будет реализовано. Изменения объема могут повлиять как на время, так и на стоимость.

• Время: сроки и время, доступные для завершения проекта. Если временные ограничения ужесточены, может потребоваться больше ресурсов (увеличение затрат) или сокращение объема.

• Стоимость: включает бюджет, все ресурсы, необходимые для завершения задач, такие как рабочая сила, материалы, оборудование и накладные расходы. Увеличение бюджета может помочь уложиться в сжатые сроки или расширить объем работ, тогда как сокращение бюджета может потребовать уменьшения объема или продления сроков.

В центре треугольника находится качество, представляющее конечную цель: поддержание критериев приемки, несмотря на ограничения.

Итак, если команда отстает от графика, то допустимо сократить объем задач или перенести сроки запуска, однако это может плохо повлиять на бизнес-результат; добавить больше разработчиков (увеличить стоимость). Однако в последнем случае вы можете столкнуться с «мифическим человеко-месяцем» и законом Брукса – концепцией, которую описал Фред Брукс в своей книге «Мифический человеко-месяц: очерки по разработке программного обеспечения».

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

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

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

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

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

ВЛАДЕЛЕЦ ПРОДУКТА: ЗАДАЧИ И РОЛЬ В КОМАНДЕ

Я специально вынесла роль владельца продукта, а не менеджера продукта, в заголовок этого раздела. Между этими ролями есть существенная разница.

В команде выделяется роль владельца продукта, который должен отвечать за представление всех заинтересованных сторон и приоритизацию работ, уточнение требований и контроль сроков и бюджетов. Часто он берет на себя роль и Scrum-мастера, ответственного за соблюдение практик в команде и проведение мероприятий вокруг спринтов: планирование, обзор, ретроспективу, ежедневные статусы (стендапы). В подавляющем большинстве известных мне случаев владельцами продуктов становились системные аналитики, бизнес-аналитики и менеджеры проектов, которые и так выполняли функции планирования и администрирования задач, создания задач для разработчиков и тестировщиков.

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

Успешные владельцы продуктов часто помогают заказчикам конкретизировать видение и воплотить его в жизнь, работая со всеми заинтересованными сторонами.

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

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

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

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

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

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

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

Таким образом, размер команды и компании имеет значение: чем крупнее организация, тем больше зависимостей и коммуникационных барьеров в ней образуется. Это неизбежно приводит к увеличению сложности. Организации (особенно в корпорациях) склонны начинать новые проекты с большими командами и долгим согласованием выделения ресурсов, годовыми бюджетными циклами, которые часто подменяют собой стратегию. Бремя координации ложится на владельцев продуктов и менеджеров проектов. В этой ситуации под прицел критики очень часто попадает именно владелец продукта. Ему «припоминают» большое количество непродуктивных встреч, отсутствие ясных и согласованных приоритетов, недостаточную проработку пользовательских историй, прототипов интерфейсов, функциональных требований, «поехавшие» релизные сроки и т. д. Вот только он не может устранить те ограничения, которые не находятся в зоне его влияния.

Применение принципов Agile, внедрение Scrum-ритуалов еще не означает, что команда приносит ценность клиенту и бизнесу, а не является фабрикой функций. Конечно, важно, чтобы к началу планирования спринта были проработаны все пользовательские истории, прототипы интерфейсов, функциональные требования и т. д. Но, даже несмотря на это, часто владелец продукта не понимает, как оценить влияние задачи на бизнес, а также уверенность в достижении оного. Ему приходится снова и снова встречаться с руководителями коммерческого блока для уточнения требований и оценок. Последние, в свою очередь, воспринимают это общение как обузу, отвлекающую их от главных задач. При этом все, конечно, понимают, что постановка внутри спринтов не может меняться, но тут и там возникают дополнительные задачи в формате «мы потеряем клиента, если не сделаем этого», «Иван Петрович позвонил и сказал…» и др.

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

LEAN STARTUP И ЕГО ВЛИЯНИЕ НА УПРАВЛЕНИЕ ПРОДУКТОМ В КОМПАНИЯХ

Многие стали задаваться вопросом: почему компания не может работать как стартап, который, как мы знаем по Стиву Бланку, «не уменьшенная версия большой компании»?

В XX веке инвесторы, по сути, говорили стартапам, что они уменьшенные версии крупных компаний. Но потом в США лопнул «пузырь доткомов»: новые бизнес-модели оказались неэффективными, а средства, потраченные в основном на рекламу, и большие кредиты привели к волне банкротств, сильному падению индекса NASDAQ. Выжили только те компании, у которых имелись устойчивые бизнес-модели. Внезапно инвесторы стали избегать риска и искать доказательства соответствия продукта рынку.

В это время появились методология Lean Startup и концепция Customer Development, книги Стива Бланка, Дэна Олсена, Марти Кагана, Эрика Риса. Ключевая идея их такова: необходимо сначала создать гипотезы относительно бизнес-модели, протестировать в экспериментах и только потом принимать решение о разработке.

В то время как крупные компании реализуют бизнес-модели, стартапы фактически ищут бизнес-модели, тестируя основные предположения (в этом суть Customer Development). В таблице 1.1 приведены ключевые отличия стартапа от зрелой компании.

Таблица 1.1. Различия стартапа и зрелой компании

Стартапы и те, кто занимается разработкой новых продуктов, уделяют большое внимание концепции Product-Market Fit. Если задача стартапа состоит в том, чтобы найти жизнеспособную бизнес-модель, то поиск соответствия продукта рынку считается результатом этих изысканий. В стартапах это часто означает, что до PMF вы направляете инвестиции в первую очередь на фазу поиска и развития клиентов.

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

Для поиска PMF используется итеративный подход Learn, Build, Measure (научиться, создать, измерить). Это цикл, который делает упор на скорость как на важнейшую составляющую развития продукта (рис. 1.5).

Рис. 1.5. Цикл Learn, Build, Measure

Продуктовый менеджмент не рассматривается как линейный путь от точки А до точки Б. Он представляет собой непрерывный цикл тестирования гипотез.

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

В цикле присутствует понятие гипотезы и MVP (Minimum Viable Product) – минимально жизнеспособного продукта. Разберемся, что это такое.

О чем-то мы точно знаем, что это правда; что-то можем только предполагать. Перед проведением эксперимента важно иметь четкую проблему, которую вы пытаетесь решить. Это может быть что угодно: от улучшения пользовательского опыта до повышения коэффициента конверсии или снижения оттока. Как только вы определили проблему, пришло время сформировать гипотезу. Гипотеза – предположение, сделанное на основе ограниченных доказательств в качестве отправной точки для дальнейшего исследования и принятия решения. Она должна быть конкретной, измеримой и поддающейся проверке.

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

Для проверки продуктовых гипотез доступен широкий спектр методов. Исследования пользователей делятся на два подмножества: качественные, которые помогут вам глубже понять, почему пользователи ведут себя определенным образом, и количественные, которые валидируют предположения, выработанные на основе качественных исследований, используя аналитические методы, такие как опросы или измерение определенных метрик (табл. 1.2).

Таблица 1.2. Особенности разных типов исследований

Люди, которые не до конца понимают разницу между качественными и количественными исследованиями, часто считают, что первые из-за маленького размера выборки могут исказить результаты и привести к неправильным выводам.

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

Мы также можем выделить два подхода к исследованию пользователей.

• Исследования отношения (Attitudinal) – путем задавания вопросов пользователям об их мыслях, чувствах и мнениях о продукте (например, интервью, фокус-группы).

• Исследования поведения (Behavioral) – непосредственное наблюдение за взаимодействием пользователей с продуктом и получение данных об их поведении. Наиболее часто используемые: юзабилити-исследования, Eye Tracking (где и как долго пользователь смотрит на различные области экрана), продуктовая аналитика (оценка активности пользователей внутри продукта), A/B-тестирование (сравнивает две версии веб-страницы или функции приложения, чтобы определить, какая работает лучше с точки зрения вовлеченности пользователей, коэффициентов конверсии или других поведенческих показателей).

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

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

Один из способов проверки гипотезы о жизнеспособности продукта – создание MVP. Кажется, что сам термин выбран неверно, поэтому появилось множество статей на тему того, что стоит использовать – MLP (Minimum Loveble Product) или Minimum Viable Process и т. п. Видимо, неоднозначность термина рождает широкий набор интерпретаций. А поскольку нет одной универсальной интерпретации, дискуссии о том, что это такое, не останавливаются.

Существует каноническое определение MVP по Эрику Рису.

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

MVP предназначен не для продажи или получения дохода, а для быстрого обучения. Соответственно, product в этой аббревиатуре – вовсе не конечный пользовательский продукт. Тут все зависит от стадии работы. На этапе проектирования это может быть интерактивный прототип для показа потенциальному клиенту. Многое зависит от ключевых гипотез и уровня достоверности, который нужно получить, ресурсов, которые вы готовы потратить на проверку, скорости получения обратной связи от рынка.

MVP должен в первую очередь сосредоточиться на проверке самых рискованных предположений. Пример, который всегда вдохновляет меня: MVP DropBox Video Explainer. В то время у DropBox не было продукта. Вместо этого они создали простое видео для сообщества первых пользователей, чтобы продемонстрировать, как должно работать решение. В результате их список ожидания бета-тестирования увеличился с 5000 до 75 000 человек за одну ночь.

Еще один вариант MVP – лендинг с описанием ценностного предложения, затем запуск рекламы на небольшой объем целевого рынка и отслеживание конверсии в целевые действия на лендинге, чтобы ответить на вопрос, сколько пользователей можно конвертировать в заявку и оплату. Так когда-то давно поступил Джефф Безос. Он рассказывал, что ключевое рискованное предположение, которое он хотел проверить в самом начале, заключалось в том, сможет ли Amazon конкурировать с книжными магазинами. Вместо того чтобы купить гору книг и арендовать склад, он создал сайт и выставил на нем книги, которых у него не было. Когда клиенты заказывали товар, он покупал книги в магазине и отправлял их по почте.

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

Глава 2. Продуктовый подход в компаниях

ОТ ФУНКЦИОНАЛЬНЫХ КОМАНД К ПРОДУКТОВЫМ

Традиционные компании были сгруппированы в функциональные бункеры: разработчики находятся в одном месте, менеджеры проектов – в другом, продавцы – в третьем. То же касается всех остальных подразделений. Коммуникация и передача данных между каждым бункером требует времени: бизнес-аналитики должны общаться и объяснять требования разработчикам; тем необходимо задокументировать функции для отдела тестирования и получить одобрение системных архитекторов; менеджеры проектов должны опрашивать людей, чтобы обновить статус проекта, и т. д. Когда вы принимаете ежедневные решения о продукте, вся эта координация подразумевает огромные накладные расходы.

ПРИТЧА О СЛОНЕ

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

Первый слепой человек трогает бок слона и говорит: «Слон похож на стену».

Второй слепой чувствует бивень и заявляет: «Нет, слон похож на копье».

Третий слепой, держа хобот, настаивает: «Вы все неправы. Слон похож на змею».

Четвертый слепой трогает ногу и говорит: «Очевидно, что слон похож на дерево».

Пятый слепой, ощупывая ухо, заключает: «Слон похож на веер».

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

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

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

Основные характеристики продуктовых команд следующие.

Долгосрочность и стабильность

Продуктовые команды обычно существуют длительное время, не меняются постоянно по объему и/или составу. Это позволяет им развивать глубокие знания в области технологий, клиентов и отрасли.

Назначение бизнес-проблем и клиентов

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

Мультифункциональность

Команда состоит из специалистов разных областей (разработчики, дизайнеры, маркетологи, менеджеры продукта и т. д.), что обеспечивает комплексный подход к разработке и улучшению продукта. Они тесно сотрудничают, чтобы определить и реализовать наилучшее решение для достижения целей продукта.

Фокус на клиентов и продукт

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

Разработка не передается на аутсорсинг

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

ПРОЦЕСС УПРАВЛЕНИЯ ПРОДУКТОМ

Ни один план не выдерживает первого контакта с клиентами.

Стив Бланк

Работа в продуктовых командах представляет собой процесс, который часто делят на два этапа: исследования (Discovery) и разработка (Delivery). Это так называемый двойной ромб или алмаз. Нередко команды хотят внедрить этап исследований из-за усталости от разработки большого количества функций, которые никому не нужны и не способствуют достижению бизнес-целей. Этот подход фокусируется на изучении рынка, быстром тестировании гипотез, проверке концепций продуктов (как минимум с помощью интервью, создания прототипов и юзабилити-тестов с реальными пользователями). Процесс заранее отфильтровывает менее жизнеспособные решения, позволяя сосредоточиться на наиболее ценных функциях, которые нужны клиентам и бизнесу. А вот процесс разработки концентрируется на воплощении проверенных идей в продуктах.

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

Вы когда-нибудь сталкивались с подобными ситуациями?

• «Да, мы проводим ежеквартальные опросы удовлетворенности клиентов (CSAT) и Net Promoter Score (NPS), но кажется, что на их основе мы не предпринимаем никаких действий».

• «Мы провели замечательное исследование рынка в прошлом году, но не могу вспомнить ни одного стратегического изменения, которое последовало бы за этим».

• «Мы провели детальное исследование конкурентной среды и выявили новые рыночные ниши. Однако отдел продаж продолжает следовать старым стратегиям, так как новое руководство не предоставило четких инструкций по использованию полученных данных».

Что здесь не так? Почему компании тратят ресурсы на качественные исследования, но не используют их результаты?

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

Это лечится, если создать систему, в которой данные исследований приходят тогда, когда они могут быть использованы командой. Тут есть очень хороший вопрос для проверки: «Что бы мы сделали по-другому, основываясь на результатах исследования?»

Удобно представить весь процесс в виде четырех ромбов, как показано на рис. 2.1.

Рис. 2.1. Процесс разработки продукта

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

Разработка продуктовой стратегии

По словам Стива Джобса, люди думают, что сосредоточиться – значит сказать «да» тому, на чем нужно сфокусироваться. Но это совсем не так. Это значит сказать «нет» сотне других хороших идей. Выбирайте тщательно. Гордиться можно и тем, что сделано, и тем, что не сделано. А при внедрении инноваций приходится отказаться от тысячи идей. Во-первых, для любой заданной проблемы довольно легко угадать множество возможных решений. Например, низкое удержание продукта может быть связано с плохим UX, плохим маркетингом, плохими функциями или производительностью и т. д. Поскольку тестирование каждого решения требует времени и усилий, как вы определяете приоритеты? В этом заключается вторая задача. Мы часто выбираем решения, которые поддерживают наши уже сложившиеся взгляды. Разработчики стремятся создавать больше фич, дизайнеры – делать визуально привлекательный интерфейс, а маркетологи – привлекать больше лидов. Это отражает проблему узкой специализации.

Лучший способ – отложить определение приоритетов решений до тех пор, пока вы лучше не поймете основную проблему, не перейдете от поверхностных проблем к первопричинам. Это требует принятия мышления «открытие до эксперимента» и создания продуктовой стратегии.

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

Продуктовая стратегия отвечает на ряд вопросов.

• На каких рынках, в каких сегментах компания будет конкурировать?

• Как компания собирается побеждать в выбранных сегментах рынка?

• Почему клиенты выберут нас?

• Какая бизнес-модель нам необходима для успеха?

Продуктовая стратегия должна задавать направление исследованиям. Когда вы изучаете продукт без стратегического видения (сознательный выбор того, где вы будете играть на рынке и какую ценность можете предложить), вам будет сложно затем определить приоритеты в проблемах и собрать информацию о том, что сильнее всего повлияет на бизнес-результат.

Например, если банк планирует разработать стратегию, чтобы завоевать рынок поколения Z в течение следующих трех лет, продакт-менеджер должен сосредоточить усилия на изучении их уникальных привычек управления финансами. Видение и стратегия создают фокус. Если у команды есть цели (OKR/KPI), она проводит исследования, чтобы выявить ключевые пользовательские или технические проблемы, становящиеся барьерами в достижении этих целей.

Запараллеливание исследований и разработки

Хотя процессы исследований и разработки происходят параллельно, они тесно интегрированы за счет постоянного общения и общих целей, описанных в дорожной карте (подробнее об этом инструменте рассказано в главе 16). Полученная в рамках исследований информация влияет на дорожную карту продукта и приоритизацию бэклога (рис. 2.2).

Рис. 2.2. Параллельные спринты исследований и разработки

Такой подход требует новых компетенций, выделяется роль менеджера продукта (уже не владельца). От него ожидают, что он будет тратить время не только на глубокий анализ требований в пространстве решений и задавать вопросы «Что?», «Когда?», «Как?», но и оспаривать статус-кво для проверки проблемного пространства и ставить вопрос «Почему?».

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

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

Таким образом, исследования обнаруживают то, что создает ценность, а разработка продукта создает то, что приносит ценность.

Для исследований и дизайна требуется время, поэтому исследователи и дизайнеры идут со своими задачами на несколько спринтов впереди разработчиков, чтобы успевать исследовать, проверять и уточнять идеи до того, как они перейдут на стадию разработки. Цель в том, чтобы гарантировать, что команда создает правильный продукт, отвечающий потребностям пользователей и бизнес-целям. Такой подход еще называют Dual Track Agile, он представляет два параллельных потока работы: исследования и разработку.

РОЛИ В ПРОДУКТОВОЙ КОМАНДЕ

Для поддержания процессов открытия и реализации и балансирования ресурсов создаются команды, которые могут относительно автономно выводить продукты на рынок. Это позволяет им быстро выполнять поставленные задачи, а поскольку они трудятся параллельно с другими командами, организация может легко масштабироваться, если хочет увеличить производительность. Полный список ролей продуктовой команды сводится к следующим (адаптируется под потребности конкретной команды).

• Продуктовый менеджер – формирует видение продукта, управляет исследованиями, приоритизирует гипотезы и бэклог.

• Исследователь – проводит качественные и количественные исследования для поддержки стратегических решений.

• Продуктовый аналитик – анализирует данные пользовательского поведения и проводит количественные исследования для принятия обоснованных продуктовых решений.

• UX/UI-дизайнер – создает прототипы и дизайн пользовательского интерфейса для обеспечения удобства использования и визуальной привлекательности.

• Технический руководитель – определяет техническую стратегию, контролирует техническую осуществимость решений и координирует разработку.

• Архитектор ПО – разрабатывает архитектуру системы, устанавливает технические стандарты и руководит архитектурными решениями.

• Менеджер проекта – управляет проектными процессами, планирует работы и обеспечивает командную координацию.

• Бизнес-аналитик / системный аналитик – анализирует бизнес-требования, переводит их на технический язык и помогает выстраивать стратегические направления разработки.

• Разработчик – создает функциональность продукта в соответствии с техническими требованиями.

• QA-инженер – проверяет качество и функциональность продукта, обеспечивает высокий уровень исправности и надежности.

• Технический писатель – разрабатывает техническую документацию и обучающие материалы для пользователей и разработчиков.

• DevOps-специалист – обеспечивает непрерывную интеграцию и доставку продукта (CI/CD, Continuous Integration / Continuous Delivery), автоматизирует процессы развертывания и мониторинга.

• Scrum-мастер и Agile-коуч – поддерживают и сопровождают команду в применении принципов Agile и методологий разработки.

• Специалист по маркетингу продукта – разрабатывает стратегии маркетинга, продвижения и анализа рынка для успешного внедрения продукта.

• Контент-менеджер – управляет контентом продукта, обеспечивает его актуальность и соответствие бизнес-задачам.

• Специалист по поддержке пользователей – обеспечивает качественную поддержку пользователей, помогает в решении проблем и собирает обратную связь для улучшения продукта.

Нетрудно заметить, что количество членов команды увеличивается, а фонд оплаты труда растет процентов на тридцать, не включая дополнительные расходы на обучение, административные издержки и необходимость внедрения дополнительных систем управления. Насколько это оправданно?

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

Запомните, расширение команды – это следствие стратегической необходимости, а не произвольное увеличение численности, потому что «много работы».

ПРЕОДОЛЕНИЕ БЮРОКРАТИИ И КАРГО-КУЛЬТА: РЕАЛЬНЫЕ ШАГИ К ПРОДУКТОВОЙ ТРАНСФОРМАЦИИ

Самая большая опасность в периоды турбулентности – не сама турбулентность, а действие с логикой вчерашнего дня.

Питер Друкер

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

Руководители часто задают вопрос: «Какова рентабельность инвестиций в исследования? Зачем нам это нужно?» Часто руководство ожидает, что сразу появится множество прорывных идей, которые выведут компанию в лидеры рынка по клиентоориентированности и доходам. Однако вероятность появления действительно успешных идей, которые приносят ценность, очень низка. В масштабах всей отрасли, среди самых сильных продуктовых культур, она может достигать 30 % от всех идей. Если ваша компания не обладает лучшей продуктовой культурой, можно установить вероятность успешных идей около 10 %. Это означает, что, даже если команда права в выборе проблемы, которую нужно решить, только одна из десяти идей, скорее всего, сработает, принеся пользу клиентам и бизнесу. Вот почему нужны продуктовые команды, которые умеют проводить регулярные исследования. Одна-две непроверенные идеи вряд ли сработают.

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

Предположим, мы выявили проблему и решение. Дальше необходима реализация серий MVP. Чем больше становится компания, тем активнее в ней развиваются бюрократия и процессы согласований, которые замедляют принятие решений и снижают способность быстро внедрять инновации из-за разного рода рисков: репутационных, юридических, безопасности. Время запуска MVP в стартапе может составлять пару дней, а в корпорации – уже в лучшем случае пару месяцев.

MVP тестируется на реальных пользователях, собирается обратная связь, анализируются результаты. MVP должно быть «точно успешным», от его успеха зависит многое, включая репутацию команды и доверие руководства.

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

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

Если опустить все эти поверхностные признаки, то можно выделить четыре культурные черты, на основе которых строится эффективный продуктовый подход.

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

2. Клиентоориентированность через проведение продуктовых исследований: также через дорожную карту и цели по исследованиям.

3. Принятие решений, ориентированных на данные, через внедрение продуктовой аналитики.

4. Уполномоченные продуктовые команды. Вы можете перейти на продуктовый подход, только если команда и разработка будут полностью сосредоточены на достижении ценности для клиента. В качестве обязательств продуктовая команда будет брать на себя реальные изменения в поведении клиентов, влияющие на выручку и прибыль. Кстати, тут ключевое слово – «команда».

НОВЫЙ ПОДХОД К РАБОТЕ С ФУНКЦИОНАЛЬНЫМИ ТРЕБОВАНИЯМИ

Создание новых функций – очень рискованный способ использования вашего времени: 80 % из них редко или никогда не используются клиентами. Но какова альтернатива? Команды создают новые функции для улучшения таких показателей, как активация, конверсия и удержание. Руководители или другие заинтересованные лица могут настаивать на разработке определенной функции без такой большой исследовательской работы, на какую нацеливаетесь вы.

Подобный подход позволяет изменять мышление команды и вникать в проблему перед поиском и реализацией эффективного решения. Функции продукта существуют для решения проблемы или удовлетворения потребностей пользователя.

Сравните: если ранее владелец продукта полагался на мнение или опыт заинтересованных сторон при реализации функций, потому что это «быстро, важно и нужно», то сейчас он имеет мандат, чтобы инициировать исследования или, по крайней мере, задать вопросы.

1. Кто пользователь? Как бы вы классифицировали эту группу людей? Что их волнует? Каковы их привычки?

2. С какими проблемами они сталкиваются? Чего они хотят добиться? Каковы их болевые точки? Как они думают и ведут себя? Какие у нас есть доказательства, чтобы верить этому?

3. Как эта фича связана с нашей целью?

4. Какие есть доказательства, что эта функция решает проблемы наших пользователей?

5. Какую проблему вы хотите решить с помощью этой фичи?

6. Как они воспримут наше предлагаемое решение? Какова их первая точка соприкосновения с решением? Что происходит у них в голове, когда они принимают решение? Чего они ожидают?

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

8. Если мы ее сделаем, как будем измерять успех?

9. Если мы ее не сделаем, что произойдет?

10. Не могли бы вы показать мне, как [вы пришли к тому, что это надо сделать].

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

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

ПРЕОБРАЗОВАНИЕ ЧЕРЕЗ ЛИДЕРОВ: КАК МЕНЬШИНСТВО ВЛИЯЕТ НА ПРОДУКТОВУЮ ТРАНСФОРМАЦИЮ

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

Нассим Талеб

Как же грамотно реализовать такой подход? Тут можно дать несколько советов.

Часто спрашивают, как внедрить в компании продуктовый подход, описанный в книгах: чтобы с «уполномоченными» продуктовыми командами, OKR, экспериментами… Тут вам будут давать много советов. Трекеры скажут, что нужно взять на трекинг одну из команд и месяца три с ней работать над постановкой гипотез; методологи – что нужно внедрить артефакты-шаблоны, описать процессы коммуникации, провести обучение; аналитики – что надо внедрить принятие решений на основе данных, начать считать юнит-экономику и оценивать эффективность по достижению метрик… Но все они забывают секретный соус.

Секретный соус в том, что, прежде чем заниматься всеми бесспорно полезными вещами, описанными выше, нужно найти лидера. Я недавно вдохновилась книгой Нассима Талеба «Рискуя собственной шкурой» (рекомендую прочитать всем change-командам). Вся она построена на теории меньшинства. Этим упрямым людям достаточно достичь значимого уровня (3–4 % людей в вашей компании), чтобы вся организация изменила свои установки. Более того, это создаст оптическую иллюзию у наивного сотрудника (который смотрит на средние показатели), что установки диктует все-таки большинство. Но есть одно условие: это меньшинство будет нести личную ответственность за принимаемые решения и их последствия. Эти лидеры должны быть готовы рисковать собственной шкурой – ставить на кон свою репутацию и карьеру ради успеха изменений. Выбирайте людей, которые продемонстрировали приверженность делу, имеют опыт влияния на других и готовы нести ответственность за результаты. Они будут двигателем трансформации.

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

Этих лидеров нужно объединить. Создайте команду или команды, которые будут воплощать желаемые изменения. Они должны быть кросс-функциональными и включать представителей различных отделов.

Эта идея действительно приводит к интересной асимметрии: понимание среднего поведения участников рынка не обязательно порождает понимание общего поведения рынка в целом. Если там есть асимметрия (власть меньшинства), то далее «при правильной структуре рынка сборище идиотов образует хорошо функционирующий рынок».

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

Фраза «структура определяет поведение» наиболее известна в связи с работами американского социолога и мыслителя Ричарда Эмерсона. Он был основателем теории социального обмена, и в его трудах часто подчеркивается, что социальная структура влияет на поведение индивидов и групп. Обеспечьте, чтобы организационная структура поддерживала трансформацию.

Убедитесь, что команда понимает и работает в соответствии с продуктовой стратегией.

Стратегия – это не только постановка целей. Часто руководство появляется с бюджетом (а не со стратегическим планом) и без объяснения контекста, стоящего за ним. Сами по себе цели не отвечают на важные вопросы о том, как и почему.

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

Еще одним важным условием становится понимание конкурентного позиционирования. Часто команда бездумно копирует функции конкурентов, забывая об уникальных сильных сторонах и отличительных чертах, которые нужно развивать, чтобы отстроиться от них.

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

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

Финансирование не должно быть препятствием для проверки новых идей. Обычно команда имеет выделенный бюджет для таких целей.

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

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

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

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

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

Обеспечьте регулярную коммуникацию. Постоянно сообщайте о видении, прогрессе и успешных примерах всей организации. Используйте рассказывание историй (сторителлинг) для аргументации изменений. Делитесь историями успеха: о том, как новый подход принес пользу командам и организации. Установите каналы обратной связи, где сотрудники могут высказывать свои опасения и предложения. Используйте ее для постоянных улучшений.

Ну и самое основное.

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

Обеспечьте, чтобы организационная структура поддерживала трансформацию, а не сопротивлялась ей. Структура определяет поведение.

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

Несколько слов о Product Operations

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

• ProductOps очень нужно (книга Product Operations Мелиссы Перри⁶).

• ProductOps – усложнение процессов, команда сама должна организовываться для доставки ценности, не мешайте ей работать и самообучаться на ошибках (книга Transformed Марти Кагана⁷). Отдельное заявление – должность ProductOps Manager (в российских компаниях это что-то вроде продуктового офиса, оптимизирующего процессы), которой сильно переплачивают за приносимую ей ценность (лучше потратьте эти деньги на ведущего продакт-менеджера).

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

Функция управления продуктом в компаниях имеет разный уровень зрелости. Об этом почему-то забывают. Никогда не бывает так, что по щелчку пальцев сразу что-то получается, тем более в масштабе. Когда у вас стартап и тесные связи, вам не нужен ProductOps. Когда у вас 1000 человек, возникают функциональные колодцы, информация застревает в них, и с этим надо что-то делать. Поскольку одному человеку сложно что-то сделать, создается продуктовый офис (ProductOps), у которого есть мандат на изменения, ему проще устранять дисфункции. Основная его задача – это изменение, а не контроль.

ЛИДЕРСТВО В ПЕРИОД ТРАНСФОРМАЦИИ: ОТ КОНТРОЛЯ К СОТРУДНИЧЕСТВУ

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

О чем эта фраза? О том, что корпоративная культура и ценности – это не о людях, а о системе взаимоотношений между ними, которая поддерживается руководством. Поэтому я не верю в то, что «нам нужно нанять продакта обязательно из стартапа с открытой культурой и предпринимательским мышлением». Он должен иметь поддержку со стороны CEO.

Представьте себе такую ситуацию. Начинается встреча, кто-то говорит о проблеме, в ответ – критика. В следующий раз начинается встреча – и вопрос предпочитают замалчивать. Руководство явно не хочет слышать о неурядицах, неудачах и тому подобном. Проблемы обсуждаются в коридорах, но не записываются. Все это – бессознательное, но целенаправленное усилие создать иллюзию, будто все идет по плану. Пока что-нибудь крупное не сломается. И тогда все удивляются: «Почему ты ничего не сказал?» Подобные ситуации способствуют тому, что называется отсутствием предпринимательского мышления: люди не предлагают идеи.

А вот другая типичная ситуация. Начинается встреча, со всех сторон поступают предложения по решению какой-то проблемы, но они так и остаются предложениями, ЛПР (лицо, принимающее решения) всегда выбирает свой путь в виде приоритетного списка функций или проектов, которые, по его мнению, действительно решат какую-то проблему.

Почему так происходит? Да, это может быть предпочтениями конкретного руководителя, но прежде всего это культурный корпоративный феномен, направленный на одержимость координацией и контролем.

Чтобы соответствовать этому требованию предсказуемости результата, планирование заменяет стратегию – руководители осознанно выбирают составление списка выполнимых инициатив, а не работу с гипотезами. Технократия доминирует над предпринимательством. Здесь кроется парадокс, связанный с тем, что планирование работает только до тех пор, пока бизнес-стратегия разумна, есть «разумный лидер», чье видение остается актуальным и стратегически правильным.

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

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

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

В последнее десятилетие возникла целая индустрия коучей, учащих людей лидерству, которая основана на том, что каждый может быть лидером. Правда в том, что быть лидером, особенно во время организационных изменений, дано лишь немногим. Тут требуется особый тип личности. Этот человек должен иметь видение, выходящее за рамки удовлетворения собственных потребностей и интересов. Я наблюдала за достаточным количеством продуктовых трансформаций, чтобы сказать, что изменения не могут произойти без видения. Каждый руководитель высшего звена должен четко и последовательно объяснять «почему», стоящее за изменениями, а также излагать, как выглядит будущее: конечное состояние, его преимущества, требования к бизнесу, заинтересованным сторонам и, если применимо, к продукту. А еще этот человек должен искренне заботиться о своей команде до такой степени, чтобы активно использвать ее мысли и идеи в работе.

Короче говоря, это должен быть человек, обладающий дальновидностью и самоотверженностью.

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

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

Глава 3. Роль продакт-менеджера

УПОЛНОМОЧЕННАЯ ПРОДУКТОВАЯ КОМАНДА

Марти Каган в своей книге «Вдохновленные» определил наделенную полномочиями продуктовую команду как имеющую проблему, которую нужно решить, а не решения, которые нужно создать, и, главное, несущую ответственность за результаты. Не во всех компаниях это можно сделать быстро и легко, однако тренд в эту сторону достаточно явный. Существует концепция, которая показывает отношение между ресурсами, задачами, результатами и воздействием на бизнес для продукта (рис. 3.1), рекомендую подробнее прочитать про нее в книге Outcome Over Output: Why Customer Behavior Is the Key Metric for Business Success Джошуа Сейдена. Она включает следующие параметры.

Рис. 3.1. Схема достижения результатов (на основе Kellogg Foundation Logic Model и книги Outcome Over Output)

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

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

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

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

Таким образом, ценные результаты (outcomes) можно измерить через улучшение показателей ценностного взаимодействия.

Воздействие (Impact) – долгосрочные бизнес-результаты, цели, которых компания желает достичь, обычно в части выручки или числа активных клиентов. Действия продуктовой команды, независимо от намерений, измеряются тем воздействием, которое она оказывает на бизнес.

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

• Какую проблему мы хотим решить?

• Как решение создает ценность для клиентов?

• Как решение создает ценность для бизнеса?

• Откуда мы это знаем? Как мы можем это узнать?

• Как мы можем измерить, что нам удалось создать ценность?

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

ВНУТРЕННИЙ И ВНЕШНИЙ ЛОКУС КОНТРОЛЯ

Роль менеджера по продукту может существенно различаться в разных компаниях. Такие факторы, как размер организации, отрасль, культура и предложение продуктов, способны влиять на конкретные обязанности, ожидания и объем задач менеджера по продукту. Вы можете найти сотни описаний его компетенций. Оглядываясь на свой опыт, опыт коллег и прочитанную литературу на эту тему, могу сказать, что все эти описания объединяет одно: необходимость решать проблемы бизнеса и клиента. Поэтому легче описать не компетенции, а ответственность. Команда сорвала сроки поставки? Это ответственность менеджера по продукту. Клиенты написали жалобу на сайт? Это его ответственность. Выручка ниже запланированной? Снова его ответственность. Что еще случилось? COVID? Санкции? Итак, если вы продакт-менеджер, то каждый день играете в «Ударь крота», пытаясь попасть в нужную цель, в то время как появляется все больше и больше животных.

Вот характерная иллюстрация грамотного подхода к делу. Однажды мусор в офисе Стива Джобса не убрали, и он потребовал объяснений от уборщика. «Замок на двери был заменен, и я нигде не мог получить ключ», – последовал ответ. Джобс счел такое объяснение приемлемым для уборщика. «Если ты уборщик, то тебе позволено оправдываться, – заявил он, – но когда ты занимаешь руководящую должность, то должен воспринимать любые оправдания как ошибку, за которую ты и отвечаешь». Жестко, да? Независимо от того, вписывается ли это в рамки письменной должностной инструкции, менеджер несет ответственность за выполнение всего, что необходимо сделать для обеспечения успеха команды и продукта. И да, это может означать в том числе доступ уборщика к ключу от помещения.

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

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

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

Представьте себе ситуацию. Вы разговариваете с продакт-менеджером Марией:

– Мария, какие прогнозы по продажам на следующий квартал?

– Мы ожидаем рост на 10 %.

– Отлично!

Однако в следующем квартале продажи падают. Вы снова обращаетесь к Марии:

– Ты же говорила, что будет рост на 10 %?!

– Так мне сказали аналитики.

Фразы вроде «так сказали», «так сообщили», «так утверждают» и «нам так рекомендовали» показывают недостаток профессионализма и ответственности. Настоящий менеджер должен самостоятельно проверять данные и нести ответственность за свои решения.

Теперь представим альтернативный сценарий.

Вы снова спрашиваете у Марии:

– Мария, какие прогнозы по продажам на следующий квартал?

– Мы ожидаем рост на 10 %. Я лично проверила данные, проанализировала рынок и учла все возможные риски.

– Отлично!

Если в следующем квартале продажи все-таки падают, Мария говорит:

– Я вижу, что наши продажи снизились. Проанализировав ситуацию, я обнаружила несколько факторов, которые не были учтены. Сейчас мы принимаем меры, чтобы исправить положение и вернуть положительную динамику. Вот эти меры…

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

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

Мы приходим к интересному выводу: управление продуктом, по сути, представляет собой управление ожиданиями. Приведу пример. Команда по не зависящим от нее причинам задержала доставку на несколько дней, но продакт-менеджер не предупредил об этом заказчика. И дело не в том, что произошел срыв сроков, а в том, что продакт-менеджер что-то пообещал, а затем, когда настало время доставки, стал оправдываться, сказав: «Это не моя вина» – вместо того, чтобы проявить инициативу. Не важно, есть ли тут его вина. Проблема связана с временем, которое было в его власти. Оправдание «собака съела мою домашнюю работу» не помогает. Когда менеджеры ставят людей в затруднительное положение, они теряют доверие, поскольку не выполняют обещания.

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

МЫШЛЕНИЕ РОСТА И ОТНОШЕНИЕ К ОШИБКАМ

Вспомните, когда вы последний раз совершали ошибку… В работе, в жизни, в отношениях…

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

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

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

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

Кэрол Дуэк в своей книге «Гибкое сознание»⁹ так описывает различия между фиксированным мышлением и мышлением роста (табл. 3.1).

Таблица 3.1. Фиксированное мышление и мышление роста

Никому не нравится совершать ошибки. Это ранит эго и заставляет чувствовать, что все предыдущие усилия были напрасны. Кроме того, вы можете быть обеспокоены тем, что люди думают, будто вы хуже, чем есть на самом деле. Однако вместо того, чтобы расстраиваться, задайте себе вопрос: «Что я могу извлечь из этой ошибки?» Используйте ее как шанс улучшить свои знания и навыки, например пройти обучение.

ОТЛИЧИЯ МЕНЕДЖЕРА ПРОДУКТА ОТ ВЛАДЕЛЬЦА ПРОДУКТА И МЕНЕДЖЕРА ПРОЕКТОВ

Подведем итоги. После внедрения Agile в компаниях появилась роль владельца продукта, который часто отвечает за планирование спринтов и приоритизацию бэклога в соответствии с требованиями бизнеса. Основная проблема в том, что такие команды сосредоточены на поставке фич, а не бизнес-результате. Это приводит к созданию так называемой фабрики функций: ответственность заключается не в том, чтобы максимизировать ценность, а в том, чтобы влиятельные заинтересованные стороны реализовали свои пожелания в предстоящих спринтах.

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

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

Отдельно нужно сказать, в чем отличие продакт-менеджера от проджект-менеджера и бизнес-аналитика.

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

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

Ниже в таблице 3.2 я привела ключевые различия этих ролей.

Таблица 3.2. Роли в компании

В заключение я хочу привести цитату из статьи Джеффа Готхельфа «Мы все теперь менеджеры по продукту»¹⁰: «Если вы работаете в любой должности, стремящейся понять рынок, обнаружить пробелы и возможности, определить видение продукта и руководить процессом воплощения этого видения в жизнь убедительно для ваших клиентов, вы – менеджер по продукту. Конкретные обязанности будут различаться в зависимости от компании и отрасли. Ваш уровень технических знаний, знаний предметной области и понимания клиентов также будет зависеть от специфики вашего контекста. Вы будете выполнять работу, которую когда-то освещали бизнес-аналитики. Вы, несомненно, будете делать то, что должны были делать владельцы продукта. И, несмотря на его гибкость и мягкость, вы также будете выполнять работу по управлению продуктом. Нам нужно имя для всего этого. Это имя – менеджер по продукту».

Часть II. Управление продуктом с точки зрения создания ценности для клиентов и бизнеса

Глава 4. Бизнес-модель

ПРОДУКТОВОЕ МЫШЛЕНИЕ: ВЗГЛЯД СКВОЗЬ ПРИЗМУ СИСТЕМНОГО ПОДХОДА

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

Продуктовое мышление – это системное мышление о продукте. Чтобы понять, что это, необходимо представить концепцию шире, чем просто решение проблем клиентов. Продукт – система, которая включает элементы, взаимосвязи между ними и цель.

Самое простое, что можно выделить в системе, – ее элементы. Каждый из них, вероятно, можно разделить на еще большее количество элементов. Взаимосвязи обычно определить сложнее: для их выявления необходимо понять причину и следствие. В основе управления продуктом как системой лежит изучение взаимодействий и отношений между различными элементами, а не их изолированный анализ.

Очень часто у нас есть представление об одном или двух элементах системы без глубокого понимания взаимозависимостей. Поэтому многие команды страдают от отсутствия середины в причинно-следственных связях. Обычно это проявляется в том, что они переходят от очень высокоуровневых бизнес-целей (impact) сразу к функциям продукта (output).

Мне нравится аналогия с айсбергом, которую использовал Дэниел Ким¹¹. Как правило, только 10 % объема ледяной глыбы находится над водой, поэтому большую ее часть невозможно увидеть. Кроме того, о форме подводной части трудно судить, глядя на то, что находится над поверхностью. Эти два наблюдения составляют основу для бытового выражения «верхушка айсберга»: то, что вы можете видеть, – лишь небольшой фрагмент всей ситуации (рис. 4.1).

Рис. 4.1. Айсберг системного мышления

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

Большинство людей рассматривают мир как серию событий. Например, клиент пожаловался на то, что ему пришло некорректное уведомление в приложении, конверсия в целевое действие упала на 0,5 %, произошел сбой в инфраструктуре, прилетел запрос от руководителя и т. д. Когда мы рассматриваем проблемы на этом уровне, наши решения, как правило, реактивные или тактические: ответить на жалобу клиента, пофиксить баг и т. д. Это тактический образ мышления. На таком уровне обычно работают младшие специалисты. Обычно проблема уже четко определена и решение согласовано, а они должны реализовать его через набор задач. Главное, чему стоит учить людей на этом уровне, – задавать вопрос «Почему?». Руководителю важно убедиться, что сотрудники понимают контекст работы, почему было принято такое решение, а также то, что такое хорошее исполнение, через контрольные показатели.

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

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

Например, представьте, что вы разрабатываете цифровой продукт для автоматизации процессов малого бизнеса. На уровне паттернов вы понимаете, что, когда пользователи подключаются к продукту, они обычно имеют в виду конкретный вариант использования (далее мы будем говорить про конкретную работу, на которую они хотят «нанять» продукт). Вы считаете, что если сделаете персонализированные шаблоны и приведете примеры в процессе онбординга (причина), то это поможет большему количеству пользователей начать применять продукт (следствие). На этом уровне появляются гипотезы, которые влияют на метрики; в нашем примере это метрики активации пользователей. Уже лучше, чем мыслить событиями, однако эта гипотеза может быть лишь локальной оптимизацией в пределах сферы влияния продуктовой команды (в процессе онбординга).

Существуют разные способы определения лучшего решения. «Лучше» может означать более быстрое создание, более дешевую интеграцию, более ценную для бизнеса в долгосрочной перспективе или более эффективную в решении краткосрочных проблем. Для руководителей высшего звена крайне важно понимать стратегическую значимость проблемы. Например, команда может поставить цель: увеличить удержание на X %. Остается выяснить, как лучше этого добиться: команде нужно сделать предположение о том, над чем работать. Тут начинающие менеджеры продуктов часто испытывают трудности из-за высокого уровня неопределенности: неясны и проблема, и решение. Это прекрасная возможность сделать шаг назад и увидеть более широкую картину в виде структуры.

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

Вот вопрос, который Джефф Безос часто задавал своим сотрудникам: «Что изменится в ближайшие десять лет?» Затем он продолжал: «Я утверждаю: лучше задать вопрос “Что не изменится?”, потому что вы можете построить бизнес-стратегию на основе параметров, которые стабильны во времени. Например, в ретейле мы знаем, что покупатели хотят низких цен, и это не изменится спустя десять лет. Они хотят быструю доставку, широкий выбор. Невозможно представить будущее через десять лет, в котором покупатель приходит ко мне и говорит: “Джефф, я люблю Amazon, но мне хотелось бы, чтобы цены были чуть-чуть повыше или доставка чуть-чуть помедленнее”. Это невозможно. Поэтому мы точно знаем, что все усилия, которые мы прилагаем к решению задач наших покупателей, будут приносить нам дивиденды даже десять лет спустя. Когда вы находите то, что остается неизменным в долгосрочной перспективе, то можете смело позволить себе вложить туда много сил».

Итак, Безос определил условия, которые никогда не изменятся: низкие цены, широкий выбор, быстрая доставка. Они синергичны: низкие цены увеличивают количество клиентов (покупок), что привлекает больше продавцов, что увеличивает объем товаров, что приводит к более высокому валовому доходу. Это означает, что Amazon может и дальше снижать цены. Именно такая динамика постоянного роста прибыльности и последующего инвестирования в снижение цен стала основой знаменитой фразы Безоса: «Ваша маржа – это моя возможность». Безос имеет в виду, что, если другие компании зарабатывают высокую маржу на своих продуктах, Amazon может предложить эти же продукты по более низким ценам, получая меньшую маржу, но за счет больших объемов продаж компенсируя это снижение. Это структура бизнеса Amazon, которая может быть описана в виде бизнес-модели и долгосрочной стратегии.

Следующим уровнем оказываются ментальные модели – то, что заставляет структуру быть такой, какая она есть. Это мысли и убеждения, существующие в головах людей, которые создали структуру, и тех, кто играет роль в ее функционировании. Все, что составляет ментальную модель, трудно идентифицировать. Некоторые из элементов – установки, убеждения, мораль, этика, ожидания, ценности. Обычно – но не всегда! – они описаны в миссии и ценностях (если миссия и ценности – не просто лозунги).

Возьмем, например, компанию OpenAI. Она занимается исследованиями и внедрением искусственного интеллекта. Ее миссия – обеспечить, чтобы общий искусственный интеллект приносил пользу всему человечеству. Это ценности, которые пропитывают продуктовые решения, например бесплатное использование, и оргструктуру компании. Эта миссия отражена в стратегии OpenAI: например, подробно описывается акцент на долгосрочной безопасности.

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

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

Нетрудно заметить, что решения проблем, возникающих на более низком уровне, как правило:

• более инновационны, ведь тактические решения, найденные на уровне событий, заменяются долгосрочными стратегическими на уровне структуры;

• сложнее для внедрения, ведь на каждом более низком уровне будет затронуто больше людей, и причины, стоящие за изменениями, будут менее понятны;

• больше воздействуют на бизнес-результат в течение более длительных периодов.

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

ВАЖНОСТЬ ПОНИМАНИЯ ПРИЧИННО-СЛЕДСТВЕННЫХ СВЯЗЕЙ

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

Первый важный принцип – начать мыслить не решениями, а проблемами, и главное для менеджера – сформировать собственное аргументированное мнение о проблеме и лучшем ее решении, которое принесет ценность для клиента и бизнеса.

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

В 1970-х Амос Тверски и Даниэль Канеман начали выявлять специфические, систематические когнитивные искажения, которые заставляют человека отклоняться от рациональности. Они выявили конкретные ограничения или предубеждения, связанные с человеческим суждением и принятием решений. В частности, люди полагаются на ряд упрощающих стратегий, известных как эвристики – эмпирические правила при принятии решений. Например, мы основываем наши суждения и решения на собственном прошлом опыте, стереотипах, степени, в которой информация поддерживает наши предыдущие выводы, и т. п. Эту идею Канеман описал в своей книге¹²: есть система 1 (интуиция) и система 2 (логика).

Когнитивные искажения – систематические ошибки человеческого мышления и принятия решений. Они становятся результатом основных процессов, которые мы разработали на протяжении нашей эволюционной истории. К сожалению, мы приспособились к среде, которая во многом отличается от современного мира. Это может вести к привычке принимать неверные решения. Когнитивные искажения предсказуемы и широко распространены. Мы становимся их жертвами, хотя считаем себя рациональными и объективными мыслителями. Никто от такой ситуации не застрахован.

Вот несколько примеров когнитивных искажений:

• эффект новизны: тенденция выбирать вариант, представленный совсем недавно, потому что он свеж в памяти;

• предвзятость бритвы Оккама: тенденция считать наиболее очевидное решение лучшим;

• когнитивная инерция: тенденция выбирать варианты, которые позволяют думать, чувствовать и действовать знакомыми способами;

• групповое мышление: тенденция сходиться к общему мнению в группе, социальное давление, которое часто останавливает содержательные споры;

• предвзятость априорной гипотезы: тенденция менеджеров формировать сильные убеждения о связях между различными факторами и продолжать им следовать, даже если факты указывают на то, что эти убеждения ошибочны;

• эскалация приверженности: менеджеры, уже инвестировавшие значительные ресурсы в провальный проект, продолжают вкладывать усилия и ресурсы для его завершения;

• репрезентативность: менеджеры неправильно обобщают решение по небольшой выборке или даже единичному эпизоду;

• иллюзия контроля: чрезмерная уверенность менеджеров в своей способности успешно выполнить задачу, переоценка своих возможностей влиять на действия и события.

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

Я уверена: залог успеха роста начинающего специалиста – попытки разобраться, что есть что. Я и сама часто что-то изучала просто из любопытства и не могла успокоиться, пока не видела всю картинку в целом. Я помню, что в начале своей карьеры, когда я работала бизнес-аналитиком, мне нужно было подготовиться к kick-off-встрече – это стартовое совещание, целью которого становится введение команды в курс дела, определение задач, ролей и ожиданий, а также согласование планов и подходов к выполнению проекта. Поскольку это была новая для меня предметная область, предварительно я постаралась составить список основных вопросов, диаграмму процесса, описать потенциальные проблемы, которые могут возникнуть в ходе разработки нового функционала. Я прочитала всю документацию, которая касалась этого процесса. Почему это важно? Во-первых, вам нужно завоевать доверие; для этого надо стремиться становиться экспертом предметной области (Subject Matter Expert), обладать глубокими знаниями в зоне ответственности. Во-вторых, нужно выявлять проблемы на стыках зон ответственности стейкхолдеров, потому что чаще всего они именно там – в «ничейных» серых зонах. В-третьих, нужно учиться самим предлагать жизнеспособные решения, а не просто выступать фасилитатором встреч. Все вышеперечисленное можно отнести и к задачам внутреннего продакт-менеджера, который управляет продуктами, ориентированными на нужды сотрудников компании. Также это становится основой для развития критического мышления.

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

Дело в том, что обычно заказчики не приходят с проблемами. Они приходят с решениями – своими идеями или даже системными требованиями и вопросом: «Когда это будет реализовано?» Все это может сопровождаться эмоциями, повышением тона, уговорами и даже угрозами пожаловаться руководству.

5 ПОЧЕМУ

Метод «5 почему» – это простой, но мощный инструмент анализа проблем, который помогает идентифицировать корневую причину проблемы, задавая последовательно пять вопросов «Почему?». Он был разработан как часть системы управления качеством Toyota в конце 1940-х и стал одним из ключевых элементов методологии Lean Manufacturing для оптимизации бизнес-процессов.

Как использовать метод «5 почему»?

Идентифицируйте проблему. Начните с ясного определения проблемы или недостатка, с которым вы сталкиваетесь в вашей организации или процессе.

Задайте первый вопрос «Почему?». Спросите себя или вашу команду, почему проблема возникла. Будьте конкретными и держите фокус на фактической причине, а не на ее симптомах.

Повторите процесс несколько раз. После того как вы получите ответ на первый вопрос, задайте еще один вопрос «Почему?» к полученному ответу. Повторяйте этот процесс еще четыре раза, задавая вопрос «Почему?» к каждому новому ответу.

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

Разработайте план действий. Когда вы определили корневую причину, разработайте и выполните план действий для решения проблемы и предотвращения ее повторения.

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

В ответ многие менеджеры скажут: «Да, давайте сделаем эту выписку!» Часто у владельцев продуктов нет достаточных аргументов, чтобы сказать «нет» и противостоять напору заказчика. Получив согласие, заказчик захочет сделать свою фичу как можно быстрее и опять использовать для убеждения все приемы, описанные выше. А если всем все время говорить «да», в какой-то момент бэклог раздуется, а ресурсов ИТ не будет. Обещания, которые не выполняются, приводят к тому, что ценность менеджера падает. За это придется отвечать своей репутацией.

Последовательное выстраивание цепочки из вопросов «Почему?» помогает понять, как принимает решения заказчик.

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

– Почему клиентам нужно смотреть все свои финансовые потоки в одной выписке и агрегировать в ней все счета?

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

– Почему они не могут посмотреть выписку по каждому счету в отдельности?

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

– Почему они не могут узнать эту информацию в интернет-банке?

– У них несколько кредитов висит на одном счете, поэтому возникает путаница, сколько денег нужно внести, чтобы не случилась просрочка.

Итак, мы подошли к формулировке проблемы: «Люди не понимают, сколько и почему им надо заплатить». На этом не стоит останавливаться.

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

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

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

Итак, допустим, в месяц поступает в среднем 400 подобных звонков от 380 уникальных клиентов. Среднее время разговора операторов контактного центра составило 5 минут. Среднее время ожидания для клиента на линии – 10 минут. Таким образом, служба поддержки в среднем тратит 400 × 5 = 2000 минут в месяц на эти запросы, а дозвонившийся клиент в среднем тратит (5 + 10) × 1,05 = 16 минут на решение своего запроса.

А сейчас внимание! В этом примере звонки – симптом проблемы, мы только что количественно оценили ее проявление. Чтобы найти оптимальное решение, в первую очередь нужно понять, кто эти люди и почему они ведут себя так, а не иначе. Опытные наблюдатели заметят, что в расчете выше мы не учитывали звонки, сброшенные клиентами до того, как им удалось соединиться с оператором, а также оценку количества клиентов, которые имеют проблему, но не обращаются в службу поддержки.

Итак, собираем информацию от сотрудников колл-центра и понимаем, что звонят не все клиенты банка с кредитными продуктами, а только те, у кого больше одного кредитного продукта; при этом списания ежемесячных платежей по ним происходят с одного расчетного счета. Клиенты не понимают, какой минимальный остаток нужно на нем держать, чтобы не было просрочки. Таких клиентов оказывается 150 000, однако с учетом плана продаж планируется прирост этого сегмента на 30 % до конца года. Это потенциальное количество клиентов, которые могут столкнуться с проблемой.

Мы до сих пор не знаем, стоит ли решать эту проблему через электронную выписку или каким-то другим способом. Однако это гипотеза о решении от вашего заказчика, мы не можем ее проигнорировать. А вдруг он знает то, чего не знаем мы?

Как клиенты из этого сегмента получают информацию о задолженности? Что вообще вы о них знаете, кроме того, что они звонят в поддержку с таким вопросом? Логично было бы сначала «надеть шляпу клиента» и посмотреть, что происходит в его опыте на этапе управления задолженностью, есть ли там логические несостыковки, которые обычно называют барьерами. Полезным подходом может быть построение карты текущего клиентского пути для этого сегмента, чтобы понять, какие шаги ему необходимо сделать, чтобы узнать свою задолженность. У клиента существуют разные способы закрытия этой потребности, звонок в кол-центр – всего лишь один из способов.

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

• Расскажите мне, что вы сейчас хотите сделать?

• Что самое сложное в вашем опыте?

• Почему это сложно?

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

Мы видим, что любая проблема должна быть оценена через влияние на жизнь клиента и бизнеса. Если в компании нет доступа к клиентам, низка зрелость аналитических инструментов, нужных данных получить не удастся. Приходится полагаться только на «чуйку» или экспертизу коллег.

ПРОДУКТ КАК СИСТЕМА. МОДЕЛИРОВАНИЕ И БИЗНЕС-ЛОГИКА

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

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

Обычные люди разговаривают о продуктах, используя слова «мне нравится», «мне не нравится… фича, реклама, цена». Продукт может быть осязаемым, как в случае с физическими товарами, или неосязаемым, как в случае с услугами. Продуктом также может стать программное обеспечение.

Люди с продуктовым мышлением говорят о продукте с точки зрения бизнес-модели, ее компонентов и их взаимосвязей. Менеджер должен понимать, как продукт создает ценность и зарабатывает деньги для компании. Бизнес-модель – это то, как продукт создает, обеспечивает и монетизирует ценность. Это определение Александра Остервальдера, одного из создателей Business Model Canvas (канвы бизнес-модели, рис. 4.2).

Рис. 4.2. Business Model Canvas

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

Очень часто компания определяет продукт слишком общим образом: «мы занимаемся страховым бизнесом» или «мы занимаемся бизнесом такси», или по какой-то другой внутренней характеристике: «мы онлайн-маркетплейс» или «мы занимаемся сдачей вещей в аренду». Так она загоняет себя в ловушку. Эти определения настолько универсальны, что могут относиться практически к любой организации!

Часто бизнес-модель могут называть по модели привлечения (Freemium), монетизации (подписка), типу продукта (маркетплейс) и модели доставки (цифровой продукт). Но это только ее элементы. Идея же в том, что она представляет целостное описание продукта как системы, которое помогает ответить на вопрос, что мы создаем.

Александр Остервальдер описывал бизнес-модель через следующие элементы.

1. Сегменты клиентов. Кто такие клиенты? Что они думают? Чего хотят? Важно: у вас односторонний или многосторонний рынок? Если многосторонний, у вас будет минимум столько же сегментов, сколько сторон.

2. Ценностные предложения. Что привлекательно в предложении? Почему покупатели приобретают, используют ваш продукт? Какую работу вы выполняете для клиента? Какую потребность удовлетворяете? Убедитесь, что вы можете определить существующую потребность/проблему и конкретные альтернативы, которые ваш клиент использует сегодня. Если вы не уверены в своей правоте, выйдите и понаблюдайте, поговорите с некоторыми клиентами.

3. Каналы. Как эти предложения продвигаются, продаются и доставляются? Почему?

4. Отношения с клиентами. Как вы взаимодействуете с клиентом на его пути? Примеры: персональная помощь, специальная персональная помощь, самообслуживание, автоматические услуги, сообщества, совместное творчество.

5. Потоки доходов. Как бизнес получает доход от ценностных предложений?

6. Структура затрат. Каковы основные факторы затрат бизнеса? Как они связаны с доходом?

7. Основные направления деятельности. Какие уникальные стратегические действия предпринимает компания для реализации своего предложения? Например: производство, решение проблем, платформа / сеть.

8. Ключевые ресурсы. Какие уникальные стратегические активы должен иметь бизнес, чтобы конкурировать успешно?

9. Ключевые партнерства. Что компания не может сделать самостоятельно, чтобы сосредоточиться на своей ключевой деятельности?

Сам Остервальдер очень любит приводить пример Nespresso. Это компания, полностью принадлежащая Nestlé. Примечательно в их бизнес-модели то, что они смогли трансформировать традиционную транзакционную бизнес-модель и заменить ее той, которая генерирует регулярные доходы. Nespresso продает фирменные капсулы кофе по прямым каналам, а не через розничных дистрибьюторов.

Этот тип бизнес-модели называется Razor and blades («Бритвы и лезвия»): стратегия, основанная на продаже того, что должно быть основным продуктом, по низкой цене или раздаче бесплатно; при этом дополнительные товары продаются с высокой наценкой. Называется она так, потому что ее применила компания Gillette, бритвы которой стоили несколько долларов. А вот набор лезвий обходится в 3–4 раза дороже, и их нужно покупать регулярно. Например, Amazon применила эту стратегию для своего Kindle: устройство реализуется по довольно низкой цене, чтобы зарабатывать деньги на электронных книгах. Эта стратегия направлена на создание длительных и стабильных потоков доходов за счет регулярных покупок дополнительных товаров или услуг.

Все элементы бизнес-модели должны соответствовать друг другу. Представим, что Nespresso решила продавать свои кофемашины и капсулы через обычные розничные магазины, а не по прямым каналам. Ценностное предложение (высококачественный кофе и эксклюзивность) стало бы менее привлекательным, так как клиенты могли бы покупать капсулы где угодно, снижая контроль компании над качеством и клиентским опытом. Компания потеряла бы часть прибыли, так как розничные дистрибьюторы взяли бы на себя часть маржи. Это могло бы привести к утрате лояльности клиентов и снижению доходов.

Давайте рассмотрим пример компании «Связной». «Связной» был успешным в первую очередь в 2000-х и начале 2010-х годов. Успех компании был обусловлен несколькими ключевыми факторами бизнес-модели. «Связной» создал одну из крупнейших сетей розничных магазинов по продаже мобильных телефонов и аксессуаров в России. В пиковые годы сеть насчитывала более 2600 магазинов в 1100 городах. Компания активно вкладывалась в маркетинг и рекламу, что позволило ей стать узнаваемым брендом и привлечь большое количество клиентов. «Связной» сотрудничал с ведущими производителями мобильных телефонов и электроники, что позволило предлагать широкий ассортимент товаров и получать выгодные условия по закупкам. Компания расширила свой бизнес, включив в него финансовые услуги, такие как потребительское кредитование, страхование и платежные услуги. Это помогло привлечь дополнительный поток клиентов и увеличить доходы.

Что пошло не так? В 2022 году многие крупные международные бренды ушли с российского рынка, что лишило «Связной» значительных маркетинговых бюджетов, которые поддерживали его бизнес. Операторы мобильной связи начали развивать собственные монобрендовые сети, что привело к уменьшению доходов независимых ретейлеров, таких как «Связной». Сама по себе продажа мобильных телефонов и аксессуаров стала менее прибыльной. Конкуренция усилилась, и маржа от продаж сократилась. Компания не смогла компенсировать снижение прибыли за счет других источников дохода. Несмотря на оптимизацию убыточных магазинов в 2020–2021 годах, компания не смогла достичь устойчивой прибыльности из-за высокого уровня долгов.

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

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

После ухода «Связного» с рынка его нишу заняли несколько компаний, обладающих более устойчивыми бизнес-моделями.

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

Несмотря на популярность шаблона Остервальдера, я никогда не видела, чтобы в компаниях его заполняли в исходном виде. Ведь основная идея шаблона – не только описать части, но и показать логику их взаимодействия, а это можно сделать и другими способами.

Давайте разберем пример цифрового продукта.

ПРИМЕР DROPBOX

Dropbox была пионером в рыночной категории облачного хранения файлов. Основные функции продукта: хранение, обмен и защита данных от внезапной потери (например, сбоя оборудования). Компания в далеком 2005 году уловила тренд будущего использования людьми множества устройств для работы с файлами и необходимости легкого доступа к ним.

Интересно, что Стив Джобс как-то назвал Dropbox функцией, а не продуктом. Подумайте, почему?

Для Стива Джобса и Apple облачное хранение – функция, которая может быть реализована для множества продуктов (например, iTunes). А для Dropbox это единственное, что компания может предложить, поэтому оно позиционируется как продукт.

В бизнес-модели выделяются три уровня анализа: востребованность клиентами, жизнеспособность для бизнеса и осуществимость для компании.

Уровень востребованности (ценности для клиента). Что нужно рынку (сегменту) и какие потребности мы сможем закрыть? Какими должны быть успешный клиентский опыт и функциональное решение?

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

Всегда начинайте с предположений о востребованности: если вы ошибетесь, уже будет не важно, сможете ли вы это построить или принесет ли это деньги.

Слишком многие корпоративные новаторы тратят огромное количество времени в Excel, планируя сложную бизнес-модель прибылей и убытков, демонстрируя, сколько денег принесет новая инициатива. Вот секрет: вы можете заставить Excel делать практически все, что захотите, – по крайней мере, с числами. Общий доход за пять лет слишком мал? Просто измените долю рынка с 1 на 2 %! «Знаем ли мы, есть ли у людей такая проблема? Действительно ли мы знаем, будут ли они платить X руб. в месяц? Знаем ли мы, что должен включать в себя MVP?» – вот более правильные начальные вопросы.

Уровень жизнеспособности. Как мы создаем на рынке конкурентное преимущество и зарабатываем деньги через связь ценностного предложения, модели монетизации и каналов продаж? После понимания решения нужно определить, сможет ли команда привлечь достаточно людей и будут ли они платить.

90 % пользователей Dropbox были привлечены через реферальные программы. Сначала их вознаграждали дополнительным свободным пространством не только за привлечение друга, но и за принятие приглашения. Обе стороны получали по 500 МБ памяти. Поскольку всем, вероятно, нужно больше места для хранения, пользователи привлекали столько людей, сколько могли, и, как только приглашенные регистрировались, делали то же самое.

К тому же Dropbox использует стратегию, которую можно охарактеризовать как Land and expand: привлечь клиента на персональный тарифный план, а затем продать продукт организации, чтобы расширить свое присутствие за счет большего количества рабочих мест или функций. Оба эти свойства – элементы бизнес-модели, связанные с каналами привлечения и отношениями с клиентами, и именно они сыграли такую колоссальную роль в росте продукта. Также Dropbox начала использовать Freemium-стратегию привлечения и активации клиентов одной из первых на рынке. Таким образом, нужно было изменить поведение пользователей таким образом, чтобы они загружали файлы, делились файлами и папками с другими, конвертировались с бесплатной на платную версию продукта.

Уровень осуществимости. Есть ли у компании технологии, процессы и ресурсы для реализации ценностного предложения? Дело не в рынке или пользователе, а в вас самих. Корпорация Theranos (канувшая в лету в 2018 году) утверждала, что ее технология позволяет проводить обширные тесты с помощью одной капли крови. С ее технологией это было научно невозможно. Руководители организации проигнорировали технико-экономический риск и поплатились за это.

Уровень востребованности, осуществимости и жизнеспособности в бизнес-модели по Остервальдеру относится к ключевым аспектам, которые помогают оценить потенциал и успех бизнес-модели или наличия соответствия продукта рынку (рис. 4.3).

Рис. 4.3. Что такое успешный продукт

1. Уровень востребованности (Desirability).

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

Понимание клиента: насколько глубоко бизнес понимает потребности, боли и желания своей целевой аудитории?

Продукт/услуга: насколько привлекательно и полезно предложенное решение для клиентов?

Тестирование рынка: проведены ли исследования рынка или тестирования продукта для подтверждения его востребованности?

Давайте рассмотрим пример с интернет-аукционом «Молоток.ру», который прекратил свою работу в 2015 году. Закрытие обусловлено несколькими ключевыми факторами. Во-первых, формат интернет-аукциона оказался невостребованным в России. В отличие от рынков США и Китая, где аукционы, такие как eBay и Alibaba, успешно развиваются, российские пользователи не привыкли к торгам в интернете. Менталитет российского потребителя не располагает к активному участию в аукционах, что и стало основной проблемой «Молоток.ру». Финансовые показатели проекта резко ухудшились. В 2014 году выручка составила всего 12 млн руб., что в 250 раз меньше, чем в 2012 году. Такое падение доходов стало критическим фактором для принятия решения о закрытии. Успешные конкуренты также захватили рынок. Naspers, владеющий «Молоток.ру», инвестировал в Avito, который приносит значительно большую прибыль. В 2014 году выручка Avito превысила 4 млрд руб. Пользователи предпочитают простую покупку и продажу товаров без необходимости участия в аукционах, что сделало Avito более востребованным. Это пример реализации риска невостребованности: недостаточный объем целевого сегмента при наличии сильного конкурента.

2. Уровень осуществимости (Feasibility).

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

Ресурсы: есть ли у компании доступ к необходимым финансовым, человеческим и материальным ресурсам?

Технологии: доступны ли и подходят ли технологии для реализации продукта или услуги?

Процессы и операции: насколько хорошо организованы внутренние процессы и операции для выполнения задач?

3. Уровень жизнеспособности (Viability).

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

Финансовая модель: насколько эффективна финансовая модель, способна ли она приносить прибыль?

Ценностное предложение: является ли ценностное предложение уникальным и конкурентоспособным на рынке?

Рыночная позиция: какова позиция компании на рынке и насколько она устойчива к конкуренции?

Ключевые рискованные предположения о бизнес-модели

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

Прежде чем углубиться в этот вопрос, основателям необходимо понять образ мышления инвесторов. Как они воспринимают и оценивают предложения?

Все ключевые предположения можно разделить на три категории: о востребованности продукта, жизнеспособности бизнес-модели и осуществимости концепции продукта. Самое первое предположение относится к востребованности. Почему? Потому что в современную эпоху мы живем в состоянии изобилия предложений, и часто предприниматели должны найти потребительский спрос, прежде чем создавать новое. Если в классической школе можно было встретить высказывание «предложение порождает спрос», то сейчас скорее спрос порождает предложение. Лучше всего это отражено в серии статей Алекса Данко о понимании изобилия. Изобилие – это состояние, при котором усилие, связанное с принятием решений о потреблении, приближается к нулю. Изобилие – противоположность дефициту. Понятно, что здесь идет речь о потребительских товарах массового спроса, а не о лекарстве от неизлечимых болезней.

Как вы думаете, откуда возникает спрос? Ответ прост: от проблемы, ожидающей решения! Именно поэтому ключевое рискованное предположение звучит так: людей/компании сильно волнует проблема, которую вы решаете.

Если вы внимательно посмотрите на любой долгосрочный бизнес, вы поймете, что он возник из решения каких-то фундаментальных потребностей, которые не удовлетворяются. Часто цитируемая фраза Ури Левина, основателя Waze: «Влюбляйтесь в проблему, а не в решение». Однако не все проблемы стоят того, чтобы их решать.

Итак, как определить проблему и понять, действительно ли ее стоит решать? Первый шаг – изучить рынок, частью которого вы хотите стать. Размер возможности зависит от того, сколько людей ее испытывают и сколько они тратят на ее решение прямо сейчас.

Стартап редко сталкивается с реальной проблемой, которую люди в данный момент никак не решают. Для инвесторов, когда вы произносите фразу: «Люди в настоящее время не решают эту проблему, потому что решения нет», – огромный красный флаг. Если люди не испытывают достаточно боли, чтобы решить проблему, зачем им начинать решать ее сейчас?

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

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

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

Хитрость заключается в том, чтобы найти глубокую проблему клиента на рынке, который достаточно велик, чтобы создать на нем жизнеспособный бизнес. Это второе рискованное предположение.

Третий критерий – проблема должна быть решаема. Создавая продукт, множество основателей начинают с решения, а затем переходят к проблеме. Например, увлекаются конкретной технологией, такой как блокчейн или искусственный интеллект, и думают, что хотят что-то создать; но вопрос в том, какую проблему они решают.

Возьмем Airbnb в качестве примера. Основатели выявили проблему, когда начали сдавать комнаты в аренду, чтобы подзаработать. Затем они создали платформу, которая поможет еще большему количеству людей получить дополнительный доход, – решение. Они обнаружили Problem Solution Fit (соответствие проблемы и решения), когда получили свои первые заказы во время Конференции по промышленному дизайну в 2008 году, а затем снова во время Национального съезда Демократической партии в Денвере. Отсюда они поняли дополнительный атрибут проблемы, а именно: крупные мероприятия с нехваткой отелей.

Wildberries был основан Татьяной Бакальчук в 2004 году. История создания компании началась с желания Татьяны найти занятие, которое она могла бы совмещать с уходом за своим ребенком. Она решила создать интернет-магазин, чтобы помочь себе и другим женщинам получать доступ к зарубежной моде. Она заметила, что многим женщинам сложно найти качественную и модную одежду по доступным ценам в России. Идея создания интернет-магазина пришла ей в голову после того, как она сама столкнулась с трудностями покупки одежды для своего ребенка через зарубежные каталоги. Она начала с продажи одежды через интернет, закупая товар из каталогов немецкого ретейлера Otto. Она создала простой сайт и начала размещать на нем товары, которые заказывала и перепродавала с небольшой наценкой.