Вова і свідома компетентність

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

#113. Чому UX на курсах і UX у реальному продукті — це різні речіУ дизайнерському середовищі UX часто сприймають як набір обовʼязкових інструментів: Double Diamond, дослідження, CJM, UX-метрики, оптимізація кількості часу котрий юзер витрачає на флоу.Цей список добре знайомий кожному, хто проходив будь-які курси або дивився UX-кейси. Але чомусь в реальності компаніям цей процес не дуже-то і потрібен.Компаніям потрібно інше — зменшити ризик від неправильних продуктових рішень.Де тут користувачіВ вас виникне питання: "А як же турбота про користувача?", "А як же якість продукту?".Проблема в тому, що для бізнесу ці речі майже ніколи не є самоціллю.Компанії інвестують у UX тому що:- кращий UX → вища конверсія- кращий UX → краща активація- кращий UX → вище retention- кращий UX → сильніша конкурентна позиція.І для цього потрібна першочергова проблема з конверсією, з активацією, з ретеншном, чи з конкурентами котрі забирають ринок кращим юексом.Тобто турбота про користувача — це не моральна позиція.Саме тому поганий UX може існувати роками у монополіях або enterprise-софті — ризик втрати користувача там просто нижчий. Ви бачили колись Salesforce? Це ад.UX не може бути однаковим всюдиБагато дизайнерів намагаються застосовувати один і той самий набір інструментів у будь-якій компанії.Але продукти живуть у різних фазах: ранній стартап, продукт у фазі росту, зрілий продукт, перезрілий продукт.І задачі там радикально різні. Тому і UX-інструменти будуть різні, та в різному рівні глибини відпрацювання.UX-процес не універсальний. Він залежить від стадії продукту і задач бізнесу.UX — це не набір ритуалів. Це спосіб зменшити невизначеність перед тим, як команда витратить час і гроші граючі в "угадайку".Early stageКоли продукт тільки шукає product-market fit, головне швидко перевіряти ідеї, знаходити напрямок, зрозуміти користувача.Корисні інструменти: інтерв’ю, швидкі прототипи, грубі перевірки гіпотезНе важливі: точні UX-метрики, оптимізація секундГоловний ризик тут зробити продукт, який нікому не потрібен. Але теж, може інвестору вистачає яєць і віри в себе.Growth stageКоли продукт вже працює і починає масштабуватися.Фокус змінюється: активація, onboarding, retention, експерименти.Тут UX-практики допомагають:- знаходити точки росту, але багато хто справляється і без них.- не ризикувати бюджетом випускаючі фічі, в котрих немає шансу активувати або утримати користувача.Зрілі продуктиУ продукті, який вже має PMF і стабільний бізнес, з’являються інші задачі, але з мого досвіду відбувається постійно одна й таж двіжуха.Багато рішень приймається на здоровому глузді, логіці і досвіді. Так працює більшість продуктових команд.Але у такого підходу є проблема, бо коли з’являються складні рішення, починаються суперечки: дизайнери думають, що рішення зрозуміле; продакт сумнівається і не хоче ризикувати, топ-менеджмент каже: "херня — перероблюйте".І тут без дослідження нічим відповісти.UX-метрики і "перезрілий" продуктЯкщо говорити про "класичні" метрики юексу: час проходження сценарію, кількість кліків, micro-friction то це прерогатива великого бюрократичного бізнесу. Де треба шось оптимізовувати, але без різких рухів.Я працював в досить великих продуктах, і там ніколи нікого не збуджували фрази накшталт "Ми скоротили сценарій з 42 до 36 секунд".Такі метрики починають мати сенс тільки на гігантському масштабі, де навіть невелика оптимізація дає великий фінансовий ефект. Ну чи стає частиною багатострінкового звіту.Коротше UX не варто сприймати як набір обов’язкових практик.Хороший дизайнер дивиться на продукт і питає себе: де зараз найбільший ризик, де найбільша невизначеність, де команда може витратити багато грошей на неправильне рішення.А вже потім обирає інструменти для вирішення цих питань, і адаптує ці інструменти під ситуацію.У всіх інших випадках виходить дискредитація методик і нашої професії.

