Ну что же, уже больше сотни комментариев, напишу свой вариант. | No Flame No Game
Ну что же, уже больше сотни комментариев, напишу свой вариант.
Ценообразование.
В моей выборке были и сильные продакты-эксперты, и классные руководители, построившие хорошие продуктовые команды. Но почему-то практически во всех случаях ценообразование случалось по одной из двух схем:
1. Либо какая-то отдельная команда (маркетинг или growth) уже пост-фактум смотрела на весь созданный фича-зоопарк и налепливала сверху ценник;
2. Либо сам продакт смотрел на конкурентов и их тарификацию, и принимал решение о приоритизации фич на основе планов конкурентов.
В большинстве случаев прайсинг считался уделом маркетинговой команды и происходил в отрыве от продуктовой разработки. В лучшем случае, маркетинг делился своими инсайтами с продактом, который учитывал эти данные при создании роадмапа.
Но никто из моей выборки не дизайнил продукт вокруг цены.
Давайте разберем на примере, почему это плохо. Предположим, я делаю приложение для to-do листов, которое стоит 10 долларов в месяц. Стоит ли мне добавить интеграцию с календарем? Или работать над улучшением UX? Может, инвестировать в автоматизацию тех поддержки? Или просто поднять цену (и знать, что пользователи не уйдут)? Если мы думаем про ценность в отрыве от цены (и наоборот), то
- мы скоро упремся в локальный максимум и выйдем на плато
- мы не сможем адекватно приоритизировать и оценить решения выше
- вероятно, у нас будет feature factory, где мы предполагаем, что “счастье” и ретеншн пользователя напрямую коррелирует с количеством функционала (нет).
Чтобы принять решение по роадмапу для приложения, мне нужно понимать:
- какую ценность оно дает пользователям и сколько за эту ценность они готовы платить (willingness to pay// WTP)?
- какой разрыв между текущей ценой и WTP, и какая эластичность цены?
- какие у нас издержки на каждого дополнительного пользователя?
Если у нас есть эта информация, мы можем посчитать ценность каждого улучшения для пользователя и, соответственно, для бизнеса.
Чем мне нравится определение продукта через “jobs to be done”, так это как раз связкой ценности и цены. Работа = “результат” + “сколько он стоит”. Условно, ты не будешь нанимать уборщика за $400, даже если он умеет вышивать на машинке и петь йодлем, если для тебе нужна просто убранная квартира, которая “стоит” $100. Но вот в продуктовой разработке такое происходит сплошь и рядом. Мы “раздаем” фичи, которые в глазах пользователей имеют более высокую ценность, чем текущая цена, и мы делаем фичи, которые решают определенные задачи, но не увеличивают финальную ценность.
Хочу дальше рассказать про связку сегмент-WTP-price-cost; про то, как посчитать ценность новой фичи; про то, как проводить исследования про ценность-цену в рамках продуктовой разработки. Интересна тема? С чего начать?
