Тримайте сім шкідливих порад для продактів та їхні рішення.
Коли хочеться спілкуватися, а не працювати – використовуйте фокус-групи зі своїх друзів і знайомих. Не бійтеся: Groupthink (по-українські: стадне мислення) з вами просто не може трапитися.
Ні! Якщо у вас немає можливості проводити повноцінне інтерв’ю, працювати з фокус-групою можна. Однак не варто набирати її зі своїх друзів. Найкраще запросити незалежних представників потенційної аудиторії. Запрошуйте різних людей, адже користувачі теж будуть відрізнятися. Так у вас вийде зібрати максимум інформації.
Не сприймайте фідбек серйозно. Образити менеджера з продукту може кожен. Пізніше, коли продукт буде вже запущений, клієнт побачить, що все працює. А результат – саме те, що він насправді хотів.
Ні!: Сприймайте фідбек серйозно. Навіть якщо він здається вам дурним, подібне може написати технічно неграмотний користувач надалі. Звісно, якщо відгук неадекватний, це слід обговорити із замовником. Однак постарайтеся знайти причину такого фідбеку в будь-якому разі. Визначте справжню проблему клієнта.
Тестуйте всі проблеми на повноцінному MVP. Тільки повна реалізація в залізі та коді, тільки хардкор. Ручний режим не покаже всіх помилок, а ви ж проводите тести напевно.
Ні!: тестуйте дрібні додавання вручну. Це заощадить час і сили команди набагато більше, ніж створення MVP щоразу. Потрібно тільки знайти в команду нормального тестувальника, тоді проблем не виникне.
Лайфхак для тих, хто працює з B2B-продуктами. За успішне тестування гіпотези про затребуваність розробки завжди можна видати продажі через “відкат”.
Ні!: ніколи не подавайте результати від продажів через “відкат” як успіхи в тестуванні. Це непрофесійно і незаконно. Коли-небудь усе розкриється, у кращому разі – вилетите з роботи.
Ставте акценти правильно. Продавайте фічі, а не цінності. Зрештою, даремно ви їх чи що придумували? Не пояснюйте сенс, не всім дано зрозуміти геніальне. Пощастить – розберуться на практиці.
Ні!: За кожною фічею має стояти якась цінність. Важливо робити акцент саме на друге. Ви пропонуєте не просто функціонал, код або дизайн, а вирішення якоїсь проблеми. Замовнику не завжди очевидно, для чого потрібна кнопка, скрипт тощо, тому пояснюйте йому за допомогою таких понять, як цінність, проблема, рішення і дія.
Навіть не починайте рахувати економічну модель. Розраховувати unit-економіку складно і, взагалі, ви не математик. Якщо трапиться так, що вартість застосунку в підсумку перевищить дохід від нього – проблема в клієнті.
Ні!: рахувати unit-економіку потрібно. До вас звертаються за послугою і довіряють проєкт, тому неуважно ставитися до нього не можна. Особливо – до фінансової частини. Важливо розрахувати потенційний прибуток, дохід від одного користувача або продажу. Це допоможе правильно розподілити ресурси команді та грамотно вкласти кошти клієнту.
Дайте повну свободу команді. Досить надзвонювати і писати розробникам. Уже не маленькі, самі впораються. Команду, взагалі, можна не турбувати аж до дня здачі продукту. Так, ви відповідальний за проект, але завжди може бути людський фактор.
Ні!: продукт-менеджер зобов’язаний контролювати команду. Для цього не обов’язково стояти з палицею біля дверей (хоча, якщо ваші смаки специфічні…), можна використовувати Jira, робочі столи на загальному сервері або фліпчарти. Це необхідно, щоб координувати кожного члена команди в рамках спринтів: не давати зароблятися, спізнюватися, робити щось не те.
