Комментарии 2
Нальешь кружечку чая, откусишь печеньку — и оп, статья закончилась ))
Думаю, очевидно, что на разном уровне у вас просто разный продукт, не так ли? Для команды компоненты: продукт — это компонента, для команды биллинга — это биллинг. Если биллинг использует компоненту, то он по сути выступает заказчиком на некоторые фичи компоненты, и соответственно получает ценность компоненты.
Команда, реализующая продвижение какой-то услуги вашей компании, для которой продукт — продажа услуги, будет по сути заказчиком для биллинга, чтобы были нужные опции расчетов.
Но вы в статье говорите, что продукт — это не биллинг, и не система подбора услуг, где есть скрам-мастер и продукт-owner. А есть некий «мега-продукт», который несет «ценность». Т.е. вы просто перешли на уровень абстракции выше, когда соединение нескольких систем дает удобство для клиента? И продукт есть feature, который как раз дает добавленную стоимость (как денежное выражение ценности для клиентов)?
Отсюда следующий вопрос. Т.е. как происходит организация команд для реализации мега-продуктов? Т.е. остается ли команда, которая, например, занимается тем же биллингом.
Думаю, очевидно, что на разном уровне у вас просто разный продукт, не так ли? Для команды компоненты: продукт — это компонента, для команды биллинга — это биллинг. Если биллинг использует компоненту, то он по сути выступает заказчиком на некоторые фичи компоненты, и соответственно получает ценность компоненты.
Команда, реализующая продвижение какой-то услуги вашей компании, для которой продукт — продажа услуги, будет по сути заказчиком для биллинга, чтобы были нужные опции расчетов.
Но вы в статье говорите, что продукт — это не биллинг, и не система подбора услуг, где есть скрам-мастер и продукт-owner. А есть некий «мега-продукт», который несет «ценность». Т.е. вы просто перешли на уровень абстракции выше, когда соединение нескольких систем дает удобство для клиента? И продукт есть feature, который как раз дает добавленную стоимость (как денежное выражение ценности для клиентов)?
Отсюда следующий вопрос. Т.е. как происходит организация команд для реализации мега-продуктов? Т.е. остается ли команда, которая, например, занимается тем же биллингом.
Я пока сфокусировался на том, чтобы писать понятно и не сложно. Как только у меня начнет это получаться — буду писать длиннее, может даже на несколько печенек хватит.
Вот именно это и побудило меня написать первую статью. Никто не понимает точно, что нужно считать продуктом, а что просто промежуточная компонента. В итоге некоторые владельцы продуктов по сути являются аналитиками, просто расписывающими юзер стори для команд.
Сейчас я склонен считать, что продукт определяется только тем, что он решает какую-то конечную задачу для определенной группы пользователей. Подробнее я планировал раскрыть эту мысль в часте про пользователей. Там, с помощью подхода JTBD можно будет наглядно увидеть как формируется ценность того или иного продукта.
Биллинг, конечно тоже имеет ценность в контексте оказания услуги, но его роль в сценарии использования в большинстве известных мне случаев будет на уровне подфункции. Про уровни целей пользователя очень хорошо писал Алистер Коберн. Постараюсь это подробно объяснить в четвертой части этого цикла.
Чуть-чуть терпения. Про организацию команд, координацию работы продактов и наиболее популярные фреймворки я еще расскажу.
Для команды компоненты: продукт — это компонента, для команды биллинга — это биллинг.
Вот именно это и побудило меня написать первую статью. Никто не понимает точно, что нужно считать продуктом, а что просто промежуточная компонента. В итоге некоторые владельцы продуктов по сути являются аналитиками, просто расписывающими юзер стори для команд.
Сейчас я склонен считать, что продукт определяется только тем, что он решает какую-то конечную задачу для определенной группы пользователей. Подробнее я планировал раскрыть эту мысль в часте про пользователей. Там, с помощью подхода JTBD можно будет наглядно увидеть как формируется ценность того или иного продукта.
Биллинг, конечно тоже имеет ценность в контексте оказания услуги, но его роль в сценарии использования в большинстве известных мне случаев будет на уровне подфункции. Про уровни целей пользователя очень хорошо писал Алистер Коберн. Постараюсь это подробно объяснить в четвертой части этого цикла.
Т.е. как происходит организация команд для реализации мега-продуктов?
Чуть-чуть терпения. Про организацию команд, координацию работы продактов и наиболее популярные фреймворки я еще расскажу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Масштабируем продакт-менеджмент, часть 2: продукт