Ментальные модели продакт менеджмента для всех

 · 
Product management

Это перевод статьи Product Management Mental Models for Everyone. Статья не претендует на идеальный перевод или на истину в последней инстанции. Если найдете трудности перевода или неточности, то сообщите мне в комментариях или на почту (найдете в разделе "Обо мне").
Также приветствуются бурные обсуждения в комментариях.

Ментальные модели - это простые выражения сложных процессов или отношений. Эти модели накапливаются индивидуально и используются для принятия более быстрых и качественных решений.

Вот пример: принцип Парето гласит, что примерно 80% всех результатов приходится на 20% усилий.

В контексте управления продуктами модель предполагает, что вместо того, чтобы потратить 100% усилий и покрыть 100% желаний клиентов, можно потратить 20% усилий и покрыть 80% желаний клиентов. Команды разработчиков постоянно прибегают к этому принципу, и результаты часто выглядят удовлетворительным, когда 20% клиентов с более сложными кейсами не поддерживаются.

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

Эта концепция была популяризирована Чарли Мангером, знаменитым вице-председателем Berkshire Hathaway, в речи, где он размышлял о том, как обрести мудрость:

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

У вас должны быть модели в голове. И вы должны объединить свой опыт — как альтернативный, так и прямой — в сеть моделей. Возможно, вы заметили студентов, которые просто пытаются запомнить и вспомнить то, что запомнилось. Они терпят неудачу в школе и в жизни. Вы должны объединить опыт в сеть моделей в вашей голове.

Какие модели? Ну, первое правило: у вас должно быть несколько моделей — потому что если у вас есть только одна или две модели, которые вы используете, то вы будете мучить реальность так, чтобы она соответствовала вашим моделям. Вы становитесь эквивалентом хиропрактика, который, конечно, является большим болваном в ​​медицине.

Это похоже на старую поговорку: «Для человека, у которого только молоток, каждая проблема выглядит как гвоздь». И, конечно, именно так хиропрактик занимается медицинской практикой. Но это совершенно катастрофический способ мышления и совершенно катастрофический способ действовать в мире. Таким образом, у вас должно быть несколько моделей.

В этом посте описаны некоторые из наиболее полезных ментальных моделей, которые я накопил за свою карьеру в области управления продуктами. По мере изучения новых моделей я буду постоянно обновлять пост.

Это также не просто для менеджеров по продуктам, это для всех, кто работает над продуктами. Продуктовое мышление не является священным для роли PM, на самом деле, оно даже более полезно в руках строителей, чем PM.

Ментальные модели, которые мы рассмотрим, структурированы по следующим категориям:

  1. Выяснить, куда инвестировать
  2. Проектирование и обзор
  3. Доставка и итерация

Выяснение, куда инвестировать — следующий набор ментальных моделей полезен для принятия решения о том, что ваша команда должна построить, или «инвестировать», далее.

1. Возврат инвестиций

Финансовая концепция: сколько вы получаете за каждый вложенный доллар? В продукте думайте о ресурсах, которые у вас есть (время, деньги, люди), как о том, что вы «инвестируете», а о прибыли - как о влиянии на клиентов.

Как это полезно

Ресурсы, доступные команде разработчиков, - это время, деньги и количество и умения людей. Когда вы сравниваете возможные проекты, которые вы можете взять на себя, вы всегда должны выбирать тот, который максимизирует влияние на клиентов для каждой имеющейся у вас единицы ресурсов.

2. Время стоимость доставки

Товар, поставляемый ранее, стоит больше для клиентов, чем товар, поставляемый позже.

Как это полезно

Принимая решение о проблемах / возможностях инвестирования, вы не можете просто сравнить преимущества различных функций, которые вы можете создать (если бы вы это сделали, вы всегда выбрали бы самую большую функцию).

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

3. Горизонт времени

Правильное решение об инвестициях зависит от периода времени который вы оптимизируете, и от времени и стоимости доставки функции.

Учитывая достаточно длинный временной интервал, стоимость разработки 3 месяца против 9 месяцев незначительна.

Как это полезно

Если вы спросите «Как мы можем оказать наибольшее влияние в течение следующих 3 месяцев?» или «Как мы можем оказать наибольшее влияние в течение следующих 3 лет?», Это приведет к радикально различным решениям для вашей команды.

Из этого следует, что согласование с вашей командой и заинтересованными сторонами того, какой временной горизонт оптимизировать, часто является первым обсуждением.

4. Ожидаемая стоимость

Предсказывать будущее очень сложно. Все решения создают вероятности множественных результатов. Взвешенная сумма этих результатов является ожидаемой ценностью решения.

