Те, як ви організуєте свою продуктову команду, критично впливає на ваші результати. Наприклад, якщо ваша команда організована за “інтерфейсами”: мобілка, сайт, то і розвиває продукт вона так само, окремо мобілку, окремо сайт.
Сьогодні розповім, які є способи організації продуктових команд, а ви зможете обрати, який підходить саме вам.
(◕‿◕) Ми у Telegram: Анонси нових статей та бонусні матеріали
- Варіант 1. За окремими продуктами. Наприклад, ви працюєте у Гуглы у вас є кілька продуктів, кожному з яких ви формуєте виділену команду: “новини”, “погода”, “стрічка”.
- Варіант 2. За функціоналом. Припустимо, ви працюєте в Notion і у вас є команда, яка займається функціоналом ‘page’, ‘kanban board’, ‘table’.
- Варіант 3. За сегментами клієнтів. Припустимо, ви працюєте в Яндекс Їжу, і команди продукту у вас організовані за групами користувачів, з якими ви працюєте: клієнти, ресторани і кур’єри.
- Варіант 4. За проблемами користувачів. Уявіть, що інтернет-магазин, припустімо, Lamoda, вирішив сфокусуватися на проблемах своїх користувачів і створив відповідні команди “зменшення кількості повернень”, “збільшення асортименту”, “поліпшення якості доставки”.
- Варіант 5. За етапами воронки/життя продукту/value chain. Наприклад, ви працюєте в ed-tech проєкті й організували свої продукти так: конверсія в перше замовлення, у друге, у п’яте, у десяте. Або ж так: залучення, активація, друга покупка, зростання LTV.
- Варіант 6. За інтерфейсами. Припустимо, ви розвиваєте сервіс пошуку авіаквитків Skyscanner і у вас є команда мобільного застосунку та десктопу.
Варіанти 1-5 допустимі й кожен має свої плюси та мінуси. Вони не універсальні, а залежать від продукту, про який ідеться.
Варіант 6 – проблемний, оскільки призводить до неконсистемності продукту. Він припустимий у всіляких продуктах під “замовну розробку”, коли продуктовий беклог формується з потреб клієнтів, які найбільше платять, і перед вами стоїть завдання утримувати їх, а не будувати консистетний продукт.
