Как не потерять ценность для пользователя при создании внутреннего продукта

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

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

Перед эти пару слов про меня.

Меня зовут Саша Первухин, и я работаю в команде СберМаркета, в домене Контент, в роли владельца продукта. Вместе с командой мы разрабатываем платформу для управления всем медиа контентом. Про сам продукт я кратко расскажу чуть позже, на примерах. Что важно для данной статьи — с начала 2020 года я работал в одном из крупных банков, стабильно входящих в TOP-3. И это не просто большой банк, а компания с серьезным продуктовым подходом. С приходом туда, я с удивлением узнал, что там более тысячи продуктовых команд. Тогда у меня в голове не совсем укладывалось как ими всеми управлять. Вторым моим удивлением было узнать, что больше половины из этой тысячи команд работают над внутренними продуктами. CRM, middle-слой для приложения, системы мониторинга, алертинга, куча инфраструктурных продуктов типа CDN, хранилища данных и т.д. Так и я в роли продакта создавал исключительно проприетарный продукт – рекламную платформу, которая помогает банку с помощью рекламных баннеров в своем же приложении продавать собственные банковские продукты. Т.е. пользователи этой платформы работали исключительно в контуре банка и других вариантов не было. Они запускали рекламные кампании, собирали статистику, настраивали креативы, A/B тесты и т.д. Платформу я запустил, и теперь банк с её помощью зарабатывает семизначные суммы в день. После этого был еще ряд корпоративных продуктов разного масштаба. 

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

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

• Внешний продукт = продукт, пользователями которого являются клиенты компании. В таких продуктах пользователи (а в случае b2b пользователь = компания) решают свои личные  задачи: ищут информацию или быстрые способы покупки товаров, играют, экономят на покупках и так далее. Такой продукт успешен, если создает добавочную стоимость. За счет этого UNIT экономика сходится, продукт масштабируется и все счастливы.

• А внутренний продукт = продукт, которым пользуются исключительно сотрудники компании. Такие продукты направлены на решение конкретных бизнес-задач конкретной компаний. Они помогают компании сократить финансовые или временные расходы, снизить риски или повысить эффективность. И в редких случаях еще и принести дополнительную прибыль. Пример внутреннего продукта с которым многие сталкивались — самописная CMS, CRM или даже ERP система.

Иными словами, внешние продукты создают ценность и решают проблемы клиента, а внутренние – решают проблемы компании повышая её эффективность.

Так, с глоссарием разобрались, предлагаю разобраться, а есть ли вообще для команды разработки и продакта в частности, разница в том, какой продукт они разрабатывают, внешний или внутренний? На мой взгляд, разница есть. Для краткости могу выделить четыре ключевых поинта:

• Степень погружения в предметную область. Т.е. когда ты приходишь на b2c продукт, то сама боль пользователя, для решения которой создается продукт, тебе с большой вероятностью понятна. Условно, все хотят быстро и выгодно получать продукты питания не выходя из дома. Или быстро и безопасно вызывать такси. А вот когда ты разрабатываешь систему автоматизированной обработки изображений, то тут обычно начинаются вопросы вида «почему всё работает именно так?» и т.д. И ответы на эти вопросы никогда не лежат на поверхности. Придётся глубоко разобраться в бизнесе компании.

• Состав команды. Например, если при создании b2c продукта зачастую в команде можно обойтись без бизнес-аналитика и разложить его функционал на CJE + SA + дизайнера, то при создании большого корпоративного продукта без BA есть большой риск упустить влияние твоего продукта, на казалось бы, сторонний бизнес-процесс. Поделюсь личным факапом — при разработке одного продукта мы упустили одну из категорий пользователей, которые в заживут лучше, если мы дадим им наш инструмент. И произошло это потому, что я не выделил достаточно времени на бизнес-анализ всех процессов в компании, а сосредоточился на наиболее приоритетных, как мне тогда казалось.

• Влияние стейкхолдеров. Здесь, на мой взгляд, ключевая разница. Ведь если в b2c ты делаешь продукт для клиента, то во внутреннем продукте ты делаешь продукт для одного или группы стейкхолдеров. И именно они будут решать, успешен твой продукт или нет. Нужно к ним прислушиваться. Например, если ты как продакт уверен что нотификация пользователей о важных событиях должна происходить через Telegram, но внутренние политики предусматривают нотификации только через рабочую почту, то будь добр сделать как нужно, а не как удобно