#112. Менеджмент як проектування аха-моментів, а не впровадження процесівНа цих вихідних думав про те, що популярна тема з аха-моментом в менеджменті продуктів, дуже класно вкладається і на менеджерську роботу.Що таке аха-момент:Це момент, коли користувач вперше відчув реальну цінність продукту.І більшість великих продуктів намагається прискорити і закріпити цей момент, аби користувач скоріше і глибше відчув це "аха!".Приклади про пережиту цінність в команді:- Перший раз отримав корисні результати з ресьорчу — "ого, воно може працювати!"- Вперше привʼязав своє рішення до метрик і менеджмент погодився — "нічосі"- Почали планувати задачі і зменшилась паніка і срачка — "а шо так можна було"Якщо аха-моменту не сталося, цінність не отримана і не відчута, позитивного досвіду не має, активація не відбулась — ініціатива, проект, процес, артефакт відмирають.Приклад з процесомКороткостроковпе планування задач робити зазвичай дуже ліньки. Середньострокове на пару місяців тимпаче.Але якщо зробити хоча б більшменш адекватно, зʼявиляється передбачуваність і зникає частина фонового стресу.Аха-момент це саме коли ти розумієш шо ти знаєш шо треба буде робити, що ти робив і всі більш-менш заалайнені навкого цього. Звісно шось залетить незаплановане, але це не буде 100% незапланованого.Якось мені дизайнер каже: “Ти знаєш, я в пʼятницю знаю, що буду робити наступного тижня. Раніше в неділю нервував, що може на тижні прилетіти.”Приклад з артефактомЗавжди на певних задачах підпушую робити тестування з користувачами.Для того щоб тут стався аха-момент, треба шо б була підходяща задача (а не будь-яка для якої тестування не зіграє ролі), шоб прийшли хоч трохи корисні результати, щоб вони допомогли потім захистити свою позицію перед командою.І отут теж "о, тепер в мене є сильна база для прийняття рішень". А потім команда починає челенджити задачу в дусі "нам здається що не зрозуміє ніхто", а ти вже "обмазався ресьорчем" і на всі мутні питання є що відповісти.З цього моменту ресьорч перестає бути "зайвою бюрократією" — він стає інструментом підкріплення позиції і аргументації.Приклад з розвитком командиМожна написати гарний документ по розвитку на 6 місяців, а можна подумати: де буде перший досвід зростання?Виділили, наприклад, необхідність качати комунікацію і презентацію. Можна залишити людину з цим, хай розбирається — єдине шо тут можна мабуть придумати сходу це пошукати курс "комунікація і презентація".А можна вибудувати досвід перших 2-4 тижнів навколо наступного: 1-2 дзвінка де ви нагадуєте і формулюєте основні теоретичні штука по презентації і комунікації, на другому тижні плануєте невеличкий виступ людині в середині команди (в своїй команді простіше), на третій тиждень на більш широку публіку на якомусь ревью, допомагаєте з підготовкою. Потім допомагаєте зібрати трошки позитивного фідбеку.Таким чином інвестиція часу і зусиль отримує своє повернення інвестицій, людина втягується, і вже вистачить мотивації і розуміння розвивати навичку далі.Що робитьОтже ми можемо сфокусуватися не на впровадженні практик, а на доведенні людей до першого пережитого доказу цінності цих практик.Якщо ви не можете відповісти на питання “де людина вперше відчує користь цього процесу?” цей процес, швидше за все, помре.Тут можна навести приклади: новий шаблон, який тільки ускладнює; новий документ, який ніхто не читає; новий артефакт без швидкої користі.Перед тим як вводити нову практику, варто подумати:- Де і як швидко буде перший measurable результат?- Чи він буде видимим?- Як зробити щоб людина пережила його як власну перемогу?

