Як наймати продакт-дизайнерів, створювати продукти у великій компанії та швидше розвиватися — три конспекти виступів на ProductCampKyiv’22

У грудні в Києві відбулася конференція ProductCampKyiv’22. Продакт-менеджери, підприємці, дизайнери та аналітики ділилися інсайтами щодо створення продуктів і давали поради для розвитку кар’єри. Vector публікує конспект виступів Анастасії Школдіної (Parimatch Tech), Руслана Мамедова («Сільпо») та Віталія Бердічевського (Boosta).

Як знайти свого ідеального продуктового дизайнера й не зробити собі боляче

Хайринг — завжди челендж. Його результат може бути сюрпризом — як позитивним, так і негативним. Якщо відкрити вимоги різних компаній до дизайнерів, то побачимо, що вони дуже різні. Наприклад, дизайнер мусить знати HTML, уміти робити UX Research, працювати з Big Data, мати досвід розроблення дизайн-систем тощо. 

Перед пошуком продакт-дизайнера в команду треба поставити собі прості питання:

• Навіщо нам продакт-дизайнер? Яку проблему розв’язуєте?
• Яким буде його / її звичайний робочий день? 
• Це допоможе відповісти на таке питання: які хард-скіли ми в цій людині шукаємо? 
• Який має бути в неї майндсет? Команду ж варто посилювати не тільки хард-скілами, але й за її цінностями та софт-навичками. 

Важливо відразу визначити, якого спеціаліста ви шукаєте. Зрозуміти, хто саме потрібен — це вже половина шляху до вдалого найму й створення «історії успіху». Інакше може статися ситуація, коли прийде людина для розв’язання великих складних проблем, але зрештою буде сидіти пиляти інтерфейси — і її очікування не справдяться. 

І це справедливо, бо продакт-дизайнер повинен не просто розробляти дизайн інтерфейсу, а дивитися ширше. Він має стати лідером із залучення команди до розв’язання проблеми кінцевого користувача. Саме в цьому його завдання. Тому він повинен вміти мислити не екранами, а більш масштабно в контексті ітерацій та варіантів, які залежать від багатьох факторів.

У мене є історія про незручного дизайнера, яка закінчилася успіхом. Одна продуктова команда не мала дизайнера, утім завдань було вдосталь. Ми знайшли чудову фахівчиню, але спочатку їхня взаємодія трохи не пішла. 

Команда звикла, що всі завдання описуються через готові рішення: «перемісти це сюди, напиши те, зроби таке». Дизайнерка їх отримувала і розуміла, що цієї інформації недостатньо для створення дійсно якісних рішень — але вона проактивна, і ставала трохи незручною для команди. Тому ставила багато питань, дізнавалася контекст, спілкувалася з користувачами. Ба більше, крім варіанта, який від неї вимагали, робила дві-три альтернативи й пояснювала, як вони працюють і чим можуть бути корисні. Так, для колег подібний підхід був десь незручний, але він про проактивність.

Водночас команда не звикла, що можуть бути інші варіанти: з ними треба розбиратися, заглиблюватися в контекст, витрачати більше часу й ресурсів. Але десь за півтора місяця підхід змінився — і вони вже очікували додаткових варіантів. 

Що зробила ця дизайнерка своєю проактивністю? Показала продакт-команді, що таке дизайн-процес. Це про постійне повернення й постановку питань: що ми робимо, навіщо, яка в нас є проблема і як нам варто її розв’язати. Для цього важливо бути в контексті. 

У цьому плані продакт-менеджер і продакт-дизайнер мають багато спільного. Я часто дивлюся на те, щоб у дизайнера було аналітичне мислення. Він може не мати «польового» досвіду роботи з тестуваннями гіпотез, А/B тестами тощо, але в нього є підхід і, що більш важливо, — експериментальний майндсет. 

Експеримент — єдиний спосіб перетворити гіпотезу на факт. Уся команда постійно будує гіпотези, навчається, і лише після цього вирішує, що робити далі.

Експериментальний підхід — це парадигма мислення команди, і якщо дизайнеру не підходить цей підхід, це може створювати непорозуміння. 

Також великий плюс, якщо дизайнер розуміє продуктові метрики, пропонує рішення на їхній основі та відстежує експерименти, на які може вплинути, — це про залученість, небайдужість. А найвищий клас — уміти допомогти з дизайном експерименту. 

Як не факапнути, будуючи IT-продукти у великих українських компаніях

У роботи на велику компанію є свої мінуси та плюси.

Мінуси: 

