#notes
Самый лучший способ обучения — коллективная практическая работа над проблемой, взаимное обучение, быстрая коммуникация. Под практической работой имеется в виду реальный проект, не симуляция, а что-то «боевое», имеющее реальный эффект.

Все, что выше 1 и 2 уровней от основания — это вспомогательные инструменты для обучения.

via: @productmaking

#notes #think

За 14+ лет работы в IT я понял одну вещь: Улучшить можно все что угодно и сколько угодно раз.

Поэтому, когда кто-то работает над чем-то с 0 и делает первые Х% базы, следующий придет и улучшит это не потому что первые Х% — хрень, а просто потому, что улучшать можно бесконечно!

Почему? Потому что критерий улучшенного» в разные времена разный, в разных, улучшающих его головах, разный.

Вывод на правах ИМХО: все работает плохо и может быть улучшено всегда. Вопрос только в том, когда это будет слишком сильно заметно кому-либо, чтобы начало напрягать и мотивировало к переменам (не факт, что будет объективно лучше, но будет лучше адаптировано к конкретному времени и его ценностям)

via: @productmaking

#think #notes

Есть ряд общих/универсальных/базовых core-skills и методологий в аналитике/управлении проектами и продуктами в сфере IT.

Но предметная область зачастую накладывает свой большой отпечаток.

К примеру, вот некоторые методики/принципы в работе над проектом из мед.сферы:

• TOGAF (The Open Group Architecture Framework — методика архитектуры открытой группы);

• SAIF (Services-Aware Interoperability Framework — методика интероперабельности ориентированной на сервисы);

• ITABOK (IT Architecture Body of Knowledge — Набор знаний ИТ Архитектур) от международной ассоциации архитекторов ПО (IASA);

Для разработки ПО будет использован:
• SWEBOK — методика знаний для разработки ПО, например стандарт 19759, а для обеспечения качества в процессе разработки ПО будут использованы стандарты серии 25000;

Оно же может применяться к любым сложным, и требующим высокого уровня контроля качества и коммуникации, проектам.

via: @productmaking

#notes

Небольшая шпаргалка по моделям
электронного бизнеса и их особенностям (есть субъективные моменты)

via: @productmaking

#notes

Как рассуждать маркетологу? (Да и любому человеку, который хочет продавать)

via: @productmaking

#notes #think

👉 Джони работает механиком на СТО вот уже 15 лет, поэтому ему предложили стать руководителем маркетплейса запчастей.

🤙 Джони знает об автомобилях все и отлично разбирается в запчастях, знает где искать и как (а также все проблемы с этим связанные).

🤜 Долгосрочные планы и «хитрые» стратки только у него в голове, а краткосрочные планы ему не интересны — это рутина. Синки/риски/roadmap-ы/vision statement/product discovery/custdev/metrics/unit-экономика/goto market strategy? Зачем??? Джонни об этом ничего не знает, ему это не нужно, он механик с 15 летним стажем и сам все знает. Делайте что говорит Джонни, а если он не говорит, то у него есть причины, а команда профи — додумает и сделает сама.

👌 Но Джонни не плохой, ему просто нужен настоящий менеджер, который превратит хаос в систему, провалидирует гипотезы, сократит риски, наладит процессы и стабильно доведет проект из точки А в точку Б.

—

Очевидный вывод: Хороший предметник/эксперт в своей области НЕ РАВНО хороший менеджер продукта или проекта.
Потому что далеко не каждый предметник/эксперт в своей области обладает нужными компетенциями менеджера.

via: @productmaking

#npd #notes

Пример процесса коммерциализации инноваций (2011 года — почти свежак).

Отчасти подходит и для mass-market/incremental идей тоже.


Gate (на схеме) — принятие решения (штабом/советом директоров) на основе собранных данных на предыдущем этапе.

А начинается все с правильно оформленного видения.

А как сделать так, чтобы идея заработала?

—
Доведение идеи до коммерциализации требует проектного подхода. Также изучаю механику «портфельного» управления (скоро начну рассказывать)

via: @productmaking

#notes
Не помню где вычитал мысль (недословно воспроизвожу): «ваш продукт начнет устаревать сразу после выхода на рынок все быстрее и быстрее. Теперь ваша задача — бороться с оным (с устареванием) все эффективнее и эффективнее»

#notes

Все крупные компании тестируют гипотезы. Мобильное приложение Facebook постоянно требует обновления, Amazon меняет код на сайте в среднем каждые 11 сек, а вице-президент по продукту Twitter признался, что значительный рост начался, когда стали тестировать десять гипотез в неделю, а не одну в две недели.

Кол-во проведённых экспериментов в неделю = скорость роста компании.

#notes #communications

According to 360 Solutions, a business with 100 employees spends an average downtime of 17 hours a week clarifying communication, which translates to a cost of $528,443 dollars per year.

Компании, в которых работает 100 сотрудников, тратят, в среднем, 17 часов в неделю на выяснение и уточнение необходимой информации, в денежном эквиваленте это ~$528,443 в год

ps: если инструменты и методы коммуникации развиты недостаточно хорошо. И это не считая случаев, когда из-за плохой коммуникации (целеполагание — это тоже коммуникации) сотрудники прокрастинируют, стагнируют, выгорают и уходят.

Источник (2015, но я думаю с того времени важность коммуникации только возросла)

#notes #uxwriting
«Найдите своего героя и делайте для него. Станет понятно, что внедрять, как писать, где продвигать». Это еще Алан Купер сказал, когда рассказывал про Personas.