#111. Про токсик: де менеджери ламають команду власноручЄ один вид токсика, який інколи важко розпізнати. Часто він народжується з найкращих намірів: бути чесним, бути “своїм”, підтримати людей, не брехати про реальність.Проблема в тому, що менеджер може переплутати людську відкритість з рольовою відповідальністю. І тоді команда стає не місцем, де працюють і ростуть — а місцем, куди зливають фрустрацію.Йдеться не про "прикидатися і брехати, що все добре". Йдеться про те, що менеджер має давати опору, а не скидати на команду свою безпорадність.Ось кілька типових помилок, від яких я хочу застерегти і менеджерів, і спеціалістів.1) Злив негативу внизМенеджер фрустрований, злий, втомлений і починає проговорювати це з репортами: "тут нічого не зміниться", "керівництво неадекватне", "все котиться".На короткій дистанції це може навіть здаватися “чесністю”. Типу нарешті хтось називає речі своїми іменами.Але на довгій — команда не може "розв’язати" проблему менеджера. Їй доводиться або підлаштовуватися і кивати, або сперечатися з власним керівником, або мовчати і накопичувати напругу.2) Плутання емпатії з солідарністю проти компаніїКоли менеджер каже “я з вами в цьому лайні” — це може звучати як підтримка, але насправді — "давайте разом знецінювати систему".“Ми нормальні, а вони там зверху — тупі”, “в цій компанії нічого не працює”, “усі рішення — політика і цирк”.Це зручна форма близькості: менеджер стає “своїм”, а команда — його фан-клубом. Але така близькість будується на цинізмі, а цинізм завжди вбиває відповідальність.Визнати складність ситуації — нормально. Робити з репорта співучасника цинізму і знецінення — ні.3) Моральна вища позиціяІноді менеджер заходить з іншого боку. Не “все котиться”, а “я єдиний нормальний”.“Топи думають тільки про гроші”, “я був за репутацію і цінності”, “мене прибрали бо я не прогнувся”.Це звучить благородно. Але по факту це той самий “ми vs вони”, тільки з ореолом мученика. Команда з цього виносить дві речі: 1) система завжди погана, 2) принциповість карається.Якщо вже хочеться говорити про конфлікт з керівництвом — говори як лідер, а не як коментатор: в чому був ризик, що ти пропонував, яке рішення прийняли, і що ми контролюємо далі.Працювати з рішеннями, з якими ти не згоден це теж частина роботи і мачурності.Що ламається в команді- падає ownership ("раз все тупо, то я просто зроблю мінімум")- вмирає ініціатива (будь-яка дія виглядає наївною)- зникає психологічна безпека- росте розкол "ми vs вони"- люди вигорають і йдутьЩо робити менеджеру замість "зливу"Емоції це нормально, але питання куди їх нести.1. Виносити фрустрацію “вбік і вгору”.Peer-менеджери, керівник, коуч/ментор, терапія, особисті друзі. Команда не має бути контейнером для твоїх емоцій і непорозумінь.2. Говорити з командою структурно.Факти → ризики → план → запит. Можна сказати: “мені теж важко” — але не можна лишати людей у безнадії.3. Якщо все настільки погано — обирай дію.Або ти намагаєшся впливати на систему (ескалації, пропозиції, зміни), або ти йдеш. Але не робиш команду співучасником цинізму.Тобто, якщо все реально погано — а таке дійсно може бути, що всі названі фактори реальні — то блін треба терміново звалювати, а не морочить команду.

#110. Інтуітивний менеджментЛідовські і менеджерські ролі, зазвичай займають тому що того потребує ситуація, і багатьом ці ролі здаються інтуїтивними. Типу я ж бачив як це робиться, розберусь.Але у більшості кейсів як результат, включається патерн наслідування. Ти просто береш за базу поведінку свого менеджера. А він до цього взяв за основу поведінку свого. І так далі по ланцюжку.Проблема в тому, що в подавляючій більшості випадків ця база була далека від професійної. Бо люди виростають у ролі через виживання, пожежі, політику, власні травми і "якось воно працювало".Це дуже схоже на батьківство — йому рідко хто вчиться.Більшість бере те, що бачили в своїй сімʼї, трохи додає від себе — і потім дуже повільно вчиться новому, коли стає боляче. В менеджменті так само: поки команда "якось їде", здається, що все ок.Але ти успадковуєш не тільки патерни поведінки, а й страхи: уникати конфліктів, тиснути контролем бо інакше все розвалиться, тримати дистанцію, робити вигляд що все нормально, або навпаки — постійно бігти і тушити пожежі.В результаті команда може виживати, але платить вигоранням, текучкою, страхом, низькою ініціативою.Також планка "нормального менеджера" часто дуже низька. "Я не кричу, я не токсік, я даю свободу (шо б це не значило) — це добре". Але цього мало, щоб команда росла і довіряла.Професійний рівень починається там, де ти розриваєш цикл: помічаєш, що ти повторюєш, і вчишся робити інакше. Переходиш від голої харизми до системи: ясність очікувань, ритми, фідбек, конфлікт-менеджмент, розвиток людей, рішення, комунікація.Мій простий тест: якщо ти не можеш чітко пояснити, чому ти дієш так, а не інакше — це, скоріш за все, не твоє рішення, а чиясь стара прошивка.Симптоми непрофесійного менеджменту- Люди не розуміють що таке "добре".- Відсутній регулярний фідбек.- Рішення приймаються випадково або “по настрою”.- Конфлікти замітаються.- Залежність від героїзму і гасіння пожеж.- Критерії росту туманні.Що можна зробити вже зараз- Ритмічні 1-2-1 дзвінки (раз на 1–2 тижні) з певним планом.- Домовитись про очікування на 1–2 ключові зони.- Навчитись давати структурний фідбек (ситуація → вплив → очікування).- Почати вчитись. Книжка/курс/ментор/ком’юніті — будь-що, аби це було системно.Особисто я пішов в менеджмент і в освіту по цій темі, шо б зменшити страждання частини дизайнерів. А для когось навіть створити умови, де робота приносить задоволення. Тому і продовжую кожного дня по троху розбиратись.

#109. Хайринг очима хайринг-менеджера (продовження)По важливих скілах і типах робіт питаю конкретно скільки разів і яка була частота виконання. Умовно "зробив пару раз протип в мейзі" не каже про те, що це навичка достатнього рівня, щоб робити це без фрікшну.Ще тут з цікавого — я дивлюсь на криву розвитку кандидата.Якщо кандидат дуже повільно зростав 10 років — скоріш за все я не зможу зробити так, щоб він раптом "полетів у космос". Натомість з кандидатами, які видно шо швидко зростали, є висока вірогідність, що якщо дати їм правильні задачі, план розвитку і підсилити сильні сторони, будуть продовжувати швидко рости.Ось тут я ще писав про структуру інтервʼю.Ну і важливий момент: під час інтервʼю я роблю собі нотатки сприводу За (pros) і Проти (cons), а після пишу ще короткий висновок. Ну і додаю це все до рекрутинг тула, шо б не забути, і передати контекст to whom it may concern.Тож:- не плутати приємну розмову з сигналом компетенції;- не оцінювати кандидата за нерелевантні питання;- фіксувати критерії оцінки заздалегідь, інакше будете підганяти під відчуття.Етап 6. Інтервʼю з PM та/або командоюТут зазвичай можна зібрати допоміжний додатковий фідбек, на те шо ви провтикали. Але його треба зважувати, бо мотивацію, питання, і скіл інтервьювання команди вам може бути не відомий.Етап 7. Фінальне рішення і оферТут в вас повинно бути хоча б 2 класних кандидати, між якими треба робити складний вибір. Бо інакше це як взяти перший ліпший концепт дизайну шо в вас вийшов. Якщо класний тільки один, то варто поспівбесідувати ще. Тут треба звести всі критерії, ще точніше виділити кого саме ви шукали, і хто краще вписується в профайл. Крім того, ваш фаворит може офер і не прийняти, тоді доведеться повертатись на пару етапів назад.І не забувати, що онбординг і його проходження — це теж частина найму.Коротше, для мене найм — це не "пара інтерв’ю", а система. Кожен крок або підсилює точність, або влаштовує лотерею. І моя задача не "відсіяти поганих", не знайти хоч одного нормального, а на кожному кроці зібрати адекватні сигнали і зробити результат передбачуваним.

#107. Матриця компетенцій: 13 проблем цього інструментуМайже всі хто приходять на наш з паном Іваном курс по дизайн-менеджменту, першим ділом питають про матриці-компетенцій, а скоро вже буде 16 запуск (бляха зараз глянув який запуск і зрозумів шо він вже зовсім скоро — 26 січня, матір-божа).І на менторшип-сесіях часто про матриці питають. Тут я вже теж вирішив подивитися, шо в мене вже перевалило за 400 сесій.Здається, що це досить простий тул, який допоможе швидко навести лад. І дизайнери з команди часто просять його впровадити.Але не все так просто.1. Їх складно зробити добреХороша матриця — це не перелік скілів, а система з чіткими поведінковими описами. Якщо зробити її посередньо, вона не допомагає розвиватися, а лише створює ілюзію структури.2. Вони забирають дуже багато часуМатриця дорога і на етапі розробки, і на етапі проходження. Заповнення, звірка оцінок, дзвінки, обговорення... Усе це має сенс лише тоді, коли масштаб команди це виправдовує.3. Дизайнери часто сприймають їх як бюрократіюБез чіткого пояснення навіщо це робиться і зрозумілого ауткаму у вигляді корисних планів по розвитку, матриця виглядає як ще один менеджерський артефакт, який не має прямого звʼязку з реальними задачами.4. Менеджери очікують від них магіїЧасто є очікування, що матриця автоматично відповість на питання «кого промоутити» і «що качати». На практиці вона дає лише загальний список дуже умовних список зон росту без пріоритетів.5. Виходить мутний список абстрактних “скілів”Креативність, лідерство, відповідальність звучать красиво, але погано вимірюються. Без конкретних проявів у роботі такі скіли лише підсилюють субʼєктивність.6. Дуже складно чітко відрізнити рівні між собоюЯкщо різниця між рівнями не описана через поведінку і вплив, матриця швидко скочується в «мені здається, що це вже сенйор».7. Без привʼязки до стратегії зʼявляється нерелевантна дичинаУ матрицю потрапляють хайпові теми, особисті хотєлки менеджера або універсальні «best practices», які не вирішують жодних поточних проблем компанії.Наприклад, аксесібіліті. Воно мені здається є в кожній інтерфейсній матриці. Тема хайпова, але вона вирішує дуже специфічний пул проблем, починаючи з певного етапу компанії. Якщо шось так попадає до матриці, то потім це гарантована фрустрація і для команди і для менеджера.8. Скілів стає занадто багатоПонад 25–30 пунктів роблять матрицю виснажливою. Асесмент займає вічність, а обговорення перестає бути фокусним.9. Вона не має сенсу для маленьких командДля 3–5 дизайнерів однієї спеціалізації простіше і ефективніше працювати через персональні розмови та плани розвитку, а не через важку систему.10. Вони погано працюють між різними дисциплінамиОдна матриця не може бути однаково корисною для продуктових дизайнерів, моушн-дизайнерів і ілюстраторів. Універсальність тут шкодить.11. Soft skills майже неможливо коректно описатиУважність, ініціативність, пунктуальність краще перевіряти на співбесідах і в щоденній роботі, ніж намагатися «розвивати» їх через матрицю.12. Матриця не гарантує промоНавіть ідеально заповнена матриця не означає підвищення. Вона створює мову для фідбеку, але не замінює управлінські рішення.13. Матриця повинна еволюціонуватиПершу версію має сенс зробити по "середній температурі по палаті". Бо бажано шо б не виявилось, шо половину команди взагалі треба негайно звільняти, а ви про це не думали. Але це не заважає вам потім кожні пів-року поступово підіймати очікувані рівні і пушити на них команду.Доречі отут я писав про те як будувати плани розвитку.А ще я зробив безкоштовний шаблон для опису розвитку по команді. Він поки в ПДФ і швидко стало очевидно, що логічніше мати його у форматі фігджему. Єдине шо я вже 2 місяці прокрастиную його перенести.Матриця компетенцій це класний інструмент. Мій меседж, шо краще добряче подумати, перед тим як її робити. Є купа інших важливіших і простіших речей.

#106. Хибні очікування і розчаруванняОстаннім часом і на робочих вантуванах і на менторшипі вспливали схожі історії.Люди приходять з очікуванням росту, підвищення зарплати, промоушену. Вони беруть більше відповідальності, «тягнуть» команду, закривають прогалини. А потім — нічого не відбувається.Типові фрази:"Я думав, мене скоро промоутять""Я тягну більше, ніж інші""Менеджер нічого не робить""В компанії все погано, і менеджер це підтверджує"І в якийсь момент зʼявляється простий висновок: компанія і менеджер — погані. Не допомагають, не помічають, не розуміють.Інколи саме так і є, але частіше я вважаю, шо це проблема хибних очікувань, з котрими треба працювати. Та і навіть якшо так і є, треба ж шось робить, а не тільки нити.Більшість конфліктів, розчарувань і токсика в командах народжується не тому, що «все погано», а тому що очікування не проговорюються і не оновлюються.Чому "поганий менеджер" це не корисний, хоч і зручний діагнозУ більшості таких історій немає злого умислу. Є дві різні картини реальності, які довго не синхронізувалися.Людина живе у своїх очікуваннях: я роблю більше, я росту, наступний крок логічний.Менеджер живе у своїй: обмеження бюджету, пріоритети компанії, політика, таймінги.Якщо ці дві реальності регулярно не звіряти, мозок починає домальовувати причини сам. І відсутність ясності дуже швидко перетворюється на відчуття несправедливості. І чим довше синхронізація не відбувається — тим фантастичніше стають очікування.В більшості, звісно, тут винний менеджер, бо людина не зобовʼязана розуміти систему, судить по доступних сигналах. Але проблеми, зазвичай, будуть не в менеджера, бо в системі зазвичай «падає» репорт з нереалістичними очікуваннями, а менеджер лишається і вчиться (або не вчиться).А тепер шо робити.Все це впирається в комунікацію, а конкретно в one-to-oneБільшість зазначених проблем народжується не на рівні стратегії чи культури, а на рівні регулярних розмов.One-to-one — це не статус-мітинг. Це багато чого, але в тому числі і ключовий інструмент управління очікуваннями, енергією і довірою.Це єдине місце, де менеджер і співробітник можуть регулярно звіряти реальність: очікування, енергію, обмеження і напрямок руху.Як структурувати one-to-oneЯ не вірю в універсальні скрипти, але я подумав шо варто виділити певні теми.1️⃣ Очікування і розвитокПро що говорити:- Чого людина зараз чекає від компанії.- Чого компанія зараз чекає від людини.- Що має статися, щоб цей наступний крок був можливий.Важливий момент: очікування без критеріїв і дедлайнів — це фантазії. Їх потрібно або приземляти, або чесно знімати.2️⃣ Навантаження, вигорання, енергіяПро що говорити:- Що зараз найбільше виснажує?- Що навпаки дає енергію?- Де ти працюєш «на автоматі», а де постійно через силу?Це не терапія, а допомога в управлінні ресурсом, від якого залежить результат.3️⃣ Реальність компанії — без токсикаМенеджер тут виконує роль перекладача.Можна і потрібно говорити: що змінюється, де є обмеження, чому деякі рішення виглядають нелогічно.Не можна: зливати цинізм, множити тривогу, робити репорта носієм менеджерської фрустраціїМенеджер перекладає складну реальність на зрозумілу, а не погіршує її.4️⃣ Людський контактКонтекст життя. Стан. Просто розмова.Не як обовʼязок і не як small talk, а як інвестиція в довіру, яка особливо важлива в складні моменти.Люди працюють з людьми.Коротше, не множте фрустрацію, працюйте з очікуваннями, не розганяйте фантазію бо вигорите.One-to-one не рятують компанію від поганих рішень, але вони рятують людей від фантазій, токсика і взаємних звинувачень.Шукати ідеальну компанію не має сенсу, а от шукати чесну розмову і зрозумілі правила гри — є.

