Когда product owner задумывается о развитии продукта и повышении его ценности для клиентов, сравнение обычно идет с тем, что предлагают конкуренты. И вот почему этого недостаточно:
Клиент не делает буквальный выбор между продуктами А и Б — он хочет решить свою задачу. И для этого у него может оказаться гораздо больше возможностей, чем кажется при анализе текущей ситуации на рынке.
Простой пример. Допустим, наша компания производит сушилки для обуви: мы много работаем над дизайном, бьемся за снижение энергопотребления и делаем провод, который не перегрызет собака. Мы смотрим на сушилки конкурентов и стараемся сделать лучше.
А теперь представьте, что вы попали под дождь. Не впервые за это лето, и в этот раз пообещали себе точно не забыть купить сушилку. Но тут вам на глаза попадается газета, из тех что вечно оказываются в почтовом ящике, — и это тоже способ решить вашу проблему. И вот уже бесплатная газета становится конкурентом сушилок производителя А, и Б, и С. А еще можно поставить обувь к батарее — не самый бережный метод, но и это тоже конкурентный способ решить проблему клиента.
Поэтому мы рекомендуем при разработке стратегии развития продукта, помимо анализа текущего поведения пользователей и сравнения с предложениями конкурентов, учитывать любые альтернативы, которые позволят клиенту решить свои задачи.
❓ А какие неочевидные альтернативы есть у вашего продукта?
верно, и хорошие маркетологи об этом, конечно, знают :) но когда речь идет о переходе к самоорганизации (например, в компании запускается продуктовая Scrum команда), важно, чтобы о клиенте и его потребностях думали все в команде, даже те, у кого нет профильного образования.
В зависимости от стиля менеджмента, в рамках которого они работают. Если им кто-то просто ставит технические задачи - то вообще не нужно, здесь вы правы (за них думают о продукте). Если они работают над продуктом в контексте Scrum команды - то нужно понимать, что и зачем ты делаешь, чтобы на выходе получилось классное для клиента решение (вместе с ними думают о продукте).
У вас в посте четко обозначена роль Product Owner. Об этом думает он! Devops и Back-Endер не обучен думать о конкурентах, да и ему это прироста не даст)
но когда речь идет о переходе к самоорганизации (например, в компании запускается продуктовая Scrum команда), важно, чтобы о клиенте и его потребностях думали все в команде, даже те, у кого нет профильного образования.
Если им кто-то просто ставит технические задачи - то вообще не нужно, здесь вы правы (за них думают о продукте).
Если они работают над продуктом в контексте Scrum команды - то нужно понимать, что и зачем ты делаешь, чтобы на выходе получилось классное для клиента решение (вместе с ними думают о продукте).