Слово «продукт» стало общим местом в деловом языке. Им называют приложение, технологию, оборудование, товар или услугу. Но привычность слова часто скрывает неопределённость его содержания. Назвав продуктом то, что мы создали, мы ещё не объяснили, для кого это существует, какую потребность удовлетворяет и почему за это будут платить. Вещь, технология или услуга могут быть лишь частью продукта.
Для описания и проектирования продуктов существует множество фреймворков. Бизнес-канвас раскрывает устройство бизнеса, канвас ценностного предложения — соответствие решения задачам, проблемам и ожиданиям клиента. Эти инструменты помогают подробно рассмотреть отдельные стороны продуктовой системы.
Наш подход рассматривает продукт как связанное целое. Платящая персона, её потребность, способ решения и оплата образуют конструкцию, которую мы называем продуктовым тетраэдром. Существующие фреймворки помогают наполнять и уточнять эту конструкцию. При этом внимание направлено не только на содержание каждого узла, но и на отношения между ними.
Такой взгляд позволяет перейти от устройства отдельного продукта к взаимодействию продуктов между собой. Где они пересекаются, где зависят друг от друга, где конкурируют, а где могут усиливать друг друга? Связанное описание может стать основой для проверяемых прогнозов конкуренции и синергии. Изучение этих возможностей составляет программу продуктовой кристаллографии.
Эта статья открывает серию исследований. Начнём с её основного объекта — продуктового тетраэдра: что означают четыре узла и как они образуют целостное предложение. Объединение нескольких тетраэдров, взаимодействие продуктов и проектирование продуктовых экосистем станут предметом следующих исследований.
Четыре узла одного предложения
Четыре вершины отвечают на разные вопросы об одном продукте: кто платит, какую его боль мы решаем, как именно её решаем и через какой механизм получаем оплату. В исходной формулировке эти узлы называются «Платящая персона», «Боль платящей персоны», «Способ решения боли или технология», «Способ оплаты или монетизация».
Платящая персона
Первый узел определяет, для кого складывается коммерческое предложение. Платящая персона — тот, кто принимает решение о покупке и связывает его со своими деньгами или доступным ему бюджетом. Здесь важны не только возраст, должность или принадлежность к отрасли, но и обстоятельства выбора: за какой результат человек отвечает, какие последствия для него имеет проблема и какие альтернативы ему доступны.
В компании платящая персона может быть представлена ролью экономического заказчика. Сотрудник использует систему, руководитель оценивает её результат, закупка оформляет договор. Эти роли следует различать. Сам факт использования технологии ещё не означает, что пользователь готов и вправе её купить; перечисление денег бухгалтерией не делает бухгалтера тем, чья боль определяет продукт.
Определив платящую персону, мы получаем точку, относительно которой рассматриваем остальные узлы. Они должны объяснять её решение о покупке.
Боль платящей персоны
Второй узел определяет, ради какого изменения платящая персона выбирает продукт. Боль — это значимая для неё проблема или неудовлетворённая потребность в конкретных обстоятельствах. Она может выражаться в потерях времени, денег, надёжности или возможностей. Термин также охватывает стремление получить желаемый результат, которого сейчас нет: боль не обязательно переживается как острое неудобство.
«Нужна автоматизация» не раскрывает боль. «Перед закрытием месяца руководитель не видит отклонений и принимает решения по запоздалым данным» связывает её с человеком, ситуацией и последствиями. Теперь можно обсуждать, какое изменение будет для него ценным. Jobs to Be Done также обращает внимание на желаемый прогресс в обстоятельствах выбора. Jobs to Be Done Theory
Важно сохранять принадлежность боли. У сотрудника может быть неудобный интерфейс, а у платящей персоны — риск несогласованных данных по нескольким отделам. Эти проблемы могут быть связаны, но облегчение первой ещё не доказывает устранение второй.
Способ решения боли или технология
Третий узел определяет, за счёт чего платящая персона получает нужное изменение. В названии узла технология обозначает средство решения боли. Это может быть программа, устройство, производственный процесс, услуга или их сочетание. Для продукта существенен весь способ получения результата: при необходимости он включает доставку, внедрение, обучение, обслуживание и поддержку.
Само наличие технологии не объясняет, какую боль она снимает. И перечень функций ещё не показывает, достигается ли нужный результат. Поэтому этот узел описывается через связь с болью платящей персоны: что изменится, при каких условиях и что потребуется для применения решения.
Если результат демонстрации обеспечивала постоянная ручная помощь разработчика, это условие входит в способ решения. Его нельзя незаметно убрать, предлагая покупателю тот же результат при самостоятельном использовании.
Способ оплаты или монетизация
Четвёртый узел определяет механизм коммерческого обмена: за что, кем, кому, когда и на каких условиях передаются деньги. Способ оплаты рассматривается со стороны платящей персоны, монетизация — со стороны получения выручки за предложение. Важно связать обе стороны одного обмена.
Банковская карта или перевод описывают платёжный инструмент. Для продуктового тетраэдра существеннее, что именно приобретается: вещь в собственность, право пользования, подписка, выполненная работа или определённый результат. Разовая продажа и регулярная оплата по-разному распределяют затраты и обязательства во времени.
Этот узел связан и с ценностью для платящей персоны, и с исполнением решения. Покупатель оценивает, оправданны ли затраты, а поставщик — что он обязуется обеспечить за полученную оплату. Наличие выручки само по себе ещё не доказывает прибыльность или устойчивость исполнения.
Почему это целостный продукт
Четыре заполненных поля могут оставаться простым списком. Например, в поле персоны записан один заказчик, в поле боли — проблема другого пользователя, технология решает лишь часть этой проблемы, а способ оплаты заимствован из другого предложения. Все элементы присутствуют, но относятся к разным ситуациям.
Связь образует целое, когда четыре узла описывают одно и то же предложение. Боль принадлежит выбранной платящей персоне; способ решения изменяет именно тот результат, который для неё значим; условия оплаты относятся к этому способу решения и понятны покупателю. При этом исполнение включает обязательства, за которые поставщик получает деньги.
Рассмотрим условный сервис доставки продуктов домой. Платящая персона — человек, который заказывает и оплачивает покупки для семьи. Его боль — необходимость регулярно находить время на закупку. Способ решения включает выбор товаров, сборку заказа и доставку в согласованное время. Способ оплаты или монетизация задаёт, что человек оплачивает за товары и доставку и что поставщик обещает за эту сумму.
Удобное приложение составляет лишь часть такого решения. Если заказ нельзя получить вовремя, связь с болью ослабевает, даже когда интерфейс работает прекрасно. Если доставка требует постоянной отдельной доплаты, не отражённой в предложении, меняются условия покупки. Если обещанная цена не позволяет выполнять обещанную доставку, возникает разрыв между способом решения и монетизацией.
Таким образом, каждый узел задаёт условия для остальных. Выбор платящей персоны помогает определить значимую боль. Боль задаёт требования к способу решения. Способ решения влияет на затраты, состав исполнения и условия оплаты. Условия оплаты, в свою очередь, влияют на выбор платящей персоны и на то, какое решение возможно предложить. Работать с продуктом означает согласовывать эту систему взаимных требований.
Поэтому в данной модели тетраэдр называется минимальным продуктовым кристаллом. Убирая платящую персону, мы теряем основание коммерческого выбора; убирая её боль — смысл покупки; убирая способ решения — путь к результату; убирая способ оплаты — условия обмена. Это объясняет необходимость четырёх узлов внутри выбранной модели. Геометрическая форма помогает удерживать их совместное рассмотрение, но сама по себе не доказывает успех продукта или универсальную достаточность четырёх узлов.
Почему между вершинами шесть связей
В тетраэдре каждая вершина соединена с тремя другими. Это позволяет поставить шесть вопросов о согласованности одного и того же предложения.
| Связь | Вопрос |
|---|---|
| Платящая персона — боль платящей персоны | Эта боль значима именно для выбранной платящей персоны? |
| Боль платящей персоны — способ решения боли или технология | Способ решения изменяет нужный результат? |
| Платящая персона — способ решения боли или технология | Платящая персона может принять предложение и обеспечить его применение? |
| Платящая персона — способ оплаты или монетизация | У неё есть право, возможность и готовность оплатить на этих условиях? |
| Боль платящей персоны — способ оплаты или монетизация | Ценность результата соразмерна затратам и условиям? |
| Способ решения боли или технология — способ оплаты или монетизация | Обещанное исполнение устойчиво при этих условиях оплаты? |
Тетраэдр — треугольная пирамида: у него четыре вершины, шесть рёбер и четыре грани. На рисунке он показан в пространственной проекции; скрытое ребро обозначено пунктиром. Каждая вершина соответствует одному узлу, каждое ребро — связи между двумя узлами. Положение вершин и длина линий не являются мерами ценности или силы продукта.
Загрузка интерактивного материала…
Нарисованная линия означает вопрос, который предстоит проверить. Для одной связи основанием будет наблюдение процесса, для другой — выбор между альтернативами, для третьей — принятые обязательства и расчёт исполнения. Если слова «готов платить» появились только в презентации команды, свидетельства связи ещё нет.
Как стартапу сохранять целостность продукта
Практическое преимущество продуктового тетраэдра — возможность постоянно возвращать внимание команды к целостности продукта. Для стартапа это особенно существенно: исследования уточняют первоначальную идею, запросы клиентов меняют приоритеты, а разработка добавляет новые функции. Каждое из этих изменений нужно соотносить со всем продуктом.
Поэтому тетраэдр следует использовать итерационно. В каждом цикле работы с продуктом, его функциями и исследованиями команда вновь проходит по четырём вершинам и проверяет связи между ними. Начать можно с любой вершины: с новой боли, технической возможности, другого заказчика или способа оплаты. Затем нужно вернуться к остальным и выяснить, сохраняют ли они согласованность.
Такой обход можно встроить в рабочий цикл:
- Зафиксировать текущее предложение. Кто такая «Платящая персона», в чём состоит «Боль платящей персоны», как устроен «Способ решения боли или технология» и что задаёт «Способ оплаты или монетизация»? Отдельно отметить, что уже подтверждено, а что пока предполагается.
- Проследить влияние изменения. Какую вершину затрагивает новая функция или гипотеза? Что вслед за ней меняется в других вершинах и в шести связях? Даже если задача выглядит технической, её последствия могут затронуть результат для покупателя, условия применения и оплату.
- Проверить возникшие вопросы. Выбрать исследование или эксперимент, который прояснит существенную неопределённость: значимость боли, применимость решения, готовность платить или возможность выполнять обещание на выбранных условиях.
- Вернуть результаты в целое. После исследования или разработки снова пройти все четыре вершины и связи. Обновить описание продукта, зафиксировать обнаруженные несоответствия и определить, что требуется проверить или изменить в следующем цикле.
Для небольшой правки такой обход может быть коротким. Существенно, чтобы вывод о её влиянии на продукт был явным. Если новая функция полезна, нужно понимать, кому именно и для какого результата. Если эксперимент успешен, нужно установить, какую связь он подтверждает и при каких условиях.
Этот порядок помогает обсуждать приоритеты. У функции появляется основание для включения в продукт: какую боль выбранной платящей персоны она помогает решить и как согласуется с условиями исполнения и оплаты. Исследования получают более точный вопрос, а команда — общую основу для сопоставления результатов. Технический прогресс становится возможным оценивать через изменение продукта в целом.
Без такого возврата стартап рискует незаметно начать разрабатывать другой продукт. Название, команда и кодовая база могут остаться прежними, хотя новые функции уже ориентированы на другую платящую персону или другую боль. При этом остальные вершины продолжают описывать исходное предложение. Возникает разрыв: разработка движется в одном направлении, а ожидания от спроса, результата и выручки относятся к другому.
Вернёмся к условному сервису доставки продуктов домой. Допустим, ресторан просит добавить оптовые заказы, регулярные поставки и отсрочку платежа. Если стартап начинает строить предложение вокруг этих запросов, меняется весь тетраэдр. Платящая персона теперь отвечает за закупки ресторана; её боль связана с бесперебойным снабжением кухни; способ решения требует другой организации поставок; оплата подчиняется условиям корпоративного договора. Общая технология доставки может сохраниться, но команда уже формирует другой продукт.
Такой переход может быть полезным решением для стартапа. Тетраэдр помогает сделать его осознанным: увидеть, какие вершины и связи изменились, описать новое предложение и проверить его как целое. Если развивается второе направление, его следует описать отдельно. Если стартап меняет основной продукт, нужно обновить всю его конфигурацию. Целостность поддерживается через согласование изменений между всеми четырьмя узлами.
Прототип и целый продукт
Рассмотрим условный корпоративный инструмент. Сотрудник собирает отчёт быстрее и доволен. Это свидетельство локальной пользы. Для руководителя же результатом может быть согласованная картина по нескольким отделам. Если новый инструмент улучшает скорость одного участка, но нарушает совместимость данных, связь с потребностью экономического заказчика остаётся недоказанной.
Это учебный пример, а не описание конкретной компании. Он показывает, почему проверка полезности начинается с определения субъекта и результата. Прототип может быть ценным этапом исследования, даже когда коммерческий кристалл ещё не собран.
Целостность описания также не гарантирует успеха. В сентябре 2022 года Google объявила завершение Stadia, сославшись на рост использования ниже ожиданий. Покупки игр и платная подписка существовали. Из этого случая нельзя определить единственную причину неудачи, но можно увидеть: наличие технологии, пользователей и оплаты не обеспечивает продолжение продукта. Stadia: объявление завершения и FAQ; Stadia Announcement FAQ
Что добавляют грани
Три вершины образуют грань. Для практической работы их можно использовать как групповые проверки: получает ли заказчик нужный результат; обоснована ли оплата потребностью; согласованы ли принятие, исполнение и оплата; можно ли поддерживать решение при данных затратах.
Такие проверки полезны, когда каждая пара выглядит убедительно, но общие условия различаются. Условный покупатель готов платить за результат после обучения, а показанный пилот достиг его только при постоянной ручной помощи разработчика. Цена относилась к самостоятельному использованию, демонстрация — к обслуживаемому решению. На уровне целого это два разных обещания.
Граням пока не нужны отдельные баллы. Сначала следует проверить, помогают ли они обнаруживать разрывы, которые команда пропускает при обсуждении рёбер.
Место среди существующих методов
Business Model Canvas описывает девять блоков бизнеса, включая организацию доставки ценности и затраты. Value Proposition Canvas подробнее рассматривает соответствие предложения задачам, потерям и желаемым приобретениям клиента. Тетраэдр может связывать такие результаты в компактную проверку одного предложения. Он оставляет часть подробностей за пределами рисунка, поэтому важно сохранять ссылки на них. Business Model Canvas; Value Proposition Canvas
Изменение вершины меняет конфигурацию предложения. История таких изменений позволяет сопоставлять прежнее и новое состояния продукта: для кого он создаётся, какую боль решает и на каких условиях. Сохранившееся название или прежняя технология сами по себе не подтверждают целостность. Вопрос о границе между новой версией и отдельным продуктом требует дальнейшего рассмотрения; уже сейчас важно явно фиксировать изменение узлов и заново проверять их связи.
Проверка, с которой стоит начать
Начать применение тетраэдра можно с ближайшей продуктовой итерации. Описать текущее предложение через четыре узла, выбрать одну запланированную функцию или исследовательскую гипотезу и проследить её влияние на шесть связей. Отдельно сохранить существенные условия за пределами рисунка: каналы, ресурсы и внешние зависимости.
После итерации сопоставить два состояния тетраэдра. Какие предположения получили основание? Где обнаружился разрыв? Продолжает ли команда развивать то же предложение или уже проверяет другое? Ответы становятся отправной точкой следующего цикла работы с продуктом.
Область применимости
Где модель может быть полезна
- Коммерческое предложение с определимым экономическим заказчиком.
- Сопоставление потребности, результата и условий оплаты в конкретном контексте.
- Итерационная работа стартапа с продуктом, его функциями и исследовательскими гипотезами.
Граница доказанного
Что еще не доказано
- Модель рассматривает коммерческое предложение с определимой платящей персоной.
- Геометрическая форма и полнота описания сами по себе не доказывают успех продукта или универсальную достаточность четырёх узлов.
- Каналы, ресурсы и внешние зависимости требуют отдельного описания.
- Дополнительная диагностическая польза граней требует проверки.
Исследование продолжается
Открытые вопросы
RAP002-OQ-001Какой уровень изменения вершины означает новую версию, а какой — отдельный продукт?
RAP002-OQ-002Дают ли грани дополнительную диагностическую пользу сверх рёбер?
RAP002-OQ-003Как хранить каналы, ресурсы, полномочия и жизненный цикл за пределами ядра?
Журнал версии
Что изменилось в версии 1.0
- 01
Первая публикация: раскрыты четыре узла, шесть связей и практика итерационной проверки целостности продукта.
Публичные основания