Генератор фич: что выяснило исследование и что из него брать

Главный ответ

Исследование искало ответ на два вопроса. Как построить воспроизводимый процесс, в котором кандидаты в фичи возникают из накопленного знания? Какие части этого процесса можно отдать языковой модели? Повод — Product Lab, конвейер продуктовой разработки автора. По замыслу идея в нём превращается в бриф, концепт и продуктовую стратегию, а стадия появления фич не спроектирована.

Результат исследования — пакет документов: 24 карточки внешних источников, собранная из них модель процесса, аудит пакета и разбор соответствия — документ о том, применима ли модель к Product Lab.

Три результата, на которых держится остальное

1. Слой возможностей. Между сигналом и фичей нужна промежуточная запись — возможность. Сигнал — сырое наблюдение: запрос клиента, число из аналитики. Возможность называет носителя проблемы, разрыв между ожиданием и реальностью, метрику и порог успеха. Ни одна из семи школ продуктовой разработки, которые сравнивает пакет, не разрешает прямой путь от запроса клиента к списку фич. Слой обязателен по согласию школ, а не по доказанной пользе: его влияние на результат продукта не измерил ни один источник.
2. Сильные идеи и однородный набор. Когда проблема зафиксирована, идеи языковой модели попадают в число лучших чаще человеческих. Но варианты одной языковой модели пересказывают друг друга, и настройки случайности генерации этого не исправляют. Исправляют разные условия на входе. Поэтому разнообразие измеряют на наборе решений и обеспечивают структурой входа, а не просьбой «будь креативнее».
3. Дисциплина проверки. Причинно подтверждена только она. В рандомизированном эксперименте на 116 стартапах одну группу учили формулировать опровержимые гипотезы, задавать метрики и пороги решения до сбора данных [3]. Обученные чаще меняли направление и охотнее отказывались от идеи. Закрывались они не реже контрольной группы. Выручка у них была выше при одномоментном сравнении групп. Эффект выразился в своевременном отказе от идей, а не в их выживаемости.

Что предложено и что берётся

Из находок авторы пакета собрали модель конвейера: четырнадцать шагов и девять гейтов. Дальше слово «модель» без уточнения означает её, а языковая модель называется полностью. Гейт — контрольная точка, где запись либо проходит дальше, либо получает отказ с названной причиной. Модель рассчитана на организацию с командой, историей релизов и телеметрией — данными о поведении пользователей в продукте.

Для Product Lab рекомендована одна вещь — слой возможностей в минимальной форме. Телеметрии и истории релизов в проекте нет, и шесть гейтов из девяти исполнять не на чем. Главные правила минимальной формы:

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

Остальная модель остаётся знанием в архиве.

Что исследование установило

Насколько верить числам

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

• Измерения сделаны не на продуктовых фичах. Генерация и отбор идей измерены на студентах, конкурсах идей и научных идеях. Процедуры компаний описаны как предписания, без данных об их пользе. Перенос на фичи продукта — допущение.
• Пакет собран за один день. Его целиком собрали агенты Claude. После этого набор источников не пополнялся: иначе любой неудобный вывод можно было бы исправить поиском ещё одной статьи.
• Правило двух источников соблюдалось формально. Каждое утверждение должно было опираться минимум на два источника. Аудит показал: в 14 из 42 проверенных пар второй источник по теме молчал. Поэтому число ссылок под утверждением не говорит о его силе.

Аудит провели шесть независимых проверяющих. Они нашли 7 блокирующих, 35 существенных и 14 мелких дефектов; подтверждённые исправлены. Из 52 числовых утверждений 44 воспроизводят карточку источника точно. Среди остальных три числа верны, но приписаны не той группе, а три пометки «подтверждено» стояли на проектных решениях.

Слой возможностей: от сигнала к возможности

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

Возможность отличает от замаскированного решения один тест: «есть ли более одного способа её закрыть?» Если способ единственный, перед нами фича, записанная задом наперёд [17]. Такую запись не удаляют: проблему в ней разрезают на части.

Самое слабое место конструкции — вход. Продуктовую документацию как источник доказательств не описывает ни один из 24 источников. При этом именно она составляет половину входа генератора.

Генерация: разнообразие даёт вход, а не настройки

Набор идей одной языковой модели однороднее человеческого. Это показали все 32 сравнения на пяти сторонних наборах данных: средняя попарная близость идей равна 0,22 у людей против 0,41–0,43 у языковой модели [2]. Чем ниже близость, тем разнообразнее набор. Повторные ответы одной языковой модели в 79 % случаев держат близость выше 0,8, то есть пересказывают друг друга [7].