• Великі компанії досить повільні. Наприклад, генератори будуть купуватися місяцями, але їх одразу приїде 500 штук, коштуватимуть вони недорого. Тобто ви зустрічатимете багато складних процесів тощо. 
• Немає хороших і поганих великих компаній. Є такі, що підходять або не підходять конкретно вам за цінностями. Тому найкраще заздалегідь дізнатися якомога більше про саму компанію та її засновників — це дасть відповіді на багато ваших запитань. 
• Не всі люди завжди будуть розуміти, навіщо вас найняли. Для цього треба давати їм більше контексту, говорити з командою та стейкхолдерами, бути проактивним. 
• MVP — це не про великі компанії. Може здаватися: «Зараз зробимо щось маленьке, потім виставимо API, і всі будуть користуватися». Ні. У вас усе одно велика кількість користувачів — як ззовні, так і всередині, великий трекшн, а з ним і відповідальність. І завжди буде якась 1C або SAP, з якими все одно треба інтегруватися. 
• Ви будете розмовляти різними мовами. Довгий час я говорив зі стейкхолдерами та керівниками технічною мовою — і мене ніхто не розумів. Для себе я визначив такий принцип: треба спілкуватися так, щоб людина виходила після розмови з відчуттям, ніби дізналася щось нове. 
• «Давай-давай» менеджмент і чайка-менеджмент. У великій компанії до вас приходитимуть і казатимуть: «Зроби це на завтра». Причина — у людей інший контекст. У моєму випадку це офлайновий бізнес, де рішення приймаються високо, але дуже швидко каскадуються донизу. І відповідно імплементуються швидко. «Епіцентр» вміє дуже круто й швидко будувати магазини, бо всі знають, що і як робити. Тому вони не дуже розуміють, чому їм роблять інтернет-магазин пів року. 
• У великих компаніях багато застарілої спадщини. Вам треба буде самостійно розвиватися, самостійно писати документацію і розуміти, що швидко це не буде. 
• Ненормований робочий день. 

Плюси: 

• Ресурси. У великих компаніях купа ресурсів. У вас вийде все, що хочете зробити, якщо дуже сильно не нафейлите. 
• Гроші. Великі компанії дозволяють вам будувати кар’єру. Ви завжди матимете можливість йти вище. Це важко, але компанія буде за це віддячувати. 

Я досі не знаю, як правильно працювати у великій компанії. Але за весь час зробив для себе кілька висновків.

Висновки:

• Ваша база, фундамент — власний тайм-менеджмент. Інакше ви помрете. Мій календар — це нескінченні мітинги. Якщо сподіваєтеся мати час, щоби попрацювати, забудьте. У вас на восьму зустріч, яку ви проспали, потім статус, на який ніхто не прийде. Тому шукати час на попрацювати — ваша відповідальність і обов’язок. 
• Стейкхолдер-менеджмент. Уміння розмовляти з людьми, що мають владу в компанії, — маст-хев. Серед них будуть ті, що вищі за вас або на одному рівні. І часто це виявлятимуться взаємозалежні стосунки: їм треба щось від вас, а вам — від них.
• Презентації — ваша основна мова. Щоб вирішити більшість питань, вам треба зробити one-pager. Тобто один слайд — але на ньому має бути така інформація і такий спосіб її викладення, щоб усі зрозуміли, що відбувалося на зустрічі і яким був результат. 
• Управління конфліктами. У кожного є люди, з якими не хочеться працювати. Але, можливо, причина в тому, що ви не навчилися з ними розмовляти. І це потрібно робити. Коли керуєте чимось величезним, ви вже не людина, а машина з комунікацій. І мусите зробити так, щоб із кожним вони були продуктивними. 
• Продукт будуватиме команда. А ви здобуватимете для неї ресурси. Тому ваше основне завдання — зробити так, щоб ви були не потрібні. Навчіть команду будувати процеси, що будуватимуть процеси. А ви будете погоджувати їм бюджети, забезпечувати онбординг і створювати комфортні умови 
• Делегування. Для мене став величезним відкриттям той факт, що персональний помічник робить життя дійсно легшим, а ваша команда може значно більше, ніж ви думали. Тож делегуйте і ще раз делегуйте. Так ви можете дати іншим людям зростати.

Основна ваша робота як менеджера у великій компанії — це про комунікацію. Обговорити, погодити, домовитися, уточнити, улагодити — ваш обов’язок. Тут немає нічого про метрики, моделі атрибуції та інші продакт-штуки, бо продукт створюватиме ваша команда. А ви робитимете все, щоб їй було комфортно. 

Як можна розвиватися швидше

