Вы смотрите на очередь, полную «Пользовательских историй». Ваша команда отправляет билеты каждую неделю в стандартном формате: _ «Как [Пользователь], мне нужна [Функция], чтобы [Значение]». _ На бумаге вы все делаете правильно. Вы слушаете пользователей и выполняете работу быстро.
Но вот фоновое беспокойство: несмотря на всю доставку, продукт ощущается скорее как набор разрозненных функций, чем как единое решение. Вы подозреваете, что если завтра вы удалите половину функций, ваши пользователи могут даже этого не заметить. Это ловушка «Фабрики функций» — состояние, когда вы создаете реализации, не понимая основной причинно-следственной связи.
Диагноз: провал пользовательских историй
Традиционная пользовательская история опасно ориентирована на реализацию. Предполагается, что строитель уже знает, в чем заключается решение, и ему просто нужно документировать задачу. Сосредотачиваясь на том, кто является пользователем (его личность) и на что он хочет нажать, вы игнорируете самую важную часть головоломки: трудный момент.
Демография и личности отвлекают. Знание того, что вашим приложением пользуется «35-летний менеджер по маркетингу», не объясняет, почему они его наняли. Как отмечают исследователи продуктов, возраст человека не объясняет, почему он покупает батончик «Сникерс»; иметь 30 секунд, чтобы утолить голод на 30 минут, вполне достаточно. Когда вы строите на основе ролей, а не ситуаций, вы строите для воображаемого человека, а не для реальной проблемы.
Рефрейминг: введите историю работы
Чтобы перейти от неопределенности к ясности, вы должны переключить свой словарный запас с задач на прогресс. В Advanced JTBD (AJTBD) мы заменяем историю пользователя на Историю работы.
История работы имеет определенную структуру, предназначенную для выявления причинно-следственных связей: [Когда _____ ] [я хочу _____ ] [чтобы я мог _____ ].
- “Когда ____” фокусируется на ситуации. Что является триггером? Каков контекст?
- “Я хочу ____” фокусируется на мотивации. Каково внутреннее стремление к переменам?
- «Чтобы я мог ____» фокусируется на Ожидаемом результате. Как выглядит «лучший я»?
Составив таким образом свою дорожную карту, вы перестанете гадать, какие функции нужно создать, и начнете определять, какие «хаки» ваши пользователи уже используют для достижения прогресса.
Практическое применение: задачи по продукту и основные вакансии
Одна из самых распространенных ошибок, которые допускают разработчики, — это путать Задание по продукту с Основным заданием.
- Задания по продукту (уровень 1): Это логистические задачи, такие как «загрузка приложения», «настройка профиля» или «экспорт CSV». Если они неуклюжи, вы потеряете доверие еще до начала путешествия.
- Основные задания (уровень 2). Это цели, которые на самом деле пытается достичь ваш клиент, не зависящие от решения, например «рассчитать заработную плату», «защитить мои данные» или «постричь газон».
Если ваша дорожная карта — это 90% заданий по продукту, вы создаете инструмент для обслуживания, а не для трансформации. Чтобы победить, ваше решение должно значительно лучше решать основную задачу (часто в 10 раз), чтобы преодолеть эффект 9x, когда пользователи переоценивают свои текущие обходные пути, а вы переоцениваете свои инновации.
От слепых действий к уверенности
Опираясь на интуицию, вы рискуете потерять время и деньги. Когда вы называете конкретную проблему, которую испытывает ваш клиент, ваш продукт становится для него очевидным следующим шагом на пути перехода от текущей ситуации к предпочтительной.
BHAG AI помогает реализовать это, используя AI + Advanced JTBD для моделирования этих сложных графиков должностей и циклов причинно-следственных связей за считанные часы. Мы помогаем вам отфильтровать «шум» запросов функций и выявить «сигнал» неудовлетворенного спроса.
Прекратите создавать функции. Начните добиваться прогресса.