Единственный измеренный рычаг — разные условия на входе. Ниже семь приёмов с показателем разнообразия набора идей: чем выше число, тем разнообразнее набор [2].

• набор идей людей, точка отсчёта — 0,773;
• случайные персоны на входе — 0,757;
• человек фиксирует проблему, языковая модель ищет другое решение — 0,739;
• случайные функциональные ограничения на входе — 0,735;
• температура, то есть настройка случайности генерации, весь диапазон — 0,618–0,679;
• просьба «сделай смелее» — 0,575;
• изолированные сессии по одной идее — 0,452.

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

Число идей само по себе не признак качества. В мета-анализе 43 сравнений эффекты вмешательств на количество и на качество идей почти не коррелируют [24]. Авторы оговаривают, что исследований мало, а другой источник считает число идей одной из переменных качества [1]. Спор не снят, поэтому модель измеряет лучшие идеи и разброс набора, а не объём.

Отбор: машина отсекает слабых, но не выбирает лучших

Автоматический отбор работает как фильтр снизу. На 21 конкурсе с 4 191 идеей ни один из четырёх автоматических способов отбора не воспроизвёл выбор экспертов [5]. Потолок точности вне обучающей выборки — AUC 0,69–0,73. AUC — вероятность, что отбор поставит случайную хорошую идею выше случайной плохой: 0,5 означает случайный отбор, 1 — безошибочный. Достижимый режим — отсеять 44 % кандидатов ценой потери 14 % тех, кто попал бы в короткий список.

Ещё два измерения ограничивают отбор:

• Шумный отбор обнуляет преимущество хорошего генератора. Процессы различались по качеству лучшей пятёрки идей почти на балл. После группового отбора различие исчезло [1].
• Кто порождает идеи, тот плохо их оценивает. Ранговая корреляция самооценки генерирующих групп с оценкой независимых судей ниже 0,2. Это измерено на студентах, а не на языковых моделях [1].

Оценка замысла не предсказывает исход

Высокая оценка идеи до реализации не обещает высокой оценки после неё. Сильная и слабая стороны языковой модели измерены в двух разных работах.

Сильная сторона. При зафиксированной проблеме идеи GPT-4 получили покупательское намерение 46–49 % против 40 % у идей студентов MBA. В лучшие 10 % они попадали в семь раз чаще [2]. Задача — потребительский товар до 50 долларов.

Слабая сторона. 43 исследовательские идеи довели до реализации и слепо отрецензировали [6]. До реализации идеи языковой модели оценивались выше человеческих. После неё они потеряли 1–2 балла из десяти, человеческие почти не потеряли, и преимущество исчезло. Причина — смена критериев: в оценке замысла строгость почти не весит, в оценке исполненного она преобладает.

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

Мета-анализ 28 исследований среднего превосходства языковой модели над человеком не находит и обнаруживает публикационное смещение [23].

Проверка и измерение

О проверке идей источники сообщают три вещи.

• Проверка проблемы и проверка решения — разные проверки. Провал первой закрывает возможность со всеми решениями под ней. Провал второй закрывает одно решение, а возможность остаётся.
• Проверяют допущения, а не идею целиком. Критерий успеха записывают до теста [17].
• Цель эксперимента — исход, годный для решения, а не победа. Годный исход — это валидная постановка и достаточная статистическая мощность, то есть способность эксперимента заметить эффект. Знак результата не важен. У Spotify доля таких экспериментов 64 %, а доля побед около 12 % [13].

Как устроена модель

Главная идея

Запись меняет тип на каждом шаге. Каждое превращение может закончиться отказом с названной причиной. Ни одно решение не принимается по самооценке того, кто породил кандидата. Модель формулирует это цепочкой различений: сигнал — не доказательство, доказательство — не возможность, возможность — не решение, решение — не кандидат, кандидат — не фича, выпуск — не результат.

Решение здесь — способ закрыть возможность. Кандидат — решение, оформленное как предложение со всеми обязательными полями.

Пример: эксперимент Atlassian

Единственный сквозной случай в источниках — эксперимент Atlassian [14]. Пользователи Trello переходят в Jira через экран, который объясняет ценность Jira, и 58 % уходят с этого экрана. Таблица проводит его через шаги модели. Случай доказывает, что практика существует, но не доказывает её эффективность.

Четырнадцать шагов и девять гейтов

Схема показывает главное свойство конвейера: между шагами стоят гейты, а урок из последнего шага возвращается в начало. Шаги обозначены T0–T13, гейты — G0–G8.

Шаги складываются в пять фаз:

• вход и доказательства: T0–T2, гейт G0;
• возможности: T3–T5, гейты G1 и G2;
• решения и кандидаты: T6–T8, гейты G3 и G4;
• проверка и выпуск: T9–T11, гейты G5, G6 и G7;
• исход и обучение: T12–T13, гейт G8.

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

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

