🧭 Рубрикатор-навигатор
Выражение "И чтец, и жнец, и на дуде игрец,и всем капец" идеально описывает идеального продакта. Потому что выбрав для себя путь Product Manager придется быть скилловым товарищем и иметь высокий уровень экспертности во многих областях.
Сегодня мы перечислим те составляющие, без которых, на наш взгляд, не может быть хорошего продуктового менеджера, и заодно превратим их в удобный (как мы надеемся) рубрикатор для последующих публикаций и поиска нужных вам тем.
1. Идея
- #JTBD_AGIMA
- #value_prop_AGIMA
- #custdev_AGIMA
- #marketing_reseach_AGIMA
- #design_thinking_AGIMA
2. План
- #roadmap_AGIMA
- #business_model_canvas_AGIMA
- #lean_canvas_model_AGIMA
- #cashflow_AGIMA
- #frameworks_AGIMA
3. Разработка продукта
- #development_methodologies_AGIMA
- #MVP_AGIMA
- #agile_AGIMA
- #lean_startup_AGIMA
- #user_stories_AGIMA
- #managing_team_AGIMA
- #user_interviews_AGIMA
- #release_notes_AGIMA
4. Качество
- #user_testing_AGIMA
- #dogfooding_AGIMA
- #demo_AGIMA
5. Запуск
- #user_guides_AGIMA
- #monetisation_AGIMA
- #community_management_AGIMA
- #cx_ux_AGIMA
6. Улучшение продукта
- #cx_ux_research_AGIMA
- #ab_testing_AGIMA
7. Общее для всех этапов
- #product_analysis_AGIMA
- #product_metrics_AGIMA
- #product_marketing_AGIMA
- #product_design_AGIMA
- #PM_reading_AGIMA
- #case_AGIMA
- #video_AGIMA
- #conference_AGIMA
- #knowledge_AGIMA
Это оглавление будет дополняться новыми рубриками и хэштегами для них — во имя развития этого канала и вашей профессиональной насмотренности 💪
Выражение "И чтец, и жнец, и на дуде игрец,
Сегодня мы перечислим те составляющие, без которых, на наш взгляд, не может быть хорошего продуктового менеджера, и заодно превратим их в удобный (как мы надеемся) рубрикатор для последующих публикаций и поиска нужных вам тем.
1. Идея
- #JTBD_AGIMA
- #value_prop_AGIMA
- #custdev_AGIMA
- #marketing_reseach_AGIMA
- #design_thinking_AGIMA
2. План
- #roadmap_AGIMA
- #business_model_canvas_AGIMA
- #lean_canvas_model_AGIMA
- #cashflow_AGIMA
- #frameworks_AGIMA
3. Разработка продукта
- #development_methodologies_AGIMA
- #MVP_AGIMA
- #agile_AGIMA
- #lean_startup_AGIMA
- #user_stories_AGIMA
- #managing_team_AGIMA
- #user_interviews_AGIMA
- #release_notes_AGIMA
4. Качество
- #user_testing_AGIMA
- #dogfooding_AGIMA
- #demo_AGIMA
5. Запуск
- #user_guides_AGIMA
- #monetisation_AGIMA
- #community_management_AGIMA
- #cx_ux_AGIMA
6. Улучшение продукта
- #cx_ux_research_AGIMA
- #ab_testing_AGIMA
7. Общее для всех этапов
- #product_analysis_AGIMA
- #product_metrics_AGIMA
- #product_marketing_AGIMA
- #product_design_AGIMA
- #PM_reading_AGIMA
- #case_AGIMA
- #video_AGIMA
- #conference_AGIMA
- #knowledge_AGIMA
Это оглавление будет дополняться новыми рубриками и хэштегами для них — во имя развития этого канала и вашей профессиональной насмотренности 💪
🧐 JTBD используют все. Или нет?
Про jobs-to-be-done можно услышать из каждого тапка, и никто вам не скажет, что в его компании этот подход не используют. Но так ли это? И с чем нередко путают JTBD?
Если очень коротко — JTBD-подход расставляет акценты не на ЦА, и даже не на том, как эта самая ЦА будет что-то делать. JTBD сосредоточен на проблемах. И результатом такого подхода должен быть продукт, который закрывает потребность/решает проблему оптимальным образом. То есть, продукт-работник (если чуть утрировать, то согласно JTBD можно и книгу нанять 😏).
Нередко JTBD — работу продукта, на которую мы его наняли — путают с его функционалом. Это не одно и то же. JTBD книги не в том, что мы можем её читать. JTBD книги — прожить ещё одну жизнь её персонажей, прокачать свои скиллы, скрасить поездку в метро и т.п.
В общем, жизнь продакта с оглядкой на JTBD — это правильное решение. Именно поэтому мы не рассказываем нашим клиентам, какие мы тут все крутые и серьезные. Мы просто показываем, о каких блокерах в работе своей компании можно забыть благодаря нам.
#JTBD_AGIMA
Про jobs-to-be-done можно услышать из каждого тапка, и никто вам не скажет, что в его компании этот подход не используют. Но так ли это? И с чем нередко путают JTBD?
Если очень коротко — JTBD-подход расставляет акценты не на ЦА, и даже не на том, как эта самая ЦА будет что-то делать. JTBD сосредоточен на проблемах. И результатом такого подхода должен быть продукт, который закрывает потребность/решает проблему оптимальным образом. То есть, продукт-работник (если чуть утрировать, то согласно JTBD можно и книгу нанять 😏).
Нередко JTBD — работу продукта, на которую мы его наняли — путают с его функционалом. Это не одно и то же. JTBD книги не в том, что мы можем её читать. JTBD книги — прожить ещё одну жизнь её персонажей, прокачать свои скиллы, скрасить поездку в метро и т.п.
В общем, жизнь продакта с оглядкой на JTBD — это правильное решение. Именно поэтому мы не рассказываем нашим клиентам, какие мы тут все крутые и серьезные. Мы просто показываем, о каких блокерах в работе своей компании можно забыть благодаря нам.
#JTBD_AGIMA
🕵🏻♂️ Метод персон при создании сайта
Сегодня мы с кейсом. И с вопросом "на подумать": противоречит ли метод персонажей JTBD-подходу? Мы вот тоже подумали и противоречий не нашли ☺️
Сначала про кейс, а потом про нашу точку зрения.
К нам за редизайном сайта обратился один НПФ, и когда встал вопрос о построении CJM, мы поняли, что ничего не знаем о действующих и потенциальных клиентах фонда. Точнее, знаем, но явно недостаточно — наши ключевые персонажи получались многоликими, как тот самый бог из Браавоса. Поэтому мы прибегли к количественному исследованию — опросили чуть больше 400 респондентов и получили две типично-усредненных персоны и даже одну вспомогательную. Исходя из мотивации "Инвестора Лилии" и "Вкладчика Игната" разработали сценарии, а потом — вжух — CJM.
И вот, когда мы работали с нашими персонами, вдруг раздался неприятный голосок сомнения: "Ребят, так вы определитесь — JTBD или метод персонажей?" И мы тут же от этого голоса избавились. Потому что метод не просто не противоречит JTBD-подходу, но и дополняет (а на самом деле и предвещает) его.
Алан Купер — создатель метода персон — уже закладывал "работу, которая должна быть сделана" в описание ключевого персонажа. Просто тогда (в 1995 году) понятия "JTBD" вообще не существовало. А фактически JTBD — это фундамент метода персон, именно вокруг нее формируются ситуации, проблемы и поведенческие паттерны пользователя.
Так что всё законно, JTBD и метод персон друг друга не исключают 😉
#JTBD_AGIMA
#cx_ux_recearch_AGIMA
Сегодня мы с кейсом. И с вопросом "на подумать": противоречит ли метод персонажей JTBD-подходу? Мы вот тоже подумали и противоречий не нашли ☺️
Сначала про кейс, а потом про нашу точку зрения.
К нам за редизайном сайта обратился один НПФ, и когда встал вопрос о построении CJM, мы поняли, что ничего не знаем о действующих и потенциальных клиентах фонда. Точнее, знаем, но явно недостаточно — наши ключевые персонажи получались многоликими, как тот самый бог из Браавоса. Поэтому мы прибегли к количественному исследованию — опросили чуть больше 400 респондентов и получили две типично-усредненных персоны и даже одну вспомогательную. Исходя из мотивации "Инвестора Лилии" и "Вкладчика Игната" разработали сценарии, а потом — вжух — CJM.
И вот, когда мы работали с нашими персонами, вдруг раздался неприятный голосок сомнения: "Ребят, так вы определитесь — JTBD или метод персонажей?" И мы тут же от этого голоса избавились. Потому что метод не просто не противоречит JTBD-подходу, но и дополняет (а на самом деле и предвещает) его.
Алан Купер — создатель метода персон — уже закладывал "работу, которая должна быть сделана" в описание ключевого персонажа. Просто тогда (в 1995 году) понятия "JTBD" вообще не существовало. А фактически JTBD — это фундамент метода персон, именно вокруг нее формируются ситуации, проблемы и поведенческие паттерны пользователя.
Так что всё законно, JTBD и метод персон друг друга не исключают 😉
#JTBD_AGIMA
#cx_ux_recearch_AGIMA
⚠️ ППО: что это и почему оно нужно
Прежде, чем мы беремся за новый продукт или развитие уже имеющегося, мы настаиваем на проведении ППО. ППО — это предпроектное обследование, которое помогает:
◾️ выявить целевую аудиторию продукта и «работы», на которые она готова наш продукт «нанять»
◾️ избавиться от неопределенности и получить формализацию процессов «as is»
◾️ определить функции, необходимые для MVP
◾️ сопоставить эти функции с реальными бизнес-процессами
◾️ разработать стратегию развития продукта
◾️ планировать ресурсы
◾️ подсветить потенциальные риски для всех участников.
ППО актуально не только для агентств — для запуска продукта самой компанией оно тоже необходимо. Знаем, что многие коллеги активно используют этот инструмент, и если вдруг вы не из их числа — настоятельно рекомендуем присмотреться. А чтобы это «присматривание» было более предметным, предлагаем познакомиться с нашим видением ☺️
Что включает в себя ППО в AGIMA:
1️⃣ Проведение серии интервью со стейкхолдерами, участниками связанных процессов, текущими/потенциальными пользователями
2️⃣ Анализ имеющихся регламентов, систем и любой документации, затрагивающей связанные процессы
3️⃣ Подготовка отчетного концепт-документа:
- цели и задачи
- схемы бизнес-процессов с их описанием
- реестр функциональных требований
- роли пользователей продукта
- ограничения
- среда функционирования
- предметная область
- требования к UI и UX
- взаимодействие между компонентами продукта и другими продуктами (опционально).
- etc. (список не закрыт, т.к. может видоизменяться в зависимости от целей и задач заказчика).
Думаем, важность ППО после того, что вы прочитали выше, очевидна. Так что пользуйтесь. Если будут вопросы — ждем в комментах, без знаний не оставим. Data-driven всем! ♥️
#roadmap_AGIMA
#managing_team_AGIMA
#JTBD_AGIMA
#frameworks_AGIMA
Прежде, чем мы беремся за новый продукт или развитие уже имеющегося, мы настаиваем на проведении ППО. ППО — это предпроектное обследование, которое помогает:
◾️ выявить целевую аудиторию продукта и «работы», на которые она готова наш продукт «нанять»
◾️ избавиться от неопределенности и получить формализацию процессов «as is»
◾️ определить функции, необходимые для MVP
◾️ сопоставить эти функции с реальными бизнес-процессами
◾️ разработать стратегию развития продукта
◾️ планировать ресурсы
◾️ подсветить потенциальные риски для всех участников.
ППО актуально не только для агентств — для запуска продукта самой компанией оно тоже необходимо. Знаем, что многие коллеги активно используют этот инструмент, и если вдруг вы не из их числа — настоятельно рекомендуем присмотреться. А чтобы это «присматривание» было более предметным, предлагаем познакомиться с нашим видением ☺️
Что включает в себя ППО в AGIMA:
1️⃣ Проведение серии интервью со стейкхолдерами, участниками связанных процессов, текущими/потенциальными пользователями
2️⃣ Анализ имеющихся регламентов, систем и любой документации, затрагивающей связанные процессы
3️⃣ Подготовка отчетного концепт-документа:
- цели и задачи
- схемы бизнес-процессов с их описанием
- реестр функциональных требований
- роли пользователей продукта
- ограничения
- среда функционирования
- предметная область
- требования к UI и UX
- взаимодействие между компонентами продукта и другими продуктами (опционально).
- etc. (список не закрыт, т.к. может видоизменяться в зависимости от целей и задач заказчика).
Думаем, важность ППО после того, что вы прочитали выше, очевидна. Так что пользуйтесь. Если будут вопросы — ждем в комментах, без знаний не оставим. Data-driven всем! ♥️
#roadmap_AGIMA
#managing_team_AGIMA
#JTBD_AGIMA
#frameworks_AGIMA