• Другие методы на этапе Product Discovery. Когда я только начал свой путь в создании внутренних продуктов, я уже имел опыт создания b2c и b2b продуктов. Поэтому мой привычный подход основывался на трех классических китах Product Discovery:

  • Глубинные интервью с пользователями

  • Итеративная валидация большого количества гипотез

  • Использование количественные методологий исследований

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

Но по мере набивания шишек я понял, что при создании внутренних продуктов такой подход работает не столь эффективно. Дело в том, что из-за небольшого числа пользователей data-driven инструменты не показывают статистически значимых результатов. А святой Грааль b2c продуктов – custdev – иногда может привести ваш продукт в пропасть. Почему?

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

• Потому что “боль” которую лечит ваш продукт, она не у пользователей, “болит” у компании. И проведя 20-30 кастдевов вы обнаружите, что пользователи “нарисовали” ровно тот же продукт что уже есть или с минорными изменениями.

Именно поэтому на этапе Product Discovery важна визионерская позиция продакта и голос стейкхолдеров, их глубинное понимание проблемы компании которую решает продукт и специфики отрасли в целом. Приведу личный пример: один из моих продуктов – DAM платформа. Это как аналог библиотеки, но для цифровых активов. Фоток, видео, rich-контента, иконок, pdf и тд. Ценность продукта в том, чтобы снижать стоимость хранения и обработки этих активов, а также увеличивать ценность медиа активов. Неотъемлемым атрибутом актива хранящегося в такой системе являются метаданные. Так вот, для конечного пользователя который ежедневно загружает туда контент, подробное заполнение метаданных по каждому активу – это целое наказание. Ведь нужно потратить на это время и определенные усилия. А для компании в целом – заполненные метаданные – благо. Потому что метаданные позволяют полноценно работать с этим активом в масштабах всей компании, не дублировать его, быстро найти из сотен тысяч похожих, видеть историю изменений, монетизировать и тд. Понятно, что одна из фичей подобного продукта это максимальная автоматизация заполнения этих метаданных, но всё же некое сопротивление от пользователей гарантированно. И это нормально. Так и должно быть.

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

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

Инвестируйте в UX / UI

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

Hidden text

или такой?

Hidden text

Да, к сожалению так часто бывает. И мой опыт говорит, что чтобы избежать подобного, нужно внедрять практики улучшения интерфейсов. Безусловно, хороший дизайнер в команде решит большинство вопросов, но мы сейчас говорим именно про действия продакта:

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

• Пройдите курс по UX. С каждым годом продвинутые навыки UX в резюме продакта всё больше ценятся среди работодателей, а развитый навык позволит вам оперативно подмечать работающие решения и качественно фильтровать собственные гипотезы

• Внедрите time-метрики на выполнение ключевых действий. Это поможет оцифровать удобство работы с продуктом. А как известно, всё что можно измерить — можно улучшить. Например, если твой продукт самописная CMS, то метрикой может служить среднее время на замену контента.

• Ну и самое простое — поставьте себя на место пользователя и спросите — «мне бы хотелось работать с этим инструментом каждый день?» Если ответ отрицательный, то возможно стоит задуматься над внедрением пунктов выше.

Взаимодействуйте с пользователями

Следующим важным пунктом для сохранения ценности продукта является взаимодействие с пользователями.

Как внедрить практики взаимодействия с пользователями? 

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

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

• Рассказывайте пользователям о ваших продуктовых планах и стратегии в целом. Это позволит сформировать ожидания, а также получить своевременную обратную связь пользователей? Врагов естественно в кавычках, вы же понимаете)

Не превращайтесь в заказную разработку

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

Например, 60% спринта тратится на развитие основной функциональности, 30% на улучшение пользовательского пути, и 10% на рефакторинг.

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

На этом я пожалуй закончу. Очень надеюсь, что текст выше поможет кому-то из вас, и вы сделаете действительно крутой продукт. А еще лучше если однажды в офисе к вам подойдет человек и скажет “Привет! Спасибо тебе за то, что ты делаешь наши продукты, а вместе с ними и мою ежедневную работу лучше и удобнее!”