#105. Growth, Retention і Enablement: як зʼявляються різні типи роботи в продуктіВ якийсь момент розвитку компанії стає зрозуміло, що не вся продуктова робота однакова. Фічі, експерименти, покращення досвіду й інфраструктурні задачі живуть за різною логікою — але часто продовжують існувати в одному беклозі.Щоб з цим упоратись, корисно дивитись на роботу через три стріми — не обов’язково як на оргструктуру, а як на різні типи мотивацій і інтенцій.За що відповідає кожен стрімRetention / Engagement — це робота з існуючим досвідом. Флоу, довіра, повторні сценарії, сервісний і post-purchase UX. Питання: чому люди повертаються і залишаються?Growth — це робота про зростання і масштабування. Гіпотези, експерименти, вплив на конверсію, чек, нові ініціативи. Ключове питання: що і як ми можемо масштабувати?Enablement — це інфраструктурна робота, яка дозволяє першим двом стрімам працювати стабільно. Дизайн-системи, внутрішні інструменти, стабільність, процеси. Вона рідко дає миттєвий бізнес-ефект, але визначає, чи здатна система витримувати навантаження і стрімке зростання.Стріми не зʼявляються одразуЦі стріми не зʼявляються з першого дня, вони приходять разом із ростом складності і етапами розвитку продукту.До market-fit частіше за все окремих стрімів немає, є хаотичний пошук цінності. Але вже тут зʼявляються зародки Growth і Retention, просто ще без метрик і системності.Коли зʼявляється fit і компанія починає масштабуватись, Growth оформлюється в окремий фокус. Зʼявляються експерименти, швидкі цикли, нові ініціативи.Зі зростанням масштабу стає болючим Retention — приводити людей виходить, а утримувати складніше. Починається системна робота з досвідом.Enablement зазвичай оформлюється останнім, коли швидкість і кількість ініціатив починають ламати систему, техборг вже надто великий і задовбує постійно конфліктувати на цю тему.Як компанії запускають новий фокусКоли ви хочете серйозно навалити на новий напрям, частіше за все вам не допоможе просто докинути задач поточній команді. Вона вже надто адаптувалась. Створюється окрема команда, яка запускає напрям з нуля зі 100% фокусом.Класичний приклад — UX або Research. Спочатку 1–5 людей формують підходи, інструменти, воркфлоу. З часом частина задач переходить до продуктових дизайнерів у спрощеному, зрозумілому вигляді, а спеціалісти рухаються в глибші рівні роботи.Стріми працюють так само. Вони дозволяють:- зафіксувати новий фокус,- не ламати старі підходи,- розвивати різні типи роботи з різним темпом, логікою і процесами,- працювати з різними беклогами, cadence і форматами ревʼю.Я тут трошки намішав мабуть топіки по запуску, і по структурі роботи, але шо робить. Мабуть головна думка не забувати про 3 паралельних напрями роботи, і шо кожний з цих стрімів потребує різних підходів, і людей з різними підходами і звичками.І якщо хочеш шось запустити з нуля, виділи це в помітний і окремий напрям роботи зі своїми правилами і воркфлоу. А не накидати це на поточну команду без досвіду, і сподіватись на диво.

