Введите хотя бы 2 символа для поиска по всем отраслям.
Английская лексика product management: стратегия, исследования и запуск продукта
Глоссарий объясняет английские термины, которыми пользуются команды цифровых продуктов: от product vision и исследования потребностей до user stories, метрик, экспериментов и выхода на рынок. Он предназначен для русскоязычных специалистов, изучающих продуктовую работу на английском, и помогает различать близкие понятия вроде product manager и product owner, output и outcome, launch и release. Переводы, примеры и пояснения показывают, как эти слова звучат в рабочих обсуждениях и документах.
- 100 терминов
- 10 тем
- 55 базовых терминов
- 200 примеров
Видение продукта и стратегия
Краткое описание будущего, которое продукт стремится создать для пользователей, обычно на несколько лет вперёд и объясняющее, зачем продукт существует.
План достижения видения продукта: каких пользователей и проблем он будет охватывать, как победит альтернативы и от чего команда откажется.
Состояние, при котором продукт явно удовлетворяет реальную потребность достаточно большого рынка: клиенты продолжают им пользоваться, платят за него и рекомендуют его.
Чёткое описание главной выгоды продукта для клиентов и причины выбрать его вместо других вариантов.
Конкретная группа клиентов, для которой продукт преимущественно создают и продают; её определяют по отрасли, размеру компании, местоположению или потребностям.
Структурированное сравнение продукта с продуктами конкурентов по функциям, ценам, сильным и слабым сторонам и позиционированию.
Изменение поведения пользователей или бизнес-показателей, вызванное работой команды, например сокращение обращений в поддержку или рост удержания, а не сама выполненная работа.
Аргументация, обычно изложенная в документе или презентации, объясняющая, почему проект или продукт оправдывает затраты денег и усилий, с учётом расходов, выгод и рисков.
Группа клиентов с похожими потребностями, поведением или характеристиками, например размером компании, отраслью или способом использования продукта.
Дорожные карты и планирование
Общий план того, над чем продуктовая команда намерена работать в ближайшие месяцы или кварталы и зачем, без подробного перечня каждой задачи.
Метод постановки целей, при котором команда формулирует вдохновляющую цель и от двух до пяти измеримых результатов, показывающих прогресс.
Важная точка или событие в плане — например, завершение бета-тестирования или готовность функции к запуску, — по которому оценивают ход работы.
Запланированная последовательность и даты основных этапов работы — от начала до запуска.
- dependencyсуществительноезависимость от другой задачи, предварительная работа, необходимая для выполнения задачи
Часть работы, которую нельзя начать или завершить, пока сначала не выполнена другая задача, часто принадлежащая другой команде или компании.
Крупный запланированный комплекс работ, направленный на конкретную бизнес-цель; обычно он включает несколько эпиков и нередко объединяет несколько команд.
Процесс, в ходе которого команды продукта и разработки раз в три месяца выбирают цели и инициативы, на которых сосредоточатся в следующем квартале.
Исследование продукта и пользователей
Самая простая версия продукта, которую можно выпустить для реальных пользователей, чтобы выяснить, стоит ли развивать идею дальше.
Работа по выяснению, какие проблемы стоит решать и какие решения действительно сработают, до того как команда возьмётся за разработку.
Изучение поведения реальных пользователей, их потребностей и проблем с помощью интервью, опросов, тестов удобства использования и других методов.
Мнения, жалобы и идеи пользователей, клиентов или коллег о продукте, помогающие команде понять, что улучшить.
Конкретная проблема, неудобство или трудность, с которой сталкиваются пользователи и которую продукт может решить или уменьшить.
Реалистичный, но вымышленный образ типичного пользователя, созданный на основе исследований и описывающий его цели, привычки и проблемы, чтобы команда проектировала продукт с учётом его потребностей.
Индивидуальная беседа с нынешним или потенциальным клиентом, чтобы понять его потребности, привычки и проблемы; обычно часть исследования продукта.
Краткое ясное описание проблемы пользователя, которую команда собирается решить, кто с ней сталкивается и почему она важна; его составляют до обсуждения решений.
- jobs to be doneсуществительноетеория Jobs to Be Done, задачи, ради решения которых клиент выбирает продукт
Подход к пониманию клиентов, который сосредоточен на прогрессе, которого они хотят достичь в конкретной ситуации — своей «задаче», — а не на их профиле или запрашиваемых функциях.
Все этапы и впечатления, которые клиент проходит во взаимодействии с продуктом или компанией: от первого знакомства до покупки, использования, обращения за помощью и, возможно, ухода.
Ранняя упрощённая модель продукта или функции — от бумажного наброска до кликабельного макета, — созданная для проверки идеи с пользователями до настоящей разработки.
Метод исследования, при котором реальные пользователи пытаются выполнить задачи с продуктом или прототипом, а команда наблюдает, где они справляются, сомневаются или терпят неудачу.
Требования и пользовательские истории
Краткое описание функции с точки зрения пользователя, обычно в форме: «Как [тип пользователя], я хочу [цель], чтобы [получить пользу]».
Часть функциональности продукта, позволяющая пользователям выполнять действие, например искать, включать тёмный режим или сохранять платёжную карту.
То, что продукт или функция должны делать, либо условие, которому они должны соответствовать; требование фиксируют, чтобы команда одинаково понимала, что создавать.
Документ, описывающий, что должен делать продукт или функция, для кого и зачем, чтобы команда опиралась на общий план.
Конкретные условия, которым должна соответствовать пользовательская история, чтобы команда и владелец продукта приняли её как завершённую и работающую правильно.
Конкретная ситуация, в которой человек использует продукт для достижения цели; её описывают пошагово или коротким сценарием.
Большой объём работ, который не помещается в один спринт и разбивается на несколько пользовательских историй, например поддержка нескольких валют.
Необычная ситуация, возникающая лишь на предельных границах обычного использования, например пустой список, очень длинное имя или потеря соединения во время оплаты.
Документ с подробным описанием того, как функция должна выглядеть и работать, чтобы дизайнеры и инженеры могли правильно её реализовать.
Предложение клиента, пользователя или коллеги добавить новую функцию либо изменить существующую.
Приоритизация задач
Решить, какая работа важнее и должна быть выполнена первой, а что подождёт или не будет сделано вовсе.
- scope creepсуществительноенеконтролируемое расширение объёма работ, ползучее расширение объёма проекта
Постепенный неконтролируемый рост объёма функции или проекта из-за новых требований, добавляемых после начала работы, обычно без переноса срока.
Ситуация, когда ради увеличения одного показателя приходится принять уменьшение другого, например выпустить продукт быстрее, но с меньшим числом функций.
Метод приоритизации, который оценивает идеи по охвату, влиянию, уверенности и трудозатратам, позволяя сравнивать разные предложения.
Метод приоритизации, распределяющий требования по четырём группам: обязательно, желательно, возможно и не входит в этот раз.
Улучшение, которое можно быстро и недорого внедрить и которое при этом приносит очевидную пользу, поэтому его стоит сделать в ближайшее время.
Будущие затраты, возникающие из-за упрощений в коде или дизайне, позволивших ускорить выпуск, но затрудняющих и делающих рискованнее последующие изменения, пока команда их не устранит.
Быстро рассмотреть поступившие ошибки, запросы или проблемы, оценить срочность и важность и решить, что делать сейчас, позже или не делать.
Гибкая разработка и поставка изменений
Упорядоченный перечень всей работы, которую команда продукта может выполнить, например функций, улучшений и исправлений ошибок; наиболее важные задачи стоят вверху.
Фиксированный короткий период, обычно от одной до четырёх недель, за который команда разрабатывает и завершает согласованный набор задач перед следующим планированием.
Единица, с помощью которой гибкие команды оценивают относительный размер пользовательской истории, учитывая трудоёмкость, сложность и неопределённость, а не считая часы.
Общий контрольный список условий качества, которым должна соответствовать каждая работа, прежде чем команда назовёт её завершённой: например, тестирование, проверка и документация.
Регулярная работа владельца продукта и команды над ближайшими задачами бэклога: их уточняют, делят крупные, оценивают и подготавливают к спринту.
Выпустить продукт, функцию или исправление для пользователей, чтобы они действительно могли начать ими пользоваться.
Постепенно улучшать продукт: выпустить версию, изучить данные и отзывы пользователей, а затем снова внести изменения, повторяя этот цикл.
Регулярная встреча в конце спринта или проекта, на которой команда обсуждает, что прошло хорошо, что нет и что следует изменить в следующий раз.
Метрики и ключевые показатели
Сокращение от английского key performance indicator («ключевой показатель эффективности»): один из немногих показателей, за которыми команда внимательно следит, чтобы оценить результаты продукта или бизнеса.
Числовой показатель свойства продукта или поведения пользователей, например числа регистраций в день, средней длительности сеанса или доли вернувшихся пользователей.
Единственная метрика, которая лучше всего отражает основную ценность продукта для клиентов и служит ориентиром долгосрочного роста для всей компании.
- conversion rateсуществительноекоэффициент конверсии, доля пользователей, совершивших целевое действие
Доля пользователей в процентах, которые выполняют нужное действие — например, регистрируются или покупают, — среди всех, у кого была возможность его выполнить.
Доля пользователей или клиентов, продолжающих пользоваться продуктом с течением времени; например, процент тех, кто остаётся активным через 30 дней после регистрации.
Потеря клиентов или пользователей, которые за определённый период перестают пользоваться продуктом или платить за него; часто выражается в процентах как уровень оттока.
Число уникальных пользователей, использующих продукт в конкретный день; показатель помогает оценивать размер и активность аудитории.
Частота и глубина взаимодействия пользователей с продуктом; её измеряют, например, числом сеансов в неделю, проведённым временем или выполненными ключевыми действиями.
Последовательность шагов, которые пользователи проходят к цели — например, посещение сайта, регистрация, активация и оплата; на каждом шаге часть пользователей отсеивается.
Степень, в которой пользователи начинают применять продукт или новую функцию; обычно измеряется долей целевой аудитории, которая попробовала её или пользуется ею регулярно.
Группа пользователей, объединённых общей характеристикой в определённый период — чаще всего неделей или месяцем регистрации, — которую затем изучают во времени.
Сокращение от Net Promoter Score — показателя лояльности клиентов, основанного на том, насколько вероятно, по их словам, что они порекомендуют продукт; оценка даётся по шкале от 0 до 10.
- customer lifetime valueсуществительноепожизненная ценность клиента, совокупная ценность клиента за весь срок сотрудничества
Общий доход или прибыль, которые компания рассчитывает получить от одного клиента за всё время его взаимодействия с ней.
Метрика, которая меняется заранее и помогает предсказать будущий результат, например еженедельные входы как признак вероятного продления подписки.
Эксперименты и A/B-тестирование
Эксперимент, в котором пользователей случайным образом делят на группы и показывают им разные версии страницы или функции, чтобы измерить, какая работает лучше.
Чёткое проверяемое утверждение о том, что, по мнению команды, произойдёт после изменения и как она поймёт, верно ли предположение.
Проверить с помощью свидетельств — например пользовательских тестов, данных или экспериментов, — верна ли идея, предположение или решение до дальнейших вложений.
В эксперименте — группа пользователей, которой показывают текущую неизменённую версию, чтобы сравнить её результаты с результатами группы, увидевшей изменение.
В A/B-тесте — изменённая версия страницы или функции, которую показывают части пользователей и сравнивают с текущей версией.
Признак того, что различие между группами эксперимента, вероятно, реально, а не объясняется случайностью; его оценивают относительно заранее принятого порога.
Показатель, за которым следят во время эксперимента или запуска, чтобы изменение не навредило важным параметрам — например скорости, выручке или числу жалоб.
Исходное значение метрики до внесения изменения, используемое как точка отсчёта для оценки его эффекта.
Запуск продукта и выход на рынок
Момент, когда новый продукт или функция становится доступна пользователям, вместе с запланированными маркетинговыми, коммерческими и поддерживающими мероприятиями.
Новая версия продукта, ставшая доступной пользователям, либо сам процесс её выпуска; часто содержит несколько функций и исправлений.
План того, как новый продукт или функция найдёт своих клиентов: для кого он предназначен, как будет оцениваться, позиционироваться, продвигаться и продаваться.
Период тестирования или тестовая версия, в рамках которых продукт либо функция становятся доступны ограниченной группе реальных пользователей до общего запуска.
Сделать новый продукт, функцию или изменение доступными пользователям, часто постепенно увеличивая долю тех, кто их получает.
Переключатель в коде, позволяющий команде включать или отключать функцию для некоторых или всех пользователей без выпуска новой версии продукта.
Краткий документ, сообщающий пользователям или клиентам, что нового, что изменилось или было исправлено в конкретной версии продукта.
Один из первых клиентов, пробующих новый продукт; обычно такой человек остро ощущает проблему и готов мириться с некоторыми ошибками ради раннего доступа.
То, как продукт воспринимают клиенты по сравнению с альтернативами: что это за продукт, для кого он предназначен и почему именно он лучше всего подходит этим людям.
То, как компания определяет цену продукта и структуру оплаты, например тарифные планы, уровни, скидки и пробные периоды.
Формальное решение, обычно на встрече незадолго до запуска, готов ли продукт или релиз выйти либо его следует отложить.
Постепенно вывести продукт или функцию из эксплуатации и прекратить поддержку, обычно заранее предупредив пользователей и помогая перейти на альтернативу.
Практика, при которой компания сама использует свой продукт, часто до выпуска, чтобы находить проблемы и лично понимать пользовательский опыт.
Команда и взаимодействие с заинтересованными сторонами
Специалист, который определяет, что должен делать продукт и зачем, изучает пользователей и бизнес и направляет команду разработки.
Любой человек или группа внутри компании или за её пределами, на кого влияет решение о продукте или кто может повлиять на него, например руководители, отделы продаж, поддержки или юристы.
В Scrum — человек, отвечающий за бэклог продукта: он определяет порядок задач, уточняет их и помогает команде сосредоточиться на наиболее ценных.
Состояние, при котором люди или команды согласны по целям, приоритетам и решениям и работают в одном направлении, а не мешают друг другу.
Реальная поддержка и согласие людей, чья помощь или одобрение необходимы, благодаря которым они поддерживают план, а не просто мирятся с ним.
Вежливо и с объяснением причин не согласиться с запросом, решением или сроком; также — передвинуть дату на более позднее время.
Команда специалистов с разными навыками — например из продукта, дизайна, разработки и аналитики, — которые вместе работают над одной продуктовой целью.
Передать проблему или разногласие более старшему руководителю, потому что на текущем уровне его не удаётся решить или оно становится срочным.
Официально подтвердить, что документ, дизайн или работа приемлемы и можно переходить к следующему этапу.
Короткий документ примерно на одну страницу, в котором кратко изложено предложение — например, проблема, возможность и предлагаемый подход, — для быстрого ознакомления.
Краткий регулярный отчёт для заинтересованных сторон о выполненном, следующих шагах, рисках и препятствиях.
Короткий тест: знаете ли вы эти термины?
Десять вопросов из словаря. Выберите правильное значение каждого термина и проверьте результат.
Как изучать лексику: Управление продуктом
- Учите пары, которые легко перепутать: product manager и product owner, output и outcome, KPI и OKR, epic и user story, launch и release. Для каждого термина запишите, за что он отвечает и в каком документе встречается.
- Читайте англоязычные PRD, описания релизов, changelog и материалы продуктовых команд. Отмечайте сочетания вроде ship a feature (выпустить функцию), run an experiment (провести эксперимент), hit a target (достичь цели) и get buy-in (заручиться поддержкой).
- Соберите фразы для встреч: What problem are we solving? (Какую проблему мы решаем?), This is blocked by… (Работа остановилась из-за…), The data doesn't support that yet (Данные пока этого не подтверждают). Подставляйте реальные задачи своей команды.
- Пишите user stories и acceptance criteria по типовым моделям: As a…, I want…, so that… и Given…, when…, then…. Так вы потренируете лексику требований, целей и проверяемых условий приёмки.
- Заводите карточки для метрик и экспериментов: название, определение, формула или условие измерения, пример употребления. Это помогает не смешивать, например, conversion rate, retention и engagement.
Частые вопросы
Чем product manager отличается от project manager?
Product manager (менеджер продукта) отвечает за то, что именно создавать и зачем, а также за результаты продукта на протяжении его жизненного цикла. Project manager (руководитель проекта) организует выполнение ограниченной по срокам работы в согласованных бюджете и объёме. Оба названия часто сокращают до PM, поэтому уточняйте контекст.
Чем product manager отличается от product owner?
Product owner — роль в Scrum, отвечающая за product backlog и помогающая команде в первую очередь создавать наиболее ценные для продукта решения. Product manager обычно отвечает за более широкий круг задач: стратегию, рынок, исследование потребностей, позиционирование, цену и запуск. В одной компании эти обязанности может выполнять один человек, в другой их распределяют между разными специалистами.
В русскоязычной продуктовой команде употреблять английские термины или переводить их?
Ориентируйтесь на аудиторию и документ. В обсуждении можно сохранить устоявшийся термин backlog, sprint или roadmap, если вся команда понимает его одинаково; в документации полезно дать русский эквивалент или краткое определение при первом упоминании. Важнее всего последовательно различать понятия и не подменять термин приблизительным переводом.
Какие документы product manager обычно составляет на английском?
Часто это PRD или product spec, пользовательские истории с критериями приёмки, краткое описание идеи, business case, статусный отчёт, сводка эксперимента и release notes. Обычно в них обозначают проблему, цель, способ измерения успеха, предлагаемое решение и открытые вопросы.
Как вежливо отказать в запросе на новую функцию по-английски?
Поблагодарите за предложение, уточните, какую проблему оно должно решить, и объясните приоритеты. Например: Thanks, that's useful input (Спасибо, это полезное замечание); Can you tell me more about what you're trying to do? (Расскажите подробнее, чего вы хотите добиться); It's not a priority this quarter (В этом квартале это не в приоритете). Не обещайте срок, который команда не согласовала.
Смежные отрасли
Закрепляйте лексику чтением
Тексты подходящего уровня помогают запоминать новые слова. Выберите бесплатные книги на английском:
