Ценность, а не функции: как приоритизировать развитие продукта и повысить продажи

Обычно на рынке побеждает продукт, который быстрее и лучше решает проблему пользователя. Если вы не понимаете, за какую именно ценность клиент готов платить, реализация каждой фичи становится лотереей без гарантии успеха. Вместе с Дарьей Щурик, Head of Growth дубайского AgriTech стартапа Greeneration.ae, разбираем, что такое ценность, какие фреймворки помогают ее определять, как измерять успех и за какую выгоду клиент готов платить и возвращаться. 

Про то, как Дарья использует инструменты продакт-менеджмента на практике в Greeneration и до этого в Revolut, можно узнать в ее телеграм канале CODE:DARIA. 

Что такое ценность для пользователя и как ее найти

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

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

Дарья Щурик, Head of Growth Greeneration.ae

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

Ценность можно представить как простое уравнение:

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

Разберем на примере реализации функции «метки»:

• фокус на фиче → сделать функцию «метки»; 

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

В Greeneration ценность для пользователя (шеф-повара) — не «красивые съедобные цветы», а уверенность, что ингредиент будет свежим, вовремя и в нужном оформлении.

Дарья Щурик, Head of Growth Greeneration.ae

Ценность редко бывает одномерной. Она может проявляться на четырех уровнях:

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

Чтобы этого избежать, учитывайте следующее:

• Требуйте подтверждения приверженности клиента: предоплата, платный пилот, или обязательный контракт. «Нравится» не равно «плачу».
• Измеряйте поведение пользователей, а не их слова: у вас должна быть информация о повторных платежах, частоте использования, сокращении времени , которое пользователь тратит на выполнение задачи (особенно актуально для В2В продуктов).

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

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

Дарья Щурик, Head of Growth Greeneration.ae

Что ломается, если непонятна ценность

Что может произойти, если команда не понимает ценность для пользователя:

• Деприоритизация и хаос. Без критерия ценности становится невозможно принимать обоснованное решение о том, что важнее реализовать для пользователя. Приоритизация проводится на основе субъективных мнений, продвижения личных интересов или прямом копировании конкурентов, что подрывает стратегическую работу с бэклогом.
• Лишние функции. В попытке «добавить больше» продукт обрастает функциями, которые не нужны 80% пользователей. Это увеличивает сложность продукта, снижает воспринимаемую ценность.
• Потеря связи с рынком. Если команда фокусируется на фичах, она конкурирует по принципу «у кого длиннее список фич». В результате продукт копирует функции конкурента вместо поиска нового решения для проблемы клиента.

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

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

Дарья Щурик, Head of Growth Greeneration.ae

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

Какие фреймворки помогают понять, что продукт нужен рынку 

Фреймворки ценности — это методики, которые позволяют перевести «ощущения» в проверяемую стратегию и задачи: когда/почему пользователи будут пользоваться продуктом и за что они готовы платить.

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

Дарья Щурик, Head of Growth Greeneration.ae

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

JTBD (Jobs To Be Done)

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

JTBD (jobs-to-be-done) — это подход, который помогает понять, какую «работу» пользователь пытается выполнить в конкретном контексте: что он делает, какие альтернативы использует.

Дарья Щурик, Head of Growth Greeneration.ae

Работа всегда строится по шаблону:

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

• вместо: «Реализовать фильтр по меткам»;
• команда формулирует: «Дать менеджеру возможность мгновенно находить задачи, чтобы он не тратил более 10 секунд на поиск». 

Если команда не может провести масштабное исследование, то можно провести экспресс-интервью и продумать несколько корневых «работ» (jobs), продукта. 

Экспресс-интервью обычно проводят в 3 этапа:

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

Формулировка «работ». На основе job создают 5-7 четких, проверяемых формулировок JTBD, которые отражают реальную потребность. Каждый job можно записать в виде карточки в таск-трекере и разместить в бэклоге.

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

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

Сначала сделайте JTBD-интервью, чтобы выявить реальные работы и поведенческий контекст пользователя. Затем переносите инсайты в Value Proposition Canvas, чтобы сформулировать предложение и выстроить гипотезы.

Дарья Щурик, Head of Growth Greeneration.ae

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

Value Proposition Canvas (VPC)

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

Value Proposition Canvas (канва ценностного предложения) — инструмент для систематизации. Сначала вы выясняете, кто клиент, какие у него боли и выгоды, и какое конкретное решение вы предлагаете. VPC хорош для проектирования самого продукта, а потом для маркетинговых сообщений и гипотез, которые вы будете тестировать.

Дарья Щурик, Head of Growth Greeneration.ae

VPC состоит из 2 основных блоков: профиль потребителя и карта ценности.

С правой стороны собирают профиль клиента:

• Работы (jobs). Что клиент пытается сделать? Это работа (job) из концепции JTBD. 
• Боли (pains). Что расстраивает клиента, мешает ему выполнить работу или представляет для него риск.
• Выгоды (gains). Что клиент хочет получить или ожидает сверх простого выполнения задачи. 

С левой стороны описывают решение — карту ценности:

• Продукты и услуги (features). Какие функции вы предлагаете.
• Обезболивающие (pain relievers). Как ваши продукты/услуги устраняют или смягчают конкретные боли клиента.
• Создатели выгоды (gain). Как ваши продукты или услуги создают конкретные выгоды (радости) для клиента.

Основная цель работы с VPC — обеспечить, чтобы ваши решения максимально эффективно закрывали ключевые потребности клиента. 

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

Дарья Щурик, Head of Growth Greeneration.ae

Стороны должны соответствовать друг другу и составлять связку — «fit»:

Внимание. Если нет убедительных связок «Pain → Pain reliever» для 3-5 самых больших болей клиента, значит, нет fit. Нужно составлять VPC заново, так как ресурсы тратятся впустую.

Job To Be Done и VPC помогают нам понять, что мы должны делать и для кого. Осталось понять, какой результат (outcome) пользователь считает идеальным, и насколько наше решение ему соответствует. В этом помогает измеримая метрика — ODI.

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

Дарья Щурик, Head of Growth Greeneration.ae

Outcome-Driven Innovation (ODI)

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

Желаемый результат (desired outcome) — это формулировка результата в измеримых терминах на основе данных из сервисов и обратной связи, по которым сам пользователь оценивает выполнение работы:

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

Каждый outcome формулируется по шаблону:

Благодаря ODI команда присваивает каждому outcome рейтинг вероятности. Обычно он строится на основе 2 характеристиках от пользователей:

• важность — насколько этот результат критичен для клиента;
• удовлетворенность — насколько хорошо текущее решение справляется с задачей.

Обычно пользователи оценивают важность и удовлетворенность по шкале от 0 до 10, а команда — собирает результаты в таблицу. Приведем пример:

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

Мы заменяем вопрос «нравится?» на проверку поведения и готовности платить: сокращается ли время до результата, растут ли повторы, готовы ли к предоплате

Дарья Щурик, Head of Growth Greeneration.ae

Как измерить успех: связываем метрики

Ценность для пользователя в конечном итоге должна конвертироваться в ценность для бизнеса, выраженную в росте и удержании. Фреймворки JTBD, VPC и ODI создают единую, неразрывную цепочку, которая переводит абстрактную потребность в конкретные метрики.

Для каждой ключевой работы (job) и связанного с ней outcome нужно определить:

• эксперимент/рычаг — функция, которая по нашим ожиданиям повлияет на outcome; 
• leading-сигнал — метрика, которая быстро меняется и показывает, что пользователь изменил свое поведение в ответ на нашу новую функцию;
• lagging-показатель — конечная метрика, которая доказывает, что изменение поведения помогло достигнуть outcome, а бизнес получил ценность;
• гардрейлы — метрики, которые нельзя «уронить», чтобы не допустить негативных последствий.

Важно. Решение по гипотезе можно принять с помощью leading-сигнала через 1-2 недели. 

Проще добиться успеха, если все фреймворки синхронизированы в таком порядке:

Приведем пример, как может выглядеть процесс:

• JTBD → VPC. Команда определяет, что пользователь «нанимает» сервис для «быстрого получения сводки по статусу проекта» — job. Теперь можно заполнить правую часть VPC — боли («нужно 4 часа на сбор данных») и выгоды («сохранить репутацию»).
• VPC → outcomes. Команда трансформирует боли и выгоды в измеримые outcomes. Так появляется формулировка «Уменьшить время, необходимое для сбора данных, с 4 часов до 15 минут». 
• Outcomes → приоритеты. Если outcomes имеет высокий рейтинг, нужно поставить задачу для его выполнения.
• Измерение. Команда контролирует, как быстро после выпуска фичи растет Leading-сигнал и как он влияет на Lagging-показатель.

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

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

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

Дарья Щурик, Head of Growth Greeneration.ae

Частые ошибки внедрения фреймворков

С какими ошибками сталкиваются чаще всего даже самые мотивированные команды:

• Неправильная выборка (не те люди). Если проводить интервью с неактивными, слишком новыми или «счастливыми» пользователями, можно получить искаженную картину болей и выгод. Истинная ценность часто скрыта в историях тех, кто пытался, но не смог выполнить работу.
• Интервью про мнения, не про факты. Не стоит задавать вопросы типа «Как вы думаете, вам понравится новая функция» — это сбор мнений. Всегда спрашивайте о прошлом опыте и конкретном контексте, собирайте факты.   
• Слишком много «работ» сразу. Попытка определить и обслуживать 10–15 ключевых JTBD одновременно приводит к распылению ресурсов. Лучше сузить фокус на 1-3 «работах» внутри одной итерации.  
• Vanity-метрики вместо реальных результатов. Измерение успеха по активности, не связанной с ценностью (например, количество кликов по кнопке). Нужно измерять outcomes — результат для пользователя.
• Нет критериев успеха до запуска. Если команда не определила заранее конкретные leading-сигналы в карточке задачи, то не сможет понять, сработал эксперимент или нет.

«Канвасы ради канвасов». VPC или ODI в красивой таблице без переноса pains, gains и outcomes в виде тегов или полей в задачи создает разрыв между стратегией и исполнением. Так разработчик будет видеть «Сделать кнопку», а не «устранить боль, которая приводит к отказу от покупки».

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

Дарья Щурик, Head of Growth Greeneration.ae

Заключение

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