Взгляд на управление: Точки зрения на продукт ru en

Представим, вы разрабатываете SaaS — тамагочи todo-лист для геймеров, или даже что-нибудь менее полезное.

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

Но что именно вы предлагаете? Только ли возможность кормить тамагочи todo-листами?

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

Давайте начнём с этих свойств и по логической цепочке пройдём через всё более сложные холистические системные точки зрения на продукт и управление им.

Неочевидные свойства продукта

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

• Доступность — возможность пользоваться продуктом в любое время с любого устройства.
• Поддержка — возможность получить помощь в случае возникновения проблем.
• Ритм выпуска обновлений — динамика появления новых фич, без которых пользователи пока что могут обойтись, но на которые надеются в будущем.
• Надёжность — хранение данных пользователей целыми и невредимыми и схожие штуки.
• Безопасность — отсутствие утечек персональной информации, отсутствие вреда для устройств пользователя.

Ваши пользователи могут даже рассчитывать на конкретные эмоции от продукта. Это касается не только игр, в которых эмоции — один из ключевых компонентов (сравните, для примера, эмоции от Dark Souls, Doom и The Sims)), но и бизнес-приложений, которые могут фокусироваться на ощущениях контроля, надёжности, осведомлённости, etc.

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

Например доступность крайне важна для большинства продуктов. О ней не всегда говорят, потому что она «максимально подразумевается» и вопрос её обеспечения всплывает в менеджерских кругах обычно, когда кто-то уже эпически накосячил, например, запустил маркетинговую активность на +1M DAU без консультации с разработчиками.

Роль каждого конкретного свойства продукта в его успешности обычно не однозначна:

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

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

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

Наш продукт длится во времени

Давайте продолжим использовать Тамагочи todo-лист из начала поста в качестве примера.

Практически все свойства нашего SaaS имеют смысл только во временном измерении.

Функциональность SaaS обеспечивается запущенным на серверах кодом, который работает в реальном времени. Если сервера остановятся, то продукт моментально «пропадёт» для пользователя.

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

Частью продукта являются формальные протяжённые во времени обязательства разработчиков перед пользователями и регуляторами: от сроков на удаление персональных данных согласно GDPR и минимального времени хранения информации о платежах (от 3-5 лет, по-моему, в зависимости от страны), до обязательств по, собственно, хранению информации пользователя существенной для задач нашего SaaS.

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

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

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

Команда как неотъемлемая часть продукта

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

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

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

Допустим вы поменяете сработанных людей на новых случайных. Из-за отсутствия знаний о работающей системе у вас моментально просядут все сопутствующие показатели. Выпуск обновлений замедлится, поддержка станет медленнее, скорее всего даже просядут доступность, надёжность и безопасность.

Пользователи заметят изменения (возможно при первом же обновлении сервиса) и изменят своё поведение — увеличится процент отказов от подписки, снизится LTV, воронка регистраций станет хуже — всё в том же духе.

Поэтому можно утверждать, что:

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

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

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

Продукт как хаотическая система

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

Поскольку все компоненты продукта связаны в тесную причинно-следственную сеть, то мы имеем в своём рассположении не предсказуемый «линейный» механизм, а хаотическую систему, изменение одной части которой может привести к непредсказуемым последствиям в других частях.

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

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

Продукт как эволюционирующая адаптирующаяся система

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

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

Нет смысла управлять конкретным органом ради управления этим органом.

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

Есть очевидные исключения:

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

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

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

Часть продукта — часть корабля

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

Роль современного лидера — направлять, а не управлять. Разница может быть неочевидной, но она значима. Управление предполагает директивность, детализацию и контроль; направление — «мягкую силу» — информирование, обучение, поддержку, поощрение, создание условий для самоорганизации.

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

Не стоит разделять управление продуктом и управление командой (инфраструктурой, процессами, артефактами — выберите своё, далее буду упоминать только команду). Меняя одно мы меняем другое. Разные роли могут иметь разный фокус, но при здоровой организации труда зоны ответственности будут пересекаться. В таких пересечениях следует способствовать возникновению коммуникации и коллаборации, а не вычищать их по правилу «останется только один ответственный».

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

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

И ещё раз отдельно отмечу, что все эти утверждения справедливы и для инфраструктуры, и для артефактов, и для процессов. С этим часто большие проблемы у инженеров — нам часто интересно покрутить что-нибудь просто потому, что мы можем (интересно что получится), а не потому что это изменит что-то существенное в продукте. Надо следить за собой и, по мере сил, пресекать такие порывы. Но иногда можно и не пресекать :-D