PRODUCT ARCHITECTURE FRAMEWORK
Feature Life Cycle
Детальное описание процесса исследования и работы с гипотезами новых свойств продукта
Общий каркас процесса
Жизненный цикл свойства продукта (мы будем использовать слово "feature" в значении не "функциональность продукта", а в значении "свойство продукта") представляет собой последовательный процесс сокращения рисков существования потребности, подходящего ценностного предложения и решения, его реализующего. Причем, чем в большей степени проведен анализ поведения текущих пользователей или новых потребителей, тем в меньшей степени необходимо потратить усилий на валидацию последующих гипотез. Бизнес-процесс работы со свойством продукта аналогичен процессу работу с самим продуктом, т.к. любое свойство продукта может быть трансформировано в самостоятельный продукт.
Целью процесса является нахождение feature / product fit для той добавочной ценности, которую принесло потребителям новое свойство продукта, а также влияние этой ценности на показатели бизнес-модели.
Целью процесса является нахождение feature / product fit для той добавочной ценности, которую принесло потребителям новое свойство продукта, а также влияние этой ценности на показатели бизнес-модели.
Stage 1
Feature Ideation
Feature Ideation
Рис. 1. Процесс генерации идей свойств продукта
Management Object Definition. В самом начале любого исследования необходимо определить, что именно будет объектом управления, на который мы хотим повлиять. В частности, какая именно часть поведения из контекста потребителя исследуется: как и какие он решает задачи при помощи нашего или конкурентных продуктов.
Internal Analysis. Анализ внутреннего контура применяется для исследования поведения пользователя при взаимодействии с продуктом, чтобы найти бутылочные горлышки или другие отклонения от нормы, которые помогут понять точки роста продукта и дадут идеи новых его свойств.
Analytics Implementation. После определения объекта управления происходит выбор и внедрение инструментов качественной и количественной аналитики, которые помогают собрать информацию о поведении пользователя.
Internal Analysis. Анализ внутреннего контура применяется для исследования поведения пользователя при взаимодействии с продуктом, чтобы найти бутылочные горлышки или другие отклонения от нормы, которые помогут понять точки роста продукта и дадут идеи новых его свойств.
Analytics Implementation. После определения объекта управления происходит выбор и внедрение инструментов качественной и количественной аналитики, которые помогают собрать информацию о поведении пользователя.
Модели и артефакты для управления количественной аналитикой.
Модели и артефакты для управления качественной аналитикой.
User Experience Analysis. Анализ опыта использования дает понимание характеристик поведения потребителя: как часто он использует продукт и почему именно. Появляется понимание "естественного" и "целевого" поведения пользователя. Естественное (или нормальное) поведение - это поведение, присущее большей доли пользователей. Целевое поведение - это ожидаемое представление о поведении пользователя, т.е. то, каким вы хотите, чтобы оно было.
Anomaly Searching. В собранной информации осуществляется поиск аномалий - отклонений от нормы или целевого (желаемого) поведения как в большую, так и в меньшую сторону.
Anomaly Root Cause Analysis. После поиска аномалий происходит анализ причин их возникновения, чтобы найти точки роста.
External Analysis. Анализ внешнего контура применяется для исследования поведения потребителя при взаимодействии с другими продуктами, чтобы понять, какую новую ценность для потребителя можно создать или каким образом можно усилить текущую.
Competitor Analysis. Анализ конкурентов позволяет определить тех игроков, которые нацелены на те же потребности(тот же value stream) или тот же сегмент потребителей, что и ваш продукт.
Alternative Products Analysis. Проводится анализ продуктов конкурентов, чтобы выяснить на какие потребности потребителей они нацелены, какие ценностные предложения включают, какой интерфейс взаймодействия с потребителями, насколько велика цена переключения и т.д.
Customer Behaviour Analysis. Для выбранных продуктов проводится анализ поведения потребителей: какие плюсы и минусы они выделяют в них, что является удобным или неудобным, почему они вообще приняли решение использовать их и т.д.
Opportunities Searching. В результате анализа получается набор возможностей, которые можно превратить в точки дифференциации относительно конкурентов или точки роста ценности для текущего продукта.
Anomaly Searching. В собранной информации осуществляется поиск аномалий - отклонений от нормы или целевого (желаемого) поведения как в большую, так и в меньшую сторону.
Anomaly Root Cause Analysis. После поиска аномалий происходит анализ причин их возникновения, чтобы найти точки роста.
External Analysis. Анализ внешнего контура применяется для исследования поведения потребителя при взаимодействии с другими продуктами, чтобы понять, какую новую ценность для потребителя можно создать или каким образом можно усилить текущую.
Competitor Analysis. Анализ конкурентов позволяет определить тех игроков, которые нацелены на те же потребности(тот же value stream) или тот же сегмент потребителей, что и ваш продукт.
Alternative Products Analysis. Проводится анализ продуктов конкурентов, чтобы выяснить на какие потребности потребителей они нацелены, какие ценностные предложения включают, какой интерфейс взаймодействия с потребителями, насколько велика цена переключения и т.д.
Customer Behaviour Analysis. Для выбранных продуктов проводится анализ поведения потребителей: какие плюсы и минусы они выделяют в них, что является удобным или неудобным, почему они вообще приняли решение использовать их и т.д.
Opportunities Searching. В результате анализа получается набор возможностей, которые можно превратить в точки дифференциации относительно конкурентов или точки роста ценности для текущего продукта.
В разделе представлены модели и артефакты для исследования потребителей.
В разделе представлены модели и шаблон для исследования конкурентных продуктов.
Getting Insight. Вне зависимости от того, проводится анализ внутреннего или внешнего контура, в результате должен получиться набор инсайтов о поведении потребителя и его потребностях.
Feature Ideation. На основании полученных инсайтов формируется идея для нового свойства продукта или усиления ценности текущих его свойств, которая формализуется в виде документа Feature Requirements Document.
Business Model Impact Calculation. Если одной из задач продукта является получение прибыли, то процесс завершается расчетом потенциального влияния идеи на изменение показателей бизнес-модели продукта.
Feature Ideation. На основании полученных инсайтов формируется идея для нового свойства продукта или усиления ценности текущих его свойств, которая формализуется в виде документа Feature Requirements Document.
Business Model Impact Calculation. Если одной из задач продукта является получение прибыли, то процесс завершается расчетом потенциального влияния идеи на изменение показателей бизнес-модели продукта.
Stage 2
Need Validation
Need Validation
Рис. 2. Процесс поиска потребности
Feature Idea. Процесс валидации потребностей потребителя начинается с какой-то идеи нового или оптимизации текущего свойства продукта. При этом, чем больше информации было проработано на предыдущем этапе Customer Behaviour Research, тем меньше усилий нужно потратить на этот этап, или же вообще его пропустить.
Customer Hypotheses Definition. Первой важной частью идеи свойства продукта является гипотеза потребности потребителя. Не обязательно, чтобы эти гипотезы были проблемами клиентов, ведь продукт может строиться и не от проблем (как ограничений текущего поведения), но и от целей клиентов, стимулируя их достижение. Будем использовать термин need (потребность, нужда) для обозначения класса этих объектов, чтобы не фокусироваться на каком-либо одном (задача / проблема / цель и т.д.) и не привязываться к конкретной методологии.
Customer Hypotheses Definition. Первой важной частью идеи свойства продукта является гипотеза потребности потребителя. Не обязательно, чтобы эти гипотезы были проблемами клиентов, ведь продукт может строиться и не от проблем (как ограничений текущего поведения), но и от целей клиентов, стимулируя их достижение. Будем использовать термин need (потребность, нужда) для обозначения класса этих объектов, чтобы не фокусироваться на каком-либо одном (задача / проблема / цель и т.д.) и не привязываться к конкретной методологии.
Проблема - это препятствие на пути к цели клиента. Это то, что мешает ему быть эффективнее, чем ему того хочется. Продукт решает проблему, если оптимизирует текущую эффективность клиента, что всегда выражается в конкретных измеримых показателях, будь то скорость решения задач, сила новых эмоций, сокращение издержек и т.д.
Не может существовать проблем "в вакууме", в отрыве от контекста. Например, если у потребителя нет автомобиля - это не проблема. Проблемой это становится только тогда, когда он хочет поехать загород в веревочный парк вместе с детьми. Ведь он стремится к тому, чтобы поездка была для семьи комфортной и как можно более быстрой, чтобы дети не устали. Но этого не получается сделать, т.к. чтобы добраться до парка, нужно ехать на электричке до остановки, а потом еще топать полтора часа пешком. Конечно же от такого путешествия дети будут сильно подавлены. При этом отсутствие автомобиля не будет для него проблемой, когда он просто хочет доехать до центра города - он просто закажет такси.
На этом примере можно очень хорошо проследить различие между фокусом на проблему и фокусом на цель клиента. В первом случае, если мы фокусируем продукт на проблему - отсутствие автомобиля, то развиваем нашу мысль в сторону продажи автомобиля или каршеринга. Во втором же случае, мы фокусируемся на цель - доехать до веревочного парка с комфортом для всей семьи, что может нас привести к тому, что никакой продажи или аренды автомобиля не нужно - нужно предоставить возможность найма микроавтобуса с водителем на дальние расстояния.
Более того, акцент на цели в данном случае позволит расширить сегмент потребителей, на который нацелен продукт - от только тех, кто имеет права на вождение, до более массового сегмента, кто может не уметь водить.
Не может существовать проблем "в вакууме", в отрыве от контекста. Например, если у потребителя нет автомобиля - это не проблема. Проблемой это становится только тогда, когда он хочет поехать загород в веревочный парк вместе с детьми. Ведь он стремится к тому, чтобы поездка была для семьи комфортной и как можно более быстрой, чтобы дети не устали. Но этого не получается сделать, т.к. чтобы добраться до парка, нужно ехать на электричке до остановки, а потом еще топать полтора часа пешком. Конечно же от такого путешествия дети будут сильно подавлены. При этом отсутствие автомобиля не будет для него проблемой, когда он просто хочет доехать до центра города - он просто закажет такси.
На этом примере можно очень хорошо проследить различие между фокусом на проблему и фокусом на цель клиента. В первом случае, если мы фокусируем продукт на проблему - отсутствие автомобиля, то развиваем нашу мысль в сторону продажи автомобиля или каршеринга. Во втором же случае, мы фокусируемся на цель - доехать до веревочного парка с комфортом для всей семьи, что может нас привести к тому, что никакой продажи или аренды автомобиля не нужно - нужно предоставить возможность найма микроавтобуса с водителем на дальние расстояния.
Более того, акцент на цели в данном случае позволит расширить сегмент потребителей, на который нацелен продукт - от только тех, кто имеет права на вождение, до более массового сегмента, кто может не уметь водить.
Customer Hypotheses Scoring. Хорошей практикой на этапе Need Validation, в отличие от многих других этапов, является генерация сразу большого количества гипотез поведения потребителей. Одновременно, например, во время одного и того же интервью, могут проверяться сразу десятки гипотез - исследователь как бы формирует целый "поезд", который затем отправляет на валидацию из "депо" беклога. Однако, подобных гипотез может быть слишком много, а времени их проверить все недостаточно, поэтому важно выбрать наиболее релевантные изначальной идеи гипотезы, чтобы именно их проверить в первую очередь.
Customer Hypotheses Validation. Есть несколько различных инструментов для валидации гипотез потребителя, но, пожалуй, самый популярный из них - это глубинные интервью. Во время интервью можно не только откинуть самые "плохие" гипотезы поведения, но и получить важные инсайты и сформулировать новые. Если гипотеза провалилась, всегда можно перейти к новой. А если провалились все гипотезы, даже с учетом новых знаний, это большой повод задуматься о смене изначальной идеи. Однако, вне зависимости от исхода, любые полученные знания должны быть зафиксированы в базе знаний результатов экспериментов.
Customer Hypotheses Validation. Есть несколько различных инструментов для валидации гипотез потребителя, но, пожалуй, самый популярный из них - это глубинные интервью. Во время интервью можно не только откинуть самые "плохие" гипотезы поведения, но и получить важные инсайты и сформулировать новые. Если гипотеза провалилась, всегда можно перейти к новой. А если провалились все гипотезы, даже с учетом новых знаний, это большой повод задуматься о смене изначальной идеи. Однако, вне зависимости от исхода, любые полученные знания должны быть зафиксированы в базе знаний результатов экспериментов.
Статья "Единственный контекст потребителя" о том, как изучить среду вокруг потребителя.
В разделе представлены шаблоны гипотез потребителей и способы их валидации.
Customer Behaviour Fixation. "Единицы" знаний о поведении клиентов фиксируется, количество кейсов постепенно разрастается. Самыми важными фактами о поведении клиентов являются его задачи, цели и проблемы, с которыми он сталкивается, на пути к их достижению.
Customer Profile Fixation. Постепенно единичные факты о поведении начинают складываться в профили потребителей, между которыми прослеживается четкая разница. Сегментация может быть в совершенно разных разрезах и определяется только контекстом задачи.
Customer Needs Scoring. Зачастую на этапе исследования потребителей выявляются несколько их потребностей, поэтому необходимо выбрать наиболее значимую потребность, на которую и будет нацелено новое свойство продукта.
Customer Profile Fixation. Постепенно единичные факты о поведении начинают складываться в профили потребителей, между которыми прослеживается четкая разница. Сегментация может быть в совершенно разных разрезах и определяется только контекстом задачи.
Customer Needs Scoring. Зачастую на этапе исследования потребителей выявляются несколько их потребностей, поэтому необходимо выбрать наиболее значимую потребность, на которую и будет нацелено новое свойство продукта.
Stage 3
Value Validation
Value Validation
Рис. 3. Процесс валидации ценностного предложения
Value Proposition Hypotheses Definition. После нахождения минимально значимой потребности формулируется гипотеза ценностного предложения, которое способно эту потребность удовлетворить. В основе гипотезы ценности лежат все знания, полученные как во время Need Validation (поведение потребителя, проблемы с текущими продуктами, его цели и т.д.), так и знания о рыночной среде (что из себя представляют конкурентные продукты, какие их слабые места можно использовать, какие ценностные предложения на рынке считаются само собой разумеющимися, а каких рынок жаждет и т.д.).
Value Proposition Hypotheses Primary Scoring. Одна и та же потребность может закрыта при помощи разных ценностных предложений, но ресурсы на их проверку всегда ограничены. Поэтому, важно отобрать для проверки в первую очередь те ценностные предложения, которые с учетом других вводных, принесут максимальную ценность потребителю и компании.
Value Proposition Hypotheses Validation. Аналогично процессу работы с гипотезами потребителей, процесс валидации гипотез ценности повторяется, пока не будет найдено их подтверждение. В ином случае, если ни одна из гипотез не подтвердилась, стоит задуматься о выборе другой потребности потребителя.
Value Proposition Fixation. В случае успешной валидации гипотезы ценности считается, что свойство продукта имеет need / value fit, когда ценностное предложение действительно находит отклик у потребителей. В этом случае ценностное предложение фиксируется в базе знаний и Feature Requirements Document.
Value Proposition Hypotheses Secondary Scoring. В случае положительных результатов валидации нескольких ценностных предложений, может встать вопрос о том, на каком из них все-таки следует остановиться. Для этого применяется скоринг.
Value Proposition Hypotheses Primary Scoring. Одна и та же потребность может закрыта при помощи разных ценностных предложений, но ресурсы на их проверку всегда ограничены. Поэтому, важно отобрать для проверки в первую очередь те ценностные предложения, которые с учетом других вводных, принесут максимальную ценность потребителю и компании.
Value Proposition Hypotheses Validation. Аналогично процессу работы с гипотезами потребителей, процесс валидации гипотез ценности повторяется, пока не будет найдено их подтверждение. В ином случае, если ни одна из гипотез не подтвердилась, стоит задуматься о выборе другой потребности потребителя.
Value Proposition Fixation. В случае успешной валидации гипотезы ценности считается, что свойство продукта имеет need / value fit, когда ценностное предложение действительно находит отклик у потребителей. В этом случае ценностное предложение фиксируется в базе знаний и Feature Requirements Document.
Value Proposition Hypotheses Secondary Scoring. В случае положительных результатов валидации нескольких ценностных предложений, может встать вопрос о том, на каком из них все-таки следует остановиться. Для этого применяется скоринг.
Ценность для потребителя состоит не в том, чтобы обладать каким-либо инструментом для удовлетворения своих потребностей, а в том, чтобы тратить на это как можно меньше ресурсов (денег, времени, нервов и т.д.). Потребители с радостью бы вообще не использовали никаких продуктов, если бы любая их проблема решалась при помощи магической кнопки. Отсутствие продукта, когда его нет, а его функции выполняются, это идеальный конечный результат, к которому нужно стремиться при проектировании любого решения.
В разделе представлены шаблоны гипотез ценности и способы их валидации.
В разделе представлены модели ценностных предложений.
Stage 4
Solution Validation
Solution Validation
Рис. 4. Процесс валидации гипотезы решения, проектирования и разработки свойства продукта
Solution Hypotheses Definition & Validation. Наличие поддтверждения соответствия между ценностными предложением и потребностями позволяет перейти к этапу проектирования решения и проверки, действительно ли спроектированная реализация ценностного предложения приносит пользу потребителям.
Стоит отметить, что более, чем в половине случаев ценностные предложения не получится провалидировать без наличия какого-то конкретного решения, с которым мог бы повзаимодействовать пользователь. Причем, чем более простой или массовый это продукт, тем меньше шансов проверить гипотезу ценности без передачи его потребителю. Поэтому зачастую валидация ценностного предложения и валидация решения представляют собой один и тот же эксперимент.
User Experience Design. Проектирование любого решения начинается с проектирования опыта взаимодействия потребителя с продуктом, потому что продукт - это способ изменения текущего поведения потребителя. Поэтому он должен начинаться с анализа текущего поведения и завершаться измерением его изменения.
Solution Prototyping. В зависимости от класса продукта взаимодействие с потребителем может быть реализовано при помощи разных интерфейсов, будь то страница оплаты на сайте, интерфейс заказа пиццы в приложении или физическое взаимодействие в магазине. Чтобы быть увереным, что каждая часть user flow будущего продукта влияет на потребителя так, как нужно, используются прототипы.
Solution Prototyping. В зависимости от класса продукта взаимодействие с потребителем может быть реализовано при помощи разных интерфейсов, будь то страница оплаты на сайте, интерфейс заказа пиццы в приложении или физическое взаимодействие в магазине. Чтобы быть увереным, что каждая часть user flow будущего продукта влияет на потребителя так, как нужно, используются прототипы.
Модели и артефакты для прототипирования интерфейса взаимодействия с продуктом.
В разделе представлены шаблоны гипотез решений и способы их валидации.
Solution Validation. Прототипы продукта или его свойств представляют собой гипотезы решений, требующие проверки - действительно ли при помощи данного решения потребитель может удовлетворить свои потребности и получить ценность.
Solution Scoring. Может оказаться, что одновременно несколько прототипов дают хорошие показатели при их валидации, поэтому появляется задача выбора из них такого, который с учетом затрачиваемых ресурсов сможет принести максимальную ценность потребителю и компании.
Minimum Viable Feature Development. Если эксперименты, при помощи которых найдено подтверждение эффективности решений, прошли удачно, можно перейти к фазе проектирования и построения самого свойства продукта, т.е. формирования MVP с минимальным или расширенным функционалом.
Requirements Definition. Важным этапом процесса разработки продукта является этап формирования требований, которые определяют конечный результат этого процесса. Чем более точно сформулированы требования, тем меньше времени потребуется на процесс проектирования технологического решения и саму разработку. Значительно сокращаются риски и время на переделку продукта, т.к. разница между желаемым и его реализацией будет минимальна.
Business Logic Design. Ясные и непротиворечивые функциональные и нефункциональные требования позволяют сформировать масштабируемую и консистентную технологическую систему. Это приводит к сокращению времени для дальнейшего развития продукта и рисков формирования технического долга.
Solution Scoring. Может оказаться, что одновременно несколько прототипов дают хорошие показатели при их валидации, поэтому появляется задача выбора из них такого, который с учетом затрачиваемых ресурсов сможет принести максимальную ценность потребителю и компании.
Minimum Viable Feature Development. Если эксперименты, при помощи которых найдено подтверждение эффективности решений, прошли удачно, можно перейти к фазе проектирования и построения самого свойства продукта, т.е. формирования MVP с минимальным или расширенным функционалом.
Requirements Definition. Важным этапом процесса разработки продукта является этап формирования требований, которые определяют конечный результат этого процесса. Чем более точно сформулированы требования, тем меньше времени потребуется на процесс проектирования технологического решения и саму разработку. Значительно сокращаются риски и время на переделку продукта, т.к. разница между желаемым и его реализацией будет минимальна.
Business Logic Design. Ясные и непротиворечивые функциональные и нефункциональные требования позволяют сформировать масштабируемую и консистентную технологическую систему. Это приводит к сокращению времени для дальнейшего развития продукта и рисков формирования технического долга.
Модели и артефакты для проектирования бизнес-логики продукта.
Модели и артефакты для проектирования требований по разработке продукта.
Feature Development. Сам процесс разработки по сложности не уступает процессам валидации гипотез, а где-то значительно его превосходит. Правильное управление проектом позволяет сократить риски и время вывода продукта на рынок (time-to-market).
Analytics Implementation. Последним этапом подготовки свойства продукта к передаче потребителям является внедрение системы количественной и качественной аналитики, данные которых будут станут отправной точкой на этапе развития.
Analytics Implementation. Последним этапом подготовки свойства продукта к передаче потребителям является внедрение системы количественной и качественной аналитики, данные которых будут станут отправной точкой на этапе развития.
Модели и артефакты для управления количественной аналитикой.
Модели и артефакты для управления качественной аналитикой.
Stage 5
Customer Onboarding
Customer Onboarding
Рис. 5. Процесс валидации вовлечения в использование свойства продукта
Onboarding Configuration Hypotheses Definition. Перед запуском необходимо определить конфигурацию для онбординга потребителей. С одной стороны, это каналы и способы привлечения как новых, так и текущих клиентов. С другой стороны, это способы активации привлеченных потребителей в использование свойств продукта.
Onboarding Configuration Hypotheses Validation. Аналогично процессу Discovery продукта, выбранная конфгурация онбординга потребителей может и не сработать, поэтому выделяется процесс валидации как конфигурации привлечения, так и активации потребителей.
Onboarding Configuration Fixation. В случае подтверждения успешной конфигурации онбординга, она фиксируется в FRD, а фокус менеджмента переходит на подтверждение того, что эта фича действительно приносит ценность потребителям в контексте продукта.
Feature Scaling. Если для свойства продукта было подтверждено наличие Feature / Product Fit, то это значит, что её можно масштабировать на всю аудиторию продукта. Сама фича переходит на стадию роста.
Onboarding Configuration Hypotheses Validation. Аналогично процессу Discovery продукта, выбранная конфгурация онбординга потребителей может и не сработать, поэтому выделяется процесс валидации как конфигурации привлечения, так и активации потребителей.
Onboarding Configuration Fixation. В случае подтверждения успешной конфигурации онбординга, она фиксируется в FRD, а фокус менеджмента переходит на подтверждение того, что эта фича действительно приносит ценность потребителям в контексте продукта.
Feature Scaling. Если для свойства продукта было подтверждено наличие Feature / Product Fit, то это значит, что её можно масштабировать на всю аудиторию продукта. Сама фича переходит на стадию роста.
Статья "Алгоритм выбора метрик для определения Product / Market Fit"
Feature / Product Fit
Состояние свойства продукта, которое подтверждается наличием группы потребителей продукта, использующих это свойство в качестве основного способа удовлетворения их потребностей.
Наличие этого свойства является необходимым условием старта дальнейшего развития этой фичи. Существует два способа определения наличия feature / product fit продукта: количественный и качественный.
Количественно критерий наличия FPF для продукта с высокочастотными потребностями можно определить по динамике retention rate когорт потребителей - если структура кривой кореллирует с альтернативными (конкурентными) способами удовлетворения и общим retention rate продукта, то можно говорить о наличии FPF. Для низкочастотных потребностей критерий определяется по показателям конверсии в использование фичи и долей аудитории продукта, которые ею воспользовались хотя бы раз. Если показатели коррелируют с альтернативными продуктами, то с большей долей вероятности это свойство продукта обладает FPF.
Качественный способ заключается в проведении опроса во время и/или после использования фичи с целью получить подтверждение от потребителя о фактически принесенной ему ценности.
Количественно критерий наличия FPF для продукта с высокочастотными потребностями можно определить по динамике retention rate когорт потребителей - если структура кривой кореллирует с альтернативными (конкурентными) способами удовлетворения и общим retention rate продукта, то можно говорить о наличии FPF. Для низкочастотных потребностей критерий определяется по показателям конверсии в использование фичи и долей аудитории продукта, которые ею воспользовались хотя бы раз. Если показатели коррелируют с альтернативными продуктами, то с большей долей вероятности это свойство продукта обладает FPF.
Качественный способ заключается в проведении опроса во время и/или после использования фичи с целью получить подтверждение от потребителя о фактически принесенной ему ценности.
Stage 6
Business Model Impact Validation
Business Model Impact Validation
Рис. 6. Процесс валидации влияния на бизнес-модель
Business Model Impact Validation. После подтверждения наличия Feature / Product Fit свойства продукта, происходит анализ влияния данной фичи на показатели бизнес-модели, если существует такая цель. Наличие импакта помогает принять решение о судьбе этого свойства продукта - следует ли его масштабировать на всю аудиторию, или же стоит закрыть.
Root Cause Analysis. В том случае, если импакт не обнаружен, происходит разносторонний анализ причин его отстуствия - по какой именно причине его нет, на каком именно этапе совершена ошибка. Результатом этого анализа может быть одно из решений:
Feature Scaling. Если для свойства продукта было подтверждено наличие Feature / Business Model Fit, то это значит, что её можно масштабировать на всю аудиторию продукта. Сама фича переходит на стадию роста.
Root Cause Analysis. В том случае, если импакт не обнаружен, происходит разносторонний анализ причин его отстуствия - по какой именно причине его нет, на каком именно этапе совершена ошибка. Результатом этого анализа может быть одно из решений:
- изменение бизнес-модели, например, стоимости всего продукта или только данной фичи;
- изменение части стратегии маркетинга, например, каналов, целевой аудитории или механизма активации;
- изменение самого свойства продукта, его пивот;
- инициация стратегии закрытия фичи.
Feature Scaling. Если для свойства продукта было подтверждено наличие Feature / Business Model Fit, то это значит, что её можно масштабировать на всю аудиторию продукта. Сама фича переходит на стадию роста.
Feature / Business Model Fit
Состояние свойства продукта, которое подтверждается наличием его положительного влияния на показатели бизнес-модели продукта.
Наличие этого свойства у фичи в некоторых компаниях является необходимым условием для старта дальнейших инвестиций в её развитие.
Проверка влияния свойства продукта на бизнес-модель очень сильно зависит от типа этой бизнес-модели. Существует три точки такого влияния:
Проверка влияния свойства продукта на бизнес-модель очень сильно зависит от типа этой бизнес-модели. Существует три точки такого влияния:
- влияние на эффективность привлечения и конвертации в клиента, если свойство связано с оптимизацией воронки или усиливает конкурентную позицию продукта, тем самым сокращая барьер для новых клиентов;
- влияние на прибыль клиента, если свойство влияет на поведение пользователя в продукте, на основе которого построена схема монетизации (ресурные, комиссионные, подписочные модели);
- влияние на издержки продукта, если свойство сокращает какую-то часть издержек производственных цепочек продукта.
Структура артефактов
Последовательная работа с продуктом или его свойствами (features), как правило, требует организации командной работы, в которой принимают участие разные специалисты. Для того, чтобы взаимодействие вокруг продукта было эффективным и предметным, используется набор артефактов, каждый из которых уменьшает свой кусок общей неопределенности.
Product Architecture Framework определяет следующую структуру артефактов для совместной работы команды:
Product Requirements Document. Общая логика работы с артефактами продукта или фичи начинается с формирования документа PRD (Product Requirements Document), который определяет целесообразность создания новой ценности.
Hypotheses Documents. По мере проверки гипотез потребителей, ценностных предложений и решений, к PRD "привязываются" артефакты, содержащие описание результатов валидации этих гипотез в виде документов Hypothesis Card. По одному на каждую тестируемую гипотезу.
Requirements Documents. С течением времени более явным становится образ решения, появляются артефакты, в которых указаны требования на разработку, внедрение качественной и количественной аналитики и/или изменения операционных процессов. Каждый из них тоже "привязывается" к PRD.
Marketing Documents. Ближе к концу проекта создания новой ценности определяются обстоятельства, как решение будет передано потребителям, а также как будут выглядеть первый релиз, план привлечения и более детальная бизнес-модель.
Product Architecture Framework определяет следующую структуру артефактов для совместной работы команды:
Product Requirements Document. Общая логика работы с артефактами продукта или фичи начинается с формирования документа PRD (Product Requirements Document), который определяет целесообразность создания новой ценности.
Hypotheses Documents. По мере проверки гипотез потребителей, ценностных предложений и решений, к PRD "привязываются" артефакты, содержащие описание результатов валидации этих гипотез в виде документов Hypothesis Card. По одному на каждую тестируемую гипотезу.
Requirements Documents. С течением времени более явным становится образ решения, появляются артефакты, в которых указаны требования на разработку, внедрение качественной и количественной аналитики и/или изменения операционных процессов. Каждый из них тоже "привязывается" к PRD.
Marketing Documents. Ближе к концу проекта создания новой ценности определяются обстоятельства, как решение будет передано потребителям, а также как будут выглядеть первый релиз, план привлечения и более детальная бизнес-модель.
Структура артефактов для работы над фичей
В результате получается один основной документ Product Requirements Document, содержащий всю необходимую информацию о продукте или фиче, чтобы выстроить эффективное взаимодействие кросс-функциональной команды. Если необходима детализация по какой-либо его части, будь то гипотезы потребности или план запуска, происходит "проваливание" вглубь необходимо документа. Этот же принцип позволяет организовать разделение зон ответственности за каждый из артефактов между разными ролями в команде.
Ниже приведены шаблоны ключевых документов.
Ниже приведены шаблоны ключевых документов.
Product Requirements Document
PRD (Product Requirements Document) - это описание концепции продукта или фичи, которое отвечает на вопрос о его целесообразности:
Снижение рисков происходит за счет последовательного прояснения сути продукта или фичи и включает в себя четыре области, которые нужно сделать прозрачными для команды:
Хорошей практикой заполнения PRD является добавление минимальной информации, достаточной для старта дискуссии над продуктом или фичей. Как правило, это пространство предназначения (purpose space). Остальные блоки добавляются по мере развития дискуссии или получения новой информации во время работы команды.
- что послужило причиной его возникновения;
- зачем он необходим, какие цели перед ним стоят;
- на какие потребности он ориентирован и как они будут удовлетворены;
- какие ресурсы необходимы для его создания и запуска;
- и как выглядит план на верхнем уровне.
Снижение рисков происходит за счет последовательного прояснения сути продукта или фичи и включает в себя четыре области, которые нужно сделать прозрачными для команды:
- Purpose - пространство предназначения;
- Customer & value - пространство ценности для потребителя;
- Solution - пространство решения;
- Execution - пространство запуска.
Хорошей практикой заполнения PRD является добавление минимальной информации, достаточной для старта дискуссии над продуктом или фичей. Как правило, это пространство предназначения (purpose space). Остальные блоки добавляются по мере развития дискуссии или получения новой информации во время работы команды.
Для использования шаблона скопируйте его (Файл → Создать копию) или скачайте документ в подходящем формате (Файл → Скачать).
Hypothesis Card
Карточка содержит полное описание проверямой гипотезы, способа её валидации и полученного результата. Она помогает сфокусировать команду в процессе эксперимента, снижая риски условий его проведения и интерпретации результатов.
Содержит информацию о:
Аналогично PRD, карточка гипотезы это динамический документ, который формируется по мере работы с гипотезой.
Содержит информацию о:
- причинах возникновения гипотезы;
- основной и дополнительных метриках результата, их контрольных значений;
- ожидаемому эффекту и условиям эксперимента;
- описании сегмента аудитории и размера выборки;
- понятном плане действий в случае подтверждения или опровержения гипотезы;
- новых знаниях, полученных в процессе валидации.
Аналогично PRD, карточка гипотезы это динамический документ, который формируется по мере работы с гипотезой.
Для использования шаблона скопируйте его (Файл → Создать копию) или скачайте документ в подходящем формате (Файл → Скачать).
