Product Management Debt

Вже багато людей знають про Technical Debt.

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

🗒️ Наприклад:

• Зробили "хотелку" топ-менеджменту не проаналізувавши ринок й аудиторію, а тепер підтримуємо цю частину функціонала, хоча їй користуються всього 2 відсотки від нашого юзербейсу.
• Пішли на компроміс з дизайн та технічною якістю, щоб швидше заделіверити щось -> тепер треба думати як обходити ці обмеження системи й думати, як зробити ваші нововведення робочими для попереднього рішення.
• Дуже довго фокусувалися на зворотньому звʼязку користувачів й зовсім забули про довгострокові цілі. Як результат, програємо нашим конкурентам у завоюванні нових сегментів ринку.

❓Задавайте собі періодично наступні питання

• Що можна видалити з продукту?
• Чим користувачі вже не користуються?
• Чи який вже наявний функціонал треба переробити, бо він не зручний?
• На який функціонал ми витрачаємо найбільше часу на його підтримку?

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

📈 Як запобігти появленню боргу?

• Періодичні рев’ю продукту, роадмапу та беклогу на предмет, чи дійсно наші дії відповідають нашим планам? Додавання часу на вирішення цих проблем до майбутніх спринтів.
• Документація рішень. Коли те чи інше стратегічне рішення приймається, треба зробити документ в якому описані причини та саме рішення.
• Стратегічне планування. Процес довгострокового планування, не до деталей, але хоча б до напрямку.