Как это полезно

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

После того, как вы изложите все результаты, сделайте взвешенную сумму значений результатов, и вы получите более точную картину прибыли, которую вы получите от инвестиций.

Проектирование и определение объема — следующий набор ментальных моделей полезен для определения объема и разработки продукта после того, как вы выбрали, куда инвестировать.

5. Работа в обратном направлении (инверсия)

Вместо того, чтобы начинать с проблемы, а затем исследовать ее, начните с идеального решения и вернитесь к сегодняшнему дню, чтобы понять, с чего начать.

Обратите внимание, что работа в обратном направлении не всегда лучше, она просто создает другую перспективу.

Как это полезно

Большинство команд стремятся работать вперёд, стараясь оптимизировать то, что в конечном итоге приносит результат.

Работа в обратном направлении помогает вам сосредоточиться на наиболее результативной и долгосрочной работе для клиента, потому что вы всегда отталкиваетесь от идеального решения для них.

Обратите внимание, что работа в обратном направлении не всегда лучше, она просто создает другую перспективу. Здорово планировать, используя обе перспективы.

6. Уверенность определяет скорость и качество

Уверенность в том, что вы: 1) решаете важную проблему, и 2) правильно определяете, насколько вы готовы идти на компромисс со скоростью и качеством при создании продукта.

Как это полезно

Эта интеллектуальная модель помогает вам построить барометр, чтобы разумно сочетать скорость и качество. Проще всего объяснить это, взглянув на крайние концы спектра выше.

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

Слева: вы даже не подтвердили, что проблема важна для клиентов. В этом сценарии, чем дольше вы инвестируете в разработку, тем больше рискуете создать решение для проблемы, которой даже не существует. Поэтому вы должны ошибиться, запустив что-то быстрое и получив подтверждение от клиента, что это действительно стоит сделать. Например, вы можете сделать целевую страницу для функции, которой даже не существует, чтобы оценить интерес клиентов.

7. Решите весь клиентский опыт

Опыт клиентов не заканчивается на интерфейсе. То, что происходит до и после использования продукта, не менее важно для разработки.

Как это полезно

При разработке продукта мы склонны переориентироваться на опыт работы с продуктом (например, пользовательский интерфейс в программном обеспечении).

Не менее важно разработать маркетинговый опыт (как вы привлекаете клиентов и устанавливаете их ожидания от продукта до того, как они его использует), так и опыт поддержки / дистресса (как ваша компания справляется с ошибкой продукта).

В частности, создание впечатлений от бедствия - это удивительные возможности завоевать долгосрочное доверие клиентов. Например, Amazon, как клиент получает наибольшее доверие, когда вам нужно что-то вернуть.

8. Эксперимент, функция, платформа

Существует три типа разработки продукта: эксперименты, функции и платформы. У каждого есть своя цель и оптимальный способ компромисса со скоростью и качеством.

Как это полезно

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

Эксперименты предназначены для тестирования гипотез, так что вы можете инвестировать в новые функции или платформы, если клиенту понравился эксперимент. Если вы тестируете гипотезу, вы можете допускать вещи, которые иначе были бы неприемлемыми: например, использовать "говнокод", который надо будет выбросить, или подделывать логику приложения.

В отличие от экспериментов, платформы вечны. Другие люди будут создавать функции поверх них, и поэтому внесение изменений в платформу после ее запуска крайне нежелательно.

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

9. Обратная связь

Причина и следствие в продуктах являются результатом цикла положительной и отрицательной обратной связи.

Как это полезно

Циклы обратной связи помогают нам помнить, что некоторые из главных факторов роста или падения продукта могут быть из других частей системы.

Например, предположим, что вы являетесь специалистом по платежам, и ваш KPI должен увеличиваться от общего количества обработанных платежей по кредитным картам. У вас есть положительная обратная связь с командой по привлечению пользователей, потому что по мере роста пользователей у вас появляется больше потенциальных пользователей, которые будут платить кредитными картами. Тем не менее, у вас есть отрицательная обратная связь с группой по оплате наличными, которая пытается помочь пользователям легче совершать сделки с наличными.

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

10. Маховик (рекурсивная петля обратной связи)

Состояние, когда петля положительной или отрицательной обратной связи питается сама собой и ускоряется от собственного импульса.

Как это полезно

Маховики — это понятие, связанное с петлями обратной связи, но они важны для управления платформами и рынками. Например, представьте, что вы используете платформу приложений Apple для iOS. У вас есть два пользователя: разработчики приложений и пользователи приложений.

