Нужно ли улучшать ваш онлайн-курс?

Проработав более 10 лет в различных образовательных проектах, я сталкиваюсь с типичными проблемами и задачами. Один из таких кейсов, который хочется обсудить - улучшение контента.

Когда ваш университет, школа или курс (от масштаба смысл не меняется) развивается и обрастает полезной функциональностью - это ли не повод для радости? Над добавленной функциональностью и новыми возможностями трудятся огромные команды. Посмотрите на любую продуктовую компанию - количество сотрудников растет в геометрической прогрессии относительно продукта.

Но становится ли конечный пользователь счастливее? Готов ли он платить больше за новые фичи? Готов ли он тратить время на заполнение личного кабинета или прохождение тестов для оценки CSAT?

В попытках тестировать десять гипотез в неделю, выпускать обновления и новые функции в виде тренажеров, геймификации и т.д., чтобы не отставать — или, в идеале, опережать — конкурентов, легко увлечься суматохой деятельности и стать “фабрикой функций”.

Под фабрикой функций я понимаю, когда продуктовая команда:

Все обновления могут хорошо смотреться в матрице сравнения продуктов и давать продавцам новый взгляд на уникальное торговое предложение (УТП), но все это не имеет значения, если эти функции не решают реальных проблем студентов.

Пообщавшись с коллегами, могу предположить, что отзывы о качестве и запросы пользователя по улучшениям являются главным источником идей о продукте, занимая примерно 35% бэклога продюсеров. Прослушивание звонков от отдела продаж и обратная связь от поддержки является источником примерно в 20% случаев, а конкуренты “вдохновляют” на новые функции в 15% случаях. 30% гипотез “спускаются сверху”, и часто это не связано с пользовательским опытом, и направлено на рост выручки и увеличение процента рентабельности. Это ни хорошо и не плохо. Выручка и положительная экономика позволяют больше выделять средств на продуктовые расходы.

Поэтому, если экономические и продуктовые показатели продолжают радовать вас и стейкхолдеров - возможно, не так важно откуда вы берете гипотезы роста. Но если инвестиции в продукт не оправдывают ожиданий, ошибки стоит искать не только в бэклоге продюсеров, но и в отсутствие четкой стратегии компании, плохой расстановки приоритетов, неправильном распределении ресурсов и неразработанных дорожных картах. Все это указывает на внутренние недостатки в планировании, а не на проблематичное исполнение.

Никто не собирается тратить ценные ресурсы на проекты, которые не приносят значимых результатов. Ни один product manager не просыпается утром с желанием необоснованно пересобрать преподавательский состав, переснять курс целиком и переписать всю практику. Но, несмотря на благие намерения, команды часто становятся фабриками фич. По разным причинам: давит KPI, непонятные цели и задачи, заставляют прибегать к методу “пушки по воробьям”, простое человеческое желание создать эффект бурной деятельности. Причин может быть много, и их можно объединить в следующие группы:

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

Команды разделяются для решения множества различных типов проблем, часто в одних и тех же спринтах. Это может постепенно способствовать улучшению образовательного продукта и потенциально удовлетворять несколько жалоб студентов, но без единого видения это также может привести к большому количеству частичных исправлений, которые не решают основные болевые точки целостным образом.

Вместо того чтобы команда уделяла больше внимания проверке и решению серьезных проблем, пользователи получают постоянный поток доработок и мелких улучшений по всем направлениям. Это создает ощущение прогресса в виде незначительных улучшений, которые могут казаться тем, что вы на правильном пути, но никогда полностью не решают эти проблемы с точки зрения учащегося.

Когда дело доходит до дорожной карты вашего продукта, пользователь определенно НЕ всегда прав, особенно когда он просит конкретные функции, а не называет задачу, к которой ищет решение (или работу, которая должна быть исполнена - прим.: по формулировке JTBD). Это не означает, что идеи и запросы пользователей следует игнорировать. Но это означает, что продуктовый менеджер и продюсер, в конечном итоге, должны нести ответственность за определение функций, проводить оценку необходимости того или иного улучшения. Хотя бы по матрице Эйзенхауэра.

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

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

Руководитель, обладающий достаточным авторитетом, может вдохновиться новой технологией, бизнес-моделью или отличительными возможностями конкурента. Здесь важно и лидеру и его команде сделать остановку на анализ вдохновляющей идеи. Я тоже этим грешу: загораюсь и бегом несу новое и интересное на суд команде. И тут главное, чтобы продюсеры не боялась задавать вопросы, подвергать сомнению решение, а инициатор не воспринимал всё “в штыки”. Не стоит игнорировать упражнения по расстановке приоритетов и проверке идеи.

Чтобы гарантировать, что ресурсы продуктовой команды расходуются на решение реальных проблем пользователей, менеджеры по продуктам должны глубоко изучить свой набор инструментов. Опора на некоторые из этих фундаментальных принципов внесет больше дисциплины в процесс и даст команде прочную основу для отстаивания своих позиций и принятия некоторых потенциально непопулярных решений.

Почти всё в дорожной карте продукта появилось потому, что кто-то подумал, что это отличная идея, или попросил об этом. К сожалению, отличных идей и пожеланий гораздо больше, чем времени на их реализацию. Мы не можем делать все, поэтому мы должны быть разборчивыми.

Управление продуктом было бы довольно простой работой, если бы все, что нам нужно было делать, это вносить задачи в бэклог и реализовывать их.

Существует много методологий оценки задач. Вы можете делать это в простой таблице, оценивая сложность и значимость для пользователя, соответствие стратегии компании, оценку рентабельности, а затем автоматически ранжировать. Вам не нужно выбирать идеальный фреймворк. Самое главное — использовать ЛЮБОЙ.

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

Единственный способ понять масштаб проблемы — проводить CustDev и вести учет/подсчет отзывов. Общайтесь с пользователями в чатах и лично. Интересуйтесь, какую жизненную ситуацию или проблему они пытаются разрешить, как взаимодействуют с продуктом.

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

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

Пользователь не ведет счет, сколько раз вы обновили курс, сколько “наворотов” добавили. Он просто хочет, чтобы было интересно учиться, чтобы решались его задачи, чтобы исполнялись те обещания, что вы ему дали.

Я описала лишь одну сторону процесса работы с образовательным продуктом, затронув проблему обновлений ради обновлений. Помните, что работа продуктового менеджера в онлайн-образовании по глубине не уступает и не должна уступать работе педагога.

P.S.: пишу про продуктовую работу в EdTech, ничего не продаю, но делюсь своими находками и рабочими табличками в канале Продюсер с одной “с”