Готуємо до запуску продукт. Чек-лист для Product Manager
«Якщо релізиш і тобі не соромно — ти релізиш пізно» — цю фразу я почула на лекції Міші Нестора ще за часів офлайн-заходів, і з того моменту часто її згадую. Постійна боротьба з перфекціонізмом, розхитані нерви, дедлайни на сніданок, обід і вечерю — приблизно так можна коротко описати запуск нового продукту у світ. Але про все за порядком.
Мене звуть Маша, і я понад п’ять років займаюся розробкою програмних продуктів. Починала в стартапі, потім була продуктова компанія і сьогодні — аутсорс. Були запуски як продуктів з нуля, так і окремих модулів у вже робочих продуктах. Досвід показав, що кожен запуск не схожий на попередній і не існує срібної кулі для вирішення (здавалося б) однакових проблем. Протягом цих запусків я колекціонувала свої граблі та фейли, а потім вирішила зібрати їх разом і скласти чек-лист, яким з радістю ділюся з вами. Упевнена, він допоможе уникнути багатьох помилок.
Ілюстрація Аліни Самолюк
Велика різниця
Я вже два роки працюю в компанії SoftServe на позиції Product Manager. Багато з вас вже пішли писати коментарі про те, що в аутсорсі не буває жодних продуктових менеджерів і що все це — вигадки. Правда в тому, друзі, що продуктові менеджери в аутсорсі існують, от тільки стек їхніх знань і перелік обов’язків сильно відрізняється від того ж набору в продуктовій компанії.
Продукт, на який я буду посилатись як на приклад — вебзастосунок у сфері e-learning, цільовою аудиторією якого є жінки з країн колишнього СНД та експати.
Ще на старті кар’єри в мене був досвід запуску вебзастосунку з кардинально іншою цільовою аудиторією, і я дійшла висновку, що запуск від запуску дуже відрізняється. Ви ніколи не знайдете ідеального сценарію колег, який спрацює для вас на 100%. Якими схожими б не були ваші продукти, вони різні за визначенням. У вас мають бути свої критерії успішного запуску і свої унікальні атрибути кожного кроку цього процесу.
Навіть саме визначення продукту буде й повинно різнитися залежно від бізнес-домену, етапу розвитку компанії та наявних елементів екосистеми: десь продуктом назвуть вебзастосунок на додачу до наявного мобільного, десь — окремий модуль для, наприклад, b2b-клієнтів, а десь це буде фіча, над якою працювали рік.
У нашу компанію звернувся клієнт із загальним описом ідеї, а ми взяли на себе всю продуктову та проєктну роботу: визначення проблеми, формування цільової аудиторії, позиціонування і візуальний стиль, монетизація, UI/UX, тестування ключових гіпотез, побудова ком’юніті early adopters, імплементація MVP і софт-лонч, підтримка користувачів і багато інших активностей.
Навіщо нам чек-лист
Я адепт мінімізації ризиків усіма можливими способами, тому якщо можна хоча б на папері пропрацювати майбутній сценарій — я зроблю це. Тут ще важливу роль відіграє стиль управління продуктом.
Я завжди намагаюся тримати в голові «велику картинку», але час від часу спускатися до деталей і опрацьовувати їх з командою або стейкхолдерами. чек-лист для запуску допомагає не забути те, що справді важливо; допомагає не тримати все в голові та звільнити оперативну пам’ять. Ще важливий плюс будь-яких чек-листів — ними можна і потрібно ділитися з командою, тому навіть якщо щось забудете, вас підстрахують колеги.
Крок 1. Критерії, ролі, планування
Отже, ви — член команди, яка готується до запуску продукту або ж самі відповідаєте за запуск. Саме час опрацювати такі питання.
Що саме означає «запуск продукту»? Здивуєтеся, але якщо вам здається відповідь очевидною, то не поспішайте з висновками. Під запуском можуть розуміти різне: наприклад, публікацію програми в AppStore, вихід на Product Hunt або публікацію коду на продакшені. Ми ж вирішили, що запуск — це публікація інформації на офіційній сторінці продукту у Facebook із запрошенням перейти на сайт.
Як ви зрозумієте, що запуск був успішним або неуспішним? За якими критеріями? Це може бути 20 безкоштовних користувачів на сайті або 30 конверсій у реєстрацію/покупку, або ж певний DAU. Варіантів може бути мільйон, але важливо зрозуміти кожен критерій успішного запуску і причину, чому саме він. Від цього буде залежати обсяг роботи та «контрольні точки» в самому процесі. Ми зупинилися на тижні після запуску без критичних багів.
У кого які ролі в запуску продукту? Розподіліть ваші завдання за напрямами: технічний аспект, підтримка, маркетинг. Обговоріть з керівником, чого він очікує від вас і що важливо вам від нього отримати. У моєму випадку був ще клієнт — замовник застосунку. Важливо було проговорити з ним усі деталі, почути побоювання та очікування, підготувати до можливих проблем і розповісти, як саме ми будемо їх розв’язувати в разі виникнення.
Які компоненти Complete Product Experience будуть потрібні в цьому запуску і чи нічого ви не забули? Є ймовірність, що не всі елементи релевантні, і це ок. Не вигадуйте собі зайвого клопоту.
Чи є у вас графік запуску? Створіть і виділіть на нього тиждень. Найкраще запускати у вівторок або в середу вранці — так у вас буде запас, щоб полагодити все, що відвалиться (можете не сумніватися, що щось відвалиться!). Час і день запуску сильно залежать від планів маркетингу, ваших домовленостей зі стейкхолдерами й користувачами та багатьох інших змінних.
Чи достатньо зустрічей з командою запланували? Якщо зазвичай у вас дві зустрічі на тиждень, то протягом тижня до і після дня Х збирайтеся щодня. Якщо запускаєте продукт в аутсорсі, заплануйте окремі зустрічі з клієнтом перед запуском (частіше, ніж зазвичай) і після запуску (обговорення результатів, очікувань і зворотний зв’язок, який отримує клієнт безпосередньо від користувачів).
Чи зі всіма документами все гаразд? Створіть папку [ProductName] Launch Documents в репозиторії документів, поділіться нею з усіма зацікавленими сторонами та вчасно оновлюйте її.
Що буде, якщо цей крок пропустити?
- Непорозуміння між учасниками процесу про те, що таке запуск і коли він повинен статися.
- Розрізнені дії команди — в результаті деякі завдання можуть бути покриті двома людьми, а деякі не будуть покриті взагалі.
- Відсутність фокусу у всіх учасників процесу.
- Різне сприйняття успіху і завершеності (для вас ви вже запустилися, а для стейкхолдерів — ще навіть не почали).
Крок 2. Продукт
Важливо: уникайте Edge Case Trap — ви не зможете врахувати всі нюанси та проблеми перед запуском, не намагайтеся покрити абсолютно всі деталі користувацьких сценаріїв. Понад те (сюрприз-сюрприз) — запуск потрібен, щоб збільшити їхню кількість.
Переконайтесь, що:
- Ваш реліз заплановано коректно, і немає жодних проблем з таймінгом з боку технічної реалізації.
- Усі види тестування відбулися успішно (тут у кожного своє definition of «успішно»), продакшн-середовище готове до релізу, а сервер — до очікуваної кількості користувачів.
- Ви підготували продукт для аналітики, проставили всі теги/івенти, переконалися що дані прилітають і зчитуються коректно.
- Всі потрібні інтеграції протестовані й працюють без збоїв (платіжна система / email-сервіс / авторизація тощо).
- Немає проблем з User Flows, які б заважали донести ключову цінність продукту (читаємо про Edge Case Trap ще раз).
- Soft launch пройшов успішно, ви усунули критичні помилки й неточності.
- Роадмап продукту на найближчі
3–6 місяців у вас під рукою — стейкхолдери, партнери та користувачі будуть вас питати про плани. - Ви узгодили з клієнтом (у разі запуску продукту в аутсорсі), хто і на які поштові скриньки заводить акаунти на всі необхідні сервіси, створили окремий документ з усіма паролями/логінами.
Що буде, якщо цей крок пропустити? Ключовий компонент продукту не буде реалізований технічно або буде реалізований некоректно — як наслідок, ви не донесете цінність своєму користувачеві.
Крок 3. Юридичні моменти
Перевірте, чи готові:
- Розділ у вашому продукті (як правило, це футер), де будуть «жити» всі документи та сертифікації, необхідні для роботи в бізнес-домені (якщо такі необхідні). Їх оформлення може тривати довше, ніж планувалося, тому подбайте про них заздалегідь.
- Політика конфіденційності та публічна оферта — маст-хев для будь-якого digital-продукту. Текст може скласти юрист, а можете й самі з командою — це залежить від вашої фантазії та ресурсів.
- Відповідність GDPR — потрібна, якщо ви працюєте з персональними даними користувачів на території ЄС.
- Усі документи, що підтверджують ваше право інтелектуальної власності на торговельну марку, слоган або інші елементи вашого бренду — не критично, але дуже бажано мати в момент запуску.
Що буде, якщо цей крок пропустити? Репутаційні ризики, непотрібні нікому проблеми з контролюючими органами та подвійні/потрійні витрати на їх вирішення. Це саме той випадок, коли скупий платить двічі (навіть тричі).
Крок 4. Маркетинг
Переконайтесь, що:
- Дата і час запуску обрані й озвучені всім, хто хоча б мінімально причетний до маркетингових активностей. Вивчіть анонси конкурентів і/або заходи вашого домену — важливо не загубитися на їхньому фоні.
- Готова go-to-market стратегія (передбачається, що раніше ви вже попрацювали над аналізом конкурентів / SWOT-аналізом / позиціонуванням / персонами / value proposition / бренд-буком та іншими компонентами GTM-стратегії).
- Комунікаційна стратегія також готова і вже в процесі імплементації — користувачі чекають запуску, а команда розуміє, коли він станеться. Не повторюйте тут мою помилку і робіть дві версії: для зовнішнього використання (користувачі та партнери) і для внутрішнього (клієнт, стейкхолдери, команда).
- Готовий контент-план для різних каналів комунікації, а також сам контент (дуже бажано мати в запасі матеріалу на тиждень уперед — тексти, віжуали, відео).
У моєму випадку ще були створені закриті ком’юніті двох сегментів користувачів, з якими велася окрема робота в період софт-лончу і запуску продукту.
Важливо: переносити запуск продукту — нормально. Краще перенести, ніж запустити в суперневідповідний момент і без ключової цінності користувачеві. Не менш важливо коректно та вчасно це озвучити всім без винятку стейкхолдерам і зовнішньому ринку.
Що буде, якщо цей крок пропустити? Про ваш продукт дізнаються не вчасно, не ваша цільова аудиторія і не те, що ви хочете донести.
Крок 5. Сапорт
Впевніться, що ви підготували FAQ для користувачів на основі зворотного зв’язку бета-користувачів після софт-лончу і реліз-ноутс. Будь ласка, використовуйте людську мову без технічних термінів.
Якщо є можливість, створіть кілька how-to відео з демо ключових сценаріїв використання. Не варто витрачати на це багато часових і фінансових ресурсів, тому що незабаром продукт зміниться і доведеться знову все міняти.
Переконайтеся, що користувачам є куди відправляти фідбек. Найпростіше — це додати email з ім’ям типу support@yourproductdomain.com і виділити людину для роботи з ним. Є безліч рішень на ринку, які легко інтегруються в будь-який продукт і допомагають оптимізувати збір і обробку зворотного зв’язку (Intercom, Crisp Chat, Tidio etc.).
Що буде, якщо цей крок пропустити? Усі раніше докладені зусилля будуть зведені нанівець, якщо не буде кому відповідати на запитання користувачів або сапорт не знатиме, як розв’язати проблему.
Крок 6. Роадмап запуску
На базі вищеописаного створіть свій роадмап запуску і визначте, на якому етапі перебуваєте зараз. Так буде значно простіше планувати своє і командне навантаження, а також визначати пріоритети. Ділюся з вами однією з перших версій свого шаблона, який можна (навіть потрібно) кастомізувати під власні потреби.
Ready, steady, go!
Якщо всі вищенаведені пункти виконані, ви готові до запуску. Мій чек-лист не є вичерпним і може бути доповнений іншими активностями залежно від того, який саме продукт ви запускаєте, з якою метою, на якому ринку (з погляду і бізнес-сегмента, і геолокації), хто бере участь в процесі, які наслідки може мати цей запуск тощо.
Неможливо підготуватися до всіх невдач, але можна їх мінімізувати. З моїх найнеприємніших фейлів на етапі запуску продукту я виділю два: я забула додати форму збору NPS і випустила з уваги важливість коректно оформлених release notes. Це коштувало мені нервів і допилювалося на ходу, але момент був утрачений.
Використовуйте стратегію fail fast (якщо це дозволяє специфіка вашого продукту) і пам’ятайте, що ваші фейли — це скарб.
Успіхів!