«Формально» означает отказ только по формальным признакам. Прекращённую запись не удаляют: она хранится вместе с причиной отказа. Без набора отклонённых записей автоматический отбор нельзя настроить на собственных данных.

Исход «данных недостаточно». Он возможен на любом гейте: запись в порядке, но измерить её нечем. Такую запись откладывают: у неё названы недостающий вход, ответственный и дата пересмотра. Нехватка, общая для всей системы, — например, мало трафика — в отказ не превращается: иначе первые кандидаты были бы прекращены по причине, не связанной с их качеством.

Что решает машина, а что человек

Каждому шагу и гейту модель присваивает один из четырёх уровней автоматизации.

• A0. Машина не участвует.
• A1. Машина считает и показывает числа. Решает человек.
• A2. Машина сама отказывает по формальным признакам, например: дубликат, недопустимый источник, кандидат ниже порога отсечения. Сказать «эта идея плохая» она не вправе.
• A3. Машина выносит все решения. Уровень присвоен двум местам: гейту G3 и постепенному выпуску, где правила остановки записаны заранее.

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

Языковая модель в конвейере предлагает, а не решает. Ей запрещены четыре вещи:

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

Семнадцать линз: как получить решения разного устройства

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

• «убрать шаг»: не показывать экран и сразу пускать в Jira;
• «подсказать в момент действия»: объяснять пользу Jira по ходу первого действия в ней;
• «закрыть без разработки»: письмо или звонок от команды тем, кто ушёл с экрана;
• «переформулировать проблему»: точно ли проблема в экране, а не в том, зачем людей ведут из Trello в Jira.

Остальные тринадцать линз:

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

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

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

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

Кандидат, прослеживаемость и оценка генератора

Что обязан содержать кандидат. Кандидат не выходит из генератора, пока в нём нет обязательных частей. В их числе:

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

Прослеживаемость. Модель хранит цепочку ссылок: источник → доказательство → возможность → гипотеза → кандидат → эксперимент → исход. Если цепочка оборвана, система называет первое недостающее звено и гейт, который должен был его потребовать.

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

Что измерено, а что назначено

Модель опирается на измерения только в части узлов; остальное авторы назначили. Сами авторы помечают каждое утверждение как «подтверждено», «выведено» или «проектное решение». Последнее значит: источники молчат, и решение нужно проверять на собственных данных. Таблица раскладывает главные узлы модели по прочности основания; пометки в ней укрупнены.

О своих численных ориентирах модель говорит: «ни один не является отраслевой нормой».

Оговорка о причинной опоре. Модель называет порог, записанный до сбора данных, единственным правилом с причинным подтверждением. Карточка источника говорит осторожнее: различие между группами «свелось к 30 % времени на научный подход — фальсифицируемые гипотезы, валидные метрики, явные пороги решения». Вклад отдельного порога эксперимент не различает. Причинно подтверждена связка практик. Поэтому обоснованно требовать всю связку — гипотезу, метрику и критерий до теста, — а не одно поле из неё.

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

Минимальная версия для Product Lab

Почему полная модель не подходит

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

• Вход недостижим. Модель не допускает частичного запуска, а брифа и внешнего исследования в проекте нет. Стадия не запустилась бы никогда.
• Шесть гейтов из девяти исполнять не на чем. Им нужны внешние источники, бюджет, опросы, трафик и расчёты мощности.
• Из 73 полей кандидата заполнимо около двадцати. Заполнять остальные приблизительно хуже: число с двумя знаками через месяц читается как факт.
• Оценки эффекта стали бы самооценкой. Если агент, породивший кандидата, сам пишет ожидаемый эффект и порог, а телеметрии нет, это самооценка генератора. Модель её запрещает.
• Проверять некому. В банке идей восемь записей, до конца доведена одна. Три кандидата на возможность при десятке возможностей дадут тридцать открытых записей на одного человека.

Одно пересечение придётся решить явно. Концепт уже содержит четыре корзины фич. По модели это готовый список решений, который понижается до сигналов. Расширять его, очищать от повторов или оспаривать — в проекте не записано.

Что берётся и что при этом теряется

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

