Почему обнуленный то? Это ведь он является автором гипотезы, как правило. А метрики уже покажут угадал он или нет:) Это какое-то ложное противопоставление маркетологов и метрик:)

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

Что-то вас унесло в холивар "экспертное мнение против метрик", а вопрос о другом был.
Нередко приходится делать что-то, чего непосредственный пользователь НЕ хочет, на самом деле, но что повышает доходность бизнеса.
Например, вставить на страницу банер, или спрятать подальше кнопку отписки.
И в этом случае тупо писать "Я как пользватель системы хочу убрать подальше кнопку отписки, чтобы мне было сложнее её найти и отписаться от вашего дебильного сервиса".

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

Все все могут и все можно. Это любители категории категоризировать категоризируют. Стори (любой текст) должен быть понятен команде. Не противоречив и исключать двойную трактовку. Ну и так же проверяться для передачи в тест. Не только на "нажимакмость" но и на соответствие задуманому.

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

Про холивар замечание принято. Но. Маркетолог тоже пользователь системы. Разве нет? Значит может написать юзерстори от своего лица/своей роли.

Отличная абстрактная сентенция. Лучше быть богатым и здоровым, чем бедным и больным. Не поспоришь!
Это, правда, не является ни для кого секретом. А вот ответа на исходный вопрос  тут не содержится.
Или отсюда надо понимать, что фальшивая история "я хочу, чтобы мне было неудобно" — это норм?

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

У маркетолога есть цели. Система призвана выполнить их. Почему же тогда маркетолог не пользователь? Только потому, что не пользуется интерфейсом, предназначенным для другой роли?

Маркетолог в роли непосредственного пользователя - да, не рассматривается.

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

история тогда звучит так: "Я как маркетолог хочу убрать подальше кнопку отписки, чтобы клиентам было сложнее её найти и отписаться от нашего прекрасного сервиса"

А что в этом не так? Маркетолог - одна из ключевых ролей.

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

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

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

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

Какие интересы у маркетолога в идеале? Знать рынок, знать целевой сегмент, прогнозировать продажи? Нет? Это разве не то что и хотели??? Может его знания таки и помогут увеличить рост продаж??? Здесь похоже люди ненавидят маркетологов))))

Это смотря где в слове "маркетинг" ударение ставить))

В общем случае есть системные уровни:
1. Бизнес
2. Бизнес-процесс
3. Пользователь
4. Продукт/система/подсистема/компонент
5. Работы по созданию/развитию 4

Классические требования работают с уровнем 4 — система должна, система должна позволять

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

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

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

Стали думать, как не терять контекст.

Сначала придумали Use Case, которые связали уровень 3 (Пользователь) и 4 (Продукт/система) — есть задача пользователя в процессе и есть конкретные шаги пользователя, которые обеспечены функциями системы.

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

User Story связали уровни 3 (Пользователь) и 2 (Бизнес-процесс), подняли уровень требований и постановок ближе к бизнесу.

Поэтому когда мы применяем US, даже не с позиции User, а с более общей Stakeholder/Role, то важно не проваливаться по уровням.

«Как маркетолог (уровень 3), я хочу, чтобы пользователи (уровень 3) чаще замечали возможность оплаты, чтобы повысить конверсию в оплату (уровень 2)». В этом смысл истории. А уже критерии приёмки можно обсудить и доработать с командой в ходе Product Backlog Refinement.

Какие именно компоненты, библиотеки, классы, таблицы надо будет поправить — это уже часть решения, US не для них.

Почему первый вариант не прижился? Вроде вполне себе живет, а US еще и сверху просят накручивать на первый вариант. А не отдельно. Вроде я вижу такую ситуацию. Да ПО(инструментарий) выпускается в таком виде, его мало, но делают.

Подход (первый) то пришел из промышленной Инженерии, не ИТ, и эти разделения на 4ре уровня потом же натянули на то что удалось перенять в ИТ из промышленной Инженерии.