Приоритизация бэклога
Контест:
Работу над продуктом перевели на Скрамо-подобный процесс. Мне как владельцу продукта нужно привести бэклог продукта в порядок, т.е. определить то, что мы отправим в Discovery процесс, а что в Delivery + всё это нужно приоритизировать и представить картинку бизнесу и команде в ближашую неделю.
Шаги:
1) Смотрим в бэклог продукта (можно в одиночку, а лучше командой), ищем около десятка элементов (задач, пользовательских историй, улучшайзеров и т.д.) в которых сомневаемся с точки зрения их ценности для пользователя или бизнеса. По каждому элементу делаем короткую заметку - в чем конкретно сомневаемся, в технологии реализации, несоизмеримости трудозатрат с эффектом от реализации и т.д. Так мы сформируем потенциальный список для Discovery.
2) Далее возвращаемся в бэклог и ищем лучших претендентов для ближайшей спринтов. Ориентируйтесь на возможности команды, выбираем элементы на 2-3 спринта. Потенциальные кандидаты в Delivery.
3) Размышляем об эффекте на бизнес при реализации выбранных элементов в обоих списках. Т.е. ищет ответ на вопрос, что поменяется в бизнесе после реализации и насколько, когда это произойдет и как вы будете отслеживать это (a.k.a. метрики). На основе этих предположений касательно эффекта и трудозатрат делаем скоринг, например с помощью ICE приоритизации.
4) Если у нас нет четко сформулированных целей от бизнеса (так называют больших и не очень боссов, которые отвечают за бюджеты), то на основе шага №3 формулируем собственные цели и метрики. Если же цели и метрики от бизнеса есть, и наш взляд отличается, то замечательно, следующий шаг будет интересней.
5) Собираем встречу команды с бизнесом, где рассказываем о наших планах, целях и метриках. Если взгляд команды и бизнеса расходится, то произойдет магия взаимного обмена мнениями и взглядами на развитие продукта. Если команда и бизнес одинаково смотрят на цели и планы их достижения, то произойдет синхронизация. В любом случае, команда и бизнес будут чувствовать себя уверенней касательно будущего развития продукта.
Контест:
Работу над продуктом перевели на Скрамо-подобный процесс. Мне как владельцу продукта нужно привести бэклог продукта в порядок, т.е. определить то, что мы отправим в Discovery процесс, а что в Delivery + всё это нужно приоритизировать и представить картинку бизнесу и команде в ближашую неделю.
Шаги:
1) Смотрим в бэклог продукта (можно в одиночку, а лучше командой), ищем около десятка элементов (задач, пользовательских историй, улучшайзеров и т.д.) в которых сомневаемся с точки зрения их ценности для пользователя или бизнеса. По каждому элементу делаем короткую заметку - в чем конкретно сомневаемся, в технологии реализации, несоизмеримости трудозатрат с эффектом от реализации и т.д. Так мы сформируем потенциальный список для Discovery.
2) Далее возвращаемся в бэклог и ищем лучших претендентов для ближайшей спринтов. Ориентируйтесь на возможности команды, выбираем элементы на 2-3 спринта. Потенциальные кандидаты в Delivery.
3) Размышляем об эффекте на бизнес при реализации выбранных элементов в обоих списках. Т.е. ищет ответ на вопрос, что поменяется в бизнесе после реализации и насколько, когда это произойдет и как вы будете отслеживать это (a.k.a. метрики). На основе этих предположений касательно эффекта и трудозатрат делаем скоринг, например с помощью ICE приоритизации.
4) Если у нас нет четко сформулированных целей от бизнеса (так называют больших и не очень боссов, которые отвечают за бюджеты), то на основе шага №3 формулируем собственные цели и метрики. Если же цели и метрики от бизнеса есть, и наш взляд отличается, то замечательно, следующий шаг будет интересней.
5) Собираем встречу команды с бизнесом, где рассказываем о наших планах, целях и метриках. Если взгляд команды и бизнеса расходится, то произойдет магия взаимного обмена мнениями и взглядами на развитие продукта. Если команда и бизнес одинаково смотрят на цели и планы их достижения, то произойдет синхронизация. В любом случае, команда и бизнес будут чувствовать себя уверенней касательно будущего развития продукта.
Уcпокаиваем возбужденный бизнес
Пару раз в месяц нахожусь на сессиях, где "бизнес" жестко просит команды взять обязательства по реализации определенного функционала. Мол, ребята это очень важно, каждый день на счету, будем недополучать по ХХ миллионов в месяц. Когда замечаю по лицам участников, что начинается "прогибание 🥺", то закидывают в возбужденный мозг бизнеса следующую фразу:
"Имя Отчество, вы так серьезно спрашиваете за сроки реализации 💁♀️, а что будет, если мы не по ХХ миллионов будем зарабатывать в месяц после реализации, а меньше в 2 или 3 раза? Вы свою квартиру московскую будете продавать или от бонуса откажитесь?" 🤔😅
Накал страстей резко идет на спадает и разговор становится более конструктивным.
Пару раз в месяц нахожусь на сессиях, где "бизнес" жестко просит команды взять обязательства по реализации определенного функционала. Мол, ребята это очень важно, каждый день на счету, будем недополучать по ХХ миллионов в месяц. Когда замечаю по лицам участников, что начинается "прогибание 🥺", то закидывают в возбужденный мозг бизнеса следующую фразу:
"Имя Отчество, вы так серьезно спрашиваете за сроки реализации 💁♀️, а что будет, если мы не по ХХ миллионов будем зарабатывать в месяц после реализации, а меньше в 2 или 3 раза? Вы свою квартиру московскую будете продавать или от бонуса откажитесь?" 🤔😅
Накал страстей резко идет на спадает и разговор становится более конструктивным.
🤔2
Придаём веса оценкам Бизнес Ценности
Контекст #1:
У вас большой продукт, несколько штук или десятков команд. Всё как обычно не влезет, и далее начинается приоритизация: "А что это даст бизнесу?". Чтобы выбрать самые жирные элементы, продакт или бизнес, дают свои оценки бизнес ценности. Например оценка 10, что является эквивалентом 50М дополнительной выручки. И чтобы твои задачи попали в ближайший квартал, порой можно пробежаться по скользкой дорожке и чуток завысить эти оценки. Всё равно разбираться никто на таких встречах не будет.
Контекст #2:
Вы используете RICE или ICE приоритизацию бэклога и вы хотите понять какую практическую пользу несет в себе параметр "С - Confidence или уверенность в оценках".
Эти два кейса связывает то, что наприер WSJF можно усилить параметром "С", и тем самым снизить влияние напыщенных оценок. Давайте разбираться 💁♀️
Confidence может быть рассмотрена со точки зрения discovery процесса. Другими словами, какие есть основания давать такую оценку. А далее мы формируем шкалу уверенности от 10% до 100%.
Confidence может иметь следующий вид:
0.1 - верит только продакт, больше никто 👀
0.2 - верит команда, но не верит продакт
0.3 - верит продакт и команда
0.4 - верит продакт, команда, бизнес и эксперты
---- далее только на вере 🙏 не поднимемся ----
0.5 - есть косвенные данные: рынок, конкуренты, тренды
0.6 - есть данные: использование продукта, поддержка
---- далее оценки при наличии экспериментов👩🔬 ---
0.7 - проведенные эксперименты/исследования/пилоты
0.8 - продакт и команда согласны в результатами экспериментов
0.9 - продакт, команда, бизнес и эксперты согласны в результатами экспериментов
---- далее только для гуру ----
1.0 - вы считаете себя пророком 🔮
Такой простой финт, позволяет придать серьезности оценкам.
P.S.: если в постах вы встречаете незнакомые для себя термины, то прояснить их вы можете в Глоссарий владельца продукта💁
Контекст #1:
У вас большой продукт, несколько штук или десятков команд. Всё как обычно не влезет, и далее начинается приоритизация: "А что это даст бизнесу?". Чтобы выбрать самые жирные элементы, продакт или бизнес, дают свои оценки бизнес ценности. Например оценка 10, что является эквивалентом 50М дополнительной выручки. И чтобы твои задачи попали в ближайший квартал, порой можно пробежаться по скользкой дорожке и чуток завысить эти оценки. Всё равно разбираться никто на таких встречах не будет.
Контекст #2:
Вы используете RICE или ICE приоритизацию бэклога и вы хотите понять какую практическую пользу несет в себе параметр "С - Confidence или уверенность в оценках".
Эти два кейса связывает то, что наприер WSJF можно усилить параметром "С", и тем самым снизить влияние напыщенных оценок. Давайте разбираться 💁♀️
Confidence может быть рассмотрена со точки зрения discovery процесса. Другими словами, какие есть основания давать такую оценку. А далее мы формируем шкалу уверенности от 10% до 100%.
Confidence может иметь следующий вид:
0.1 - верит только продакт, больше никто 👀
0.2 - верит команда, но не верит продакт
0.3 - верит продакт и команда
0.4 - верит продакт, команда, бизнес и эксперты
---- далее только на вере 🙏 не поднимемся ----
0.5 - есть косвенные данные: рынок, конкуренты, тренды
0.6 - есть данные: использование продукта, поддержка
---- далее оценки при наличии экспериментов👩🔬 ---
0.7 - проведенные эксперименты/исследования/пилоты
0.8 - продакт и команда согласны в результатами экспериментов
0.9 - продакт, команда, бизнес и эксперты согласны в результатами экспериментов
---- далее только для гуру ----
1.0 - вы считаете себя пророком 🔮
Такой простой финт, позволяет придать серьезности оценкам.
P.S.: если в постах вы встречаете незнакомые для себя термины, то прояснить их вы можете в Глоссарий владельца продукта💁
Погружение в клиентов. Где твоя гипотеза? (1/3)
Контекст:
Нам сказали или мы решили, что нужно проводить "КастДев" клиентов, другими словами начать проводить глубинные интервью с клиентами.
С чего начать и как это устроить?
Для начала отвечаем на вопрос:
"А зачем вам проводить исследование клиентов?"
Хорошим ответом будет:
"Проверить гипотезы, касательно развития продукта 💁♀️"
Слабеньким ответом будет:
"Узнать что-то новое о наших клиентах 🧐"
Слабенький, потому что ответ сигнализирует об отсутствии фокуса исследования. Если слышу такой ответ, то мучаю продакта вопросами: Что конкретно ты хочешь узнать? А почему именно это? Так мы рождаем гипотезы 👩🏼⚕️
Как только гипотеза появляется на свет, определяем её тип:
Гипотеза проблемы:
Мы предполагаем, что:
- в клиентском опыте есть проблемы/сложности
- текущие потребности клиентов не закрываются в полной мере
- у клиентов есть незакрытые потребности
Гипотеза решения:
Мы предполагаем, что:
- сможем разработать решение (технологические риски)
- решение сработает (функциональные риски)
- клиент останется довольным
Гипотеза ценности:
Мы предполагаем, что:
- клиент нам заплатит (конверсия в покупку)
- клиент к нам вернется (Retention)
- у нас сойдется экономика
Гипотеза роста:
Мы предполагаем, что:
- клиенты будут нас рекомендовать (Virality)
- найдем канал привлечения
- улучшим конверсии в канале (конверсия в покупку)
Глубинные интервью, замечательно подходят для проверки Гипотез проблем. Следовательно, если нам явилась гипотеза друго типа, то вам стоит откатить её до гипотезы проблемы.
Пример для наглядности:
Первоначальная гипотеза
Мы предполагаем, что клиенты банка будут больше покупать бытовe. электронику, если банк даст им возможность покупки с кэшбеком.
По формулировке это гипотеза решения.
Мучаем продакта вопросами, с чего он это взял, что клиенты станут больше покупать именно бытовую электронику. Он раскалывается и сообщает, что в банке есть YXZ клиентов, которые снимают редко (раз в 3-6 мес) крупные сумму денег (от 50К до 150К). Он подумал, что эти деньги идут на покупку бытовой электроники, потому что есть магазины, которые продают технику за наличку дешевле, чем за безнал. А значит, если клиентам банка дать возможность купить технику за примерно за те же деньги, то они не будут снимать наличку и беспокоиться за такие сделки.
Так акушер получает целые две гипотезы проблемы:
1) Мы предполагаем, что клиенты банка снимают крупные суммы наличных для покупки бытовой техники.
2) Мы предполагаем, что покупая бытовую технику за наличку, клиент испытывает дискомфорт и беспокойство касательно таких сделок.
Эти гипотезы, мы точно можем проверять с помощью интервью.
Как только вы сформулируете гипотезы проблем, с которыми сталкиваются ваши клиенты, задайте себе вопрос. А есть ли у нас данные, которые позволят проверить гипотезу без интервью, иногда такие прецеденты встречаются на практике. Если же данных нет, то переходим к процессу экипировки гипотезы (2/3), а после к подготовке вопросов для интервью (3/3).
P.S.: в России "Customer Development a.k.a Касдев" называют проведение глубинных интервью с клиентами, что является нелепым недоразумением, так как проведение интервью это один из способов понять мир клиента.
Контекст:
Нам сказали или мы решили, что нужно проводить "КастДев" клиентов, другими словами начать проводить глубинные интервью с клиентами.
С чего начать и как это устроить?
Для начала отвечаем на вопрос:
"А зачем вам проводить исследование клиентов?"
Хорошим ответом будет:
"Проверить гипотезы, касательно развития продукта 💁♀️"
Слабеньким ответом будет:
"Узнать что-то новое о наших клиентах 🧐"
Слабенький, потому что ответ сигнализирует об отсутствии фокуса исследования. Если слышу такой ответ, то мучаю продакта вопросами: Что конкретно ты хочешь узнать? А почему именно это? Так мы рождаем гипотезы 👩🏼⚕️
Как только гипотеза появляется на свет, определяем её тип:
Гипотеза проблемы:
Мы предполагаем, что:
- в клиентском опыте есть проблемы/сложности
- текущие потребности клиентов не закрываются в полной мере
- у клиентов есть незакрытые потребности
Гипотеза решения:
Мы предполагаем, что:
- сможем разработать решение (технологические риски)
- решение сработает (функциональные риски)
- клиент останется довольным
Гипотеза ценности:
Мы предполагаем, что:
- клиент нам заплатит (конверсия в покупку)
- клиент к нам вернется (Retention)
- у нас сойдется экономика
Гипотеза роста:
Мы предполагаем, что:
- клиенты будут нас рекомендовать (Virality)
- найдем канал привлечения
- улучшим конверсии в канале (конверсия в покупку)
Глубинные интервью, замечательно подходят для проверки Гипотез проблем. Следовательно, если нам явилась гипотеза друго типа, то вам стоит откатить её до гипотезы проблемы.
Пример для наглядности:
Первоначальная гипотеза
Мы предполагаем, что клиенты банка будут больше покупать бытовe. электронику, если банк даст им возможность покупки с кэшбеком.
По формулировке это гипотеза решения.
Мучаем продакта вопросами, с чего он это взял, что клиенты станут больше покупать именно бытовую электронику. Он раскалывается и сообщает, что в банке есть YXZ клиентов, которые снимают редко (раз в 3-6 мес) крупные сумму денег (от 50К до 150К). Он подумал, что эти деньги идут на покупку бытовой электроники, потому что есть магазины, которые продают технику за наличку дешевле, чем за безнал. А значит, если клиентам банка дать возможность купить технику за примерно за те же деньги, то они не будут снимать наличку и беспокоиться за такие сделки.
Так акушер получает целые две гипотезы проблемы:
1) Мы предполагаем, что клиенты банка снимают крупные суммы наличных для покупки бытовой техники.
2) Мы предполагаем, что покупая бытовую технику за наличку, клиент испытывает дискомфорт и беспокойство касательно таких сделок.
Эти гипотезы, мы точно можем проверять с помощью интервью.
Как только вы сформулируете гипотезы проблем, с которыми сталкиваются ваши клиенты, задайте себе вопрос. А есть ли у нас данные, которые позволят проверить гипотезу без интервью, иногда такие прецеденты встречаются на практике. Если же данных нет, то переходим к процессу экипировки гипотезы (2/3), а после к подготовке вопросов для интервью (3/3).
P.S.: в России "Customer Development a.k.a Касдев" называют проведение глубинных интервью с клиентами, что является нелепым недоразумением, так как проведение интервью это один из способов понять мир клиента.
❤1
Погружение в клиентов. Экипировка гипотезы. (2/3)
Гипотезы, которые были представлены в прошлом посте, мягко говоря голые, потому что практическая польза от них в таком виде нулевая. Преображение гипотезы происходит добавлением таких элементов как способ проверки (1), границы исследования (2), критерии успеха (3) и план действий (4).
Голая гипотеза:
Клиенты, оформившие карту с лендинга, плохо понимают систему лояльности банка.
Так как мы уже определились со способом проверки: Интервью с клиентами, то переходим к определению границ исследования:
- кого исследуем?
Клиентов оформивших карту не более 3 месяцев назад, которые совершили по карте от 30 транзакций на общую сумму от 50К.
- количество исследуемых?
20 клиентов.
- что собираем/исследуем?
Ответы на тему: условия кэшбека и бесплатное обсуживание.
Далее переходим к самой щекотливой теме - критерии успеха.
Как поймём, что мы правы? Другими словами, какие нужно получить данные в результате интервью, чтобы вы считали, что гипотеза подтверждена.
Более 10 клиентов не смогут правильно рассказать про любой блок системы лояльности либо отвечают "не знаю".
И венцом нашей экипировки является план действий, который необходимо выполнить для проверки гипотезы.
1. Выгрузить данные 500 клинетов, подходящих под критерий.
2. Проверить можно ли коммуницировать с данными клиентами, так останется примерно 100-150 клиентов.
3. Составить вопросы для интервью.
4. Провести интевью.
5. Проанализировать данные.
В таком шикарном виде, гипотезе не стыдно появиться перед бизнесом и командой. Следующий пост раскроет тему вопросов для интервью.
Гипотезы, которые были представлены в прошлом посте, мягко говоря голые, потому что практическая польза от них в таком виде нулевая. Преображение гипотезы происходит добавлением таких элементов как способ проверки (1), границы исследования (2), критерии успеха (3) и план действий (4).
Голая гипотеза:
Клиенты, оформившие карту с лендинга, плохо понимают систему лояльности банка.
Так как мы уже определились со способом проверки: Интервью с клиентами, то переходим к определению границ исследования:
- кого исследуем?
Клиентов оформивших карту не более 3 месяцев назад, которые совершили по карте от 30 транзакций на общую сумму от 50К.
- количество исследуемых?
20 клиентов.
- что собираем/исследуем?
Ответы на тему: условия кэшбека и бесплатное обсуживание.
Далее переходим к самой щекотливой теме - критерии успеха.
Как поймём, что мы правы? Другими словами, какие нужно получить данные в результате интервью, чтобы вы считали, что гипотеза подтверждена.
Более 10 клиентов не смогут правильно рассказать про любой блок системы лояльности либо отвечают "не знаю".
И венцом нашей экипировки является план действий, который необходимо выполнить для проверки гипотезы.
1. Выгрузить данные 500 клинетов, подходящих под критерий.
2. Проверить можно ли коммуницировать с данными клиентами, так останется примерно 100-150 клиентов.
3. Составить вопросы для интервью.
4. Провести интевью.
5. Проанализировать данные.
В таком шикарном виде, гипотезе не стыдно появиться перед бизнесом и командой. Следующий пост раскроет тему вопросов для интервью.
Погружение в клиентов. Вопросы для интервью. (3/3)
Подготовка вопросов к интервью, это считай 50% успеха.
Задавая правильно, правильные вопросы мы увеличиваем глубину изучения клиентского опыта. А чем глубже мы погружаемся в мир клиента, чем ценней находки мы сможем обнаружить.
Схема интервью текущих клиентов выглядит следующим образом:
"Интересующий кейс или сценарий использования" →
"Цели и мотивы" →
"Сложности в сценариии" →
"Опыт"
Для раскрытия первого блока можно использовать следующие вопросы:
1) Расскажите, как вы ..?
2) Расскажите про последний опыт подробнее ...?
3) Когда это было последний раз ...?
4) Как часто такое происходит ...?
Далее следует блок вопросов про "Цели и мотивы":
5) Зачем вам ....?
6) Почему это важно для вас?
7) Что вы перестали делать, используя наше решение?
8) Что вы начали делать/успевать, используя наше решение?
9) Насколько вы довольны текущей ситуацией?
После исследуем сложности и неудобства:
10) Какие сложности вы испытываете при достижении цели/результата?
11) Бывали ли ситуации, когда что-то пошло не так?
12) Когда это было последний раз?
13) Как часто вы сталкиваетесь с этой ситуацией?
14) Как это отражается на достижении цели/результатах?
15) Какие альтернативные решения вы уже пробовали?
Теперь осталось проверить, какой опыт имеет клиент в решении названных сложностей и неудобств:
16) Что вы делали, когда возникали эти сложности?
17) Как вы воспринимаете/относитесь к данным неудобствам?
18) Какие альтернативные решения вы уже пробовали?
19) Когда использовали альтернативу в последний раз?
20) Почему отказались от альтернатив?
21) Чем альтернативные решения лучше текущего?
Вооруженные базовыми вопросами, проводим их тчательный отбор и тюнинг согласно нашему контексту. Прошу вас не используйте весь арсенал вопросов за одну беседу, у вас же не романтический ужин с клиентом.
Возвращаясь к нашей прошлой гипотезе.
"Клиенты, оформившие карту с лендинга, плохо понимают систему лояльности банка."
Определяем темы, которые хотим исследовать:
1) Использует ли клиент выгоды от системы лояльности.
2) Понимает ли клиент, как работает система лояльности и кэшбека. (эта тема ключевая, так как проверяет гипотезу)
3) Важность системы лояльности для клиента.
4) Насколько клиент доволен системой лояльности.
5) Какие у него были сложности с системой лояльности.
Остальные темы, позволяют спуститься в мир клиента и найти новые идеи и гипотезы.
Далее накидываем дерево вопросов и потенциальных ответов. Отправляемся на интервью и по ходу шлифуем формулировки вопросов и варианты ветвлений диалогов с клиентами. Как правило после 3-4 интервью у вас появится отшлифованный гайд.
P.S.: готова черновая версия брошюры Исследование клиентов (руководство по глубинным интервью). Сейчас она у дизайнера 🙂
Если вы жаждете, как можно скорее получить варианты вопросов для исследования "Новых клиентов" и "Ушедших клиентов" + 💁♀️ у вас есть желание помочь с вычиткой материала, то дайте знать.
Подготовка вопросов к интервью, это считай 50% успеха.
Задавая правильно, правильные вопросы мы увеличиваем глубину изучения клиентского опыта. А чем глубже мы погружаемся в мир клиента, чем ценней находки мы сможем обнаружить.
Схема интервью текущих клиентов выглядит следующим образом:
"Интересующий кейс или сценарий использования" →
"Цели и мотивы" →
"Сложности в сценариии" →
"Опыт"
Для раскрытия первого блока можно использовать следующие вопросы:
1) Расскажите, как вы ..?
2) Расскажите про последний опыт подробнее ...?
3) Когда это было последний раз ...?
4) Как часто такое происходит ...?
Далее следует блок вопросов про "Цели и мотивы":
5) Зачем вам ....?
6) Почему это важно для вас?
7) Что вы перестали делать, используя наше решение?
8) Что вы начали делать/успевать, используя наше решение?
9) Насколько вы довольны текущей ситуацией?
После исследуем сложности и неудобства:
10) Какие сложности вы испытываете при достижении цели/результата?
11) Бывали ли ситуации, когда что-то пошло не так?
12) Когда это было последний раз?
13) Как часто вы сталкиваетесь с этой ситуацией?
14) Как это отражается на достижении цели/результатах?
15) Какие альтернативные решения вы уже пробовали?
Теперь осталось проверить, какой опыт имеет клиент в решении названных сложностей и неудобств:
16) Что вы делали, когда возникали эти сложности?
17) Как вы воспринимаете/относитесь к данным неудобствам?
18) Какие альтернативные решения вы уже пробовали?
19) Когда использовали альтернативу в последний раз?
20) Почему отказались от альтернатив?
21) Чем альтернативные решения лучше текущего?
Вооруженные базовыми вопросами, проводим их тчательный отбор и тюнинг согласно нашему контексту. Прошу вас не используйте весь арсенал вопросов за одну беседу, у вас же не романтический ужин с клиентом.
Возвращаясь к нашей прошлой гипотезе.
"Клиенты, оформившие карту с лендинга, плохо понимают систему лояльности банка."
Определяем темы, которые хотим исследовать:
1) Использует ли клиент выгоды от системы лояльности.
2) Понимает ли клиент, как работает система лояльности и кэшбека. (эта тема ключевая, так как проверяет гипотезу)
3) Важность системы лояльности для клиента.
4) Насколько клиент доволен системой лояльности.
5) Какие у него были сложности с системой лояльности.
Остальные темы, позволяют спуститься в мир клиента и найти новые идеи и гипотезы.
Далее накидываем дерево вопросов и потенциальных ответов. Отправляемся на интервью и по ходу шлифуем формулировки вопросов и варианты ветвлений диалогов с клиентами. Как правило после 3-4 интервью у вас появится отшлифованный гайд.
P.S.: готова черновая версия брошюры Исследование клиентов (руководство по глубинным интервью). Сейчас она у дизайнера 🙂
Если вы жаждете, как можно скорее получить варианты вопросов для исследования "Новых клиентов" и "Ушедших клиентов" + 💁♀️ у вас есть желание помочь с вычиткой материала, то дайте знать.
👍1
Многоликий User Experience 🎭
В управлении продуктами большой пласт работ связан с проектированием и улучшением пользовательского опыта. С первого взгляда эта область может показаться достаточно незатейливой, а при детальном расмотрении приобретает восемь очертаний:
- исследование пользователей
- поведенчиский дизайн
- модель взаимодейсвия
- юзабилити (эргономичность)
- графический дизайн
- промышленный дизайн
- дизайн интерфейсов
- техрайтинг (onboarding)
Исследование пользователей
Наблюдение за потенциальными пользователями в их обычных жизни для лучшего понимания их потребностей и стремлений.
Поведенческий дизайн
Создание целостной концептуальной модели продукта, которая является последовательной и простой в освоении и понимании. Поведенческий дизайн должен согласовать между собой: требования к продукту, результат получаевый в итоге с навыками, знаниями и возможностями предполагаемых пользователей.
Модель взаимодействия
Создания макетов, прототипов, систем, которые позволяют протестировать взаимодейсвие пользователя с решением.
Юзабилити (эргономичность)
Создание и тестирование сценариев использования разрабатываемых решений. Направлено для исследования удобства использования.
⚠️ Важное различие между Исследованиями пользователей и разработко Юзабилити. Исследования пользователей сосредоточены на прогнозировании поведения, а разработка юзабилити делает акцент на тестировании и оценки поведения пользователей.
Графический дизайн
Объединяет слова, символы и изображения для создания визуального представления идей и сообщений для целевой аудитории. Маркетинговые коммуникации, упаковка и реклама основные проявления графического дизайна.
Промышленный дизайн
Разработки решений направленых для улучшения эстетики, эргономики, функциональности и удобства физического использования продукта.
Дизайн интерфейсов
Разработки решений направленых для улучшения эстетики, эргономики, функциональности и удобства использования цифровых продуков.
Техрайтинг (onboarding)
Представление описания продукта или услуги, которое необходимо знать пользователю для использования решения.
Сложность области User Experience состоит в том, что без должного внимания хоть одной грани, вы рискуете обесценить пользовательский опыт который начинается до начала использования решения и продолжается после. И как вы уже догадались, все эти грани сложно вместить в одну голову, а следовательно требуют хорошо слаженной работы небольшой команды, в которой "Важно всё и неважно на сколько".
В управлении продуктами большой пласт работ связан с проектированием и улучшением пользовательского опыта. С первого взгляда эта область может показаться достаточно незатейливой, а при детальном расмотрении приобретает восемь очертаний:
- исследование пользователей
- поведенчиский дизайн
- модель взаимодейсвия
- юзабилити (эргономичность)
- графический дизайн
- промышленный дизайн
- дизайн интерфейсов
- техрайтинг (onboarding)
Исследование пользователей
Наблюдение за потенциальными пользователями в их обычных жизни для лучшего понимания их потребностей и стремлений.
Поведенческий дизайн
Создание целостной концептуальной модели продукта, которая является последовательной и простой в освоении и понимании. Поведенческий дизайн должен согласовать между собой: требования к продукту, результат получаевый в итоге с навыками, знаниями и возможностями предполагаемых пользователей.
Модель взаимодействия
Создания макетов, прототипов, систем, которые позволяют протестировать взаимодейсвие пользователя с решением.
Юзабилити (эргономичность)
Создание и тестирование сценариев использования разрабатываемых решений. Направлено для исследования удобства использования.
⚠️ Важное различие между Исследованиями пользователей и разработко Юзабилити. Исследования пользователей сосредоточены на прогнозировании поведения, а разработка юзабилити делает акцент на тестировании и оценки поведения пользователей.
Графический дизайн
Объединяет слова, символы и изображения для создания визуального представления идей и сообщений для целевой аудитории. Маркетинговые коммуникации, упаковка и реклама основные проявления графического дизайна.
Промышленный дизайн
Разработки решений направленых для улучшения эстетики, эргономики, функциональности и удобства физического использования продукта.
Дизайн интерфейсов
Разработки решений направленых для улучшения эстетики, эргономики, функциональности и удобства использования цифровых продуков.
Техрайтинг (onboarding)
Представление описания продукта или услуги, которое необходимо знать пользователю для использования решения.
Сложность области User Experience состоит в том, что без должного внимания хоть одной грани, вы рискуете обесценить пользовательский опыт который начинается до начала использования решения и продолжается после. И как вы уже догадались, все эти грани сложно вместить в одну голову, а следовательно требуют хорошо слаженной работы небольшой команды, в которой "Важно всё и неважно на сколько".
🔥2❤1
Go-To-Market Strategy (Стратегия выхода на рынок)
Ваша команда подготовила крупный релиз, запилила wow-фичу или вы готовы представить продукт широкой публике. Такие знаковые события, как правило требуют подготовки маркетинговых и sales мероприятий. Описание того, как продукт/super-обновление/killer-фича будет представлено рынку называют go-to-market strategy.
Если вам выпала возможность подготовить данное мероприятие, то следующие вопросы вам в помощь:
На какой конкретный сегмент рынка (ЦА) будет нацелен первоначальный запуск продукта?
Какая функциональность продукта требуется для запуска?
Какие планируются цены и тарифы во время запуска?
Какие каналы распространения будут использоваться?
Какие предполагаются скидки, бонусы, партнерские роялти на время запуска?
Какие ключевые идеи, образы, смыслы будут использоваться в рекламе, маркетинге и для позиционирования продукта?
Какие предполагается использовать каналы коммуникации?
Какие предполагаются мероприятия по обучению партнеров, лидеров мнений и т.д.?
Какие мероприятия предлагаются по обучению и поддержке первых клиентов?
Какие ресурсы необходимы для запуска?
Какими метриками будем определять успешность запуска?
Какой требуется бюджет на запуск?
Какой прогноз по выручке?
Ваша команда подготовила крупный релиз, запилила wow-фичу или вы готовы представить продукт широкой публике. Такие знаковые события, как правило требуют подготовки маркетинговых и sales мероприятий. Описание того, как продукт/super-обновление/killer-фича будет представлено рынку называют go-to-market strategy.
Если вам выпала возможность подготовить данное мероприятие, то следующие вопросы вам в помощь:
На какой конкретный сегмент рынка (ЦА) будет нацелен первоначальный запуск продукта?
Какая функциональность продукта требуется для запуска?
Какие планируются цены и тарифы во время запуска?
Какие каналы распространения будут использоваться?
Какие предполагаются скидки, бонусы, партнерские роялти на время запуска?
Какие ключевые идеи, образы, смыслы будут использоваться в рекламе, маркетинге и для позиционирования продукта?
Какие предполагается использовать каналы коммуникации?
Какие предполагаются мероприятия по обучению партнеров, лидеров мнений и т.д.?
Какие мероприятия предлагаются по обучению и поддержке первых клиентов?
Какие ресурсы необходимы для запуска?
Какими метриками будем определять успешность запуска?
Какой требуется бюджет на запуск?
Какой прогноз по выручке?
Стимул и реакция.
Во время проблемных интервью, исследователю важно узнать была ли негативная реакция, если была, то что её вызвало (стимул). Как мы знаем, у исследователей клиентов, любимым оружием являются вопросы. Многим известно, что существую открытые и закрытые вопросы, и что на интервью лучше задавать открытые вопросы, хотя это не всегда так. Предлагаю открыть бочёнок с медом и наполнить себя расширенным знанием темы вопросов и как можно доставать информацию о стимулах и реакциях клиента 🧐
Какие бывают вопросы:
- открытые
- полузакрытые
- закрытые
- наводящие (по стимулу / по эмоциям)
- общие
- частные
Контекст:
Вам нужно провести интервью клиентов, которые посещали офис банка на прошлой неделе. Мы хотим узнать насколько клиенты, довольны обслуживанием и где мы можем улучшить клиентский опыт.
Открытый вопрос:
Расскажите, о вашем опыте посещения отделения банка на прошлой неделе?
Открытые вопросы обычно свободны в отношении стимула и реакции, другими словами интервьюируемый сам определяет фокус своего внимания, причем он может сделать это в двух аспектах:
а) ответ может быть дан о каком-то этапе клиентского опыта: парковка у здания офиса, ожидание в очереди, общение со специалистом, операция в кассе и т.д. Или обо всем опыте посещения в целом.
б) ответ может быть содержать информацию о реакции клиента, на события которые происходили во время посещения офиса банка.
Варианты ответов:
- Мне понравилась скорость обслуживания (стимул и реакция)
- Всё было хорошо (реакция)
- Приехал, взял талон, подождал 30 сек., быстро решили вопрос. (стимул)
- Пришлось искать место для парковки. А так всё ок. (стимул и реакция)
Полузакрытые вопрос:
Подскажите, вам понравилось (реакция) посещение отделения банка на прошлой неделе?
Комментарий:
Вопрос свободный в отношении стимула, но не реакции, так как мы конкретизируем, что нас интересует негативная реакция. И если респондент отвечает "Нет" то, далее мы уточняем стимулы, которые создали такой опыт.
Так же, мы можем задать вопрос свободный в отношении реакции, но закрытый в отношении стимула:
Расскажите, как прошло обслуживание специалистом (стимул) по ипотеке?
Другими словами полузакрытые вопросы фиксируют либо стимул, либо реакцию в своей формулировке.
Закрытый вопрос:
Вам понравилось (реакция) обслуживание специалистом банка (стимул) во время вашего посещения банка на прошлой неделе?
Комментарий:
В вопросах этого типа интервьюер осуществляет контроль над вариантами ответов респондента, что позволяет быстро валидировать респондента и наличия у него проблемного опыта в интересующем кейсе. В закрытых вопросах фиксируются и стимул и реакция.
⚠️Важно помнить ⚠️
Если на закрытый или полузакрытый вопрос мы получаем интересующий нас отклик, то просим клиента рассказать подробнее про стимул или реакцию.
Наводящий вопрос может быть Открытым:
Расскажите, что вам понравилось (или не понравилось) во время посещения отделения банка на прошлой неделе?
(открытый и наводящий по реакции)
Все полузакрытые и закрытые вопросы относятся к наводящим 👀
Наводящие вопросы отличается от нейтральных своей формулировкой, в той или иной степени предопределяющей ответ респондента, другими словами оказывающей на него своего рода психологическое давление.
Расскажите, что вам понравилось во время посещения отделения банка на прошлой неделе? (наводящий по реакции)
Расскажите, как прошло ваше посещение отделения банка на прошлой неделе? (открытый и нейтральный)
Общий и частный вопросы:
Данные вопросы отражают различия в объеме исследуемого опыта. Так в общих вопросах мы исследуем агрегированный опыт респондента, который может включать в себя неактуальную информацию, из-за давности события. В частных случаях мы исследуем конкретные диапазон в прошлом. Так же общее и частное применимо к объему исследования клиентского пути, т.е. мы можем исследовать весь путь клиента в банке от подачи заявки на ипотеку до выдачи ипотеки, а можем исследовать конкретный этап, например только выдачу кредита.
Во время проблемных интервью, исследователю важно узнать была ли негативная реакция, если была, то что её вызвало (стимул). Как мы знаем, у исследователей клиентов, любимым оружием являются вопросы. Многим известно, что существую открытые и закрытые вопросы, и что на интервью лучше задавать открытые вопросы, хотя это не всегда так. Предлагаю открыть бочёнок с медом и наполнить себя расширенным знанием темы вопросов и как можно доставать информацию о стимулах и реакциях клиента 🧐
Какие бывают вопросы:
- открытые
- полузакрытые
- закрытые
- наводящие (по стимулу / по эмоциям)
- общие
- частные
Контекст:
Вам нужно провести интервью клиентов, которые посещали офис банка на прошлой неделе. Мы хотим узнать насколько клиенты, довольны обслуживанием и где мы можем улучшить клиентский опыт.
Открытый вопрос:
Расскажите, о вашем опыте посещения отделения банка на прошлой неделе?
Открытые вопросы обычно свободны в отношении стимула и реакции, другими словами интервьюируемый сам определяет фокус своего внимания, причем он может сделать это в двух аспектах:
а) ответ может быть дан о каком-то этапе клиентского опыта: парковка у здания офиса, ожидание в очереди, общение со специалистом, операция в кассе и т.д. Или обо всем опыте посещения в целом.
б) ответ может быть содержать информацию о реакции клиента, на события которые происходили во время посещения офиса банка.
Варианты ответов:
- Мне понравилась скорость обслуживания (стимул и реакция)
- Всё было хорошо (реакция)
- Приехал, взял талон, подождал 30 сек., быстро решили вопрос. (стимул)
- Пришлось искать место для парковки. А так всё ок. (стимул и реакция)
Полузакрытые вопрос:
Подскажите, вам понравилось (реакция) посещение отделения банка на прошлой неделе?
Комментарий:
Вопрос свободный в отношении стимула, но не реакции, так как мы конкретизируем, что нас интересует негативная реакция. И если респондент отвечает "Нет" то, далее мы уточняем стимулы, которые создали такой опыт.
Так же, мы можем задать вопрос свободный в отношении реакции, но закрытый в отношении стимула:
Расскажите, как прошло обслуживание специалистом (стимул) по ипотеке?
Другими словами полузакрытые вопросы фиксируют либо стимул, либо реакцию в своей формулировке.
Закрытый вопрос:
Вам понравилось (реакция) обслуживание специалистом банка (стимул) во время вашего посещения банка на прошлой неделе?
Комментарий:
В вопросах этого типа интервьюер осуществляет контроль над вариантами ответов респондента, что позволяет быстро валидировать респондента и наличия у него проблемного опыта в интересующем кейсе. В закрытых вопросах фиксируются и стимул и реакция.
⚠️Важно помнить ⚠️
Если на закрытый или полузакрытый вопрос мы получаем интересующий нас отклик, то просим клиента рассказать подробнее про стимул или реакцию.
Наводящий вопрос может быть Открытым:
Расскажите, что вам понравилось (или не понравилось) во время посещения отделения банка на прошлой неделе?
(открытый и наводящий по реакции)
Все полузакрытые и закрытые вопросы относятся к наводящим 👀
Наводящие вопросы отличается от нейтральных своей формулировкой, в той или иной степени предопределяющей ответ респондента, другими словами оказывающей на него своего рода психологическое давление.
Расскажите, что вам понравилось во время посещения отделения банка на прошлой неделе? (наводящий по реакции)
Расскажите, как прошло ваше посещение отделения банка на прошлой неделе? (открытый и нейтральный)
Общий и частный вопросы:
Данные вопросы отражают различия в объеме исследуемого опыта. Так в общих вопросах мы исследуем агрегированный опыт респондента, который может включать в себя неактуальную информацию, из-за давности события. В частных случаях мы исследуем конкретные диапазон в прошлом. Так же общее и частное применимо к объему исследования клиентского пути, т.е. мы можем исследовать весь путь клиента в банке от подачи заявки на ипотеку до выдачи ипотеки, а можем исследовать конкретный этап, например только выдачу кредита.
Заключение 💁♀️
Если исследуем (стимулы), что же раздражает или радует наших клиентов, то используем открытые или наводящие по реакции вопросы.
Если исследуем (реакции), как клиенты реагируют на новый сервис, услугу или продукт, то используем открытые или наводящие по стимулу вопросы.
Если исследуем (стимулы и реакции в связке), то задаем открытые вопросы.
Если исследуем (стимулы), что же раздражает или радует наших клиентов, то используем открытые или наводящие по реакции вопросы.
Если исследуем (реакции), как клиенты реагируют на новый сервис, услугу или продукт, то используем открытые или наводящие по стимулу вопросы.
Если исследуем (стимулы и реакции в связке), то задаем открытые вопросы.
Формула упаковки клиентского опыта в бэклог
Многие знают, что формулировка элементов бэклога продукта в пользовательских сценариях даёт лучшее понимание того, что планируется сделать в продукте всем заинтересованным сторонам: бизнесу, клиентам, разработчикам, самому владельцу продукта.
Изучив разные варианты упаковки, собрал формулу которая позволяет лаконично и ёмко оформить бэклог: Кто? Когда? Что? Чтобы что? Что мешает?
Переменные в формуле можно миксовать и оставлять только те, которые подходят под ваш контекст.
——
Когда продуктом=решением пользуются регулярно, например каждый день, потому что это часть должностных инструкций, то использовать переменную "Когда?" может быть бессмысленно. И наоборот, когда продуктом=решением пользуются в определенных ситуациях, например человек опаздывает, не выполняет KPI, праздник или знаковое событие в жизни, то переменная "Когда?" становиться ключевым элементом формулы.
——
Если у вас не получится уместить клиентский опыт в формулу, дайте знать🙂
Многие знают, что формулировка элементов бэклога продукта в пользовательских сценариях даёт лучшее понимание того, что планируется сделать в продукте всем заинтересованным сторонам: бизнесу, клиентам, разработчикам, самому владельцу продукта.
Изучив разные варианты упаковки, собрал формулу которая позволяет лаконично и ёмко оформить бэклог: Кто? Когда? Что? Чтобы что? Что мешает?
Переменные в формуле можно миксовать и оставлять только те, которые подходят под ваш контекст.
——
Когда продуктом=решением пользуются регулярно, например каждый день, потому что это часть должностных инструкций, то использовать переменную "Когда?" может быть бессмысленно. И наоборот, когда продуктом=решением пользуются в определенных ситуациях, например человек опаздывает, не выполняет KPI, праздник или знаковое событие в жизни, то переменная "Когда?" становиться ключевым элементом формулы.
——
Если у вас не получится уместить клиентский опыт в формулу, дайте знать🙂
Взялся за липкую и скользкую тему:
Откуда взялся весь продуктовый менеджмент 💁
https://scrumtrek.ru/blog/product-management/7082/product-management-history/
Откуда взялся весь продуктовый менеджмент 💁
https://scrumtrek.ru/blog/product-management/7082/product-management-history/
Блог ScrumTrek
История появления и развития Product Management — статья в блоге ScrumTrek
Это первая часть цикла из 4-х статей про Менеджера продукта и Владельца продукта, которая поможет вам понять, откуда взялся весь продуктовый менеджмент.
Инвестиционная политика кастрирует Инновации ✂️
Если вы хотите создать действительно "disruptive 🚀" продукт, то у вас могут быть только предположения, вера, визионерство и возможно 🤞косвенные данные о том, что где-то, через какое-то время, возможно 🔮 появится новый и огромный рынок. То есть рынка, который можно изучать нет 🤷♀️. В таких инновациях требования к разработке не просто не известны - они и не могут быть известны, это всё чистой воды гипотезы с огромной потенциалом погрешности. Таким образом, в стратегиях и планах "подрывных" инноваций основной упор ⚠️ должен делать на получение новой информации, обучение и исследование, а не реализацию. Это важно понять, потому что менеджемент, который думает, что знает будущее рынка, строит планы и инвестирует совсем иначе, чем менеджмент, осознающий и принимающий неопределенность несуществующего рынка.
Пример:
Инвестиционная политика компании по отношению к новым продуктам и сервисам:
1) Потенциально достижимый рынок за три года от ₽500М
2) Маржинальность от 15%
3) ROI не более 2 лет
Вот так, три понятных и простых критерия для выбора инвестиционного портфеля, уже на входе будут отсекать "disruptive" инновации. По таким продуктам просто не возможно предоставить данные для прохождения коммитета по инновациям. И скорее всего, в компании не будет людей, которые будут находить и верить в инновации так сильно, что осмелятся приходить на ивесткоммитет, и просить деньги для воздушных замков в глазах менеджмента.
Подобные инвестиционные политики компаний сфокусированы на поддерживающих инновациях - где потребности и размеры рынка известны, конкуренты и тренды понятны. А это значит, что у предпринимателей всегда будет возможность создать очередной единорог 🦄.
Если вы хотите создать действительно "disruptive 🚀" продукт, то у вас могут быть только предположения, вера, визионерство и возможно 🤞косвенные данные о том, что где-то, через какое-то время, возможно 🔮 появится новый и огромный рынок. То есть рынка, который можно изучать нет 🤷♀️. В таких инновациях требования к разработке не просто не известны - они и не могут быть известны, это всё чистой воды гипотезы с огромной потенциалом погрешности. Таким образом, в стратегиях и планах "подрывных" инноваций основной упор ⚠️ должен делать на получение новой информации, обучение и исследование, а не реализацию. Это важно понять, потому что менеджемент, который думает, что знает будущее рынка, строит планы и инвестирует совсем иначе, чем менеджмент, осознающий и принимающий неопределенность несуществующего рынка.
Пример:
Инвестиционная политика компании по отношению к новым продуктам и сервисам:
1) Потенциально достижимый рынок за три года от ₽500М
2) Маржинальность от 15%
3) ROI не более 2 лет
Вот так, три понятных и простых критерия для выбора инвестиционного портфеля, уже на входе будут отсекать "disruptive" инновации. По таким продуктам просто не возможно предоставить данные для прохождения коммитета по инновациям. И скорее всего, в компании не будет людей, которые будут находить и верить в инновации так сильно, что осмелятся приходить на ивесткоммитет, и просить деньги для воздушных замков в глазах менеджмента.
Подобные инвестиционные политики компаний сфокусированы на поддерживающих инновациях - где потребности и размеры рынка известны, конкуренты и тренды понятны. А это значит, что у предпринимателей всегда будет возможность создать очередной единорог 🦄.
Почему сложно создавать внутренние client-centric решения🤩?
В придачу к внутренней разработке как правило идет наследство:
1) Заказчиком выступает менеджмент или руководство.
2) Заказчик хочет видеть результат, а участвовать в не процессе создания решения.
3) Показатели эффективности решения интересуют Заказчика больше, чем удобство его использования конечными пользователями.
4) Конечным пользователи являются подчиненными Заказчика, а это означает сложности со сбором честную обратной связи.
5) Разрабатываемое решения может напрямую угрожать сотрудникам (конечным пользователям), например сокращением.
6) Владелец продукта, продуктовый менеджер или проектный менеджер, так же могут быть подчиненными Заказчика.
7) Команды для разработки таких решений редко бывают выделенными на 100%, чаще это сборная сотрудников из разных отделов под эгидой Стратегический проект.
Ответы на следующие вопросы прокачают ваш Ownership💪:
1) Как Заказчик планирует участвовать в разработке?
2) Как Заказчик будет определять успешность процесса реализации?
3) Как Заказчик будет определять выгоду от внедрения решения?
4) На чем основываются ожидания Заказчика относительно потенциальной выгоды?
5) Мнение каких внутренних пользователей стоит учитывать наравне с мнением Заказчика?
6) Какие риски несет игнорирование мнения конечных пользователей на показатели успешности реализации решения?
7) При разногласии мнений ключевых заинтересованных лиц, за кем остается последнее слово?
9) Сколько принесет денег/выгоды сокращение реализации решения на 1/3/6/12 месяцев?
10) Можно ли начать получать выгоду от реализации через 1/3/6/12 месяцев?
В придачу к внутренней разработке как правило идет наследство:
1) Заказчиком выступает менеджмент или руководство.
2) Заказчик хочет видеть результат, а участвовать в не процессе создания решения.
3) Показатели эффективности решения интересуют Заказчика больше, чем удобство его использования конечными пользователями.
4) Конечным пользователи являются подчиненными Заказчика, а это означает сложности со сбором честную обратной связи.
5) Разрабатываемое решения может напрямую угрожать сотрудникам (конечным пользователям), например сокращением.
6) Владелец продукта, продуктовый менеджер или проектный менеджер, так же могут быть подчиненными Заказчика.
7) Команды для разработки таких решений редко бывают выделенными на 100%, чаще это сборная сотрудников из разных отделов под эгидой Стратегический проект.
Ответы на следующие вопросы прокачают ваш Ownership💪:
1) Как Заказчик планирует участвовать в разработке?
2) Как Заказчик будет определять успешность процесса реализации?
3) Как Заказчик будет определять выгоду от внедрения решения?
4) На чем основываются ожидания Заказчика относительно потенциальной выгоды?
5) Мнение каких внутренних пользователей стоит учитывать наравне с мнением Заказчика?
6) Какие риски несет игнорирование мнения конечных пользователей на показатели успешности реализации решения?
7) При разногласии мнений ключевых заинтересованных лиц, за кем остается последнее слово?
9) Сколько принесет денег/выгоды сокращение реализации решения на 1/3/6/12 месяцев?
10) Можно ли начать получать выгоду от реализации через 1/3/6/12 месяцев?
👍9👻1
Сваял летопись роли Владельца Продукта 💁♀️
https://scrumtrek.ru/blog/product-management/7590/history-product-owner/?_thumbnail_id=7633
https://scrumtrek.ru/blog/product-management/7590/history-product-owner/?_thumbnail_id=7633
Блог ScrumTrek
История появления и развития роли Product Owner — статья в блоге ScrumTrek
Это вторая часть цикла из 4-х статей про Менеджера продукта и Владельца продукта, которая поможет вам понять, откуда взялся весь продуктовый менеджмент.
👍8🔥2
Продолжаю исследовать тему Владельца Продукта, в этот раз, смотрим через призму фреймворков масштабирования 🔎
https://scrumtrek.ru/blog/product-management/8060/product-owner-less-nexus-safe/
https://scrumtrek.ru/blog/product-management/8060/product-owner-less-nexus-safe/
Блог ScrumTrek
Владелец продукта во фреймворках масштабирования: LeSS, Nexus, SAFe® — статья в блоге ScrumTrek
Это третья часть цикла из 4-х статей про Менеджера продукта и Владельца продукта, которая поможет вам понять, откуда взялся весь продуктовый менеджмент.
👍8
Взаимодействие со стейкходерами 🧞♂️.
Всем прекрасно известно, что Продакты (Product Managers or Product Owners) имеют круг людей, кто оказывает влияние на развитие продукта. В корпорациях, как правило этот список может достигать десятков людей: потребители, руководитель финансового отдела, непосредственный руководитель Продакта, начальник отдела рисков, регулирующие органы, руководитель юридического отдела, другие Продакты в компании, вендоры и т.д.
Как Продакту не раствориться в этом водовороте коммуникаций, а осознанно и сфокусированно выстраивать взаимодействие с теми, чей вклад даст наибольшую ценность для продукта?
1) Составьте список всех заинтересованных лиц, рекомендую сделать это с командой, потому что, туда могут попасть эксперты внутренних систем компании, с которыми взаимодействует только члены команды.
2) Сколько времени уходит на взаимодействие с каждым из списка? Указываем в час./нед. или час./мес или час./кв.
3) Вклад заинтересованных лиц. Возле каждого ФИ записываем, в чем заключается вклад заинтересованного лица в развитие продукта. Например: эксперт рынка, критичная система компании, стандарная процедура в компании, бюджетирование команды и т.д.
4) Ключевые персонажи в списке. Выделяем наиболее важных лиц из списка (3-5), общение с которыми важно в горизонте ближайших 3-6 месяцев. Кратко описываем почему Продакту/команде необходимо с ними плотно взаимодействовать ближайшее время и как это отразится на ценности продукта.
5) Оцените достаточно ли вы уделяете время этим лицам из п.4. Если вы понимаете, что нет, то перебалансируйте время общения. Если заинтересованные лица из п.4 занятые люди, то расскажите им про п.3 и скорее всего вам пойдут на встречу.
6) Сокращайте общение с оставшимися заинтересованными лицами до минимально необходимого уровня. Освободившиеся время отдайте вашим клиентам, пользователям и конкурентам.
Всем прекрасно известно, что Продакты (Product Managers or Product Owners) имеют круг людей, кто оказывает влияние на развитие продукта. В корпорациях, как правило этот список может достигать десятков людей: потребители, руководитель финансового отдела, непосредственный руководитель Продакта, начальник отдела рисков, регулирующие органы, руководитель юридического отдела, другие Продакты в компании, вендоры и т.д.
Как Продакту не раствориться в этом водовороте коммуникаций, а осознанно и сфокусированно выстраивать взаимодействие с теми, чей вклад даст наибольшую ценность для продукта?
1) Составьте список всех заинтересованных лиц, рекомендую сделать это с командой, потому что, туда могут попасть эксперты внутренних систем компании, с которыми взаимодействует только члены команды.
2) Сколько времени уходит на взаимодействие с каждым из списка? Указываем в час./нед. или час./мес или час./кв.
3) Вклад заинтересованных лиц. Возле каждого ФИ записываем, в чем заключается вклад заинтересованного лица в развитие продукта. Например: эксперт рынка, критичная система компании, стандарная процедура в компании, бюджетирование команды и т.д.
4) Ключевые персонажи в списке. Выделяем наиболее важных лиц из списка (3-5), общение с которыми важно в горизонте ближайших 3-6 месяцев. Кратко описываем почему Продакту/команде необходимо с ними плотно взаимодействовать ближайшее время и как это отразится на ценности продукта.
5) Оцените достаточно ли вы уделяете время этим лицам из п.4. Если вы понимаете, что нет, то перебалансируйте время общения. Если заинтересованные лица из п.4 занятые люди, то расскажите им про п.3 и скорее всего вам пойдут на встречу.
6) Сокращайте общение с оставшимися заинтересованными лицами до минимально необходимого уровня. Освободившиеся время отдайте вашим клиентам, пользователям и конкурентам.
👍14🔥1