Product management: від непоганої ідеї до доречної фічі

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

Це теж у своєму роді управління продуктами, але мова піде про інше.

Disclaimer:

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

Feature request, хороший і поганий.

Якщо продукт, над яким ви працюєте, не володіє надвужкою специфікою, чи не кожен зустрічний вважатиме своїм обов'язком надіслати вам feature request. Потрібно вміти фільтрувати їх, особливо якщо ресурси обмежені. Якщо дизайнер зі сльозами на очах буде переконувати, що вашій системі обробки даних прийде кінець, якщо не привести інтерфейс у відповідність з модними трендами, це не означає, що потрібно кидати все і робити так, щоб система нагадувала останні дослідження сера Джонатана Айва. Або навпаки: коли програміст відстоює точку зору, що користувачеві підказки не потрібні, оскільки «все і так очевидно», це не привід відмовлятися від тултипів. Взагалі, багато не дуже хороших ідей викликані професійною деформацією: UX готовий піклуватися про користувача на шкоду бізнесу, розробники воліють будь-якому інтерфейсу теплий ламповий командний рядок, деяких бізнес-хлопців взагалі нічого не хвилює, крім термінів і грошей і т. п. На це все слід робити поправки.

Наприклад, я фільтрую свіжопридумані фічі так:

• відверто слабка або небезпечна ідея, можна відразу відмовитися;
• неочевидна фіча, потрібен додатковий аналіз;
• явно корисна фіча, кладемо в беклог, виставляємо пріоритет.

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

Приклад фічі, орієнтованої на цілі:

• портувати додаток на Windows Phone, щоб він був присутній на всіх мобільних платформах

Приклад KPI-орієнтованої фічі:

• зробити блок «Кращі статті тижня» персоналізованим, щоб збільшити кількість переглянутих сторінок на кожного користувача

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

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

Перед початком розробки

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

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

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

Перевірка корисності

Існує такий антипатерн у продуктовому менеджменті: «Давайте зробимо класну фічу, а там подивимося!». У таких випадках «... там подивимося» часто призводить до «Ну, начебто все ок», чого явно недостатньо. Проблема особливо актуальна для KPI-орієнтованих фічів.

До того, як фіча розроблена і з'явилася на продакшені, потрібно визначитися, як буде здійснюватися експеримент, які дані будуть використовуватися і що буде критерієм успішності/неуспішності. Не потрібно винаходити велосипед, статистичні науки давно підготували для цього теоретичну базу, якої нескладно дотримуватися. Це стосується і A/B тестів, які є одним з найкращих способів тестування корисності фічі, і будь-яких інших способів. Не підготувавши заздалегідь дизайн експерименту, легко піддатися спокусі і притягнути результат за вуха.

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

Замість ув'язнення

Для управління продуктом немає нічого важливішого за здоровий глузд і системність. Кожне рішення має відповідати генеральній лінії розвитку, бути виваженим і розглянутим з різних сторін. Навіть ідеально реалізована і хороша сама по собі ідея необов'язково корисна в контексті продукту.