#104. Усе в компанії можна звести до revenue. Але чи вартоНещодавно ми зарубились на цю тему в новій серії подкасту, котру я викладу вже на днях.Позиція проста: у будь-якій компанії всі цілі в кінцевому підсумку зводяться до revenue. Можливо, відкладеного. Можливо, потенційного. Можливо, через економію, оптимізацію чи зниження ризиків. Але все одно — до грошей.Але чи варто зводити все до цього — і чи всім про це говорити?Компанії не існують заради благодійностіНавіть ті, що говорять про місію, цінності, вплив і користь. Усе це може бути важливим і щирим, але без грошей компанія просто перестає існувати.Якість — це коли продукт не підводить користувача, не зупиняє команду і не створює постійних витрат на виправлення.Юзабіліті — швидший адопшн, вищий ретеншн і відчуття продукту, до якого хочеться повертатись.Дизайн-система — дешевше масштабування і швидші зміни без експоненційного росту вартості.Аксесібіліті — не тільки про інклюзію, а й про доступ до сегментів, які на масштабі стають значними, і про уникнення дорогих юридичних проблем.Бренд — дешевше залучення, вища довіра і простіші продажі з часом.Це цинізм, чи базова математика?Проблеми починаються коли ми робимо вигляд, що це не так.Комунікаційний аспект“Revenue” як ціль — не працює для всіх рівнів в компанії.Якщо прийти до дизайн-менеджера або команди і сказати: «ваша ціль — revenue», це не може спрацювати, бо:- вони не контролюють цю метрику напряму;- починають оптимізувати не те, що в їхній зоні впливу;- або імітують корисність, замість реально покращувати продукт.У результаті метрика є, а реального впливу — немає.Взагалі, складно одночасно мислити в оперативному, тактичному та стратегічному контекстах. Виконавці більшість часу живуть в операційці, топ-менеджмент — у стратегії. І без правильної декомпозиції цілей це майже гарантовано створює проблеми в комунікації.Тож верхньорівневі цілі треба декомпозувати і приземлити.Revenue — це не ціль, а фінальний наслідокЗрілі компанії це розуміють і тому працюють через проксі-цілі.Для дизайну це не «заробити гроші», а:- знизити ризик неправильних рішень;- скоротити time-to-value;- підвищити якість execution;- зробити продукт масштабованим.Для менеджменту — передбачуваність, фокус, вартість змін. Для продукту — баланс між effort і impact.Усі ці речі не виглядають як revenue в таблиці. Але саме з них він і складається.North Star метрика — це теж про корректну комунікацію, про приземленість, але при цьому зазвичай прямий вплив на гроші.Наприлад в Airbnb це є/була кількість забуканих ночей. Зрозуміло як оптимізувати, але при цьому напряму впливає на кількість зароблених грошей. І звучить красиво.Навіщо все ж тримати revenue в головіПопри це, робити вигляд, що економіки не існує — теж інфантильно.Якщо компанія роками не заробляє — вона не «шукає себе», вона скоро вмре. Якщо revenue падає кожен місяць — паніка не за горами, незалежно від культури.Якщо це стартап — останній раунд і burn-rate це таймер, а не абстракція.Це важливо тримати в голові хоча б для того, щоб реалістично дивитись на:- бюджети,- найм,- «стратегічні ініціативи»,- власну роль у цій системі,- і коли треба досягнути результатів, або полірувати CV.Про зрілість, а не про грошіУ підсумку питання не в тому, чи все зводиться до revenue.Питання в іншому:- кому про це варто говорити прямо;- а кому — через правильні проксі;- і хто здатен тримати цю реальність у голові, не перекладаючи її напряму на команду.Зрілість менеджера — не в тому, щоб вимагати грошей від дизайнерів, а в тому, щоб розуміти економіку бізнесу і допомагати будувати системи, які до цих грошей приводять.