А ты знаешь своего героя, собирательный образ того единственного, жизнь которого ты хочешь улучшить?

#notes #productdiscovery

“Too often, we jump to the first solution that comes to mind. Our brains are remarkably good at closing the loop—when we hear about a problem, we jump to solve it. But if we want to find good solutions, we need to take the time to make sure that our solutions are tailored to our customers’ specific needs.” 
—Teresa Torres, product discovery coach

#notes #think

#notes #hr #brandandidentity

Что подразумевают под корпоративной культурой vs Чем она является на самом деле — скрыто под водой (и это еще не все 🤿 )

#notes
Притча о том, как транслировать ценностное предложение и обещания рынку и клиентам.

Да и про любые коммуникации в принципе.

#think #notes

Заметил, что в зрелых компаниях, слишком уж сильно опираются на то, как что-либо реализовано у конкурентов. Вы, наверное, бывали в ситуации, когда стэйкхолдеры говорили: «сделай как у ..…, думать будешь/будем потом»


Почему это опасно?

• высок риск того, что вы повторите продукт конкурента, не улучшив его. Вы скопируете его текущую версию, в то время, как он вот-вот выкатит улучшенную новую. Очков вам это точно не прибавит

• просто повторить, значит, отключить эмпатию. Не чувствуя копируемую фичу раз за разом, вы рискуете перестать чувствовать свою аудиторию совсем, в то время, как ваши конкуренты используют метод проб и ошибок и все глубже погружаются в головы своих клиентов

• слепо копируя, вы подтверждаете, что вы не новаторы, у вас не так много амбиций, вы идете по протоптанной дорожке (утрирую, но если всегда выбирать путь наименьшего сопротивления, это станет привычкой для всей вашей компании)

• сделать по-своему, но ошибиться — намного более эффективный способ нащупать a-ha момент

• копируя, вы никогда не станете драйвером рынка, а будете догоняющим, вскоре, это станет болючим клеймом.

—
Смотрите на решения конкурентов, но делайте лучше.
—
Не нужно бояться ошибиться. Ошибки — это отличный источник опыта. Чтобы снизить страх ошибки, пробуйте мыслить, добавляя в начало «а что если?». Каждый такой эксперимент приблизит вас к 🎯

Развитие продукта, стратегия, цели — это, прежде всего, прыжок веры.

Да прибудет с вами сила! 🖖

ps: посвящается всем, чья должность начинается на “product”

#notes
Притча о том, как транслировать ценностное предложение и обещания рынку и клиентам.

Да и про любые коммуникации в принципе.

#psy #notes #management
https://teletype.in/@productmaking/MuW3O7rtk

via: @productmaking

#notes #think

👉 Джони работает механиком на СТО вот уже 15 лет, поэтому ему предложили стать руководителем маркетплейса запчастей.

🤙 Джони знает об автомобилях все и отлично разбирается в запчастях, знает где искать и как (а также все проблемы с этим связанные).

🤜 Долгосрочные планы и «хитрые» стратки только у него в голове, а краткосрочные планы ему не интересны — это рутина. Синки/риски/roadmap-ы/vision statement/product discovery/custdev/metrics/unit-экономика/goto market strategy? Зачем??? Джонни об этом ничего не знает, ему это не нужно, он механик с 15 летним стажем и сам все знает. Делайте что говорит Джонни, а если он не говорит, то у него есть причины, а команда профи — додумает и сделает сама.

👌 Но Джонни не плохой, ему просто нужен настоящий менеджер, который превратит хаос в систему, провалидирует гипотезы, сократит риски, наладит процессы и стабильно доведет проект из точки А в точку Б.

—

Очевидный вывод: Хороший предметник/эксперт в своей области НЕ РАВНО хороший менеджер продукта или проекта.
Потому что далеко не каждый предметник/эксперт в своей области обладает нужными компетенциями менеджера.

via: @productmaking

#notes
Про критику в CX/UX/UI — необходимый процесс, чтобы улучшать опыт пользователя и повышать качество продукта.

"Приложение ужасное! Я пытался сделать заказ и все сломалось. Ничего не работает, и я потратил полчаса на то, чтобы попытаться разобраться в этом барахле. Поправьте и сделайте хорошо!" (С) User

"Дизайн ужасный. Эти цвета не работают вместе, шрифт невыразительный и элементы управления расположены в самых странных местах. Вам нужно начать все сначала и сделать это правильно." (C) Дизайнер

Критика должна быть конструктивной и ориентированной на решение проблем, а не на создание новых:
• Подойдите к критике объективно: не делайте ее личной, а сконцентрируйтесь на том, что нужно улучшить.
• Будьте специфичны: укажите на конкретные элементы, которые нужно изменить, и дайте четкие и конкретные рекомендации по улучшению.
• Обоснуйте свои комментарии: убедитесь, что вы можете объяснить, почему считаете, что определенные изменения помогут улучшить опыт пользователя.
• Будьте конструктивны: предлагайте решения вместо того, чтобы только указывать на проблемы. Как правило, если вы видите проблему, то идеи по ее решению уже есть у вас в голове.
• Старайтесь не критиковать напрямую работу коллеги: лучше сосредоточьтесь на улучшении опыта пользователя. Если же вы все-таки видите, что работа коллеги не соответствует качеству, попробуйте обсудить этот вопрос в частном порядке.
• Уважайте мнение других: сотрудничайте с коллегами, чтобы разработать лучшее решение. Общение и совместная работа могут привести к наиболее эффективным решениям
• Критикуешь — предложи решение