Маховик — это феномен, когда все больше пользователей приложений привлекают больше разработчиков приложений (потому что появляется больше возможностей для продажи), что, в свою очередь, привлекает больше пользователей приложений (потому что покупается больше приложений), что, в свою очередь, привлекает больше разработчиков приложений, и так далее. Пока вы взращиваете маховик, вы не только будете расти, но и будете расти с ускоряющейся скоростью.

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

Построение и повторение — следующий набор интеллектуальных моделей полезен, когда вы создаете, эксплуатируете и повторяете существующий продукт.

11. Снижение прибыли

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

Как это полезно

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

12. Локальные максимумы

В связи с уменьшением доходности локальные максимумы — это точка, в которой постепенные улучшения вообще не создают никакой ценности для клиента, заставляя вас сделать шаг в изменении возможностей продукта.

Как это полезно

Эта ментальная модель тесно связана с уменьшением отдачи. Итерация теперь не имеет смысла, и единственный путь к прогрессу — это инновации.

Эта концепция была недавно популяризирована вирусной публикацией Юджина Вея «Невидимые асимптоты», которая охватывает пример, подобный Амазону, который привел их к созданию Prime.

13. Вторая версия — ложь

При создании продукта не рассчитывайте на вторую версию. Убедитесь, что первая версия представляет собой законченный продукт, потому что он может существовать вечно.

Когда программное обеспечение продавалось на полках, командам приходилось жить с версией 1 навсегда.

Как это полезно

Когда вы определяете первую версию своего продукта, вы накапливаете всевозможные функции, которые вы мечтаете добавить позже в будущих версиях. Признайте, что они могут никогда не выйти в продакшн, потому что вы не знаете что может произойти: изменения стратегии компании, ваш ведущий инженер уходит, или вся команда перераспределяется на другие проекты.

Чтобы застраховаться от этих сценариев, убедитесь, что то, что вы делаете, является «полным продуктом», который без улучшений будет полезен для клиентов в обозримом будущем. Не поставляйте функцию, которая зависит от будущих релизов, чтобы реально решить проблему.

14. Freeroll

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

Как это полезно

Фрироллы обычно появляются в продукте, когда текущий пользовательский опыт настолько плох, что внесение любых разумных изменений, основанных на интуиции, может сделать его намного лучше.

Если вы находитесь в ситуации, когда ваша команда думает: «Давай просто сделаем что-то ... мы не можем сделать это еще хуже», у тебя, скорее всего, будет фриролл.

(r/CrappyDesign на Reddit - кладезь таких ситуаций)

15. Большая часть стоимости создается после первой версии

После того, как вы запустите продукт, вы узнаете больше о клиенте, не упустите возможность использовать эти знания.

Как это полезно

Все является гипотезой, пока клиенты не используют продукт. В то время как ваша команда вкладывает в «тестирование перед запуском» — интервью с клиентами, тестирование прототипов, количественный анализ, бета-тестирование и т. д. — может дать вам большую оценку вероятности быть правым. Всегда есть ситуации когда что-то идет не так, когда вы отправляете эту функцию 100% клиентов.

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

16. Ключевой индикатор отказа (Key Failure Indicator — KFI)

Сопоставление ключевых показателей эффективности (Key Performance Indicators — KPI) с показателями, которые вы не хотите уменьшать, идет в определенном направлении, чтобы вы были сосредоточены на здоровом росте.

Как это полезно

Команды часто выбирают KPI, который напрямую отражает положительные результаты, которые они ищут, без учета отрицательных путей достижения этих результатов. Как только они начинают оптимизировать KPI, они фактически создают результат, который является плохим для компании.

Классический пример — команда, которая думает, что она добилась успеха, удваивая конверсию при регистрации на целевой странице, но общее количество клиентов не растет, потому что коэффициент конверсии снизился на 60% из-за этого изменения.

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

Примеры популярных пар KPI <> KFI:

  1. Рост доходов при сохранении валовой прибыли
  2. Расширять использование функции A, не отказываясь от принятия функции B
  3. Расширить использование функции A без увеличения нагрузки на поддержку

Сеть, а не контрольный список

Это может быть неудовлетворительно для многих читателей, но, насколько я могу судить, нет методологии использования этих ментальных моделей. Если вы попытаетесь использовать их в качестве контрольного списка — просматривая каждый и проверяя, применимы ли они — вы в конечном итоге будете заниматься умственной гимнастикой, которая запутает и разочарует вас и окружающих.

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

По мере накопления большего количества моделей, в идеале на основе опыта, тем лучше вы будете получать результат.