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

Один из таких фреймворков — это known/unknown, который полезен при планировании и оценки рисков.

Его можно представить в виде матрицы или дерева. На обеих осях у нас known/unknown и на пересечениях мы получаем четыре категории:

1) Known knowns — то, что мы знаем и прекрасно знаем, что мы это знаем. В математической задаче мы бы это записали как "дано".

В контексте бизнеса это — известные нам вещи. Например, мы знаем текущие метрики продукта или сроки вступления в силу нового закона.

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

2) Known unknowns — мы знаем, что "нечто неизвестное" существует и оно познаваемо, но мы не сделали работу, чтобы копнуть глубже и ответить на интересущие нас вопросы.

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

Например, мы можем знать, что половина пользователей у нас отваливается, но не знать где именно. Для измерения требуется инструментация воронки и сбор метрик. Задача решаемая и, приложив усилия, мы переведём её в категорию known knowns.

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

3) Unknown knowns — пожалуй, самая сложная категория для понимания. Как мы можем что-то знать, но не знать о том, что мы это знаем?

Это наша интуиция и насмотренность, помогающие формировать гипотезы.

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

Мы начинаем копать в этом направлении, анализируем данные, общаемся с пользователями и выдвигаем гипотезу. Проверив её и получив положительные результаты, мы можем обосновать добавление новой фичи, переместив эту задачу в known knowns. Или же не обосновать, таким образом, скалибровав свою чуйку под реальность.

4) Unknown unknowns — это территория интеллектуальной скромности. В Амазоне руководители часто спрашивают о том, какие у нас есть unknown unknowns для того, чтобы прощупать риски.

Unknown unknowns — не просто риски, а риски из категории "чёрный лебедь". Что может случиться, что поставит бизнес под угрозу (законодательство, конкуренты, события на макро-уровне, возникновение LLM), либо наоборот — даст нам толчок?

Тут главное не переусердствовать с катастрофизацией плохого (headwinds) и надеждой на хорошее (tailwinds). Эта категория — про реализм и понимание того, что может пойти не так и как мы будем на это реагировать.

Это так же про то, что мы все, собравшиеся на ревью нового проекта (включая руководство), осознаём риски на берегу и не бросаемся друг на друга с обвинениями, когда они вдруг материализовались.

—

Хорошие фреймворки также можно использовать частично. В Амазоне мы никогда не рисовали матрицу или дерево. Обычно мы оперировали терминами unknown unknowns и known unknowns в рамках обсуждений и все всегда понимали, что это такое. Это было частью лексикона всей компании.

Категорию unknown knowns мы никогда не называли этим именем. Это была просто "проверка гипотез".

Однако, мы всегда понимали, что задачи по устранению неопределённости (ключевая компетенция продакт менеджеров) всегда делятся на четыре категории:

1. То, что мы и так знаем и куда хотим затащить остальные три категории (known knowns)
2. То, для чего нам нужно достать данных (known unknowns)
3. То, что для чего нужно проверить гипотезы (unknown knowns)
4. То, что хз (unknown unknowns)