#114. Робота в продукті — це прийняття рішень без повної інформаціїТипова помилка дизайнерів у продуктових командах — намагатися максимально прибрати невизначеність перед тим, як почати роботу.Логіка зазвичай звучить так: давайте спочатку зробимо повний ресерч. Звучить наче правильно, але в продуктовій роботі рідко працює так.Чому так думаютьУ навчальних UX-моделях робота виглядає дуже акуратно: спочатку дослідження, потім синтез, потім ідеї, потім тестування.Процес виглядає послідовним. І створює відчуття, що спочатку треба повністю розібратися в проблемі, а вже потім переходити до рішень.Де ця логіка ламаєтьсяУ реальному продукті і бізнесі майже ніколи немає повної інформації, не буває достатньо часу, не буває впевненості у правильному рішенні.Команда повинна рухатися швидко. Є дедлайни, є плани запусків, є конкуренти.Тому чекати, поки вся невизначеність зникне, зазвичай просто неможливо. Тимпаче нереально досягнути 100% визначеності.Більшість продуктових рішень приймаються в умовах неповної інформації. І чим більше ти в ієрархії компанії, тим з меншою визначенністю тобі доводиться приймати рішення.Чим вище рівень рішення — тим:- менше даних- більше ставок- більше невизначеності- більший радіус впливуІ це прямо пояснює чому senior-рівень відрізняється від junior.Junior хоче:- більше інформації- більше інструкцій- більше впевненостіSenior вміє:- приймати рішення з 60%(умовно) інформації- запускати експерименти- рухати роботу вперед попри невизначенністьТоп-менеджери майже ніколи не мають повної картини. Вони приймають рішення на основі часткових даних, сигналів і гіпотез.Як насправді працюють продуктові командиЗазвичай робота виглядає інакше — команда робить дві речі паралельно.1. Робить те, що вже зрозумілоНаприклад:- базовий флоу- зрозуміла логіка фічі- існуючі патерни продуктуНемає сенсу відкладати цю частину тільки тому, що інша ще не досліджена.2. Розбирається з тим, що незрозумілоНаприклад:- як користувач приймає рішення- де виникають проблеми- який із варіантів працюватиме кращеТут вже має сенс робити дослідження, тестування або аналіз.Тому реальна робота рідко виглядає як красивий UX-процес, а скоріше робимо те, що зрозуміло, досліджуємо те, що незрозуміло, уточнюємо рішення по дорозіЦе ітеративний режим, а не послідовний.Bias for actionСаме тому в продуктових командах дуже цінується bias for action.Здатність рухати роботу вперед, приймати рішення при неповній інформації, уточнювати рішення по ходу.Багато дизайнерів намагаються зменшити невизначеність перед тим, як почати роботу. Продуктові команди зменшують невизначеність через роботу.Штука в тому, що б розуміти:- де потрібно зупинитися і розібратися- де достатньо робочого припущення- де потрібно просто почати робитиІ дуже часто найшвидший спосіб зрозуміти правильне рішення — почати щось робити і подивитися на результат.Fuck Around — Find Out