#tools Эффект Златовласки (Goldilocks principle) – прицип в социлогии/математике/медицине, который также используется в продакт-менеджменте с целью побуждения юзера к покупке.
Принцип Златовласки назван по аналогии с детской сказкой "Три медведя", в которой Златовласка пробует три разные тарелки каши и выбирает тарелку с кашей средней температуры.
Одним из наиболее ярких примеров использования эффекта является подписка Netflix.
Несмотря на то, что #Netflix предлагает три варианта подписки, он пытается сделать свой стандартный план как можно более привлекательным.
Так, его базовый план сильно уступает стандартному по качеству видео. А преимущества премиального плана не сильно отличаются и не так важны для среднего юзера, чем стандартный план, в то время, как он умышленно продается по более высокой цене.
Даже этого достаточно, чтобы запустить эффект Златовласки – большинство пользователей сочтут премиум дорогим/излишним, а базовый вариант слабым, что повышает конверсию стандартного плана.
Принцип Златовласки назван по аналогии с детской сказкой "Три медведя", в которой Златовласка пробует три разные тарелки каши и выбирает тарелку с кашей средней температуры.
Одним из наиболее ярких примеров использования эффекта является подписка Netflix.
Несмотря на то, что #Netflix предлагает три варианта подписки, он пытается сделать свой стандартный план как можно более привлекательным.
Так, его базовый план сильно уступает стандартному по качеству видео. А преимущества премиального плана не сильно отличаются и не так важны для среднего юзера, чем стандартный план, в то время, как он умышленно продается по более высокой цене.
Даже этого достаточно, чтобы запустить эффект Златовласки – большинство пользователей сочтут премиум дорогим/излишним, а базовый вариант слабым, что повышает конверсию стандартного плана.
#hr #tools Наткнулся на гугловскую стратегию найма сотрудников под названием "Озеро Вобегон" из далёкого 2006 года.
...Мы полагаемся на стратегию Lake Wobegon, которая гласит:
нанимайте только тех кандидатов, которые выше среднего уровня ваших нынешних сотрудников.
Озеро Вобегон призвано заменить стратегию "нанимайте выше любого из ваших нынешних сотрудников", которая была популярна во времена бума доткомов и, которая, обычно, приводила к простому найму выше минимального.
Мы даже провели симуляцию 1000 кандидатов и обнаружили, что найм сотрудников выше минимального приводит к резкому падению уровня общей квалификации.
Еще одна стратегия найма, которую мы используем — отсутствие hr-менеджеров в проектах.
Мы нанимаем всех сотрудников на уровне компании, а не на уровне проектов.
Мы обнаружили, что когда вы возлагаете на менеджеров проектов ответственность за найм сотрудников для их собственных проектов, они берут лучшего кандидата из корпоративного резерва. Просто потому, что каждый менеджер хочет получить реальную помощь для своего проекта.
...Мы полагаемся на стратегию Lake Wobegon, которая гласит:
нанимайте только тех кандидатов, которые выше среднего уровня ваших нынешних сотрудников.
Озеро Вобегон призвано заменить стратегию "нанимайте выше любого из ваших нынешних сотрудников", которая была популярна во времена бума доткомов и, которая, обычно, приводила к простому найму выше минимального.
Мы даже провели симуляцию 1000 кандидатов и обнаружили, что найм сотрудников выше минимального приводит к резкому падению уровня общей квалификации.
Еще одна стратегия найма, которую мы используем — отсутствие hr-менеджеров в проектах.
Мы нанимаем всех сотрудников на уровне компании, а не на уровне проектов.
Мы обнаружили, что когда вы возлагаете на менеджеров проектов ответственность за найм сотрудников для их собственных проектов, они берут лучшего кандидата из корпоративного резерва. Просто потому, что каждый менеджер хочет получить реальную помощь для своего проекта.
#tools Разбираемся в том, как писать спецификации, которые помогут команде генерировать по-настоящему востребованные гипотезы и продуманные фичи.
Telegraph
Как писать спецификации на фичи
Думаю, что существенная часть успеха любого продукта состоит в том, как продакт-менеджер доносит своё видение до команды. И раз внутреннее продуктовое видение транслируется через сторис, гипотзеы, родмэп и бэклог, то можно предположить, что их успех зависит…
#tools #exp Ещё один способ приоритизации идей/гипотез/фич без сложных методологий, графиков и прочих умных моделей.
Сколько бы мы не говорили про бесценность фидбека от юзеров, в большинстве случаев, родмэпы формируются на основе данных от продуктовой или бизнес-команд.
Раз так, то вот простая и работающая схема как вовлечь команду в этот процесс и повысить качество выдаваемых ею гипотез/идей/фич:
1. Раз в квартал проводите тематический мозговой штурм с командой маркетинга, продаж и поддержки (и только после своей команды идите за идеями и хотелками к СЕО/инвесторам (помня, что они в другой команде).
Мой совет – лучше вообще к ним не идите, а если сами позовут, то придёте с готовой инфой "от вашей профессиональной команды".
2. Попросите каждого члена этих команд, вне зависимости от их количества и статуса, добавить и отранжировать их идеи/фичи по личной субъективной значимости (да, именно так).
3. Выберите от каждого отдела 3/5/10 самых популярных идеи-фичи и далее уже самостоятельно оцените их по трём критериями:
1) ожидаемое воздействие (метрика);
2) необходимые ресурсы (время);
3) потенциальные профиты и риски (деньги).
4. Следуйте правилу "70/20/10", где:
– 70% ресурсов должны направляться на истории с низким уровнем риска и быстрой отдачей в метрику (развиваем настоящее);
– 20% ресурсов должны идти на рискованные долгосрочные ставки и отдачу (строим задел на будущее);
– 10% ресурсов должно идти на всякие забавы, пасхалки и другие приятные/необычные/wow-вещи, от которых команда и юзеры будут испытывать эмоции (эмоции всегда работают в плюс сквозь время).
5. Если до сих пор не определились с приоритетами, то сделайте третий подход и самостоятельно приоритизируйте оставшиеся идеи на основе:
1) результатов командного голосования (какая история является любимой в команде и почему);
2) стратегической важности (есть ли гипотезы/идеи/фичи, которые продукт должен иметь именно сейчас и почему);
3) простейшей логики и интуиции (что сейчас ощущается важным и почему).
Снова тупняк и сомнения? Снова прогоняйте выбранные идеи по критериям из пункта №3.
Как часто собирать команду? Ежеквартально – оптимальный баланс между актуальностью и частотой. Но если вы или команда в какой-то момент почувствуете, что НЕЧТО в продукте нуждается в своём пересмотрении, просто соберитесь и обсудите именно это.
P.S. И да, если инвестор всё же навязывает вам нечто, кхм... забавное, включите его хотелку в те 10% 😏
Полезное по теме:
– Как НЕ надо работать с бэклогом;
– Инструкция по интуиции для продакт-менеджера
– Как организована приоритизация фичей в SkyEng, Ali, Wrikle
– Приоритизация на основе баллов и скоринга
Сколько бы мы не говорили про бесценность фидбека от юзеров, в большинстве случаев, родмэпы формируются на основе данных от продуктовой или бизнес-команд.
Раз так, то вот простая и работающая схема как вовлечь команду в этот процесс и повысить качество выдаваемых ею гипотез/идей/фич:
1. Раз в квартал проводите тематический мозговой штурм с командой маркетинга, продаж и поддержки (и только после своей команды идите за идеями и хотелками к СЕО/инвесторам (помня, что они в другой команде).
Мой совет – лучше вообще к ним не идите, а если сами позовут, то придёте с готовой инфой "от вашей профессиональной команды".
2. Попросите каждого члена этих команд, вне зависимости от их количества и статуса, добавить и отранжировать их идеи/фичи по личной субъективной значимости (да, именно так).
3. Выберите от каждого отдела 3/5/10 самых популярных идеи-фичи и далее уже самостоятельно оцените их по трём критериями:
1) ожидаемое воздействие (метрика);
2) необходимые ресурсы (время);
3) потенциальные профиты и риски (деньги).
4. Следуйте правилу "70/20/10", где:
– 70% ресурсов должны направляться на истории с низким уровнем риска и быстрой отдачей в метрику (развиваем настоящее);
– 20% ресурсов должны идти на рискованные долгосрочные ставки и отдачу (строим задел на будущее);
– 10% ресурсов должно идти на всякие забавы, пасхалки и другие приятные/необычные/wow-вещи, от которых команда и юзеры будут испытывать эмоции (эмоции всегда работают в плюс сквозь время).
5. Если до сих пор не определились с приоритетами, то сделайте третий подход и самостоятельно приоритизируйте оставшиеся идеи на основе:
1) результатов командного голосования (какая история является любимой в команде и почему);
2) стратегической важности (есть ли гипотезы/идеи/фичи, которые продукт должен иметь именно сейчас и почему);
3) простейшей логики и интуиции (что сейчас ощущается важным и почему).
Снова тупняк и сомнения? Снова прогоняйте выбранные идеи по критериям из пункта №3.
Как часто собирать команду? Ежеквартально – оптимальный баланс между актуальностью и частотой. Но если вы или команда в какой-то момент почувствуете, что НЕЧТО в продукте нуждается в своём пересмотрении, просто соберитесь и обсудите именно это.
P.S. И да, если инвестор всё же навязывает вам нечто, кхм... забавное, включите его хотелку в те 10% 😏
Полезное по теме:
– Как НЕ надо работать с бэклогом;
– Инструкция по интуиции для продакт-менеджера
– Как организована приоритизация фичей в SkyEng, Ali, Wrikle
– Приоритизация на основе баллов и скоринга
#tools Отмечайте успех и прогресс пользователя(ей)
Постепенно, интерес пользователей к вашему продукту начнёт ослабевать (а с ним и вовлечение/возврат).
На помощь приходит простой психологический хак, когда продукт начинает уделять личности пользователя отдельное и персональное внимание.
Самый яркий и удачный пример – системы наград и ачивок в играх (в mmorpg это еще и эффект социального одобрения-превосходства), механики и концепции которых можно частично перенять и интегрировать в SaaS-продуктах
Особенно этим славится Гугл и его продукты типа Search Console или того же Youtube, которые любят присылать разные сводки/аналитику/кнопки, специально отмечающие успешные достижения и мотивирующие юзеров к их наращиванию.
Постепенно, интерес пользователей к вашему продукту начнёт ослабевать (а с ним и вовлечение/возврат).
На помощь приходит простой психологический хак, когда продукт начинает уделять личности пользователя отдельное и персональное внимание.
Самый яркий и удачный пример – системы наград и ачивок в играх (в mmorpg это еще и эффект социального одобрения-превосходства), механики и концепции которых можно частично перенять и интегрировать в SaaS-продуктах
Особенно этим славится Гугл и его продукты типа Search Console или того же Youtube, которые любят присылать разные сводки/аналитику/кнопки, специально отмечающие успешные достижения и мотивирующие юзеров к их наращиванию.
#tools Сбор обратной связи "здорового человека" командой Gamestop.
Меня, как продакта, особенно радует:
– выбран чертовски верный канал для сбора (твиттер, где тусуется вся крипто аудитория и идёт весь nft-движ);
– канал в режиме live, команда может тут же уточнять вопросы, при необходимости;
– хотя зачем ей это делать, когда за них это могут сделать сами же пользователи, которые имеют возможность обсудить и оценить через лайки предложенные другими юзерами фичи;
– а значит это сильная прокачка лояльности и формирование лояльного комьюнити вокруг продукта;
– Твиттер – соцсеть (ваш АЯ), а значит сбор фидбека превращается ещё и в шоу (маркетинг).
P.S. Толковое руководство и команда творят с it-компаниями чудеса! God bless Ryan Cohen 🫶
Меня, как продакта, особенно радует:
– выбран чертовски верный канал для сбора (твиттер, где тусуется вся крипто аудитория и идёт весь nft-движ);
– канал в режиме live, команда может тут же уточнять вопросы, при необходимости;
– хотя зачем ей это делать, когда за них это могут сделать сами же пользователи, которые имеют возможность обсудить и оценить через лайки предложенные другими юзерами фичи;
– а значит это сильная прокачка лояльности и формирование лояльного комьюнити вокруг продукта;
– Твиттер – соцсеть (ваш АЯ), а значит сбор фидбека превращается ещё и в шоу (маркетинг).
P.S. Толковое руководство и команда творят с it-компаниями чудеса! God bless Ryan Cohen 🫶
#tools 4 совета по работе с метриками и целями:
1. Разделите метрики/цели на достижимые и амбициозные.
После чего делите их в зависимости от приоритетов и текущих возможностей по этим группам в нужных пропорциях, например, по-классике "80/20".
Распространенная ошибка заключается в том, что команды не разделяют свои цели и не выдерживают пропорцию, ставя 100 только на один тип метрик/целей, что ведёт к недостижению другого типа целей со всеми вытекающими в будущем перекосами.
2. Ещё одна распространенная ошибка – перенос старых целей на новый период после их недостижения.
В большинстве случаев, причина падения метрики – объект метрики/цели уменьшил свою значимость для пользователя. Либо кривой UI/UX. Либо плохой трафик. Либо рынок сдувается. Либо бага на сайте. Что угодно.
Цель – разобраться и найти истинную причину спада, а не слепо долечивать и гнаться за поставленной ранее метрикой уже в новом квартале.
3. Не упрощайте метрики/цели
«Уменьшить задержку загрузки страницы на x%» – написано красиво.
«Уменьшить задержку загрузки страницы на x%, чтобы повысить % конверсии в Y» — лучшее описание цели, которая будет понятна и вам, команде и даже пользователям.
4. Не забывайте про пост-анализ метрик/целей
Какие метрики и цели продукт/команда достигли без сильного напряжения, а над какими пришлось попотеть? Ответы на эти вопросы дадут вам понимание того, насколько верно вы приоритизировали цели в п.1 и с каким темпом вы к ним идёте.
– Как держать в голове кучу метрик и следить за ними
– Приоритизация по модели "Матрица влияния/усилий"
– Приоритизации без сложных методологий
1. Разделите метрики/цели на достижимые и амбициозные.
После чего делите их в зависимости от приоритетов и текущих возможностей по этим группам в нужных пропорциях, например, по-классике "80/20".
Распространенная ошибка заключается в том, что команды не разделяют свои цели и не выдерживают пропорцию, ставя 100 только на один тип метрик/целей, что ведёт к недостижению другого типа целей со всеми вытекающими в будущем перекосами.
2. Ещё одна распространенная ошибка – перенос старых целей на новый период после их недостижения.
В большинстве случаев, причина падения метрики – объект метрики/цели уменьшил свою значимость для пользователя. Либо кривой UI/UX. Либо плохой трафик. Либо рынок сдувается. Либо бага на сайте. Что угодно.
Цель – разобраться и найти истинную причину спада, а не слепо долечивать и гнаться за поставленной ранее метрикой уже в новом квартале.
3. Не упрощайте метрики/цели
«Уменьшить задержку загрузки страницы на x%» – написано красиво.
«Уменьшить задержку загрузки страницы на x%, чтобы повысить % конверсии в Y» — лучшее описание цели, которая будет понятна и вам, команде и даже пользователям.
4. Не забывайте про пост-анализ метрик/целей
Какие метрики и цели продукт/команда достигли без сильного напряжения, а над какими пришлось попотеть? Ответы на эти вопросы дадут вам понимание того, насколько верно вы приоритизировали цели в п.1 и с каким темпом вы к ним идёте.
– Как держать в голове кучу метрик и следить за ними
– Приоритизация по модели "Матрица влияния/усилий"
– Приоритизации без сложных методологий
#tools #exp Lenny Rachitsky вчера поделился новым фреймворком для развития продукта под названием The Racecar Growth Framework.
Пост закрыт за paywall, но и без него понятно, как оно всё может работать.
P.S. Оч клёвая визуализация, есть чему поучиться.
Пост закрыт за paywall, но и без него понятно, как оно всё может работать.
P.S. Оч клёвая визуализация, есть чему поучиться.
#tools Делаем фичу или новый суб-продукт?
Придумали с командой грандиозную идею-фичу и не понимаете, должна ли она быть фичей внутри продукта или нужно набраться смелости/рук/денег и её можно и нужно делать отдельным суб-продуктом?
Ответы на вопросы ниже помогут вам понять основные качества будущей фичи-идеи-решения и выбрать правильное направление:
– Фича предлагает новое решение новой проблемы (суб-продукт) или улучшенное решение старой проблемы (внутр. фича)?
– Объём рынка новой фичи по отношению к объёму рынка основного решения продукта станет больше (суб-продукт) или он меньше и не изменится (внутр. фича)?
– Фича влияет на удержание/прилипание пользователей (внутренняя фича) или способствует росту новых пользователей (суб-продукт)?
– Фича способна влиять на одно пользовательское действие/метрику (внутренняя фича) или может сразу на несколько (суб-продукт)?
– Новая фича может стать точкой входа и далее самостоятельным маховиком со своим CJM для всего решения (суб-продукт) или она не сможет существовать автономно без основного продукта (внутр. фича)?
– Готовы ли юзеры платить за фичу отдельно (её способность продаваться автономно от основного продукта/проблемы) или только в комплекте с основным продуктом (внутренняя фича)?
– Сможет ли фича в одиночку выдержать отток/снижение продаж (суб-продукт) или не сможет, т.к. юзерам нужна фича-механика-якорь, за которую они смогут удержаться как в основном продукте (внутр. фича)?
– Фичу и даже её mvp сложно/долго/дорого интегрировать в нынешний продукт и легче протестить это отдельно (суб-продукт) или же её легко встроить в него (внутр. фича)?
– Нужны ли новые люди/деньги/процессы на поддержание и развитие фичи (суб-продукт) или она способна работать в текущих (внутр. фича)?
Конечно же, эти вопросы не являются универсальным и единственным способом для принятия подобных решений, но они точно помогут прояснить картину возможного развития очередной грандиозной идеи на краткосрочном и среднесрочных периодах.
Придумали с командой грандиозную идею-фичу и не понимаете, должна ли она быть фичей внутри продукта или нужно набраться смелости/рук/денег и её можно и нужно делать отдельным суб-продуктом?
Ответы на вопросы ниже помогут вам понять основные качества будущей фичи-идеи-решения и выбрать правильное направление:
– Фича предлагает новое решение новой проблемы (суб-продукт) или улучшенное решение старой проблемы (внутр. фича)?
– Объём рынка новой фичи по отношению к объёму рынка основного решения продукта станет больше (суб-продукт) или он меньше и не изменится (внутр. фича)?
– Фича влияет на удержание/прилипание пользователей (внутренняя фича) или способствует росту новых пользователей (суб-продукт)?
– Фича способна влиять на одно пользовательское действие/метрику (внутренняя фича) или может сразу на несколько (суб-продукт)?
– Новая фича может стать точкой входа и далее самостоятельным маховиком со своим CJM для всего решения (суб-продукт) или она не сможет существовать автономно без основного продукта (внутр. фича)?
– Готовы ли юзеры платить за фичу отдельно (её способность продаваться автономно от основного продукта/проблемы) или только в комплекте с основным продуктом (внутренняя фича)?
– Сможет ли фича в одиночку выдержать отток/снижение продаж (суб-продукт) или не сможет, т.к. юзерам нужна фича-механика-якорь, за которую они смогут удержаться как в основном продукте (внутр. фича)?
– Фичу и даже её mvp сложно/долго/дорого интегрировать в нынешний продукт и легче протестить это отдельно (суб-продукт) или же её легко встроить в него (внутр. фича)?
– Нужны ли новые люди/деньги/процессы на поддержание и развитие фичи (суб-продукт) или она способна работать в текущих (внутр. фича)?
Конечно же, эти вопросы не являются универсальным и единственным способом для принятия подобных решений, но они точно помогут прояснить картину возможного развития очередной грандиозной идеи на краткосрочном и среднесрочных периодах.
#tools #best #team Как команде генерировать рабочие гипотезы, а не рандомно фантазировать?
Поможет шаблон для сбора командных идей в Notion, состоящий из 3 простых вопросов, на которые смогут ответить даже сотрудники без специальных знаний.
Несколько моментов:
1. Поля заполняются в порядке нумерации.
2. Фокус на проблеме, ориентация на результат.
3. Коммуникации 1:1 рулят, в шаблоне есть обратная связь от продакта к автору идеи.
👉 Ссылка на шаблон в Notion.
Уточню, что данный шаблон предназначен лишь для быстрого сбора и фиксации командных идей. Все работы по обогащению гипотез/сторис лучше проводить в отдельных тасках.
P.S. Для копирования шаблона в свой проект, скопируйте ссылку на нужную страницу с ним, вставьте в свой проект как linked и потом просто сделайте Duplicate.
Для назначения шаблона зайдите в нужную вам доску, нажмите создать новую таску и в пустом поле её описания выберите or create a template, в который и нужно вставить эти поля с формой.
Полезное по теме:
– Самая полезная обратная связь — негативная
– Повышаем качество выдаваемых комндой гипотез/идей/фич
Поможет шаблон для сбора командных идей в Notion, состоящий из 3 простых вопросов, на которые смогут ответить даже сотрудники без специальных знаний.
Несколько моментов:
1. Поля заполняются в порядке нумерации.
2. Фокус на проблеме, ориентация на результат.
3. Коммуникации 1:1 рулят, в шаблоне есть обратная связь от продакта к автору идеи.
👉 Ссылка на шаблон в Notion.
Уточню, что данный шаблон предназначен лишь для быстрого сбора и фиксации командных идей. Все работы по обогащению гипотез/сторис лучше проводить в отдельных тасках.
P.S. Для копирования шаблона в свой проект, скопируйте ссылку на нужную страницу с ним, вставьте в свой проект как linked и потом просто сделайте Duplicate.
Для назначения шаблона зайдите в нужную вам доску, нажмите создать новую таску и в пустом поле её описания выберите or create a template, в который и нужно вставить эти поля с формой.
Полезное по теме:
– Самая полезная обратная связь — негативная
– Повышаем качество выдаваемых комндой гипотез/идей/фич
#tools #metrics Измерение NPS - пустая трата времени.
Уверен, вы не раз цепляли форму опроса и спрашивали своих активированных юзеров «Достаточно ли вы удовлетворены сейчас, чтобы бла-бла в будущем?».
Просить людей предсказывать будущее очень рискованно – в будущем мы всегда принимаем лучшие решения, никогда не ошибаемся и не заставляем никого чувствовать себя некомфортно.
Вместо этого задавайте вопрос:
«Что делают довольные клиенты в нашем продукте?»
и адресуйте его... своей команде.
Ответы, которые найдёте вы и ваша команда и будут следствием удовлетворенности юзеров.
И именно они будут теми показателями, которые вы должны замерять для оценки удовлетворенности вместо NPS.
Вот некоторые примеры:
– Количество товаров, купленных за одно посещение.
– Среднее кол-во товаров, проданных одному покупателю в месяц.
– Количество посещений/время на пользователя в месяц.
– Количество погашенных реферальных кодов.
– Количество уже размещенных рекомендаций в соц. сетях.
Уверен, вы не раз цепляли форму опроса и спрашивали своих активированных юзеров «Достаточно ли вы удовлетворены сейчас, чтобы бла-бла в будущем?».
Просить людей предсказывать будущее очень рискованно – в будущем мы всегда принимаем лучшие решения, никогда не ошибаемся и не заставляем никого чувствовать себя некомфортно.
Вместо этого задавайте вопрос:
«Что делают довольные клиенты в нашем продукте?»
и адресуйте его... своей команде.
Ответы, которые найдёте вы и ваша команда и будут следствием удовлетворенности юзеров.
И именно они будут теми показателями, которые вы должны замерять для оценки удовлетворенности вместо NPS.
Вот некоторые примеры:
– Количество товаров, купленных за одно посещение.
– Среднее кол-во товаров, проданных одному покупателю в месяц.
– Количество посещений/время на пользователя в месяц.
– Количество погашенных реферальных кодов.
– Количество уже размещенных рекомендаций в соц. сетях.
#tools "Дерево продукта" - творческий и наглядный инструмент, который помогает увидеть основы и концепцию продукта, его слабые и сильные стороны, а также потенциальные направления его развития через визуализацию образа обычного дерева.
P.S. Шаблон "Дерево продукта" в Miro (раньше там был пример с Метеоагентом, но кто-то поленился сделать копию, всё стёр и заполнил очередным финтехстартапом). Оригинал картинки для печати.
P.S. Шаблон "Дерево продукта" в Miro (раньше там был пример с Метеоагентом, но кто-то поленился сделать копию, всё стёр и заполнил очередным финтехстартапом). Оригинал картинки для печати.
Telegraph
Методология "Дерево продукта (Product Tree)"
"Дерево продукта" - это творческий и наглядный инструмент, который помогает найти и организовать направления развития продукта и его концепции, а также увидеть его слабые и сильные стороны через визуализацию образа и процесса роста обычного дерева. Шаг №1.…
#tools DDDD – подход от Британского совета по дизайну, который помогает систематизировать процесс работы над чем угодно (исследования, дизайн, разработка, маркетинг и т.д.)
Так, любой процесс состоит из двух областей работы над ним – Область проблемы (с расходящимся потоком информационной дивергенции и конвергенции) и Область решения.
Каждая из областей является составной частью другой и включает в себя этапы работ:
1. Discover (изучение). Включает в себя поиск и сбор информации по поставленной проблеме, рынку, данным и т.п.
Задавай вопросы, проводи исследования и собирай всю необходимую информацию для определения потенциальных возможностей и решений.
2. Define (определение). Аналитика и обработка полученной информации, её интерпретация на предмет дальнейшего возможного внедрения, стратегия продукта, его цели и основные функции.
На этом этапе также создается каркас продукта, включая пользовательские сценарии, требования и макеты.
3. Develop (разработка). Переход в область непосредственных работ по интеграции, внедрению, запуску (и тестированию) решения.
На этом этапе происходит процесс создания дизайна, разработки, тестирования и итеративного улучшения продукта.
4. Deliver (доставка). Дальнейшие действия, когда решение "передаётся" в руки того, для кого оно предназначается – пользователей или заказчиков.
Этот этап включает подготовку продукта к запуску, управление релизом, маркетинговые и PR-активности, а также обратную связь пользователей и мониторинг его использования.
Соблюдение этого порядка действий позволяет "не терять то, с чего начали" и держать фокус на логике процессов.
😎 RUSPM
Так, любой процесс состоит из двух областей работы над ним – Область проблемы (с расходящимся потоком информационной дивергенции и конвергенции) и Область решения.
Каждая из областей является составной частью другой и включает в себя этапы работ:
1. Discover (изучение). Включает в себя поиск и сбор информации по поставленной проблеме, рынку, данным и т.п.
Задавай вопросы, проводи исследования и собирай всю необходимую информацию для определения потенциальных возможностей и решений.
2. Define (определение). Аналитика и обработка полученной информации, её интерпретация на предмет дальнейшего возможного внедрения, стратегия продукта, его цели и основные функции.
На этом этапе также создается каркас продукта, включая пользовательские сценарии, требования и макеты.
3. Develop (разработка). Переход в область непосредственных работ по интеграции, внедрению, запуску (и тестированию) решения.
На этом этапе происходит процесс создания дизайна, разработки, тестирования и итеративного улучшения продукта.
4. Deliver (доставка). Дальнейшие действия, когда решение "передаётся" в руки того, для кого оно предназначается – пользователей или заказчиков.
Этот этап включает подготовку продукта к запуску, управление релизом, маркетинговые и PR-активности, а также обратную связь пользователей и мониторинг его использования.
Соблюдение этого порядка действий позволяет "не терять то, с чего начали" и держать фокус на логике процессов.
Please open Telegram to view this post
VIEW IN TELEGRAM