Англійські терміни продуктового менеджменту українською

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

План досягнення бачення продукту: на яких користувачах і проблемах зосередитися, як перемогти альтернативи та від чого відмовитися.

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

Чітке твердження про головну користь продукту для клієнтів і причину вибрати його серед альтернатив.

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

Систематичне порівняння продукту з конкурентами за функціями, цінами, сильними й слабкими сторонами та позиціюванням.

Зміна поведінки користувачів або бізнес-результатів, спричинена роботою команди, наприклад менше звернень у підтримку чи вище утримання, на відміну від самої виконаної роботи.

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

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

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

Скорочення від objectives and key results: метод постановки цілей, у якому команда визначає надихальну ціль і від двох до п’яти вимірюваних результатів поступу.

Важлива точка або подія плану, як завершення бета-тестування чи готовність функції до запуску, за якою перевіряють поступ.

Запланована послідовність і дати головних етапів роботи від початку до запуску.

Робота або зв’язок між роботами, за якого одну не можна почати чи завершити до виконання іншої, часто іншою командою або компанією.

Великий запланований комплекс робіт для конкретної бізнес-мети, зазвичай із кількох епіків і нерідко за участю кількох команд.

Процес, у якому продуктові й інженерні команди кожні три місяці визначають цілі та ініціативи наступного кварталу.

Скорочення від minimum viable product: найпростіша версія продукту, яку можна випустити реальним користувачам, щоб з’ясувати, чи варто розвивати ідею далі.

Робота з визначення проблем, які варто розв’язувати, та рішень, які справді спрацюють, до зобов’язання команди їх створити.

Вивчення поведінки, потреб і проблем реальних користувачів через інтерв’ю, опитування, тести зручності та інші методи.

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

Конкретна проблема, розчарування або труднощі користувачів, які продукт може усунути чи послабити.

Реалістичний вигаданий профіль типового користувача на основі досліджень, що описує його цілі, звички й проблеми та допомагає проєктувати продукт.

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

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

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

Усі кроки й враження клієнта у взаємодії з продуктом або компанією: від першого знайомства до купівлі, користування, підтримки й можливого відходу.

Рання спрощена модель продукту або функції, від паперового ескізу до інтерактивного макета, для перевірки ідеї до повноцінної розробки.

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

Стислий опис функції з погляду користувача, зазвичай у формі: «Як [тип користувача], я хочу [мета], щоб [користь]».

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

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

Скорочення від product requirements document: документ, що пояснює, що має робити функція чи продукт, для кого й навіщо, аби команда працювала за спільним планом.

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

Конкретна ситуація, у якій людина користується продуктом для досягнення мети, описана кроками або коротким сценарієм.

Великий обсяг роботи, завеликий для одного спринту, який розбивають на кілька менших історій користувача, наприклад «Підтримка кількох валют».

Незвична ситуація на межі звичайного використання: порожній список, дуже довге ім’я або втрата зв’язку під час оплати.

Скорочення від specification: документ із докладним описом вигляду й поведінки функції, за яким дизайнери та інженери можуть правильно її створити.

Пропозиція клієнта, користувача чи колеги додати нову функцію або змінити наявну.

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

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

Ситуація, коли збільшення одного бажаного результату вимагає поступитися іншим, наприклад випустити швидше, але з меншою кількістю функцій.

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

Метод пріоритизації, що розподіляє вимоги на чотири групи: обов’язкові (Must), бажані (Should), можливі (Could) і ті, від яких цього разу відмовляються (Won’t).

Поліпшення, яке можна швидко й недорого реалізувати з відчутною користю, тому його варто зробити невдовзі.

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

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

Упорядкований список робіт, які команда продукту може виконати: функцій, поліпшень і виправлень, із найважливішими пунктами вгорі.

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

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

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

Регулярна робота, під час якої власник продукту й команда переглядають майбутні елементи беклогу, прояснюють їх, ділять великі на менші й оцінюють, щоб підготувати до спринту.

