Хочу поговорить не про формирование задач, а именно про их получение 
Большинство проектных менеджеров работает с входящими требованиями: от бизнеса, заказчиков, стейкхолдеров, смежных команд и т.д.
И если принимать задачи без пояснений, они быстро превращаются в набор бессмысленных хотелок 
Сейчас речь не про сложное целеполагание, критерии завершенности и прочий роскошный максимум
Давайте сойдемся хотя бы на двух базовых вещах: гипотезах
Прежде чем брать задачу в работу, стоит спросить:
Что эта задача принесет?
Так
— мы проверяем причинно-следственную связь: какое изменение хотим сделать и какой результат ожидаем получить
— команда понимает свою причастность к результату
— проще оценивать риски, приоритет и целесообразность работы
И так мы хотя бы базово проверяем автора на вменяемость и адекватность
Гипотеза в продуктовой разработке — это формализированное предположение о том, какое изменение в продукте даст измеримый эффект на поведение пользователей или метрики бизнеса.
Самый популярный формат:
Если мы сделаем X, то пользователи сделают Y, потому что есть причина Z.
Плохо
«Нужно добавить чат-бот».
Это просто идея. Или хотелка.Лучше
«Если мы внедрим чат-бот на странице оплаты, то конверсия в покупку вырастет на 5%, потому что пользователи смогут быстро решать вопросы по доставке, не уходя с сайта».
Здесь уже есть действие, ожидаемый эффект, метрика и причина.
Как проверять гипотезы
Для проверки часто используют HADI-цикл 
Hypothesis (гипотеза) — формулируем предположение.
Action (действие) — делаем минимальное действие для проверки.
Data (данные) — собираем метрики.
Insights (выводы) — решаем, подтвердилась гипотеза или нет.
Если подтвердилась — масштабируем
Если нет — фиксируем выводы и не тратим команду на бесполезную разработку
Какие бывают гипотезы?
Гипотеза проблемы 
Проверяем, существует ли проблема вообще.
Пример: «Пользователям неудобно каждый раз вводить данные банковской карты».
Гипотеза решения 
Проверяем, решит ли конкретное решение эту проблему.
Пример: «Кнопка Apple Pay снизит трение при оплате».
Гипотеза ценности или роста 
Проверяем, даст ли решение пользу бизнесу.
Пример: «Если мы добавим Apple Pay, то повторные покупки вырастут, а LTV (Lifetime Value, пожизненная ценность клиента) увеличится».
Ну и не могу не напомнить про MVP
Прежде чем делать полноценный функционал, автору можно предложить более дешевую проверку его гипотезы
MVP (Minimum Viable Product, минимально жизнеспособный продукт) — это ранняя версия продукта или решения с минимальным набором функций, достаточным для получения обратной связи.
Есть самые разные способы проверки через MVP, например:
Fake Door (фальшивая дверь) 
Добавляем кнопку новой функции, но вместо самой функции показываем сообщение: «Функция в разработке. Оставьте почту».
Если нажимают много — интерес есть
Если нет — возможно, полноценная разработка не нужна
Консьерж-MVP 
Делаем вручную то, что потом хотим автоматизировать.
Например, стилист вручную подбирает одежду клиенту, прежде чем команда начнет разрабатывать сложный алгоритм.
Прототип 
Показываем кликабельный макет и смотрим, понимают ли пользователи, что происходит и зачем им это нужно.
В общем мысль простая — не нужно все тащить в работу, вы такой же участник процесса и ответственны за конечный результат
Нужно иногда корректировать и направлять инициаторов задач в сторону смысла, ценности и сформулированных ожиданий 
