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

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

  • Убедитесь, что запрос имеет смысл: это кажется очевидным. Запрос должен иметь смысл для всех, кто собирается с ним контактировать. Если он написан плохо, расплывчато, не представляет проблемы или просто не имеет смысла, обратитесь к лицу, отправившему запрос. Поработайте с ними, чтобы переписать запрос. Это показывает тому, кто запрашивает, не только то, что вы заботитесь об их отзывах, но и искренне хотите выполнить то, что они просят.
  • Убедитесь, что запрос не является дубликатом: вы не хотите, чтобы дублирующиеся запросы загромождали список невыполненных работ по продукту. Однако повторяющиеся запросы - отличное свидетельство того, что запрос имеет ценность для сообщества в целом. Множество пользователей, сталкивающихся с одной и той же проблемой, приходящих к одному и тому же выводу, и достаточно увлеченных этой проблемой, чтобы отправить запрос, - хороший показатель того, что у группы разработки продукта есть возможность предоставить ценность. Великие владельцы продуктов будут отслеживать эти дубликаты другими способами, например, голосами по существующему запросу.
  • Убедитесь, что дана приблизительная оценка стоимости: убедитесь, что запрашивающая сторона сообщает «почему». (Почему это так важно? Какую ценность вы получите от этой функции? Каких затрат вы избежите? Сколько часов вашего времени это сэкономит?) Понимание «почему» приближает вас к пониманию того, как на самом деле сообщество использует ваш продукт и возможности, которые у вас есть, чтобы по-настоящему принести им пользу.
  • Предоставьте приблизительную оценку трудозатрат: это предоставлено командой разработчиков продукта. Ответственность не всегда лежит на Владельце продукта, но на данном этапе это важный элемент запроса. Усилия играют большую роль в процессе расстановки приоритетов для выполнения ценных запросов. Если вы сможете получить даже приблизительную оценку на раннем этапе, это очень поможет вам в долгосрочной перспективе. Обычно я оцениваю каждый запрос в количестве спринтов, которое, по моему мнению, потребовалось бы одному разработчику для завершения проекта. Обычно это достаточный уровень детализации, чтобы продлиться до тех пор, пока приоритет запроса не станет достаточно высоким, чтобы Разработчик дал истинную оценку.
  • Сохранение метаданных: фиксируйте атрибуты запроса, которые позволят вам увидеть шаблоны. (На какую часть продукта влияет этот запрос? Кто является аудиторией? В какую часть процесса пользователя он попадает?) Ключевые точки данных будут варьироваться от продукта к продукту, но ценность возникающих шаблонов - нет. Например, обнаружение того, что семьдесят пять процентов всех запросов влияют на процесс адаптации вашего продукта, дает вам четкое представление о том, что у вас есть возможность улучшить эту область и привлечь больше пользователей.
  • Проанализируйте запрос на альтернативные решения: это важный ранний шаг в борьбе со слишком частым появлением запросов, которые отправляют проблему, которую можно легко решить без разработки, или которую продукт уже решает, а запросчик просто не знает решения. На этом этапе может оказаться невозможным углубиться в запрос, чтобы полностью изучить все альтернативные решения, поэтому просто проведите предварительный мысленный эксперимент, чтобы увидеть, есть ли какие-либо альтернативные решения, которые вы могли бы предложить для проблемы, отправившей запрос.

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