• Один файл пула. В нём записана возможность: носитель, разрыв, ссылка на раздел концепта или стратегии, серьёзность словами. Под ней три–шесть кандидатов, у каждого свой класс механизма. Теряется проверка доказательств: основанием служит намерение автора. Честное имя результата — «выведенный из принятых артефактов», то есть из уже утверждённых документов проекта.
• Восемь полей кандидата. Все поля формулируются словами, измеряемых среди них нет. Теряется численный порог до теста. Качественный признак неудачи слабее, но он не даёт задним числом объявить любой исход подтверждением.
• Один ручной гейт. У каждой значимой возможности не менее трёх кандидатов разных классов. Ни один не пересказывает другой. Один из классов — «без разработки». Теряется машинная проверка близости. Классы размечает сам агент, поэтому близкие варианты под разными метками никто не поймает.
• Обратная связь. Это два поля в файле фичи: чего ожидал и что вышло. Статус «выпущено» при пустом результате запрещён. Теряется измерение: запись о результате — суждение.
• Лимит работы. Это одно правило о числе непроверенных кандидатов в работе. Теряются хранилища, история пересмотров и оценка версий генератора.

Восемь полей кандидата:

1. ссылка на возможность;
2. кому;
3. класс механизма и линза;
4. формулировка решения;
5. самое рискованное допущение и его тип;
6. как проверю дёшево и за ограниченное время;
7. что увижу, чтобы признать неудачу;
8. оценка в днях.

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

Всё это рекомендация, а не исполненное решение. Разбор соответствия называет себя так: «рекомендация на момент, когда он [владелец проекта] даст команду, а не сама команда». Оглавление пакета называет те же разделы «принятым решением». Что из пяти частей уже сделано, здесь не проверялось.

Что остаётся неизвестным и что из этого следует

Три пробела ограничивают доверие к модели.

• Улучшает ли генератор продукт. Связь качества генератора с результатом продукта не измерил никто. Все измеренные связи идут через заменители: решение менеджеров, экспертный короткий список, заявленное намерение купить. Если не воспроизведётся и эффект дисциплины проверки, то, по словам журнала решений пакета, «у системы не останется ни одного эмпирически обоснованного основания предпочесть её ручному процессу».
• Годится ли документация как источник. Если документы лишь подтверждают сами себя, заметить это можно только по росту копирования классов механизма из входных документов.
• Есть ли сквозные данные. Размеченного набора «сигнал → возможность → фича → результат» нет ни у одной организации.

Итог

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

Источники

Предмет разбора — исследовательский пакет автора: исходная постановка, 24 карточки источников, шесть файлов с выводами и моделью, аудит и разбор соответствия Product Lab. Разбор пересказывает пакет: инструкции по внедрению и нового исследования в нём нет. Первоисточники не читались, о них известно по карточкам пакета. Состояние Product Lab взято из разбора соответствия от 4 сентября 2026 года и позже не перепроверялось.

Число в квадратных скобках в тексте — номер источника в списке ниже. Пакет оценивает силу доказательства по шкале от 1 до 5: 5 — рецензируемое исследование, 4 — материал компании с собственными измерениями, 3 — описание предписанного процесса.

Список разбит на четыре группы:

• 1–8 — академические работы, сила 5;
• 9–16 — материалы компаний, сила указана в скобках;
• 17–22 — методологии, сила 3;
• 23–24 — мета-анализы, сила 5.

1. Girotra и др. Idea Generation and the Quality of the Best Idea, 2010.
2. Terwiesch и др. Artificial intelligence and its impact on creativity and diversity, 2026.
3. Camuffo и др. A Scientific Approach to Entrepreneurial Decision Making, 2020.
4. Hoornaert и др. Identifying New Product Ideas, 2017.
5. Bell и др. Can AI Help in Ideation? 2024.
6. Si и др. The Ideation-Execution Gap, 2026.
7. Jiang и др. Artificial Hivemind, 2025.
8. Koning и др. Experimentation and Start-up Performance, 2022.
9. GitLab. Product Development Flow (сила 4).
10. GitLab. Product Processes (сила 4).
11. Airbnb. Eval-driven development, 2026 (сила 3).
12. Microsoft. Beyond Power Analysis, 2021 (сила 3).
13. Spotify. Beyond Winning, 2025 (сила 4).
14. Atlassian. Life of a Growth experiment, 2021 (сила 4).
15. Amazon. An insider look at Amazon's culture and processes, 2021 (сила 4).
16. Intercom. Start with the problem, 2022 (сила 3).
17. Torres. Continuous Discovery Habits, 2021.
18. SVPG. The Product Operating Model, 2023.
19. Bryar, Carr. Working Backwards, 2021.
20. Cooper. The Stage-Gate Model, 2026.
21. Patton. Dual Track Development is not Duel Track, 2017.
22. Perri. Escaping the Build Trap, 2018.
23. Holzner и др. Generative AI and Creativity, 2025.
24. Sio и др. Fixation or inspiration? 2015.

Автор публикации — Павел Диордиц. Текст подготовлен агентом Claude и сверен с карточками источников выборочно.