Анализ продуктов конкурентов

Когда product owner задумывается о развитии продукта и повышении его ценности для клиентов, сравнение обычно идет с тем, что предлагают конкуренты. И вот почему этого недостаточно:

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

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

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

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

А какие неочевидные альтернативы есть у вашего продукта?

6 comments

Это было написано ещё 20 лет назад в любой книге по маркетингу! Называется «непрямые конкуренты»
Алексей Ивакин
Это было написано ещё 20 лет назад в любой книге по маркетингу! Называется «непрямые конкуренты»
верно, и хорошие маркетологи об этом, конечно, знают :)
но когда речь идет о переходе к самоорганизации (например, в компании запускается продуктовая Scrum команда), важно, чтобы о клиенте и его потребностях думали все в команде, даже те, у кого нет профильного образования.
"Jobs to be done" как раз об этом
Алексей Ивакин
И нафига back-end разработчику или DevOpsУ знать о непрямых конкурентах продукта?
В зависимости от стиля менеджмента, в рамках которого они работают.
Если им кто-то просто ставит технические задачи - то вообще не нужно, здесь вы правы (за них думают о продукте).
Если они работают над продуктом в контексте Scrum команды - то нужно понимать, что и зачем ты делаешь, чтобы на выходе получилось классное для клиента решение (вместе с ними думают о продукте).