Работа с данными
При работе над продуктом есть 2 ключевых вопроса: 1) чем и как пользуются пользователи 2) почему именно этим и так. На первый вопрос отвечают данные, на второй - инсайты от пользователей.
Моя метафора про продуктовую аналитику - это система видеорегистраторов в пещере под названием “продукт” 😂Без данных ты не понимаешь, как пользователи “ходят” в продукте, где они продвигаются быстро, а где - стопорятся. Без аналитики у тебя нет объективных данных для приоритизации и формирования гипотез.
Поэтому я считаю, что самой важно задачей продакта в работе с данными является определение, какие данные нужно собирать и анализировать. Т.е. где эти самые видеорегистраторы вешать.
Как определять? Вы, как продакт, должны понимать, на какие вопросы вам нужны будут ответы. Например, вы отвечаете за signup conversion rate воронки, состоящей из 5 шагов. Абсолютный минимум в таком случае - иметь ивенты на каждый переход из шага в шаг, чтобы визуализировать полностью воронку.
Дальше вы должны подумать, по каким критериям вам важно сегментировать пользователей в воронке - эти параметры станут свойствами в ивентах. Например - вам нужно знать маркетинговый канал, промокод, какой вид подписки\плана пользователь выбрал на первом шаге, и т.д.
После этого логично пройтись по каждому шагу и определить, какие ключевые действия пользователь должен совершить, чтобы перейти на следующий шаг. Эти данные помогут вам сказать не просто “нужно улучшать конверсию из шага 1 в шаг 2”, а “пользователи отваливаются перед тем, как сделать действие Х, почему?”
Потом вы решили запустить эксперимент, в котором часть информации будет скрыта под кнопкой see more. Для интерпретации результатов эксперимента вам важно увидеть, какой процент пользователей будет нажимать на кнопку, поэтому в критерии приемки вы должны добавить отправку соответствующего ивента.
Или вам нужно понять, улучшился ли retention после такого-то обновления приложения. Значит вам нужно сделать когортный анализ, а для этого в свойствах ивента должна фигурировать версия приложения.
Тоже самое касается визуализации данных на дашбордах. В большом количестве данных легко потерять действительно важный сигнал. Дашборд должен отвечать на ключевые вопросы вашей части продукта и фокусировать команду вокруг этих вопросов.
Как вы понимаете, описанное выше вообще не требует знания sql. Но требует глубокого понимания продукта и пользователей.
Нужно ли вам будет знание sql или владение какой-то конкретной системой аналитики будет зависеть от продукта и наличие product analyst в команде. Если на продукте используется система аналитики типо Amplitude, то ИМХО вообще не проблема научиться ей пользоваться, и отвечать на свои узкие вопросы к продукту самостоятельно, а не дергать каждый раз аналитика данных.
В посте “Из бизнес-аналитика в продакты. Личный опыт” #вопросподписчиков был “курсы/литература/вебинары/практикумы”. Я проходила симулятор GoPractice по управлению продуктом на основе данных. Он весь построен на анализе данных, в том числе там обучают пользоваться Amplitude (не реклама, если что).
Под тем же постом был #вопросподписчиков “какие навыки нужно добрать БА, чтобы работать с данными”. Это не навык, конечно, но: мне пришлось привыкать к тому, что данные - это основа моей работы. Т.е. тебе никто не скажет - Лена, делай вот такую фичу. Лена должна проанализировать данные, выдвинуть гипотезы и пойти их проверять. Соответственно нужно не забывать добавлять ивенты; следить за тем, что они отправляются в нужном месте и в нужное время (ивенты имеют свойство ломаться, как и всё в продукте); ставить задачи аналитику на визуализацию основных метрик или глубокое количественное исследование части продукта, и т.д.
#горопека_о_продукте
При работе над продуктом есть 2 ключевых вопроса: 1) чем и как пользуются пользователи 2) почему именно этим и так. На первый вопрос отвечают данные, на второй - инсайты от пользователей.
Моя метафора про продуктовую аналитику - это система видеорегистраторов в пещере под названием “продукт” 😂Без данных ты не понимаешь, как пользователи “ходят” в продукте, где они продвигаются быстро, а где - стопорятся. Без аналитики у тебя нет объективных данных для приоритизации и формирования гипотез.
Поэтому я считаю, что самой важно задачей продакта в работе с данными является определение, какие данные нужно собирать и анализировать. Т.е. где эти самые видеорегистраторы вешать.
Как определять? Вы, как продакт, должны понимать, на какие вопросы вам нужны будут ответы. Например, вы отвечаете за signup conversion rate воронки, состоящей из 5 шагов. Абсолютный минимум в таком случае - иметь ивенты на каждый переход из шага в шаг, чтобы визуализировать полностью воронку.
Дальше вы должны подумать, по каким критериям вам важно сегментировать пользователей в воронке - эти параметры станут свойствами в ивентах. Например - вам нужно знать маркетинговый канал, промокод, какой вид подписки\плана пользователь выбрал на первом шаге, и т.д.
После этого логично пройтись по каждому шагу и определить, какие ключевые действия пользователь должен совершить, чтобы перейти на следующий шаг. Эти данные помогут вам сказать не просто “нужно улучшать конверсию из шага 1 в шаг 2”, а “пользователи отваливаются перед тем, как сделать действие Х, почему?”
Потом вы решили запустить эксперимент, в котором часть информации будет скрыта под кнопкой see more. Для интерпретации результатов эксперимента вам важно увидеть, какой процент пользователей будет нажимать на кнопку, поэтому в критерии приемки вы должны добавить отправку соответствующего ивента.
Или вам нужно понять, улучшился ли retention после такого-то обновления приложения. Значит вам нужно сделать когортный анализ, а для этого в свойствах ивента должна фигурировать версия приложения.
Тоже самое касается визуализации данных на дашбордах. В большом количестве данных легко потерять действительно важный сигнал. Дашборд должен отвечать на ключевые вопросы вашей части продукта и фокусировать команду вокруг этих вопросов.
Как вы понимаете, описанное выше вообще не требует знания sql. Но требует глубокого понимания продукта и пользователей.
Нужно ли вам будет знание sql или владение какой-то конкретной системой аналитики будет зависеть от продукта и наличие product analyst в команде. Если на продукте используется система аналитики типо Amplitude, то ИМХО вообще не проблема научиться ей пользоваться, и отвечать на свои узкие вопросы к продукту самостоятельно, а не дергать каждый раз аналитика данных.
В посте “Из бизнес-аналитика в продакты. Личный опыт” #вопросподписчиков был “курсы/литература/вебинары/практикумы”. Я проходила симулятор GoPractice по управлению продуктом на основе данных. Он весь построен на анализе данных, в том числе там обучают пользоваться Amplitude (не реклама, если что).
Под тем же постом был #вопросподписчиков “какие навыки нужно добрать БА, чтобы работать с данными”. Это не навык, конечно, но: мне пришлось привыкать к тому, что данные - это основа моей работы. Т.е. тебе никто не скажет - Лена, делай вот такую фичу. Лена должна проанализировать данные, выдвинуть гипотезы и пойти их проверять. Соответственно нужно не забывать добавлять ивенты; следить за тем, что они отправляются в нужном месте и в нужное время (ивенты имеют свойство ломаться, как и всё в продукте); ставить задачи аналитику на визуализацию основных метрик или глубокое количественное исследование части продукта, и т.д.
#горопека_о_продукте
4 Ps Framework
Продукт (или проект в аутсорсе) - никогда не сводится только к функциям, которые вы разрабатываете.
Какая бы у вас ни была выверенная стратегия, основанная на исследованиях и данных, она ничего не стоит без реализации. А реализация невозможна без хорошо подобранной команды, налаженных процессов и прочного технического фундамента.
Поэтому крайне рекомендую раз в квартал вместе с командой делать оценку продукта со всех сторон, выявлять блокеры и риски, и ставить цели не только с точки зрения бизнес-метрик (т.е. продукта), но и в остальных трёх P.
#framework #горопека_техники
Продукт (или проект в аутсорсе) - никогда не сводится только к функциям, которые вы разрабатываете.
Какая бы у вас ни была выверенная стратегия, основанная на исследованиях и данных, она ничего не стоит без реализации. А реализация невозможна без хорошо подобранной команды, налаженных процессов и прочного технического фундамента.
Поэтому крайне рекомендую раз в квартал вместе с командой делать оценку продукта со всех сторон, выявлять блокеры и риски, и ставить цели не только с точки зрения бизнес-метрик (т.е. продукта), но и в остальных трёх P.
#framework #горопека_техники
DIBB Framework
DIBB framework был придуман в Spotify как метод аргументированной приоритизации инициатив. Мне приходилось использовать его на практике при работе над роудмапом, поэтому решила поделиться с вами своим опытом.
Но прежде всего давайте быстренько разберемся в теории.
Фреймворк помогает донести, почему вы хотите приоритизировать те или иные инициативы через визуализацию вашей логической цепочки. 4 буквы акронима значат:
1. Data - начальные данные и факты, из которых вы исходили.
2. Insight - тренды, паттерны и выводы, которые вы делаете из проанализированных данных.
3. Belief - это ваши допущения / гипотезы по поводу причин таких данных и инсайтов.
4. Bet - собственно, ваше предложение, что нужно предпринять на основании данных и гипотез.
Мое понимание механики работы этого фреймворка следующее:
1. Data и Insights - это контакт с реальностью. Как пользователи используют приложение? Как ведет себя рынок? Что делают конкуренты? Важно, чтобы это был действительно контакт с реальностью, а не подгон данных под ваши фантазии. Т.е. на данном этапе нужно опираться на факты, цифры, смотреть разные источники, чтобы составить картину мира максимально близкую к реальности
2. Belief и Bet - это уже ваша интерпретация реальности. Ваш ответ, что нужно сделать, чтобы изменить реальность или изменить продукт под наступающую новую реальность. Исходя из вашего опыта, экспертизы, насмотренности, креативности, понимания рынка и возможностей команды.
Прелесть фреймворка в том, что он и вам помогает оценить логичность ваших рассуждений, и стейкхолдером объясняет причины, по которым вы предлагаете сконцентрироваться на таких-то инициативах.
Естественно, понимать на примерах всегда проще. Поэтому ниже мой собственный пример, а по ссылке вы можете увидеть пример применения от самого Spotify.
Теперь несколько советов:
1. Мне часто сложно разделять мой поток сознания на D, I, B, B. Ну если с данными всё-таки проще (хотя часто сложно данные от инсайтов отличить), то дальше возникали вопросы - вот эта “мысль”, это инсайт или уже гипотеза? Но это дико полезно, потому что порядок в голове приводит к порядку в стратегии и решениях.
2. Прямой путь использования фреймворка - закопаться в данные, выделить из них инсайты, и затем думать, что с этим делать. Естественно, результат будет лучше, если в процессе есть с кем посоветоваться и об кого подумать.
3. Но можно пользоваться и инверсивным методом. Правда, он требует определенного уровня сеньорности и непредвзятости. Вы ловите себя на том, что у вас есть вот такая вот гипотеза (Belief) о реальности. И дальше задаете себе вопрос - если она верная, как это должно было бы отразиться в данных и инсайтах? Записываете - и идете проверять, согласована ли реальность с вашими гипотезами. Именно поэтому метод требует железобетонной непредвзятости. Потому что вы не должны подгонять данные под ваши гипотезы. Вы должны проверять гипотезы данными. И если они не подтвердились - легко расставаться с ними.
4. По этому фреймворку можно рассматривать не только продуктовые данные. Вы можете также собирать метрики о работе команды, о количестве багов и состоянии тех. долга, чтобы аргументировать инвестиции в другие Ps.
Приходилось вам применять данный фреймворк? А если нет - попробуете поиграться на своих проектах?)
#горопека_техники
DIBB framework был придуман в Spotify как метод аргументированной приоритизации инициатив. Мне приходилось использовать его на практике при работе над роудмапом, поэтому решила поделиться с вами своим опытом.
Но прежде всего давайте быстренько разберемся в теории.
Фреймворк помогает донести, почему вы хотите приоритизировать те или иные инициативы через визуализацию вашей логической цепочки. 4 буквы акронима значат:
1. Data - начальные данные и факты, из которых вы исходили.
2. Insight - тренды, паттерны и выводы, которые вы делаете из проанализированных данных.
3. Belief - это ваши допущения / гипотезы по поводу причин таких данных и инсайтов.
4. Bet - собственно, ваше предложение, что нужно предпринять на основании данных и гипотез.
Мое понимание механики работы этого фреймворка следующее:
1. Data и Insights - это контакт с реальностью. Как пользователи используют приложение? Как ведет себя рынок? Что делают конкуренты? Важно, чтобы это был действительно контакт с реальностью, а не подгон данных под ваши фантазии. Т.е. на данном этапе нужно опираться на факты, цифры, смотреть разные источники, чтобы составить картину мира максимально близкую к реальности
2. Belief и Bet - это уже ваша интерпретация реальности. Ваш ответ, что нужно сделать, чтобы изменить реальность или изменить продукт под наступающую новую реальность. Исходя из вашего опыта, экспертизы, насмотренности, креативности, понимания рынка и возможностей команды.
Прелесть фреймворка в том, что он и вам помогает оценить логичность ваших рассуждений, и стейкхолдером объясняет причины, по которым вы предлагаете сконцентрироваться на таких-то инициативах.
Естественно, понимать на примерах всегда проще. Поэтому ниже мой собственный пример, а по ссылке вы можете увидеть пример применения от самого Spotify.
Теперь несколько советов:
1. Мне часто сложно разделять мой поток сознания на D, I, B, B. Ну если с данными всё-таки проще (хотя часто сложно данные от инсайтов отличить), то дальше возникали вопросы - вот эта “мысль”, это инсайт или уже гипотеза? Но это дико полезно, потому что порядок в голове приводит к порядку в стратегии и решениях.
2. Прямой путь использования фреймворка - закопаться в данные, выделить из них инсайты, и затем думать, что с этим делать. Естественно, результат будет лучше, если в процессе есть с кем посоветоваться и об кого подумать.
3. Но можно пользоваться и инверсивным методом. Правда, он требует определенного уровня сеньорности и непредвзятости. Вы ловите себя на том, что у вас есть вот такая вот гипотеза (Belief) о реальности. И дальше задаете себе вопрос - если она верная, как это должно было бы отразиться в данных и инсайтах? Записываете - и идете проверять, согласована ли реальность с вашими гипотезами. Именно поэтому метод требует железобетонной непредвзятости. Потому что вы не должны подгонять данные под ваши гипотезы. Вы должны проверять гипотезы данными. И если они не подтвердились - легко расставаться с ними.
4. По этому фреймворку можно рассматривать не только продуктовые данные. Вы можете также собирать метрики о работе команды, о количестве багов и состоянии тех. долга, чтобы аргументировать инвестиции в другие Ps.
Приходилось вам применять данный фреймворк? А если нет - попробуете поиграться на своих проектах?)
#горопека_техники
Как поделить ответственность на проекте
Для “менеджерских” ролей - проджект-менеджер, продукт-менеджер, бизнес-аналитик, и т.д. - характерна размытая граница ответственности (сколько нас, всяких менеджеров, развелось 😂). Нет, на бумаге всё вроде прописано, и все со всем согласны, но на практике постоянно возникают конфликты по типу “это не моя ответственность!”, “я была уверена, что ты это сделаешь!”.
На мой взгляд, такие конфликты неизбежны. Как только у вас на проекте есть продакт-менеджер и бизнес-аналитик (например), у вас будет период притирки и периодические обострения. Поэтому я бы сконцентрировалась не на том, как этого избежать, а на способах проходить такие моменты эффективно и с пользой для всех.
Выясните ожидания от вас
Первое, что вы должны сделать, приходя на новый проект - выяснить ожидания от вашей роли. Назначаете 1:1 c ключевыми людьми на проекте, и спрашиваете словами через рот - как я могу принести максимальную пользу на своей позиции. Записываете и анализируете.
Иногда от вас могут ожидать неожиданного =) Например, ПМ проекта рассчитывает, что вы будете проводить ретроспективы. В таком случае вы должны подумать, готовы ли вы брать на себя такую задачу (вдруг вам всегда хотелось попробовать респы SM), и если нет - аргументировано объяснить, почему.
Обозначьте свои ожидания
Потому что они у вас точно есть, а люди пока читать мысли не научились. Например, вы общаетесь с тех. лидом и говорите ему “я считаю, что наиболее эффективно придумывать решения вместе с командой, ведь инженеры часто лучше знают реализуемость тех или иных идей”. А в ответ получаете - “эээ, мы так не работаем. Ты нам конкретные требования к решению - мы их делаем. Почему мы должны делать работу за тебя, что-то там придумывать?”. Теперь вы знаете ожидания от вас. Согласны вы с ними или нет - это уже другой разговор. Но только зная ожидания, вы можете адекватно спланировать свое дальнейшее поведение.
Не замалчиваете проблемы, поднимайте их на ретрах и персоналах.
В любых отношениях, в том числе рабочих, неизбежны недопонимания и конфликты. Поэтому и были придуманы инструменты ретроспективы и персоналов - чтобы оперативно выявлять и решать такие проблемы. Если вас что-то не устраивает, вы убираете эмоции и поднимаете вопрос. Приводите примеры ситуаций и ваши аргументы, и НИКОГДА не оценивайте личность человека - только поведение в конкретной ситуации. Ну и естественно, внимательно слушайте обратную связь в ваш адрес и изменяйте свое поведение.
Пост родился из ваших постоянных вопросов “а как у вас поделена ответственность между этим и тем”. Я понимаю, что иногда полезно подсмотреть best practices. Но в случае отношений внутри команды любые советы и практики нужно рассматривать очень критически, ведь люди - это сложно: разные характеры, разный опыт, разные амбиции. Поэтому никакие best practices не избавят вас от необходимости потрудиться и найти рабочую схему в вашем контексте - т.е. с этими конкретными людьми.
#горопека_о_проекте
Для “менеджерских” ролей - проджект-менеджер, продукт-менеджер, бизнес-аналитик, и т.д. - характерна размытая граница ответственности (сколько нас, всяких менеджеров, развелось 😂). Нет, на бумаге всё вроде прописано, и все со всем согласны, но на практике постоянно возникают конфликты по типу “это не моя ответственность!”, “я была уверена, что ты это сделаешь!”.
На мой взгляд, такие конфликты неизбежны. Как только у вас на проекте есть продакт-менеджер и бизнес-аналитик (например), у вас будет период притирки и периодические обострения. Поэтому я бы сконцентрировалась не на том, как этого избежать, а на способах проходить такие моменты эффективно и с пользой для всех.
Выясните ожидания от вас
Первое, что вы должны сделать, приходя на новый проект - выяснить ожидания от вашей роли. Назначаете 1:1 c ключевыми людьми на проекте, и спрашиваете словами через рот - как я могу принести максимальную пользу на своей позиции. Записываете и анализируете.
Иногда от вас могут ожидать неожиданного =) Например, ПМ проекта рассчитывает, что вы будете проводить ретроспективы. В таком случае вы должны подумать, готовы ли вы брать на себя такую задачу (вдруг вам всегда хотелось попробовать респы SM), и если нет - аргументировано объяснить, почему.
Обозначьте свои ожидания
Потому что они у вас точно есть, а люди пока читать мысли не научились. Например, вы общаетесь с тех. лидом и говорите ему “я считаю, что наиболее эффективно придумывать решения вместе с командой, ведь инженеры часто лучше знают реализуемость тех или иных идей”. А в ответ получаете - “эээ, мы так не работаем. Ты нам конкретные требования к решению - мы их делаем. Почему мы должны делать работу за тебя, что-то там придумывать?”. Теперь вы знаете ожидания от вас. Согласны вы с ними или нет - это уже другой разговор. Но только зная ожидания, вы можете адекватно спланировать свое дальнейшее поведение.
Не замалчиваете проблемы, поднимайте их на ретрах и персоналах.
В любых отношениях, в том числе рабочих, неизбежны недопонимания и конфликты. Поэтому и были придуманы инструменты ретроспективы и персоналов - чтобы оперативно выявлять и решать такие проблемы. Если вас что-то не устраивает, вы убираете эмоции и поднимаете вопрос. Приводите примеры ситуаций и ваши аргументы, и НИКОГДА не оценивайте личность человека - только поведение в конкретной ситуации. Ну и естественно, внимательно слушайте обратную связь в ваш адрес и изменяйте свое поведение.
Пост родился из ваших постоянных вопросов “а как у вас поделена ответственность между этим и тем”. Я понимаю, что иногда полезно подсмотреть best practices. Но в случае отношений внутри команды любые советы и практики нужно рассматривать очень критически, ведь люди - это сложно: разные характеры, разный опыт, разные амбиции. Поэтому никакие best practices не избавят вас от необходимости потрудиться и найти рабочую схему в вашем контексте - т.е. с этими конкретными людьми.
#горопека_о_проекте
Как разработчик был бизнес-аналитиком
Недавно мой друг, по совместительству senior разработчик и тимлид, поделился своим опытом выполнения роли бизнес-аналитика.
Он работает в продуктовой компании, которая специализируется на разработке небольших продуктов в одной доменной области. Работает он там долго, поэтому хорошо разбирается в домене.
И вот ему дали в команду несколько разработчиков, одного стейкхолдера и задачу разработать небольшой продукт.
У друга не было проблемы с выяснением требований. Стейкхолдер один, домен он знает, с людьми разговаривать умеет =) Не было проблем и с документированием - проект небольшой, разработчиков не много, просто записывались задачи в jira. С проектированием тоже всё было ок - продукт “технический”, UI не много, поэтому там не нужно было продумывать user flow, скорее нужно было сделать хорошую архитектуру. А с этим проблем у senior-разработчика нет.
Но проблема пришла откуда не ждали😁. Вот стейкхолдер говорит, что мне нужно, чтобы с этим объектом можно было делать x, y, z. Но друг понимает, что (сейчас будет очень грубое описание, не придирайтесь) если сделать немного на другой абстракции, то тогда с этим объектом можно будет делать еще +n операций. Да, это займет плюс пару дней, но ничего, зато будет красиво и логично. А если вот для этой задачи заюзать такой-то фрейморк, то можно будет сделать еще более гибко и с дополнительными функциями.
В итоге в продукте не только появились фичи, которыми никто и никогда не пользуется. По словам друга, разрабатывать и поддерживать код вскоре стало намного сложнее, потому что все эти дополнительные сущности и свойства нужно держать в голове и правильно обрабатывать при имплементации следующих функций. А это плюс время, плюс баги, и минус в удовольствии от кодинга.
Так что есть от нас с вами польза 😂. И она именно в том, чтобы выяснять всю пирамиду требований, экономить деньги и время на избыточных функциях, и направлять желание инженеров покодить в полезное для бизнеса и пользователей русло.
#горопека_заметки
Недавно мой друг, по совместительству senior разработчик и тимлид, поделился своим опытом выполнения роли бизнес-аналитика.
Он работает в продуктовой компании, которая специализируется на разработке небольших продуктов в одной доменной области. Работает он там долго, поэтому хорошо разбирается в домене.
И вот ему дали в команду несколько разработчиков, одного стейкхолдера и задачу разработать небольшой продукт.
У друга не было проблемы с выяснением требований. Стейкхолдер один, домен он знает, с людьми разговаривать умеет =) Не было проблем и с документированием - проект небольшой, разработчиков не много, просто записывались задачи в jira. С проектированием тоже всё было ок - продукт “технический”, UI не много, поэтому там не нужно было продумывать user flow, скорее нужно было сделать хорошую архитектуру. А с этим проблем у senior-разработчика нет.
Но проблема пришла откуда не ждали😁. Вот стейкхолдер говорит, что мне нужно, чтобы с этим объектом можно было делать x, y, z. Но друг понимает, что (сейчас будет очень грубое описание, не придирайтесь) если сделать немного на другой абстракции, то тогда с этим объектом можно будет делать еще +n операций. Да, это займет плюс пару дней, но ничего, зато будет красиво и логично. А если вот для этой задачи заюзать такой-то фрейморк, то можно будет сделать еще более гибко и с дополнительными функциями.
В итоге в продукте не только появились фичи, которыми никто и никогда не пользуется. По словам друга, разрабатывать и поддерживать код вскоре стало намного сложнее, потому что все эти дополнительные сущности и свойства нужно держать в голове и правильно обрабатывать при имплементации следующих функций. А это плюс время, плюс баги, и минус в удовольствии от кодинга.
Так что есть от нас с вами польза 😂. И она именно в том, чтобы выяснять всю пирамиду требований, экономить деньги и время на избыточных функциях, и направлять желание инженеров покодить в полезное для бизнеса и пользователей русло.
#горопека_заметки
Нещадно визуализируйте
Внезапно родилась рубрика #непрошенныесоветы
Речь и письмо - инструменты прекрасные, но почему-то плохо работающие в делах донесения требований, проработки логики взаимодействия, описания user flow.
Вы можете сколько угодно упарываться на детальном описании, таблицах и списках. Или в случае речи - 10 раз спрашивать “все поняли? все согласны?”. Но в итоге другая сторона с большой вероятностью поймет вас не так.
Поэтому никакие мои обсуждения не обходятся без визуализации на miro-борде. Но только визуализировать нужно правильно. Не написать сказанную мысль на стикере, а визуализировать её через разбиение на элементы и связи между ними.
Если у инженеров началось обсуждение “да ты ж мне тут с бэка пришлешь данные, а я тогда отображу” - я сразу рисую два кватратика бэкенд и фронтенд, и дальше стрелки взаимодействия. Что отправит фронт, как преобразует бэк, что отправит в ответ. Тут и выясняется, что фронт не может отправить бэку то, что им нужно. Или бэк планировал возвращать вообще другое.
Если мы решили, что отображаем какое-то сообщение 5 раз, при этом 1 раз в сессию, то я нарисую 6 квадратов сессии, пронумерую их, а на шестом поставлю ЖИРНЫЙ КРЕСТ. Потому что иначе сделают 5 отображений сообщений, но в рамках одной сессии (вот только сегодня разгребала такую ошибку, сделанную до моего прихода. И пока я не нарисовала - сути ошибки команда не понимала).
В общем, не переоценивайте свою способность объяснить и описать что-то только через plain текст. И даже не предполагайте, что ваш текст воспримут так, как вы его написали) Рисунки, схемы, диаграммы, мокапы - наше всё.
#горопека_лайфхаки
Внезапно родилась рубрика #непрошенныесоветы
Речь и письмо - инструменты прекрасные, но почему-то плохо работающие в делах донесения требований, проработки логики взаимодействия, описания user flow.
Вы можете сколько угодно упарываться на детальном описании, таблицах и списках. Или в случае речи - 10 раз спрашивать “все поняли? все согласны?”. Но в итоге другая сторона с большой вероятностью поймет вас не так.
Поэтому никакие мои обсуждения не обходятся без визуализации на miro-борде. Но только визуализировать нужно правильно. Не написать сказанную мысль на стикере, а визуализировать её через разбиение на элементы и связи между ними.
Если у инженеров началось обсуждение “да ты ж мне тут с бэка пришлешь данные, а я тогда отображу” - я сразу рисую два кватратика бэкенд и фронтенд, и дальше стрелки взаимодействия. Что отправит фронт, как преобразует бэк, что отправит в ответ. Тут и выясняется, что фронт не может отправить бэку то, что им нужно. Или бэк планировал возвращать вообще другое.
Если мы решили, что отображаем какое-то сообщение 5 раз, при этом 1 раз в сессию, то я нарисую 6 квадратов сессии, пронумерую их, а на шестом поставлю ЖИРНЫЙ КРЕСТ. Потому что иначе сделают 5 отображений сообщений, но в рамках одной сессии (вот только сегодня разгребала такую ошибку, сделанную до моего прихода. И пока я не нарисовала - сути ошибки команда не понимала).
В общем, не переоценивайте свою способность объяснить и описать что-то только через plain текст. И даже не предполагайте, что ваш текст воспримут так, как вы его написали) Рисунки, схемы, диаграммы, мокапы - наше всё.
#горопека_лайфхаки
Думать об бумагу
Что вы делаете, когда вам нужно подумать, проанализировать комплексную ситуацию, принять важное решение? Я - открываю гугл-док и начинаю писать.
Делала я так не всегда. Но после внедрения практики “думать об бумагу” качество моих решений заметно выросло. Ниже гипотезы, почему это очень круто работает.
Мой мозг способен активно думать ОГРАНИЧЕННОЕ количество мыслей. А анализ комплексной ситуации всегда требует посмотреть на проблему с разных сторон, что значит - подумать много мыслей. Поэтому процесс выглядит как-то так: выгрузила на бумагу то, что думаю на текущий момент → появилось место и энергия на новые мысли → выгружаю следующую партию → повтор. И так до тех пор, пока мысли (или время 😂) не закончатся.
Нет боязни потерять или забыть очень классную мысль. Т.е. если я произвожу весь мыслительный процесс в голове и пришла к чему-то интересному - то дальше не сдвинусь. Потому что мозг будет сконцентрирован на том, чтобы не забыть эту идею. Но я не хочу останавливаться на первой интересной мысли, когда анализирую что-то сложное - в этом есть большой риск упустить и недокрутить. А если идея и вся аргументация выгружена на бумагу, то мозг успокаивается и думает дальше.
Проще переключаться между режимами собираю данные / анализирую данные. Часто “подумать” предполагает последовательное прохождение цикла сбор данных → анализ и синтез → выводы → сбор данных… Например, после интервью пользователей (сбор данных) я группирую обратную связь в повторяющие паттерны (анализ и синтез), потом генерирую и приоритизирую гипотезы (делаю выводы), а потом иду проверять жизнеспособность гипотез на данных (снова сбор). Сложно представить, как такой процесс возможно проделать без выгрузки мыслей на бумагу.
Проще переключаться между ролями генератор / критик идей. Слышали же, наверное, про метод 6 шляп. Я ВСЕГДА одеваю шляпу жесткого критика, т.е. думаю о том “что может пойти не так? почему это может не сработать? какие есть риски?”. Но делаю это только после фазы генерации, потому что качество финальной идеи почти всегда есть функция от количества исходных опций. Поэтому сначала я пишу свои мысли, прихожу к какому-то выводу, а потом перехожу в режим критики. Не представляю, как это всё сделать в голове.
Сам процесс написания заставляет структурировать мысли. Написав “если”, нужно написать и “то”, а значит - построить логическую связь. Если я начала перечислять пункты, то мысль идет по пути “подумать обо всех возможных опциях”. Когда написала несколько вариантов решений, сам текст просит теперь их сравнить. А значит - подумать над критериями сравнения.
Всегда можно вспомнить, почему было принято такое решение. А еще лучше - напомнить всем остальным. У меня был очень яркий кейс, когда я проработала гипотезу, и по итогу проработки стало понятно, что она не жизнеспособна. Вся проработка была сделана на бумаге, а не устно на мите. А потом сменился менеджер, и пришел с той же идеей. Но я просто скинула документ, из которого он тут же понял, почему гипотеза не жизнеспособна, еще и похвалил меня за крутую работу.
Для разных типов проблем у меня сложились разные шаблоны, которые помогают “думать об бумагу”. Могу поделиться с вами несколькими, если тема будет интересной
#горопека_лайфхаки #думать_об_бумагу
Что вы делаете, когда вам нужно подумать, проанализировать комплексную ситуацию, принять важное решение? Я - открываю гугл-док и начинаю писать.
Делала я так не всегда. Но после внедрения практики “думать об бумагу” качество моих решений заметно выросло. Ниже гипотезы, почему это очень круто работает.
Мой мозг способен активно думать ОГРАНИЧЕННОЕ количество мыслей. А анализ комплексной ситуации всегда требует посмотреть на проблему с разных сторон, что значит - подумать много мыслей. Поэтому процесс выглядит как-то так: выгрузила на бумагу то, что думаю на текущий момент → появилось место и энергия на новые мысли → выгружаю следующую партию → повтор. И так до тех пор, пока мысли (или время 😂) не закончатся.
Нет боязни потерять или забыть очень классную мысль. Т.е. если я произвожу весь мыслительный процесс в голове и пришла к чему-то интересному - то дальше не сдвинусь. Потому что мозг будет сконцентрирован на том, чтобы не забыть эту идею. Но я не хочу останавливаться на первой интересной мысли, когда анализирую что-то сложное - в этом есть большой риск упустить и недокрутить. А если идея и вся аргументация выгружена на бумагу, то мозг успокаивается и думает дальше.
Проще переключаться между режимами собираю данные / анализирую данные. Часто “подумать” предполагает последовательное прохождение цикла сбор данных → анализ и синтез → выводы → сбор данных… Например, после интервью пользователей (сбор данных) я группирую обратную связь в повторяющие паттерны (анализ и синтез), потом генерирую и приоритизирую гипотезы (делаю выводы), а потом иду проверять жизнеспособность гипотез на данных (снова сбор). Сложно представить, как такой процесс возможно проделать без выгрузки мыслей на бумагу.
Проще переключаться между ролями генератор / критик идей. Слышали же, наверное, про метод 6 шляп. Я ВСЕГДА одеваю шляпу жесткого критика, т.е. думаю о том “что может пойти не так? почему это может не сработать? какие есть риски?”. Но делаю это только после фазы генерации, потому что качество финальной идеи почти всегда есть функция от количества исходных опций. Поэтому сначала я пишу свои мысли, прихожу к какому-то выводу, а потом перехожу в режим критики. Не представляю, как это всё сделать в голове.
Сам процесс написания заставляет структурировать мысли. Написав “если”, нужно написать и “то”, а значит - построить логическую связь. Если я начала перечислять пункты, то мысль идет по пути “подумать обо всех возможных опциях”. Когда написала несколько вариантов решений, сам текст просит теперь их сравнить. А значит - подумать над критериями сравнения.
Всегда можно вспомнить, почему было принято такое решение. А еще лучше - напомнить всем остальным. У меня был очень яркий кейс, когда я проработала гипотезу, и по итогу проработки стало понятно, что она не жизнеспособна. Вся проработка была сделана на бумаге, а не устно на мите. А потом сменился менеджер, и пришел с той же идеей. Но я просто скинула документ, из которого он тут же понял, почему гипотеза не жизнеспособна, еще и похвалил меня за крутую работу.
Для разных типов проблем у меня сложились разные шаблоны, которые помогают “думать об бумагу”. Могу поделиться с вами несколькими, если тема будет интересной
#горопека_лайфхаки #думать_об_бумагу
Практика journaling для рабочих задач
С нового года я внедрила практику довольно подробного описания своего рабочего дня. Уже заметила положительное влияние на свою работу, поэтому решила поделиться с вами.
Зачем я это начала
Честно говоря, изначально я начинала практику journaling для личных целей. В последнее время мой мозг думает слишком много мыслей обо всем и сразу. Мне стало очевидно, что если я не начну куда-нибудь их складывать, то головушка моя взорвется.
Но поскольку я недавно сменила работу, мой фокус внимания сильно сместился в эту область. В результате, как-то не заметно для меня, подробный journaling перекинулся и на работу
Как выглядит процесс
Начиналось всё просто с описания всех задач, сделанных за день. Но со временем практика трансформировалась в следующий процесс:
1. Инструмент: личный notion
2. Вечер пятницы - утро понедельника: составить список задач на неделю. Примерно раскидать их по дням с учетом загрузки и специфики задачи. Забронировать в календаре слоты для deep work
3. Утро рабочего дня: составить список задач на день из приоритетов недели и результатов прошлого дня.
4. В течение дня: ставить галочки напротив сделанных дел (самое любимое!!) и вносить незапланированные дела. Проставлять затраченное время.
Какие бенефиты я уже заметила
1. Всегда есть, что сказать на дейлике: чем занималась и что планирую делать. Наверное, это возраст😅, но я реально часто забываю, что делала. А не хочется производить впечатление ничего не делающей, тем более когда это правда не так.
2. Выделяется дофаминчик от осознания сделанного дела. Да, я такая: люблю ставить галки, вычеркивать, переводить в done.
3. Есть объективное понимание своего прогресса. Думаю, меня поймут все менеджеры - бывают дни, когда ты весь день работала, а вроде бы ничего и не сделала. А если записывать всё проделанное, то внезапно получается, что ты разруливала блокеры по важным задачам. Или наоборот - действительно занималась неважной ерундой, и нужно улучшить фокус на важном.
4. Легче балансировать стратегические и тактические задачи. Вы можете миксовать разные задачи в рамках одной недели. Или осознанно одну неделю больше заниматься тактикой (например, подготовкой к следующему спринту), а на второй больше времени уделять стратегическим задачам.
5. Накапливается объективное понимание своей пропускной способности. Сколько задач в день в тебя “влазит”? Какие типы задач хорошо объединяются, а какие - нет? Сколько времени уходит на написание важных документов, анализ, продумывание, а сколько - на мелкие задачи.
6. Намного легче формулировать достижения для performance review и резюме. Поверьте, вам будет намного проще готовиться к разговорам о зарплате, когда у вас есть конкретные измеримые достижения. И достижения проще формулировать, когда есть лог сделанных задач.
7. Можно проводить личные ретроспективы, внедрять изменения и отслеживать результат. Особенно, если вы умеете быть честными с самим собой.
И последнее. Я долгое время не верила в восторженные отзывы о практике journaling. Пока не призналась себе, что я просто боюсь того, что могу туда написать. Ведь если осознаешь проблему - придется её решать. Так что если у вас тоже сильный скепсис к прочитанному - возможно, вам правда не нужен journaling. А возможно - вы просто не хотите встретиться с реальностью.
#горопека_лайфхаки
С нового года я внедрила практику довольно подробного описания своего рабочего дня. Уже заметила положительное влияние на свою работу, поэтому решила поделиться с вами.
Зачем я это начала
Честно говоря, изначально я начинала практику journaling для личных целей. В последнее время мой мозг думает слишком много мыслей обо всем и сразу. Мне стало очевидно, что если я не начну куда-нибудь их складывать, то головушка моя взорвется.
Но поскольку я недавно сменила работу, мой фокус внимания сильно сместился в эту область. В результате, как-то не заметно для меня, подробный journaling перекинулся и на работу
Как выглядит процесс
Начиналось всё просто с описания всех задач, сделанных за день. Но со временем практика трансформировалась в следующий процесс:
1. Инструмент: личный notion
2. Вечер пятницы - утро понедельника: составить список задач на неделю. Примерно раскидать их по дням с учетом загрузки и специфики задачи. Забронировать в календаре слоты для deep work
3. Утро рабочего дня: составить список задач на день из приоритетов недели и результатов прошлого дня.
4. В течение дня: ставить галочки напротив сделанных дел (самое любимое!!) и вносить незапланированные дела. Проставлять затраченное время.
Какие бенефиты я уже заметила
1. Всегда есть, что сказать на дейлике: чем занималась и что планирую делать. Наверное, это возраст😅, но я реально часто забываю, что делала. А не хочется производить впечатление ничего не делающей, тем более когда это правда не так.
2. Выделяется дофаминчик от осознания сделанного дела. Да, я такая: люблю ставить галки, вычеркивать, переводить в done.
3. Есть объективное понимание своего прогресса. Думаю, меня поймут все менеджеры - бывают дни, когда ты весь день работала, а вроде бы ничего и не сделала. А если записывать всё проделанное, то внезапно получается, что ты разруливала блокеры по важным задачам. Или наоборот - действительно занималась неважной ерундой, и нужно улучшить фокус на важном.
4. Легче балансировать стратегические и тактические задачи. Вы можете миксовать разные задачи в рамках одной недели. Или осознанно одну неделю больше заниматься тактикой (например, подготовкой к следующему спринту), а на второй больше времени уделять стратегическим задачам.
5. Накапливается объективное понимание своей пропускной способности. Сколько задач в день в тебя “влазит”? Какие типы задач хорошо объединяются, а какие - нет? Сколько времени уходит на написание важных документов, анализ, продумывание, а сколько - на мелкие задачи.
6. Намного легче формулировать достижения для performance review и резюме. Поверьте, вам будет намного проще готовиться к разговорам о зарплате, когда у вас есть конкретные измеримые достижения. И достижения проще формулировать, когда есть лог сделанных задач.
7. Можно проводить личные ретроспективы, внедрять изменения и отслеживать результат. Особенно, если вы умеете быть честными с самим собой.
И последнее. Я долгое время не верила в восторженные отзывы о практике journaling. Пока не призналась себе, что я просто боюсь того, что могу туда написать. Ведь если осознаешь проблему - придется её решать. Так что если у вас тоже сильный скепсис к прочитанному - возможно, вам правда не нужен journaling. А возможно - вы просто не хотите встретиться с реальностью.
#горопека_лайфхаки
4 типа стратегий
Раньше мне казалось, что стратегия компании - это что-то слишком далекое от меня, на что я никак не влияю. Усугублялось это тем, что 1) стратегией называют всё подряд (от vision\mission до системы OKR); 2) хороших стратегий - очень мало.
Хорошая стратегия - это ясный план, что компания будет делать в текущих условиях, с текущими ресурсами. Мало того, типов стратегий всего лишь 4:
1. Стратегия поиска PMF (product - market fit). У компании есть только идея продукта и представление, кому его можно продавать. Но, как вы знаете, первые идеи очень редко оказываются рабочими. Обычно компания проходит через период поиска, когда адаптирует продукт и каналы продаж, чтобы найти тот самый PMF.
2. Стратегия роста. Компания нашла produt-market fit, и теперь начинает “давить на педаль газа”: растить или выручку, или пользователей, или средний чек. Стратегия масштабирования - это подвид стратегии роста, когда компания выжимает педаль газа сильнее.
3. Стратегия оптимизации. Фокус компании - растить прибыль (не выручку). Часто используется в сложных экономических условиях (рецессия, нет дешевых денег) или после периода активного роста, когда операционный убыток становится ну слишком большим.
4. Стратегия pivot. То, что компания построила, перестает работать. Нужно менять бизнес-модель, рынок, продукт, позиционирование, whatever, иначе компания умрет.
Я думаю, каждому из нас важно представлять, какой стратегии следует ваша компания, потому что это может повлиять непосредственно на нашу карьеру.
Период поиска PMF всегда ограничен. У компании просто не будет ресурсов искать его годами. Поэтому если PMF не найдется - вам придется искать другую работу. Также предполагаю, что работать в компании на такой стадии может быть довольно стрессово - время идет, деньги заканчиваются, результатов нет. Но может быть и дико интересно, потому что нет бюрократии, процессов, согласований и прочего - только ваша команда и рынок, к которому нужно найти подход.
При стратегии роста фокус компании будет на быстрой (но системной) проверке гипотез. Кросс-функциональные команды, поиск точек роста, выход на новые сегменты и на новые рынки, выстраивание процессов upsells и cross-sales - опыт, который вы можете получить, работая в растущей компании.
Период оптимизации часто связан с увольнениями. Вы же читали новости про массовые сокращении в ИТ-компаниях - все они оптимизируются после периода бурного роста в пандемию. Еще одним известным примером стратегии оптимизации является компания Apple в конце 90х. Вернувшийся Стив Джобс радикально сократил линейку продуктов, что естественно сопровождалось закрытием заводов и увольнением людей. Но в результате компания не только выжила, но и снова начала успешно расти. Подытожим - в период оптимизации компания фокусируется на сокращении затрат, автоматизации, операционной эффективности. И вы должны быть суперценным сотрудником, задействованным в инициативах оптимизации, чтобы вас не сократили.
Стратегия pivot - очень похожа на поиск PMF, только с той разницей, что у компании уже есть некоторая накопленная экспертиза и конкурентные преимущества. В пример можно привести компанию Netflix, которая начинала бизнес с аренды DVD-диско по почте, а сейчас является одним из крупнейших стриминговых сервисов, еще и со своим собственным производством кинопродукции.
В общем, хорошо написанная стратегия - это не пустые слова и лозунги. Это ясный план, из которого любому сотруднику понятно, чего и как компания хочет добиться. Если вы читаете стратегию вашей компании, и ничего не понимаете - то 99% проблема не в вас, а в авторах.
#горопека_о_стратегии
Раньше мне казалось, что стратегия компании - это что-то слишком далекое от меня, на что я никак не влияю. Усугублялось это тем, что 1) стратегией называют всё подряд (от vision\mission до системы OKR); 2) хороших стратегий - очень мало.
Хорошая стратегия - это ясный план, что компания будет делать в текущих условиях, с текущими ресурсами. Мало того, типов стратегий всего лишь 4:
1. Стратегия поиска PMF (product - market fit). У компании есть только идея продукта и представление, кому его можно продавать. Но, как вы знаете, первые идеи очень редко оказываются рабочими. Обычно компания проходит через период поиска, когда адаптирует продукт и каналы продаж, чтобы найти тот самый PMF.
2. Стратегия роста. Компания нашла produt-market fit, и теперь начинает “давить на педаль газа”: растить или выручку, или пользователей, или средний чек. Стратегия масштабирования - это подвид стратегии роста, когда компания выжимает педаль газа сильнее.
3. Стратегия оптимизации. Фокус компании - растить прибыль (не выручку). Часто используется в сложных экономических условиях (рецессия, нет дешевых денег) или после периода активного роста, когда операционный убыток становится ну слишком большим.
4. Стратегия pivot. То, что компания построила, перестает работать. Нужно менять бизнес-модель, рынок, продукт, позиционирование, whatever, иначе компания умрет.
Я думаю, каждому из нас важно представлять, какой стратегии следует ваша компания, потому что это может повлиять непосредственно на нашу карьеру.
Период поиска PMF всегда ограничен. У компании просто не будет ресурсов искать его годами. Поэтому если PMF не найдется - вам придется искать другую работу. Также предполагаю, что работать в компании на такой стадии может быть довольно стрессово - время идет, деньги заканчиваются, результатов нет. Но может быть и дико интересно, потому что нет бюрократии, процессов, согласований и прочего - только ваша команда и рынок, к которому нужно найти подход.
При стратегии роста фокус компании будет на быстрой (но системной) проверке гипотез. Кросс-функциональные команды, поиск точек роста, выход на новые сегменты и на новые рынки, выстраивание процессов upsells и cross-sales - опыт, который вы можете получить, работая в растущей компании.
Период оптимизации часто связан с увольнениями. Вы же читали новости про массовые сокращении в ИТ-компаниях - все они оптимизируются после периода бурного роста в пандемию. Еще одним известным примером стратегии оптимизации является компания Apple в конце 90х. Вернувшийся Стив Джобс радикально сократил линейку продуктов, что естественно сопровождалось закрытием заводов и увольнением людей. Но в результате компания не только выжила, но и снова начала успешно расти. Подытожим - в период оптимизации компания фокусируется на сокращении затрат, автоматизации, операционной эффективности. И вы должны быть суперценным сотрудником, задействованным в инициативах оптимизации, чтобы вас не сократили.
Стратегия pivot - очень похожа на поиск PMF, только с той разницей, что у компании уже есть некоторая накопленная экспертиза и конкурентные преимущества. В пример можно привести компанию Netflix, которая начинала бизнес с аренды DVD-диско по почте, а сейчас является одним из крупнейших стриминговых сервисов, еще и со своим собственным производством кинопродукции.
В общем, хорошо написанная стратегия - это не пустые слова и лозунги. Это ясный план, из которого любому сотруднику понятно, чего и как компания хочет добиться. Если вы читаете стратегию вашей компании, и ничего не понимаете - то 99% проблема не в вас, а в авторах.
#горопека_о_стратегии
#горопека_заметки
Портал dev.by собрал со своей аудитории основные стереотипы про БА и попросил меня прокомментировать. Если хотите знать, что коллеги по индустрии о нас думают - гоу по ссылке.
Разбирая стереотипы, я думала о том, что за каждым из них ведь стоит реальный кейс. Я лично за свою карьеру успела повидать и душнил, и “девочек\мальчиков из иняза”, и ленивых записывателей за заказчиком. И в большинстве случаев такие “коллеги” прекрасно осознают свои слабые стороны, вот только делать ничего с этим не желают.
Я окей с концепцией, что на работе нужно зарабатывать деньги, а не “болеть душой за проект”. Я сама такая. Но чего я не могу понять - как можно не уважать себя как профессионала. Как можно продолжать делать говно, зная, что делаешь именно его.
Сорри за внеплановые нравоучения, накипело)
И сорри за редкие посты. Я сейчас учусь, плюс новая работа - пока фокус там. Зато у меня стооолько тем накопилось на рефлексию и обдумывание. А поскольку думаю я об бумагу, в том числе в виде этого маленького, но гордого блога, обязательно буду делиться с вами.
Тем не менее, хочется не только писать о своем, но и вам помогать. Поэтому принимаю заявки на волнующие темы по этой ссылке анонимно или в комментариях к посту. С какими проблемами вы сталкиваетесь? Что интересно про продукт-менеджмент и бизнес-анализ?
Портал dev.by собрал со своей аудитории основные стереотипы про БА и попросил меня прокомментировать. Если хотите знать, что коллеги по индустрии о нас думают - гоу по ссылке.
Разбирая стереотипы, я думала о том, что за каждым из них ведь стоит реальный кейс. Я лично за свою карьеру успела повидать и душнил, и “девочек\мальчиков из иняза”, и ленивых записывателей за заказчиком. И в большинстве случаев такие “коллеги” прекрасно осознают свои слабые стороны, вот только делать ничего с этим не желают.
Я окей с концепцией, что на работе нужно зарабатывать деньги, а не “болеть душой за проект”. Я сама такая. Но чего я не могу понять - как можно не уважать себя как профессионала. Как можно продолжать делать говно, зная, что делаешь именно его.
Сорри за внеплановые нравоучения, накипело)
И сорри за редкие посты. Я сейчас учусь, плюс новая работа - пока фокус там. Зато у меня стооолько тем накопилось на рефлексию и обдумывание. А поскольку думаю я об бумагу, в том числе в виде этого маленького, но гордого блога, обязательно буду делиться с вами.
Тем не менее, хочется не только писать о своем, но и вам помогать. Поэтому принимаю заявки на волнующие темы по этой ссылке анонимно или в комментариях к посту. С какими проблемами вы сталкиваетесь? Что интересно про продукт-менеджмент и бизнес-анализ?
Давайте сегодня разберем #вопросподписчика. Публикую с сокращениями.
Часто в рабочей практике сталкиваюсь с проблемой «ухода в детали», чем сильно торможу процесс. Я вроде понимаю, что если не выходит быстро решить вопрос или найти подход, то стоит остановиться и оценить важность этого этапа, спросить себя на что он повлияет и могу ли я идти дальше. Но как правило в моменте это сложно, особенно если проект большой и таких белых пятен очень много (при этом всегда кажется что эти белые пятна и незнание как подступить к вопросу только в моей голове из-за недостатка опыта).
Подскажите, можно ли как-то научиться видеть картину в целом? Не уходить в нюансы и держать в голове суть?
Первое, что хочется сказать - это нормально, что начинающий специалист скатывается в детали, и теряет картину в целом. И очень круто, что вы осознаете это как точку росту.
Второе - такого рода “навыки” развиваются долго, больно, через откаты и наступления на те же самые грабли. Успеха добиваются те, кто упорно не сдается и экспериментирует с разными методами. Так что не ожидайте быстрых результатов, но и не сдавайтесь.
Третье - не думаю, что для таких запросов есть единственно верная метода. Поэтому я расскажу, что помогает мне, но вы должны экспериментировать и рефлексировать сами.
Определите acceptance criteria для задачи, и каждый день сверяйтесь с ними
Введите в привычку для каждой крупной задачи документировать цель и acceptance criteria. Не проговаривать, а документировать. Это поможет ясно сформулировать, лучше запомнить, а главное - убедиться, что вы правильно поняли суть задачи.
Дальше самое главное: каждый день сверяться - вы делаете то, что продвигает вас к цели, или нет? Прям с самого утра, после утренней проверки почты. Нет, “я и так помню” не канает.
Документируйте все возникающие вопросы.
При работе над любой задачей всплывают новые вводные и подзадачи, которые и приводят к “уходу в детали”. Вы не бросаетесь их делать, а создаете раздел “Бэклог”, и документируете всё туда. Так вы решите сразу несколько проблем:
1) боязнь забыть важные нюансы.
2) прозрачность вашей работы - лид будет видеть, какого объема информации вы проработали, пока делали задачу.
3) приоритизации - после окончания текущей задачи вы всегда сможете предложить, что бы вы сделали следующим этапом.
Учитесь фокусу и концентрации. Пришла в голову мысль или вопрос, не связанный с текущей задачей - записали, и больше не отвлекаетесь.
Техника timeboxing
Мы постоянно сталкиваемся с нехваткой контекста, из-за чего боимся принять неправильное решение или оказаться тем самым человеком с кучей тупых вопросов. Поэтому важно находить баланс между ресерчем темы вширь (наработать общий контекст) и вглубь (найти ответ на конкретный узкий вопрос).
Когда я сталкиваюсь с новым контекстом, я всегда даю себе лимитированное количество времени на общий ресерч. В вопросе вы приводили пример Как пример такая ситуация: необходимо было исследовать Google api и понять имеем ли мы возможность получать необходимые показатели. Заказчиком изначально выступал отдел финансов и самым важным показателем который мы должны были найти и получать - был кост за рекламу относительно каждого продукта.
Я бы в этой ситуации отвела себе 2-4 часа на изучение Google API в целом: структура API; наборы параметров; примеры интеграций (case studies); отзывы, вопросы на Stake Overflow; поговорить с chatGPT😁. Таким образом вы погрузитесь немного в контекст, разберете основные определения и сокращения, увидите примеры использования API, что поможет вам в поиске ответа на конкретный вопрос.
Ключевое здесь - жестко следовать лимиту времени. Дали себе 2 часа - после 2х часов вы прекращаете общее изучение и переходите к конкретному вопросу.
Свой вопрос в рубрику #вопросподписчика можете оставить по этой ссылке анонимно или в комментариях к посту.
#горопека_лайфхаки
Часто в рабочей практике сталкиваюсь с проблемой «ухода в детали», чем сильно торможу процесс. Я вроде понимаю, что если не выходит быстро решить вопрос или найти подход, то стоит остановиться и оценить важность этого этапа, спросить себя на что он повлияет и могу ли я идти дальше. Но как правило в моменте это сложно, особенно если проект большой и таких белых пятен очень много (при этом всегда кажется что эти белые пятна и незнание как подступить к вопросу только в моей голове из-за недостатка опыта).
Подскажите, можно ли как-то научиться видеть картину в целом? Не уходить в нюансы и держать в голове суть?
Первое, что хочется сказать - это нормально, что начинающий специалист скатывается в детали, и теряет картину в целом. И очень круто, что вы осознаете это как точку росту.
Второе - такого рода “навыки” развиваются долго, больно, через откаты и наступления на те же самые грабли. Успеха добиваются те, кто упорно не сдается и экспериментирует с разными методами. Так что не ожидайте быстрых результатов, но и не сдавайтесь.
Третье - не думаю, что для таких запросов есть единственно верная метода. Поэтому я расскажу, что помогает мне, но вы должны экспериментировать и рефлексировать сами.
Определите acceptance criteria для задачи, и каждый день сверяйтесь с ними
Введите в привычку для каждой крупной задачи документировать цель и acceptance criteria. Не проговаривать, а документировать. Это поможет ясно сформулировать, лучше запомнить, а главное - убедиться, что вы правильно поняли суть задачи.
Дальше самое главное: каждый день сверяться - вы делаете то, что продвигает вас к цели, или нет? Прям с самого утра, после утренней проверки почты. Нет, “я и так помню” не канает.
Документируйте все возникающие вопросы.
При работе над любой задачей всплывают новые вводные и подзадачи, которые и приводят к “уходу в детали”. Вы не бросаетесь их делать, а создаете раздел “Бэклог”, и документируете всё туда. Так вы решите сразу несколько проблем:
1) боязнь забыть важные нюансы.
2) прозрачность вашей работы - лид будет видеть, какого объема информации вы проработали, пока делали задачу.
3) приоритизации - после окончания текущей задачи вы всегда сможете предложить, что бы вы сделали следующим этапом.
Учитесь фокусу и концентрации. Пришла в голову мысль или вопрос, не связанный с текущей задачей - записали, и больше не отвлекаетесь.
Техника timeboxing
Мы постоянно сталкиваемся с нехваткой контекста, из-за чего боимся принять неправильное решение или оказаться тем самым человеком с кучей тупых вопросов. Поэтому важно находить баланс между ресерчем темы вширь (наработать общий контекст) и вглубь (найти ответ на конкретный узкий вопрос).
Когда я сталкиваюсь с новым контекстом, я всегда даю себе лимитированное количество времени на общий ресерч. В вопросе вы приводили пример Как пример такая ситуация: необходимо было исследовать Google api и понять имеем ли мы возможность получать необходимые показатели. Заказчиком изначально выступал отдел финансов и самым важным показателем который мы должны были найти и получать - был кост за рекламу относительно каждого продукта.
Я бы в этой ситуации отвела себе 2-4 часа на изучение Google API в целом: структура API; наборы параметров; примеры интеграций (case studies); отзывы, вопросы на Stake Overflow; поговорить с chatGPT😁. Таким образом вы погрузитесь немного в контекст, разберете основные определения и сокращения, увидите примеры использования API, что поможет вам в поиске ответа на конкретный вопрос.
Ключевое здесь - жестко следовать лимиту времени. Дали себе 2 часа - после 2х часов вы прекращаете общее изучение и переходите к конкретному вопросу.
Свой вопрос в рубрику #вопросподписчика можете оставить по этой ссылке анонимно или в комментариях к посту.
#горопека_лайфхаки
#вопросыподписчиков Что помогает вам расти в карьере?
Много чего помогает, больше всего - счастливый случай😂.
Если без шуток и структурно, то для любой карьеры нужны:
1) хорошие харды. И поэтому вы часто слышите советы про специализацию - проще сконцентрировать и довести несколько хардов до топ уровня.
2) отличные софты. Да, не просто так из каждого утюга рассказывают про коммуникацию, ответственность, ownership.
3) понимание и своевременное реагирование на тренды рынка труда. И я хз как это поженить со специализацией, ведь только ты на чем-то сконцентрируешься, как уже все поменялось: программисты больше не нужны, стори пишет chatGPT, блокчейн уже не в топе.
Но думаю, это вы и без меня знаете, поэтому давайте я лучше поделюсь тем, что без шуток считаю своим самым важным конкурентным преимуществом. Это - контакт с реальностью.
Мне не важно быть правой или лучше всех - мне важно узнать, а как на самом деле. Т.е. я всегда предпочитаю видеть реальность, а не кормить себя сказками, мечтами и оправданиями. Потому что понимаю: только зная реальность, можно спланировать действия по ее изменению и принять адекватные решения. Это относится и к перфомансу продукта, и к моей работе, и к жизни вообще.
Вроде бы супер очевидная вещь, правда? Только вот почему-то очень многие упражняются в обратном.
5ый спринт подряд команда не выполняет и половину взятых сторей - на 6ой мы возьмем еще больше, ведь у нас всегда были “объективные” причины залажать (реальность - в проектных процессах что-то очень сильно поломано)
4ый месяц неоплачиваемых овертаймов на проекте - меня ценят и любят, и вообще без меня проект развалится (реальность - тебя используют, играя на чувстве тщеславия)
АБ тест возвращается отрицательным - какая-то ошибка в данных, там же в середине АБ теста я видела, был выход в положительную зону, давай перезапустим (реальность - только 20-30% АБ тестов выигрывают).
У меня за плечом 5 успешных проектов, и на этом проекте от всех положительные отзывы, только Вася недоволен моей работой. Я - недостаточно хороший профессионал (реальность - ты отличный профессионал, проблема в Васе).
Принцип контакта с реальностью является основой моей работы. Поэтому я провожу интервью с пользователями, читаю все отзывы, отслеживаю метрики, провожу АБ тесты, исследую конкурентов - чтобы понимать реальных пользователей и реальные рыночные условия, а не строить продукт на фантазиях. По той же причине я регулярно спрашиваю фидбек на свою работу - только так можно узнать свои сильные и слабые стороны, и разработать реалистичный план развития.
А что является вашим "секретным соусом"? Соображаете быстрей других? Сильная эмпатия? Трудолюбие? Слабоумие и отвага😂 ? Давайте порефлексируем в комментах - это будет полезно всем.
#горопека_о_карьере
Много чего помогает, больше всего - счастливый случай😂.
Если без шуток и структурно, то для любой карьеры нужны:
1) хорошие харды. И поэтому вы часто слышите советы про специализацию - проще сконцентрировать и довести несколько хардов до топ уровня.
2) отличные софты. Да, не просто так из каждого утюга рассказывают про коммуникацию, ответственность, ownership.
3) понимание и своевременное реагирование на тренды рынка труда. И я хз как это поженить со специализацией, ведь только ты на чем-то сконцентрируешься, как уже все поменялось: программисты больше не нужны, стори пишет chatGPT, блокчейн уже не в топе.
Но думаю, это вы и без меня знаете, поэтому давайте я лучше поделюсь тем, что без шуток считаю своим самым важным конкурентным преимуществом. Это - контакт с реальностью.
Мне не важно быть правой или лучше всех - мне важно узнать, а как на самом деле. Т.е. я всегда предпочитаю видеть реальность, а не кормить себя сказками, мечтами и оправданиями. Потому что понимаю: только зная реальность, можно спланировать действия по ее изменению и принять адекватные решения. Это относится и к перфомансу продукта, и к моей работе, и к жизни вообще.
Вроде бы супер очевидная вещь, правда? Только вот почему-то очень многие упражняются в обратном.
5ый спринт подряд команда не выполняет и половину взятых сторей - на 6ой мы возьмем еще больше, ведь у нас всегда были “объективные” причины залажать (реальность - в проектных процессах что-то очень сильно поломано)
4ый месяц неоплачиваемых овертаймов на проекте - меня ценят и любят, и вообще без меня проект развалится (реальность - тебя используют, играя на чувстве тщеславия)
АБ тест возвращается отрицательным - какая-то ошибка в данных, там же в середине АБ теста я видела, был выход в положительную зону, давай перезапустим (реальность - только 20-30% АБ тестов выигрывают).
У меня за плечом 5 успешных проектов, и на этом проекте от всех положительные отзывы, только Вася недоволен моей работой. Я - недостаточно хороший профессионал (реальность - ты отличный профессионал, проблема в Васе).
Принцип контакта с реальностью является основой моей работы. Поэтому я провожу интервью с пользователями, читаю все отзывы, отслеживаю метрики, провожу АБ тесты, исследую конкурентов - чтобы понимать реальных пользователей и реальные рыночные условия, а не строить продукт на фантазиях. По той же причине я регулярно спрашиваю фидбек на свою работу - только так можно узнать свои сильные и слабые стороны, и разработать реалистичный план развития.
А что является вашим "секретным соусом"? Соображаете быстрей других? Сильная эмпатия? Трудолюбие? Слабоумие и отвага😂 ? Давайте порефлексируем в комментах - это будет полезно всем.
#горопека_о_карьере
Что “продуктового” может делать бизнес-аналитик на проекте
Профессии бизнес-аналитика и продукт-менеджера очень похожи. Нужно докопаться до сути потребности и придумать решение с пользой для бизнеса и пользователей. Но почему-то часто бизнес-аналитики смотрят на продукт-менеджерство как на совсем далекую профессию.
Давайте я покажу на примере, как много “продуктовых” практик вы уже делаете или можете сделать на своих проектах.
Предложить стратегию развития продукта
Если ваши заказчики строят продукт от бизнеса и потребностей, а не потому что “мне так нравится”, то вы можете потренироваться в написании стратегии развития продукта.
Проанализируйте контекст продукта: рынок, конкурентов \ аналоги, продукт. Выделите ключевые проблемы и возможности. Предложите план действий.
Худшее, что может случится - вашу стратегию проигнорируют. Но даже в этом случае вы потренируетесь на реальном продукте. А скорей всего вы инициируете очень важную дискуссию с заказчиком и зарекомендуете себя как равноправного партнера в развитии продукта, а не “стореписателя”.
Проводить качественные и количественные исследования
Наблюдение за пользователями. Как-то я работала на проекте, где пользователями системы были сотрудники отдела планирования добычи нефти. Одним из самых важных источников требований было наблюдение за их текущей работой. Они садились планировать свои планы, а я садилась рядом и записывала “инсайты”. Более полезной и отрезвляющей практики сложно придумать, вот уж где контакт с реальностью на максималках😁.
Usability-тестирование. Делаете кликабельные прототипы, готовите сценарии тестирования, и просите ваших пользователей выполнить действия в прототипе. Ужасаетесь тому, как кнопки не видят, обязательные поля игнорируют, тултипы и подсказки в принципе не читают - и идете переделывать. Так вы сэкономите деньги заказчика и нервы команды.
Брейншторм. Да-да, это тоже один из методов качественного исследования - когда вы собираете большое количество идей без их критического анализа, а потом приоритизируете и выбираете лучшие. Хорошо работает в ситуации, когда вы зашли тупик, и нужен “взгляд со стороны”. Можно проводить с командой разработки, можно - с конечными пользователями.
Опросы. Спорите с product owner о приоритетах фичей? Сделайте опрос среди ваших конечных пользователей! Да, опросы нужно уметь составлять, это не так просто. Но в этом и суть - пока не попробуете на практике, не научитесь.
Собирать продуктовые метрики
Конечно, если вашим продуктом пользуются 20 человек, то в этом нет смысла. Но если у вашего продукта есть DAU хотя бы пару сотен, уже можно подключить аналитику. Сейчас все основные игроки на рынке предлагают бесплатные планы до какого-то лимита. Имея аналитику, вам будет проще общаться с заказчиком на языке цифр. “Смотри, вот этой функцией почти не пользуются, а ты хочешь делать улучшения на 2 спринта работы. Может быть, пересмотрим приоритеты”?
Делать MVP версии фичей, если нет уверенности в востребованности
Видите, что идея спорная? Предложите заказчику сделать MVP и определите критерии, по которым MVP будет считаться успешным. Так вы будете приучать себя и Заказчика искать дешевые способы проверить гипотезы.
В общем, было бы желание. Я знаю примеры таких сильных “продуктовых” процессов на номинально аутсорсных проектах, что любой продукт позавидует.
#горопека_о_продукте
Профессии бизнес-аналитика и продукт-менеджера очень похожи. Нужно докопаться до сути потребности и придумать решение с пользой для бизнеса и пользователей. Но почему-то часто бизнес-аналитики смотрят на продукт-менеджерство как на совсем далекую профессию.
Давайте я покажу на примере, как много “продуктовых” практик вы уже делаете или можете сделать на своих проектах.
Предложить стратегию развития продукта
Если ваши заказчики строят продукт от бизнеса и потребностей, а не потому что “мне так нравится”, то вы можете потренироваться в написании стратегии развития продукта.
Проанализируйте контекст продукта: рынок, конкурентов \ аналоги, продукт. Выделите ключевые проблемы и возможности. Предложите план действий.
Худшее, что может случится - вашу стратегию проигнорируют. Но даже в этом случае вы потренируетесь на реальном продукте. А скорей всего вы инициируете очень важную дискуссию с заказчиком и зарекомендуете себя как равноправного партнера в развитии продукта, а не “стореписателя”.
Проводить качественные и количественные исследования
Наблюдение за пользователями. Как-то я работала на проекте, где пользователями системы были сотрудники отдела планирования добычи нефти. Одним из самых важных источников требований было наблюдение за их текущей работой. Они садились планировать свои планы, а я садилась рядом и записывала “инсайты”. Более полезной и отрезвляющей практики сложно придумать, вот уж где контакт с реальностью на максималках😁.
Usability-тестирование. Делаете кликабельные прототипы, готовите сценарии тестирования, и просите ваших пользователей выполнить действия в прототипе. Ужасаетесь тому, как кнопки не видят, обязательные поля игнорируют, тултипы и подсказки в принципе не читают - и идете переделывать. Так вы сэкономите деньги заказчика и нервы команды.
Брейншторм. Да-да, это тоже один из методов качественного исследования - когда вы собираете большое количество идей без их критического анализа, а потом приоритизируете и выбираете лучшие. Хорошо работает в ситуации, когда вы зашли тупик, и нужен “взгляд со стороны”. Можно проводить с командой разработки, можно - с конечными пользователями.
Опросы. Спорите с product owner о приоритетах фичей? Сделайте опрос среди ваших конечных пользователей! Да, опросы нужно уметь составлять, это не так просто. Но в этом и суть - пока не попробуете на практике, не научитесь.
Собирать продуктовые метрики
Конечно, если вашим продуктом пользуются 20 человек, то в этом нет смысла. Но если у вашего продукта есть DAU хотя бы пару сотен, уже можно подключить аналитику. Сейчас все основные игроки на рынке предлагают бесплатные планы до какого-то лимита. Имея аналитику, вам будет проще общаться с заказчиком на языке цифр. “Смотри, вот этой функцией почти не пользуются, а ты хочешь делать улучшения на 2 спринта работы. Может быть, пересмотрим приоритеты”?
Делать MVP версии фичей, если нет уверенности в востребованности
Видите, что идея спорная? Предложите заказчику сделать MVP и определите критерии, по которым MVP будет считаться успешным. Так вы будете приучать себя и Заказчика искать дешевые способы проверить гипотезы.
В общем, было бы желание. Я знаю примеры таких сильных “продуктовых” процессов на номинально аутсорсных проектах, что любой продукт позавидует.
#горопека_о_продукте
Как я проходила собеседование в международную компанию
В конце прошлого года я искала новую работу зарубежом. Для интереса подавалась в разные компании, от больших и известных (Bolt, Klarna) до небольших и локальных.
Вы уже не раз слышали, что зарубежный процесс рекрутинга более долгий, в резюме нужно писать о достижениях (а не задачах), подаваться лучше через реферальные программы.
Поэтому я не хочу еще раз рассказывать теорию - лучше поделюсь своим опытом (неудачным😁) собеседования в компанию Klarna.
Этап первый - Скрининг с рекрутером
Ни в одной международной компании не обходилось без скрининга с рекрутером. Иногда это был просто телефонный звонок, иногда прям собес с камерой. Практически никакие детали о вакансии не рассказывают в Linkedin / email, всё на скрининг-звонке.
Вопросы стандартные: про свой опыт и достижения, почему в поиске работы, какой timeline поиска работы, почему именно в эту компанию, вилка зп.
Кажется, здесь главное показать свое соответствие вакансии (описывайте работу и достижения в терминах вакансии) и желание работать именно в этой компании 😄
Этап второй - логический тест
Это был прикол. Сначала мне выслали вот эту ссылку как пример. Потом на звонке с рекрутером с включенной камерой (обязательное условие) я проходила их версию теста, которая раза в 3 была тяжелее. Результат прохождения сразу ты не знаешь.
На следующей день мне прислали письмо, что результат теста 16/18, и меня готовы позвать на интервью дальше. Видимо, таким забавным образом проверялось “логическое мышление”?
Этап третий - Behavioural interview
Мне выслали документ с описанием их ценностей (Customer Obsession, Courage, Deliver Quality Results и т.д.). Попросили подумать о конкретных примерах из работы, которые подтверждают соответствие этим ценностями.
Собеседование так и проходило - продакт рассказывала про ценность и спрашивала о моем отношении и примерах из работы.
Этап четвертый - Skills interview
На этом этапе проверяется, насколько ты владеешь теорией и практикой в product management.
Доказывать владение опять-таки нужно конкретными примерами из работы. Меньше “мы сделали”, больше “я организовала”, “я залидила”. Все примеры нужно рассказывать по STAR.
Этап пятый - выполнение case study и обратная связь по нему
Case study можно посмотреть тут. Я считаю, что скоуп case study неадекватен. Определить mission, vision, competitive landscape, initiatives - это слишком большой запрос на тестовое задание. Если будет интересно - я поделюсь case study от Bolt, который мне показался намного уместнее с точки зрения объема и скиллов, которые проверяются.
После выполнения была встреча по представлению и обсуждению своего case study. Подключились 2 продакта, и за час мы обсудили мою работу.
Дальше я не прошла (поэтому мне case study и не понравился 😂), но предполагалось, что флоу будет
Этап шесть - встреча с командой и Этап семь - обсуждение оффера
Выводы: 1) пройти отбор в международную компанию сложно, но возможно 2) закладывайте длинный процесс рекрутинга и время на выполнение case studies 3) в каждой следующей компании мне было проще продвигаться по процессу, потому что я делала выводы из своих ошибок.
Делитесь в комментариях своим опытом прохождения собеса в международные компании!
#горопека_о_собеседованиях
В конце прошлого года я искала новую работу зарубежом. Для интереса подавалась в разные компании, от больших и известных (Bolt, Klarna) до небольших и локальных.
Вы уже не раз слышали, что зарубежный процесс рекрутинга более долгий, в резюме нужно писать о достижениях (а не задачах), подаваться лучше через реферальные программы.
Поэтому я не хочу еще раз рассказывать теорию - лучше поделюсь своим опытом (неудачным😁) собеседования в компанию Klarna.
Этап первый - Скрининг с рекрутером
Ни в одной международной компании не обходилось без скрининга с рекрутером. Иногда это был просто телефонный звонок, иногда прям собес с камерой. Практически никакие детали о вакансии не рассказывают в Linkedin / email, всё на скрининг-звонке.
Вопросы стандартные: про свой опыт и достижения, почему в поиске работы, какой timeline поиска работы, почему именно в эту компанию, вилка зп.
Кажется, здесь главное показать свое соответствие вакансии (описывайте работу и достижения в терминах вакансии) и желание работать именно в этой компании 😄
Этап второй - логический тест
Это был прикол. Сначала мне выслали вот эту ссылку как пример. Потом на звонке с рекрутером с включенной камерой (обязательное условие) я проходила их версию теста, которая раза в 3 была тяжелее. Результат прохождения сразу ты не знаешь.
На следующей день мне прислали письмо, что результат теста 16/18, и меня готовы позвать на интервью дальше. Видимо, таким забавным образом проверялось “логическое мышление”?
Этап третий - Behavioural interview
Мне выслали документ с описанием их ценностей (Customer Obsession, Courage, Deliver Quality Results и т.д.). Попросили подумать о конкретных примерах из работы, которые подтверждают соответствие этим ценностями.
Собеседование так и проходило - продакт рассказывала про ценность и спрашивала о моем отношении и примерах из работы.
Этап четвертый - Skills interview
На этом этапе проверяется, насколько ты владеешь теорией и практикой в product management.
Доказывать владение опять-таки нужно конкретными примерами из работы. Меньше “мы сделали”, больше “я организовала”, “я залидила”. Все примеры нужно рассказывать по STAR.
Этап пятый - выполнение case study и обратная связь по нему
Case study можно посмотреть тут. Я считаю, что скоуп case study неадекватен. Определить mission, vision, competitive landscape, initiatives - это слишком большой запрос на тестовое задание. Если будет интересно - я поделюсь case study от Bolt, который мне показался намного уместнее с точки зрения объема и скиллов, которые проверяются.
После выполнения была встреча по представлению и обсуждению своего case study. Подключились 2 продакта, и за час мы обсудили мою работу.
Дальше я не прошла (поэтому мне case study и не понравился 😂), но предполагалось, что флоу будет
Этап шесть - встреча с командой и Этап семь - обсуждение оффера
Выводы: 1) пройти отбор в международную компанию сложно, но возможно 2) закладывайте длинный процесс рекрутинга и время на выполнение case studies 3) в каждой следующей компании мне было проще продвигаться по процессу, потому что я делала выводы из своих ошибок.
Делитесь в комментариях своим опытом прохождения собеса в международные компании!
#горопека_о_собеседованиях
#вопросыподписчиков Как вы выбираете места для работы? По каким критериям?
Очевидно, что на разных этапах жизни и карьеры критерии меняются. Если вы молодая мама с маленькими детьми, вы можете приоритизировать свое спокойствие, гибкий график работы, отсутствие командировок и в целом челленджей. Если карьера и рост ваш приоритет, то критерии будут во многом противоположные.
Поэтому сначала честно ответьте себе на вопрос, почему вы хотите поменять работу. Меньше работать и при этом больше зарабатывать тоже нормальные критерии, если это то, что вы действительно хотите. Просто не говорите об этом на собеседовании😂
Сделав оговорку, что всё индивидуально, расскажу про свою схему.
В начале карьеры бизнес-аналитика (а потом и продукт-менеджера) я всегда приоритизировала опыт и начальников. Особенно важно выбрать крутого начальника и команду, которые будут давать адекватный фидбек и учить вас. Иначе вы рискуете потратить время впустую и заработать неадекватную профессиональную самооценку.
В плане опыта я бы не советовала идти в условный стартап или в хаотичные процессы. Да, с одной стороны вы сможете попробовать много разных задач. Но с другой - вы не узнаете, как строятся правильные процессы работы, что может застопорить ваш карьерный рост в дальнейшем, особенно по менеджерской ветке.
А вот дальше, когда я росла в сеньоры, я выбирала те компании и позиции, где смогу лучше всего монетизировать свои скиллы🙂. Когда я переходила в Oxagile, в компании не было отдела бизнес-анализа. У меня же был опыт построения бизнес-аналитических процессов с нуля, опыт найма и руководства бизнес-аналитиками, и т.д. Мне уже не нужен был начальник, чтобы об него учиться, я сама могла им стать. Что я и сделала😁 И я не плохо росла в деньгах и задачах в рамках компании на протяжении нескольких лет, потому что очевидно имела намного больше влияния на свою карьеру, будучи руководителем.
Еще, лично для меня важно не быть винтиком в огромной машине. Я сознательно не шла в EPAM, и сознательно не рвусь в FAANG - не хочу быть еще одной среди многих. Мой выбор - компании среднего размера, где уже есть деньги и масштаб, но при этом проще быть видимой.
Итого:
1. В начале карьеры:
1. выбирайте крутого начальника и команду.
2. лучше начинайте в компаниях с хорошими процессами.
3. приоритизируйте опыт, а не деньги
2. После этого выбирайте те компании, где:
1. вы сможете лучше всего применить свой опыт и знания, и монетизировать вложения начала карьеры.
2. нет начальников, бардак в процессах, и т.д. - это ваш шанс не ждать повышения долгие годы, а сразу получить нужную вам должность, грамотно проявив себя.
Свой вопрос в рубрику #вопросподписчика можете оставить по этой ссылке анонимно или в комментариях к посту.
#горопека_о_карьере
Очевидно, что на разных этапах жизни и карьеры критерии меняются. Если вы молодая мама с маленькими детьми, вы можете приоритизировать свое спокойствие, гибкий график работы, отсутствие командировок и в целом челленджей. Если карьера и рост ваш приоритет, то критерии будут во многом противоположные.
Поэтому сначала честно ответьте себе на вопрос, почему вы хотите поменять работу. Меньше работать и при этом больше зарабатывать тоже нормальные критерии, если это то, что вы действительно хотите. Просто не говорите об этом на собеседовании😂
Сделав оговорку, что всё индивидуально, расскажу про свою схему.
В начале карьеры бизнес-аналитика (а потом и продукт-менеджера) я всегда приоритизировала опыт и начальников. Особенно важно выбрать крутого начальника и команду, которые будут давать адекватный фидбек и учить вас. Иначе вы рискуете потратить время впустую и заработать неадекватную профессиональную самооценку.
В плане опыта я бы не советовала идти в условный стартап или в хаотичные процессы. Да, с одной стороны вы сможете попробовать много разных задач. Но с другой - вы не узнаете, как строятся правильные процессы работы, что может застопорить ваш карьерный рост в дальнейшем, особенно по менеджерской ветке.
А вот дальше, когда я росла в сеньоры, я выбирала те компании и позиции, где смогу лучше всего монетизировать свои скиллы🙂. Когда я переходила в Oxagile, в компании не было отдела бизнес-анализа. У меня же был опыт построения бизнес-аналитических процессов с нуля, опыт найма и руководства бизнес-аналитиками, и т.д. Мне уже не нужен был начальник, чтобы об него учиться, я сама могла им стать. Что я и сделала😁 И я не плохо росла в деньгах и задачах в рамках компании на протяжении нескольких лет, потому что очевидно имела намного больше влияния на свою карьеру, будучи руководителем.
Еще, лично для меня важно не быть винтиком в огромной машине. Я сознательно не шла в EPAM, и сознательно не рвусь в FAANG - не хочу быть еще одной среди многих. Мой выбор - компании среднего размера, где уже есть деньги и масштаб, но при этом проще быть видимой.
Итого:
1. В начале карьеры:
1. выбирайте крутого начальника и команду.
2. лучше начинайте в компаниях с хорошими процессами.
3. приоритизируйте опыт, а не деньги
2. После этого выбирайте те компании, где:
1. вы сможете лучше всего применить свой опыт и знания, и монетизировать вложения начала карьеры.
2. нет начальников, бардак в процессах, и т.д. - это ваш шанс не ждать повышения долгие годы, а сразу получить нужную вам должность, грамотно проявив себя.
Свой вопрос в рубрику #вопросподписчика можете оставить по этой ссылке анонимно или в комментариях к посту.
#горопека_о_карьере
Как решать кейсы
В процессе собеседования на продакта компании часто просят выполнить case study. Честно говоря, я их очень понимаю: языком молоть все горазды, так что проверять нужно на деле (пусть и тестовом).
У меня неплохой опыт решения кейсов на учебе и собесах. Поэтому есть несколько рекомендаций, которые помогут вам справиться с кейсами успешно.
Поймите, какие навыки проверяются в рамках кейса.
Кейс всегда дается для того, чтобы проверить знания и навыки, а не получить “правильный” ответ. Соответственно, вы должны понять, какие навыки проверяются, и сконцентрировать решение кейса на демонстрации этих навыков.
Также кейс проверяет вашу способность (и желание🙂) быстро вникнуть в доменную область. Например, при решении кейса от Bolt мне пришлось поресерчить ride-hailing industry, чтобы понять возможные ограничения в способах проверки гипотез. Так что рекомендую исследовать индустрию и продукт, чтобы ввернуть парочку релевантных терминов и подходов в кейс. Это покажет вашу мотивацию работать именно с данным продуктом.
В решении должна быть понятная и логичная структура.
Повторюсь: кейс помогает понять ваши знания, навыки, а также подход к решению задач и в целом ход мыслей. Так вот структура решение - это отражение всего вышеперечисленного. На какие этапы вы делите работу? Какие альтернативы вы рассмотрите на таком-то этапе? Какие техники \ фреймворки примените? Как поступите в зависимости от результатов предыдущего этапа?
Оберните ограничения тестового формата в свою пользу.
При решении кейсов коллеги часто впадают в ступор “мало данных”. В реальной работе у тебя всегда есть аналитика, инсайты от пользователей, прошлые результаты тестов, которые формируют вводные и ограничения. А тут тебя просят предложить решение по сути без данных. Это же невозможно!
Предлагаю перевернуть свое отношение на противоположное - данных почти нет, поэтому я могу делать такие допущения и ограничения, которые выгодно покажут мое владение навыками. Я не могу пойти и провести исследование пользователей, но я могу написать “предположим, после исследования я получила такие-то инсайты”. После чего сформулировать такие гипотезы, по которым у меня есть крутые идеи по быстрой проверке, чтобы выгодно показать свой навык “проверять гипотезы дешево”.
Понимаете, да? Ограничения кейса - это уникальная возможность повернуть его в ту сторону, где вы сильнее. Но не увлекайтесь, всё-таки в кейсе есть определенные вопросы, вы не можете в процессе решения придумать себе совершенно другой кейс 😂.
Поработайте над качеством оформления и ясностью изложения
Кейсы проверяют навык письменной коммуникации. Поэтому обязательно выделите краткое summary, разделите текст на разделы, поработайте с форматированием. Пишите простым и ясным языком, проверьте английский. В общем, сделайте всё, чтобы навык письменной коммуникации показать в лучшем виде.
А теперь аттракцион невиданной щедрости. Ниже дана реальная задача из кейса от Bolt. Первых 3 человека, которые в течение недели его решат, получат мои комментарии по кейсу. Ссылку на решение постить в комментах к посту (ничего из лички смотреть не буду).
Imagine that you are the product manager responsible for Bolt’s ride-hailing product. One of the ideas that was added to your backlog is the ride scheduling functionality. Analyse this scheduling feature from the product perspective and make a recommendation whether to proceed to the implementation step. What is important for flawless rider and driver experience? What are the constraints to consider when planning this feature? Should Bolt build it or not, and why? How would you measure success?
P.S. У меня нет иллюзий. Вряд ли кто-то из вас сядет и реально потренируется. Но, как говорится, мое дело - предложить, ваше дело - отказаться.
В процессе собеседования на продакта компании часто просят выполнить case study. Честно говоря, я их очень понимаю: языком молоть все горазды, так что проверять нужно на деле (пусть и тестовом).
У меня неплохой опыт решения кейсов на учебе и собесах. Поэтому есть несколько рекомендаций, которые помогут вам справиться с кейсами успешно.
Поймите, какие навыки проверяются в рамках кейса.
Кейс всегда дается для того, чтобы проверить знания и навыки, а не получить “правильный” ответ. Соответственно, вы должны понять, какие навыки проверяются, и сконцентрировать решение кейса на демонстрации этих навыков.
Также кейс проверяет вашу способность (и желание🙂) быстро вникнуть в доменную область. Например, при решении кейса от Bolt мне пришлось поресерчить ride-hailing industry, чтобы понять возможные ограничения в способах проверки гипотез. Так что рекомендую исследовать индустрию и продукт, чтобы ввернуть парочку релевантных терминов и подходов в кейс. Это покажет вашу мотивацию работать именно с данным продуктом.
В решении должна быть понятная и логичная структура.
Повторюсь: кейс помогает понять ваши знания, навыки, а также подход к решению задач и в целом ход мыслей. Так вот структура решение - это отражение всего вышеперечисленного. На какие этапы вы делите работу? Какие альтернативы вы рассмотрите на таком-то этапе? Какие техники \ фреймворки примените? Как поступите в зависимости от результатов предыдущего этапа?
Оберните ограничения тестового формата в свою пользу.
При решении кейсов коллеги часто впадают в ступор “мало данных”. В реальной работе у тебя всегда есть аналитика, инсайты от пользователей, прошлые результаты тестов, которые формируют вводные и ограничения. А тут тебя просят предложить решение по сути без данных. Это же невозможно!
Предлагаю перевернуть свое отношение на противоположное - данных почти нет, поэтому я могу делать такие допущения и ограничения, которые выгодно покажут мое владение навыками. Я не могу пойти и провести исследование пользователей, но я могу написать “предположим, после исследования я получила такие-то инсайты”. После чего сформулировать такие гипотезы, по которым у меня есть крутые идеи по быстрой проверке, чтобы выгодно показать свой навык “проверять гипотезы дешево”.
Понимаете, да? Ограничения кейса - это уникальная возможность повернуть его в ту сторону, где вы сильнее. Но не увлекайтесь, всё-таки в кейсе есть определенные вопросы, вы не можете в процессе решения придумать себе совершенно другой кейс 😂.
Поработайте над качеством оформления и ясностью изложения
Кейсы проверяют навык письменной коммуникации. Поэтому обязательно выделите краткое summary, разделите текст на разделы, поработайте с форматированием. Пишите простым и ясным языком, проверьте английский. В общем, сделайте всё, чтобы навык письменной коммуникации показать в лучшем виде.
А теперь аттракцион невиданной щедрости. Ниже дана реальная задача из кейса от Bolt. Первых 3 человека, которые в течение недели его решат, получат мои комментарии по кейсу. Ссылку на решение постить в комментах к посту (ничего из лички смотреть не буду).
Imagine that you are the product manager responsible for Bolt’s ride-hailing product. One of the ideas that was added to your backlog is the ride scheduling functionality. Analyse this scheduling feature from the product perspective and make a recommendation whether to proceed to the implementation step. What is important for flawless rider and driver experience? What are the constraints to consider when planning this feature? Should Bolt build it or not, and why? How would you measure success?
P.S. У меня нет иллюзий. Вряд ли кто-то из вас сядет и реально потренируется. Но, как говорится, мое дело - предложить, ваше дело - отказаться.
Что важно сделать в первые месяцы работы
рубрика #вопросыподписчиков
Нужно 1) разобраться в контексте и 2) зарекомендовать себя.
Теперь несколько практических советов:
1. Никому сразу не верьте на слово. Одни коллеги вам будут рассказывать, какой заказчик - редиска. Другие коллеги будут жаловаться вам на менеджмент. Третьи будут в супер-восторге от компании и продукта. Вы слушайте, принимайте к сведению, но не верьте никому на слово и не делайте поспешных выводов. Ваша задача - составить ваше собственное понимание контекста.
2. Не вступайте ни в какие коалиции и кружки. Да, в компаниях с хорошей культурой нет вражды между отделами или командами. Но в реальности всегда (я подчеркну - ВСЕГДА) есть какие-то терки. В большом или меньшем масштабе. На уровне функций (маркетинг не дружит с продуктом) или просто на уровне людей (Ваня не переваривает Васю). И пока вы новенькая и не разобрались во всем этом - вы должны держать нейтралитет.
3. Разберитесь, кто в реальности принимает решения в компании. Иногда это не ваш начальник на бумаге, а какой-нибудь старожила, работающий в компании 15 лет. И если вы не сработаетесь и не понравитесь ему, никакой начальник вам не поможет. Да, это несправедливо. Нет, ничего с этим вы не сделаете, пока не зарекомендуете себя.
4. Разберитесь, кто в реальности делает работу, а кто балаболит. Если сознательно обращать внимание, то быстро становится очевидно, какие коллеги работают (часто больше и шире своих прямых обязанностей), а кто только затычка в каждом слак-трэде. Если вы пришли делать работу, то вам нужно наладить хорошие отношения с первыми. Если вы пришли просаживать штаны - учитесь мастерству у вторых.
5. Разберитесь, что “болит” у вашего начальника, и как вы можете помочь. Не хватает времени на стратегически-важные задачи - вы можете закрывать часть задач (пусть даже в вакансии этого не стояло); требуют улучшения метрик и доходов - приоритизируйте поиск точек роста, а не очередной редизайн.
6. Сконцентрируйтесь на easy wins. Эти easy wins должны быть напрямую связаны с болями команды и начальника. Лучший способ зарекомендовать себя - сделать 2-3 конкретных небольших достижений за 3 месяца испытательного срока. ИС не время для изменений и нытья “по таким процессам ничего не заработает”, “я не могу работать нормально, пока не не выделят дизайнера и аналитика” и т.д. ИС не время для инициации масштабных изменений - у вас еще нет кредита доверия, да и результаты вы не получите за 3 месяца. До всего этого вы дойдете, но сначала нужно хорошо разобраться в контексте и не наломать дров.
#горопека_о_карьере
рубрика #вопросыподписчиков
Нужно 1) разобраться в контексте и 2) зарекомендовать себя.
Теперь несколько практических советов:
1. Никому сразу не верьте на слово. Одни коллеги вам будут рассказывать, какой заказчик - редиска. Другие коллеги будут жаловаться вам на менеджмент. Третьи будут в супер-восторге от компании и продукта. Вы слушайте, принимайте к сведению, но не верьте никому на слово и не делайте поспешных выводов. Ваша задача - составить ваше собственное понимание контекста.
2. Не вступайте ни в какие коалиции и кружки. Да, в компаниях с хорошей культурой нет вражды между отделами или командами. Но в реальности всегда (я подчеркну - ВСЕГДА) есть какие-то терки. В большом или меньшем масштабе. На уровне функций (маркетинг не дружит с продуктом) или просто на уровне людей (Ваня не переваривает Васю). И пока вы новенькая и не разобрались во всем этом - вы должны держать нейтралитет.
3. Разберитесь, кто в реальности принимает решения в компании. Иногда это не ваш начальник на бумаге, а какой-нибудь старожила, работающий в компании 15 лет. И если вы не сработаетесь и не понравитесь ему, никакой начальник вам не поможет. Да, это несправедливо. Нет, ничего с этим вы не сделаете, пока не зарекомендуете себя.
4. Разберитесь, кто в реальности делает работу, а кто балаболит. Если сознательно обращать внимание, то быстро становится очевидно, какие коллеги работают (часто больше и шире своих прямых обязанностей), а кто только затычка в каждом слак-трэде. Если вы пришли делать работу, то вам нужно наладить хорошие отношения с первыми. Если вы пришли просаживать штаны - учитесь мастерству у вторых.
5. Разберитесь, что “болит” у вашего начальника, и как вы можете помочь. Не хватает времени на стратегически-важные задачи - вы можете закрывать часть задач (пусть даже в вакансии этого не стояло); требуют улучшения метрик и доходов - приоритизируйте поиск точек роста, а не очередной редизайн.
6. Сконцентрируйтесь на easy wins. Эти easy wins должны быть напрямую связаны с болями команды и начальника. Лучший способ зарекомендовать себя - сделать 2-3 конкретных небольших достижений за 3 месяца испытательного срока. ИС не время для изменений и нытья “по таким процессам ничего не заработает”, “я не могу работать нормально, пока не не выделят дизайнера и аналитика” и т.д. ИС не время для инициации масштабных изменений - у вас еще нет кредита доверия, да и результаты вы не получите за 3 месяца. До всего этого вы дойдете, но сначала нужно хорошо разобраться в контексте и не наломать дров.
#горопека_о_карьере
#пятничныйread #горопека_заметки
Всем, кто интересуется темой стратегии - рекомендую к прочтению статью-мнение про стратегию Apple в AI.
Офигенный пример хорошей стратегии:
1️⃣Основана на понимании своих сильных и слабых сторон:
1. privacy и excellent user experience - основа бренда, которая не должна страдать при внедрении чего-либо
2. наличии собственных чипов и возможности адаптировать работу моделей под конкретные свои чипы
3. продукты типо Siri, которые очевидно выигрывают от внедрения AI
2️⃣Работает на укрепление собственных конкурентных преимуществ (а не просто копирует конкурентов):
1. связка чипы эппла + on-device machine learning должна дать крутой UX
2. позволит еще больше накапливать данные —> больше инсайтов о поведении пользователей → больше крутых продуктов и фичей
3️⃣Фокусирует компанию.
Apple не собирается распыляться на прямую конкуренцию с OpenAI или Google, или делать продукты вокруг AI. Apple будет концентрироваться на том, в чем уже является лидером - на своих продуктах и девайсах, используя AI в тех случаях, где это уместно.
#горопека_о_стратегии
Всем, кто интересуется темой стратегии - рекомендую к прочтению статью-мнение про стратегию Apple в AI.
Офигенный пример хорошей стратегии:
1️⃣Основана на понимании своих сильных и слабых сторон:
1. privacy и excellent user experience - основа бренда, которая не должна страдать при внедрении чего-либо
2. наличии собственных чипов и возможности адаптировать работу моделей под конкретные свои чипы
3. продукты типо Siri, которые очевидно выигрывают от внедрения AI
2️⃣Работает на укрепление собственных конкурентных преимуществ (а не просто копирует конкурентов):
1. связка чипы эппла + on-device machine learning должна дать крутой UX
2. позволит еще больше накапливать данные —> больше инсайтов о поведении пользователей → больше крутых продуктов и фичей
3️⃣Фокусирует компанию.
Apple не собирается распыляться на прямую конкуренцию с OpenAI или Google, или делать продукты вокруг AI. Apple будет концентрироваться на том, в чем уже является лидером - на своих продуктах и девайсах, используя AI в тех случаях, где это уместно.
#горопека_о_стратегии
Откуда продакт берет гипотезы
#вопросподписчика Простите за глупый вопрос, но откуда продакты берут гипотезы? У вас нет страха, что вы просто не сможете придумать, что делать дальше?
Думаю, какое-то количество продактов именно об этом разговаривает со своим психологом😂 И как в любой шутке, тут только доля шутки.
Дорогой подписчик зрит в корень. Одно из отличий между бизнес-аналитиком и продакт-менеджером заключается в том, что бизнес-аналитику скоуп “приносят” (и проблема скорее в том, как убедить включить в этот скоуп свои идеи), а продакт самостоятельно отвечает за генерацию скоупа.
Этот навык называется системная работа с гипотезами. Продакт должен уметь выстраивать процесс end-to-end: от сбора и генерации гипотез и их приоритизации до быстрой валидации и доставки до пользователей.
Откуда, собственно, можно и нужно брать гипотезы:
1. Анализировать данные. На каком шаге воронки пользователи отваливаются? Какими функциями пользуются, а какими - нет? Какие функции коррелируют с хорошим ретеншеном?
2. Отзывы и информация от суппорта \ сейлзов. Что пишут в сторах, на сайтах типо trustpilot? С какими обращениями приходят в суппорт? Что указывают в причине отписок?
3. Проводить качественные исследования пользователей. Это могут быть опросы, глубинные интервью, usability testing, дневниковые исследования. Всё определяется целью, бюджетом и навыками команды.
4. Анализировать конкурентов. Какие функции \ изменения они выпускают? Почему? Можем ли мы похожее пробовать, сработает ли это для нашей стратегии и нашей аудитории? Подсматривать и вдохновляться можно не только у прямых конкурентов, но и у продуктов c других индустрий.
5. Раннить АБ тесты и качественно анализировать результаты. Качественный post-test анализ результатов АБ теста может принести несколько хороших гипотез. Многие успешные идеи в моей практике родились из проигранных АБ тестов.
6. Проводить брейнштормы с командой. Возможно, это показатель моей некрутости, но НИКОГДА не было такого, чтобы я самостоятельно придумала решение лучше, чем в брейншторме с кем-то. Самые лучшие идеи рождаются на стыке разных экспертиз и знаний.
7. Behavioral science-based hypotheses, UX basics, classic CRO / marketing tactics. Однажды 1 тест, основанный на loss aversion bias (гугл переводит как “предвзятость избегания потерь”), сделал весь OKR на квартал. В другой раз добавление понятного call to action в воронке привлечения сильно увеличил конверсию в оплату. Поэтому такие идеи всегда есть в моем роудмапе.
8. Интуиция, озарения, “а давай попробуем”. Не рекомендую использовать, пока вы не погрузитесь в продукт и индустрию основательно. И конечно же весь роудмап не должен быть основан только на таких гипотезах. Но не зря есть понятие produce sense, поэтому игнорировать свою продуктовую интуицию постоянно тоже не стоит.
Свой вопрос в рубрику #вопросподписчика можете оставить по этой ссылке анонимно или в комментариях к посту.
#горопека_о_продукте
#вопросподписчика Простите за глупый вопрос, но откуда продакты берут гипотезы? У вас нет страха, что вы просто не сможете придумать, что делать дальше?
Думаю, какое-то количество продактов именно об этом разговаривает со своим психологом😂 И как в любой шутке, тут только доля шутки.
Дорогой подписчик зрит в корень. Одно из отличий между бизнес-аналитиком и продакт-менеджером заключается в том, что бизнес-аналитику скоуп “приносят” (и проблема скорее в том, как убедить включить в этот скоуп свои идеи), а продакт самостоятельно отвечает за генерацию скоупа.
Этот навык называется системная работа с гипотезами. Продакт должен уметь выстраивать процесс end-to-end: от сбора и генерации гипотез и их приоритизации до быстрой валидации и доставки до пользователей.
Откуда, собственно, можно и нужно брать гипотезы:
1. Анализировать данные. На каком шаге воронки пользователи отваливаются? Какими функциями пользуются, а какими - нет? Какие функции коррелируют с хорошим ретеншеном?
2. Отзывы и информация от суппорта \ сейлзов. Что пишут в сторах, на сайтах типо trustpilot? С какими обращениями приходят в суппорт? Что указывают в причине отписок?
3. Проводить качественные исследования пользователей. Это могут быть опросы, глубинные интервью, usability testing, дневниковые исследования. Всё определяется целью, бюджетом и навыками команды.
4. Анализировать конкурентов. Какие функции \ изменения они выпускают? Почему? Можем ли мы похожее пробовать, сработает ли это для нашей стратегии и нашей аудитории? Подсматривать и вдохновляться можно не только у прямых конкурентов, но и у продуктов c других индустрий.
5. Раннить АБ тесты и качественно анализировать результаты. Качественный post-test анализ результатов АБ теста может принести несколько хороших гипотез. Многие успешные идеи в моей практике родились из проигранных АБ тестов.
6. Проводить брейнштормы с командой. Возможно, это показатель моей некрутости, но НИКОГДА не было такого, чтобы я самостоятельно придумала решение лучше, чем в брейншторме с кем-то. Самые лучшие идеи рождаются на стыке разных экспертиз и знаний.
7. Behavioral science-based hypotheses, UX basics, classic CRO / marketing tactics. Однажды 1 тест, основанный на loss aversion bias (гугл переводит как “предвзятость избегания потерь”), сделал весь OKR на квартал. В другой раз добавление понятного call to action в воронке привлечения сильно увеличил конверсию в оплату. Поэтому такие идеи всегда есть в моем роудмапе.
8. Интуиция, озарения, “а давай попробуем”. Не рекомендую использовать, пока вы не погрузитесь в продукт и индустрию основательно. И конечно же весь роудмап не должен быть основан только на таких гипотезах. Но не зря есть понятие produce sense, поэтому игнорировать свою продуктовую интуицию постоянно тоже не стоит.
Свой вопрос в рубрику #вопросподписчика можете оставить по этой ссылке анонимно или в комментариях к посту.
#горопека_о_продукте