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

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

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

Меня зовут Саша Первухин, и я работаю в команде СберМаркета, в домене Контент, в роли владельца продукта. Вместе с командой мы разрабатываем платформу для управления всем медиа контентом. Про сам продукт я кратко расскажу чуть позже, на примерах. Что важно для данной статьи — с начала 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% на рефакторинг.

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

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