Надавати користувачам продукт, функцію або виправлення, щоб вони справді могли ними користуватися.

Поліпшувати продукт повторюваними циклами: випустити версію, навчитися на даних і відгуках та внести наступні зміни.

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

Key performance indicator: один із небагатьох показників, які команда уважно відстежує для оцінювання успіху продукту або бізнесу.

Число, що вимірює певну властивість продукту або поведінку користувачів: щоденні реєстрації, середню тривалість сеансу чи частку тих, хто повертається.

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

Частка користувачів, які виконали цільову дію, наприклад зареєструвалися або купили, серед усіх, хто мав таку можливість, у відсотках.

Частка користувачів або клієнтів, які продовжують користуватися продуктом із часом, наприклад залишаються активними через 30 днів після реєстрації.

Втрата користувачів або клієнтів, які припиняють користуватися продуктом чи платити за нього протягом періоду; часто виражається відсотком churn rate.

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

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

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

Ступінь, до якого користувачі починають користуватися продуктом або новою функцією, часто частка тих, хто спробував її чи використовує регулярно, серед тих, кому вона доступна.

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

Net Promoter Score: показник лояльності за відповідями про ймовірність рекомендувати продукт за шкалою від 0 до 10.

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

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

Експеримент, у якому користувачів випадково розподіляють між групами з різними версіями сторінки або функції, щоб порівняти результативність.

Чітке перевірюване твердження про очікуваний наслідок зміни та спосіб визначити, чи справдилося очікування.

Перевірити на доказах — наприклад тестах із користувачами, даних чи експериментах, — чи справді правильні ідея, припущення або рішення, перш ніж інвестувати в них далі.

Група учасників експерименту, яка бачить поточну незмінену версію для порівняння з тими, хто отримав зміну.

Змінена версія сторінки або функції в A/B-тесті, яку показують частині користувачів і порівнюють із поточною.

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

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

Значення показника до зміни, яке використовують як точку порівняння для оцінювання поліпшення.

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

Нова версія продукту, доступна користувачам, або дія з її надання; часто включає кілька функцій і виправлень.

План доведення нового продукту або функції до клієнтів: цільова аудиторія, ціна, позиціювання, просування й продаж.

Тестова версія або період, коли продукт чи функцію надають реальним користувачам перед повним запуском.

Робити новий продукт, функцію або зміну доступними користувачам, часто поступово збільшуючи їхню частку.

Перемикач у коді, що дозволяє вмикати або вимикати функцію для частини чи всіх користувачів без нового випуску продукту.

Короткий документ для користувачів або клієнтів про нове, змінене й виправлене в конкретній версії продукту.

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

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

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

Формальне рішення, зазвичай на зустрічі незадовго до запуску, чи готовий продукт або випуск виходити, чи його треба відкласти.

Поступово припинити роботу продукту чи функції та її підтримку, зазвичай завчасно попередивши користувачів і допомігши перейти на альтернативу.

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

Людина, яка визначає, що має робити продукт і навіщо, розуміючи користувачів і бізнес та спрямовуючи команду розробки.

Людина або група всередині чи поза компанією, на яку впливає продуктове рішення або яка може впливати на нього: керівництво, продажі, підтримка, юристи тощо.

У Scrum — людина, відповідальна за беклог продукту: визначає порядок елементів, робить їх зрозумілими й стежить, щоб команда працювала над найціннішим.

Стан, коли люди або команди погодили цілі, пріоритети й рішення та діють в одному напрямку.

Справжня підтримка людей, чия допомога або схвалення потрібні: вони активно підтримують план, а не просто терплять його.

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

Команда фахівців із різними навичками — продукту, дизайну, розробки й даних, — які разом працюють над спільною продуктовою метою.

Звертатися з проблемою або суперечкою до старшої відповідальної особи, коли її не вдається розв’язати на поточному рівні або вона стає терміновою.

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

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

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