Які шість типових помилок робить продакт-менеджер і як їх уникати

Привіт, мене звати Олексій, я Product Lead продукту Mailtrap в команді Railsware. Оскільки професія продакт-менеджера є наразі досить затребуваною в Україні та й на світовому ринку праці (і тенденція до цього буде тільки зростати), хотів би поділитись своїми знаннями та досвідом, який накопичував протягом шести років. Фокус зроблю на невід’ємній частині будь-якої професії — помилках.

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

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

Помилка перша. Неорганізована командна

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

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

Так само не сприяє ефективності продакт—медіатор команди. По суті, «передавальником» інформації від одних фахівців іншим. Наприклад, вимагати від дизайнера UX-гайдлайни, яких бракує інженерам. Але ваша задача — геть не в цьому, адже подібний «зіпсований телефон» затримує процеси та гальмує командну роботу.

Моя порада: створюйте неієрархічні зв’язки

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

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

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

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

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

📢 Побачимося в Києві? Купуй квитки на велику конференцію DOU Day!

Помилка друга. Інтуїція замість даних

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

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

Моя порада: вчіться ухвалювати рішення на основі даних

Сформуйте та відпрацюйте процес прийняття рішень, що базується на інформації. Це має бути чіткий алгоритм дій, який можна передавати іншим спеціалістам і використовувати як універсальний інструмент в усіх або майже всіх випадках. У нашій команді, приміром, це фреймворк BRIDGeS (але про нього трохи згодом).

Привчайте себе регулярно працювати з метриками продукту. Створіть інформативні дешборди та налагодьте процес їхнього аналізу (регулярні зустрічі, аналіз показників, пошук причин негативної динаміки тощо). Обов’язково бронюйте час у своєму календарі для перегляду аналітики щодня/тижня/місяця, щоб точно знати, що матимете можливість сфокусувати свою увагу.

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

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

Помилка третя. Перфекціонізм на ранніх етапах

Досконалість — ворог прогресу. Фраза не нова, але вона завжди актуальна для розробки продуктів. Якщо ви намагаєтеся створити ідеальний продукт вже на початку, ви прямуєте до провалу. І ось чому 👇

  • Еволюція продукту непередбачувана. Важко визначити, як виглядає «досконалість», навіть у більш зрілій версії продукту. Потреби клієнтів, ринкові тенденції та бізнес-пріоритети постійно змінюються.
  • Затримка запуску продукту йде на користь тільки конкурентам. У багатьох випадках, чим довше ви витрачаєте часу на прототипування або налаштування свого початкового продукту, тим важче вам буде зайняти своє місце на ринку. Ви лише витратите дорогоцінний час і гроші.
  • Ризикувати необхідно. Доведення ранньої версії вашого продукту до ідеалу не допоможе вам досягти довгострокових цілей. Втрачаючи з поля зору довгострокові, масштабні цілі й просто оптимізуючи те, що у вас є, ви ніколи не спроможетесь на щось радикальне.

Моя порада: почніть з неідеального MVP

Створіть MVP, який вирішує проблеми клієнтів, а вже потім розвивайте продукт на основі відгуків. Наприклад, коли моя команда взялась за розробку Calendly, у його засновника був довгий список фіч, які він хотів втілити тут і зараз.

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

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

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

Помилка четверта. Нездатність розпізнати власні упередження

Ваші упередження можуть закласти міну як вашим продуктами, так і вашій кар’єрі. Ось деякі з найпоширеніших упереджень, які допускають продакт-менеджери.

На мою думку, упередження власної точки зору є найнебезпечнішим, оскільки його легко не помітити. Скажімо, у вас є ідея щодо нової фічі, яка, за вашим прогнозом, матиме великий вплив на утримання клієнтів (customer retention). Ви хочете переконати свою команду та стейкголдерів, але спочатку вам потрібні докази. Отже, ви шукаєте запити клієнтів, проводите аналіз конкурентів та ринкових тенденцій, які підтверджують вашу думку, пропускаючи свідчення того, що ваша ідея слабка.

Хоча й ненавмисно, ми часто обираємо фічу, яку хочемо самі, а не ту, що потребують наші клієнти.

Моя порада: критично оцінюйте всі свої ідеї

Станьте справжнім захисником своїх клієнтів. Поглибте своє розуміння їхніх бажань, потреб і проблем, провівши серію CustDev-інтерв’ю та приділяючи пильну увагу запитам, скаргам і новим дослідженням ринку. Намагайтеся побачити проблему очима вашої аудиторії, а не через власну призму.

Якщо в команді виникають внутрішні розбіжності, корисно ставити себе і на місце колег. Хороші продакт-менеджери не припускають, що всі думають, як вони. Натомість, вони сумніваються у власних мотивах і активно вислуховують думки інших.

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

Помилка п’ята. Гонитва за прибутком без чіткої стратегії

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

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

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

Моя порада: не гоніться за швидкими перемогами

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

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

Помилка шоста. Занадто часто говорити «Так»

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

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

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

Моя порада: оцінюйте ідеї, перш ніж сказати їм своє «Так»

Перш ніж погодитись із чимось, варто впевнитись, що це рішення:

  • підвищить цінність продукту та користувацький досвід;
  • можна реалізувати за наявних ресурсів.

Щоб це зробити, раджу використовувати фреймворки для пріоритизації та ухвалення рішень, такі як метод MoSCoW (єдина Москоу, яка має існувати), RICE та створений нашою командою BRIDGeS. Якщо коротко, BRIDGeS допомагає нам аналізувати проблему з різних точок зору та генерувати життєздатні рішення.

Під час сесії ми використовуємо кольорові картки, віртуальну дошку та вбудовану систему пріоритизації, щоб проводити мозкові штурми й розв’язувати проблеми структуровано і продуктивно.

Ці інструменти допоможуть вам організувати ідеї з різних ресурсів, оцінити їхню терміновість та сформувати неупереджені рішення, які будуть оптимальними за наявних умов.

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

Наостанок

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

  • перфекціонізмом,
  • упередженнями,
  • браком інформації,
  • поганим плануванням.

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

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дивно, що тема «dogfooding» не розкрита, ... бігло переглянув, що у вашої компанії є 3 продукти — це щось типу сервісів тестування email, дата скрепінгу та кращого перформансу при таск-трекінгу, от, на їх прикдаді могли описати dogfooding, або хоча би як дана техніка застосовується, коли клієнт аутсорсить ваші послуги розробки.

Також для повноцінного досвіду продакт-менеджера чи розробки комплексних продуктів потрібно обирати для роботи продуктову компанію, а не сервісну — це, напевно, ключова порада могла бути.

Привіт.
Насправді не влізло про догфуддінг, але він у нас у всьому.
Всі наші продукти в цілому пішли з власних потреб.

Ми всі користуємось Coupler і багато задач по імпорту данних з разних сорсів у BigQuery зроблено через нього. Для консалтенсі пропонуємо авжеж якщо це вирішує задачу клієнта + для нас це фідбек.

Mailtrap, Coupler та декілька клієнтів відправляють листи через Mailtrap, наші продукти і клієнти користуються і імейл тестінгом.
Calendly дуже добре гарно по API для автоматизація тестування імейлів з Маілтрапом mailtrap.io/case-studies/calendly

Jira Checklist у нас основний екстеншн у джирі. Багато процесів власних на чеклістах.

>

Також для повноцінного досвіду продакт-менеджера чи розробки комплексних продуктів потрібно обирати для роботи продуктову компанію

мені здається це дуже очевидно

Фраза

коли моя команда взялась за розробку Calendly

якось магічно додає ваги цим порадам.

Підписатись на коментарі