Компании, создающие программное обеспечение, постоянно сталкиваются с вопросом: стоит ли добавить ещё одну функцию?
И обычно ответ — «да». Когда вы умеете хорошо разрабатывать софт, хочется решить каждую проблему в мире с помощью программного обеспечения.
В Intercom мы научились ценить, где заканчиваются задачи, которые выполняет наш продукт.
Если слишком строго следовать подходу Jobs-to-be-Done, можно дойти до попытки охватить весь рабочий день клиента через один продукт.
Вы начинаете как трекер времени, добавляете выставление счетов, потом расчёт заработной платы — и не успеете оглянуться, как у вас окажется идеальное решение для очень узкой группы пользователей. Нужно научиться видеть границы вашего продукта.
Самое важное, что делает продакт-менеджер — решает, где заканчивается его продукт, и начинается продукт другого разработчика.
Если ваш продукт делает слишком мало — он не стоит даже затрат на установку, не говоря уже о цене покупки.
Если же он делает слишком много — он вступит в конфликт с уже существующим софтом или привычными рабочими процессами, с которыми пользователи уже довольны.
Это задача уровня «Златовласки» — нужно найти продукт, который будет «в самый раз».
Возьмём, к примеру, продукт для трекинга времени. В минимуме трекинг времени — это просто сумма списка чисел. Если бы это было всё, что предлагает продукт, он был бы бесполезен. Excel или Google Sheets уже справляются с этой задачей. В этот момент мы понимаем: простота переоценена. Даже самый продуманный интерфейс не спасёт продукт, который не приносит пользы.
В максимуме, трекинг времени может включать управление проектами, бюджетирование, работу с подрядчиками, выставление счетов, учёт чеков и мониторинг сотрудников. Приложения, которые охватывают столько смежных задач, наступают на территорию уже существующих решений — таких как Xero, Wrike, Basecamp, Teamwork и др.
Продукты существуют для решения проблем, возникающих в рамках рабочего процесса. У них есть точка начала и точка завершения в этом процессе. Чтобы понять, где должны находиться эти точки, нужно понять весь рабочий процесс. Разберём его на примере команды, заказывающей обед каждый день.
Если вы создаёте приложение, помогающее командам заказывать обед каждый день, рабочий процесс может выглядеть так: