Продакт-менеджери першими знаходять болі користувачів, та роблять все, аби їх позбутися, та вдосконалити продукт, з яким працюють. Однак вони й самі мають чимало складних моментів у роботі: нечіткі посадові інструкції, відповідальність за команду, невизначеність на шляху до ідеальних показників та інше.
Про найбільш розповсюджені болі продакт-менеджерів розповідає Борис Куликовський, Product Manager у Keiki. Борис має чотири роки досвіду в продакт-менеджменті, розпочинав карʼєру з edtech-продуктів. В Keiki прийшов зі стартапу, де був кофаундером та займав позицію продакта.
Будь-хто з продуктової команди може прийти до продакт-менеджера з ідеями. В ідеалі треба не просто запропонувати зміну, а й пояснити, навіщо вона потрібна і чим буде корисна. Проте часто люди приносять «сирі» ідеї в форматі «а давайте додамо ще один екран». Коли я починаю розкручувати думку й ставити навідні запитання, виявляється, що гіпотеза не збігається з бізнес-цілями або не приведе до очікуваного результату.
Я займаюся вебпродуктом, де після першої покупки юзеру показуються екрани з апсейлами. Нещодавно один з членів команди запропонував збільшити delay для показу цього екрану на 10 секунд. Мовляв, тоді користувач трохи краще познайомиться з продуктом та зрозуміє, чи потрібні йому апсейли. Однак після обговорень ми зрозуміли, що за 10 секунд юзер не встигне дізнатися нічого суттєвого.
Крім того, специфіка продукту така, що користувач після покупки має скачати матеріал, щоб почати взаємодію з застосунком, тож він не повертається у вебкабінет певний час. Відповідно, у нас є декілька секунд після для апсейлу — поки юзер знаходиться на туторіалі й тільки знайомиться з функціоналом.
Переконати продакт-менеджера реалізувати свою ідею допомагає апеляція до найсильніших конкурентів («Вони нещодавно реалізували ось таку фічу, давайте теж спробуємо») або Customer Development, коли ми знаємо, що користувачів зацікавлять нові зміни.
Уявімо, що ми плануємо додати ще один екран з опитуванням на онбордингу користувача, аби краще кастомізувати контент у застосунку. Однак, це може як збільшити залучення, так і спричинити обвал цієї метрики. Тест може бути як успішним, так і не дуже — і з цим нічого не поробиш.
На початку це може демотивувати: тобі здається, що ідея класна, ви всією командою з ентузіазмом над нею працюєте, а результату немає. Однак невдалі тести — це така ж частина робочого процесу, як і інші завдання. Важливо вчасно відмовлятися від неробочих ідей та рухатися далі, а не пояснювати собі та іншим, чому все мало працювати інакше.
Продакт-менеджер краще за інших розуміється на потребах бізнесу, тому його завдання — визначити, куди рухається команда, над чим варто працювати зараз, а що можна відкласти на потім. Інакше кажучи, розробити стратегію, або, як мінімум, сформулювати план дій і цілі.
Буває так, що сам продакт не знає, який напрям виявиться успішним — треба просто пробувати. Водночас це не знімає з нього відповідальності за роботу команди. У людей виникатимуть питання — під час чи після реалізації змін — і продакт має знайти релевантні відповіді, аби мотивувати тих, хто з ним працює. У подібних випадках можна «поділити» відповідальність і чесно зізнатися, що ви робите щось уперше разом з усіма, і поки не знаєте, що буде далі.
У книзі «Мислення швидке й повільне» Девід Канеман наводить історію про пожежників. Вони увійшли в охоплене полум’ям приміщення, й раптом їхній керівник закричав: «Йдемо звідси!». Щойно пожежники вибігли, підлога під ними обвалилася. Як виявилося потім, пожежа виникла поверхом нижче, у підвалі. Керівник одразу відчув небезпеку, проте у моменті не зміг пояснити, в чому вона проявлялася. Лише потім він усвідомив, що спека в приміщенні не співвідносилася з силою вогню.
У продакт-менеджерів бувають схожі ситуації. Data-driven підхід дуже важливий, але іноді ти на 100% впевнений в успішності рішення, відповідних аргументів бракує — і їх доводиться винаходити. Таке трапляється, коли, наприклад, треба протестувати нове позиціювання, а грошей і часу для повноцінного, статистично значимого тесту нема. В такі моменти доводиться ухвалювати рішення на інтуїції або, як ми говоримо, «на чуєчку». Чим більше досвіду та надивленості, тим більше подібних рішень будуть вдалими.
Втім, зловживати не варто. Я завжди намагаюся знайти пояснення, що ми робимо, та чому. Тоді, якщо тест спрацює, ми зможемо масштабувати результати, а якщо ні — зробити відповідні висновки та уникнути помилок у майбутньому.
Під час custdev я можу запланувати собі на вечір десь п’ять інтерв’ю з юзерами. Скасовую всі інші зустрічі, підлаштовую плани, припускаю, якими будуть подальші кроки. А в результаті жоден не приходить на зустріч — хтось забув, у когось важливіші справи тощо. І це боляче. Та треба розуміти що це теж частина процесу. Для того, щоб мінімізувати такі кейси, перевірте воронку, за якою юзер реєструється. Можливо, з нею щось не так — і користувач хоче прийти, але не може.
Я багато працював зі стартапами, які ще тільки шукають Product Market Fit або щойно знайшли й намагаються масштабуватися. На цьому етапі у вас тільки формується чітке уявлення про юзерів — хто вони, чим займаються, що їм подобається тощо. Це, по суті, експерименти, і, відповідно, результат, який важко або неможливо спрогнозувати. Далі, коли з’являється краще розуміння ринку та більший обсяг даних, стає простіше.
Якщо продакт-менеджер недосвідчений, йому також буде важко спрогнозувати метрики чи фінансові показники, до яких приведе та чи інша зміна. Втім, з досвідом вам уже простіше пояснювати команді свої рішення. Ідеально, щоб змін, які ви не можете спрогнозувати ставало менше, ніж тих, які можете.
Щодня продакту потрібно ухвалювати з десяток різноманітних рішень. Деякі з них прості та майже непомітні, як-от, перефарбовувати кнопку в інший колір чи ні. Деякі — комплексні та складні, наприклад, чи потрібно зараз виходити на ринок Латинської Америки. Останні можуть визначити успіх (чи поразку) на роки вперед. Ставки високі — і рівень стресу також.
Часто нервове напруження спричиняє страх помилки: якщо гіпотеза буде невдалою, є ризик втратити довіру та авторитет. Однак якщо ви оберете шлях продакт-менеджера, ухвалення рішень та перевірка гіпотез стануть вашими щоденними робочими тасками. Тому уже на старті варто усвідомити: від помилок нікуди не дітися. Набагато важливіше, які висновки ви зробите. Я ділю невдачі на помилки й факапи. Перші робляться через незнання, другі — уже траплялися й повторюються постійно. Відповідно, варто приймати помилки та уникати факапів.
Аби ухвалювати рішення швидше, я виділяю для себе декілька ключових принципів, які важливі для бізнесу просто зараз. Наприклад, чи принесуть конкретні зміни прибуток? Якщо на даному етапі гроші важливіші, всі рішення потрібно розглядати через цю призму. Можна зробити собі декілька подібних принципів, і вам буде простіше.
Потрібно знайти Product Market Fit і розібратися з метриками? Чи треба ще й налагодити процеси та синхронізувати між собою усіх стейкхолдерів? У підпорядкуванні буде один розробник чи потрібно буде керувати цілою дев-командою? На старті продакт-менеджер має домовитися про те, чим він займатиметься в продукті чи бізнесі. Інакше кожен крок потрібно буде постійно проговорювати або серед тасок з’являтимуться додаткові завдання — а це боляче.
У продакт-менеджерів можуть бути різні обов’язки. В одних бізнесах вони фокусуються на прибутку, тестують безліч воронок та роблять так, щоб сходилася юніт-економіка. У інших половину робочого часу займає управління ресурсами: поставити ТЗ розробникам, оцінити час на завдання, оптимізувати роботу QA-інженерів та дизайнерів. Обидва напрями можуть уживатися в одній компанії й навіть конкурувати між собою. Трапляються вакансії, де продактам треба відповідати й за гроші, і за процеси, але одній людині буде важко показати якісний результат за таких умов.
Одне з завдань продакт-менеджера — скласти технічне завдання, за яким діятимуть розробники, коли будуть реалізовувати конкретну ідею та оцінити терміни виконання завдання. Щоби ґрунтовно описати суть завдання та сформулювати чіткі acceptance criteria, продакту потрібно набити руку. Інакше стається так, що розробник зрозумів завдання неправильно, деталі не узгодили — і на виході виходить зовсім не те, що очікувалося. А це призводить до зірваних термінів або конфліктів в команді.
Must-have у подібних випадках — чіткі ґайдлайни для постановки завдань та acceptance criteria. У себе в команді ми випрацювали детальні шаблони, якими мають користуватися всі стейкхолдери, якщо чогось хочуть від розробників. Крім того, ми послідовно доносимо думку: коли є навіть мінімальні сумніви щодо того, як виконувати завдання — краще не соромитися та перепитати. Декілька набитих шишок — і ви вже знаєте, де слабкі місця у командній комунікації.
Інший челендж — підтримувати уже відпрацьований механізм. Буває так, що всі про все домовилися, ТЗ гарні, acceptance criteria чіткі, але якесь завдання оформили пізніше, ніж потрібно — і процес поламався. Не те, щоб це критично впливало на продукт, але на «ремонт» доводиться витрачати додатковий час та ресурси.