Одразу з висновків: 

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

А тепер детальніше. Є така концепція — модель айсберга. На верхівці, яку всі бачать, — наша поведінка, те, що ми робимо. Нижче йдуть приховані від усіх аспекти нашої особистості. Спочатку — ресурси й можливості, що в нас є. Далі — мислення: як ми думаємо, щоб використовувати ресурси й діяти. І найнижчий аспект — наші цілі та стратегії. Це про те, що ми робимо й чому. 

Як ми можемо цим керувати

Є чотири точки докладання зусиль: поведінка, можливості, мислення й стратегія. Ми можемо докладати зусилля у сфері можливостей: читати книги, ходити на курси. Але найбільше мене прискорила робота саме з мисленням і стратегією. Це те, у що інвестую я та моя команда. 

Що може заважати нам прискорити розвиток

• Іти найважчим шляхом, аби бити себе в груди та розповідати про складнощі. 
• Не звертатися за порадою та по допомогу. 
• Дотримуватися тих стратегій, яких дотримувався раніше. 

У якийсь момент я декомпозував те, що вкладаю в поняття щастя. Спочатку це було про самореалізацію як продакт-менеджера. Але потім я розбив щастя на складові: роботу, родину, батьківство. І зрозумів, що моя стратегія — не шукати найскладніші шляхи, а прагнути до щастя як до кількості щасливих моментів: пробіжки з дружиною, занять із донькою, успіхів на роботі. І далі знизу я почав каскадувати, як цього досягти, — аж до моєї поведінки. 

Наведу приклади. У мене було бажання вивчити SQL, бо це корисна навичка для продакт-менеджера. Я почав ходити на курси, але не закінчив їх. Просто на продукті, де я працював у той час, це було не потрібно — розробники швидко робили запити самостійно. 

Далі я попросив розробника дати мені кілька лекцій про SQL. Я знову почав розбиратися в цьому питанні, навчився робити запити, але це забирало багато часу — від 15 до 60 хвилин. Я робив це замість дійсно важливих речей. 

Я почав думати інакше. Дійшов до гіпотези — процес значно прискориться, якщо запити робитимуть розробники, а я буду їх копіювати, змінювати й запускати повторно. І це спрацювало — тепер я за потреби модифікую запити й роблю їх самостійно — і це сильно мене прискорило. 

Інший приклад — про книги. Я дуже полюбляв читати книги, часто навіть ночами. Зрозумів: треба робити конспекти, щоб не забувати прочитане й ділитися головними думками з людьми. У якийсь момент мені стали рекомендувати книгу «Есенціалізм» — про найважливіше в житті. І тут я став мислити інакше. 

Як я почав думати

Насправді ж мені не треба читати книги — вистачить одного-двох найпопулярніших за рейтингом конспектів, щоб ухопити основні думки. І це також сильно мене прискорило. На читання книги я витрачав два тижні, а один конспект можна засвоїти за 40 хвилин. І не сильно втратити в якості. 

Нарешті, у мене була мета краще розуміти дизайнерів. Бо одного дня у своїй роботі в мене постало завдання — зробити редизайн сайту, щоби підвищити рівень конверсії. Я вирішив знайти дизайнера методом оплачуваних тестових завдань. Знайшов чотирьох спеціалістів, отримав від них роботу, зібрав фідбек від команди… і отримав відмову від інвесторів. Жодний із чотирьох варіантів їм не сподобався. 

Я пішов усталеною стратегією:

• прочитав про атомарний дизайн, зробив конспект;
• почав розбиратися з дизайн-системами, зробив конспект;
• пройшов теоретичний курс про UI/UX, зробив конспект. 

Але проблема залишилася — я все ще не знав, як хайрити класних дизайнерів. 

Тому я пішов іншим шляхом і спитав себе: чи є люди, що вже розв’язували подібне завдання? Як можна достукатися до них?

Так я звернувся за допомогою до ком’юніті продактів — і отримав три персональні консультації. 

Я навіть пішов далі й попросив одну зі спеціалістів — Даніелу Мунтян — Design Director в Parimatch Tech — зробити сліпе рев’ю дизайн-систем нових кандидатів, яких я знайшов після консультацій. Зрештою, новий редизайн було погоджено. А я за чотири години та 3500 грн отримав те, що зайняло б у мене два місяці самостійних спроб і помилок. 

Тож, як висновок, пораджу частіше ставити собі такі питання: 

• Як думати інакше, щоб вирішити завдання? 
• Чи досі працює моя усталена стратегія? 
• Хто вже вирішував схоже завдання і як таку людину знайти?