Let's go global: как создавать продукты, которые будут востребованы на зарубежных рынках

Многие компании начинают задумываться о международной экспансии после появления первых зарубежных клиентов. В этот момент кажется, что продукту достаточно локализации интерфейса. Однако выход на новый рынок нужно начинать c с другого: сначала нужно убедиться, что решение действительно отвечает потребностям новой аудитории, а затем – заложить архитектуру, которая позволит масштабировать продукт без постоянных доработок. О том, что стоит предусмотреть в продукте с самого начала, чтобы не переписывать его под каждый новый рынок, порталу Biz360.ru рассказал продакт-лид Артур Маркарян.

Многие воспринимают международную экспансию как задачу локализации уже существующего продукта. Однако начинать следует с проверки самой идеи «на «жизнеспособность». Даже если решение успешно работает на одном рынке, это ещё не означает, что оно будет востребовано в другой стране. 

Пользователи могут сталкиваться с похожей проблемой, но решать её иначе: использовать альтернативные инструменты или иметь другие ожидания от сервиса. По данным CB Insights, отсутствие рыночной потребности является одной из самых распространённых причин закрытия стартапов: 43% компаний оказались в ситуации, когда созданный продукт не решал достаточно важную для пользователей задачу. 

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

Один из самых известных примеров того, почему нельзя просто переносить успешную модель на новый рынок – история Uber в Китае. Несмотря на глобальный успех сервиса, компании не удалось обойти локального конкурента Didi Chuxing, и в 2016 году Uber объединил китайский бизнес с Didi. 

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

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

Представим справочник товаров, в котором есть такой продукт, как Coca-Cola с разными вкусами, объёмами и упаковками. Но если мы планируем работать на нескольких рынках, сортировки лишь по этим характеристикам уже недостаточно. Ведь одна и та же банка Coca-Cola может иметь разные коды в разных странах и торговых сетях одной страны. Например, в одной сети этот товар имеет код 1, в другой – код 2, а в международной сети Walmart – код 345. При этом для бизнеса это один и тот же товар, а для системы – разные объекты. 

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

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

Следующая ошибка становится заметной уже при масштабировании. 

Часто на старте проекта работа строится «в логике Excel»: пользователи самостоятельно заполняют таблицы, каждый по своим правилам. Это работает, пока система остаётся небольшой и управляемой вручную. Но с появлением новых рынков и команд такая простота становится главным источником хаоса. 

Типичный пример – разное представление одной и той же сущности. Один написал «Пятерочка», другой – «Пятёрочка», третий – «Пятерка». Для человека и бизнеса это одна торговая сеть, для системы – уже три разных объекта. 

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

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

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

Решением становится мастер-справочник – отдельный слой данных, который сопоставляет сущности между проектами и показывает, что это один и тот же товар, процесс или объект, даже если они записаны по-разному. Без такого слоя невозможно строить аналитику на уровне всей платформы, а не отдельного клиента. Кроме того, при помощи мастер-справочников значительно легче оценивать эффективность не только продукта, но и бизнеса в целом – например, стоимость привлечения и поддержки клиента на разных рынках. 

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

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

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

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

Изначально задача выглядела довольно просто: мерчендайзер выкладывает товар на полку и делает фотографию. Затем система анализирует изображение и рассчитывает KPI по заданным правилам. Например, клиент хочет, чтобы доля его товара на полке была не менее 30%. В этом случае система распознаёт товар на фото и фиксирует фактическое значение – например, 25% – и тогда KPI считается невыполненным. 

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

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

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

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

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

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

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

Поэтому я рекомендую изначально разделять любой новый функционал на две части: 

• Первая – core или ядро продукта, которая содержит универсальную бизнес-логику, применимую для всех клиентов.

• Вторая – кастомные доработки под конкретного заказчика. 

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

Формально задача выполнена, но такое решение сложно назвать эффективным. В разработке подобные решения называют «костылями». Иногда они оправданы, если нужно быстро запустить клиента. Но если костыли становятся основным способом развития продукта, со временем система начинает терять гибкость и управляемость. 

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

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

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

Ещё одна распространенная ошибка – попытка выйти на новый рынок с тем же продуктом, который никак не адаптирован под местную специфику. 

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

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

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

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

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

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

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

Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал и страницу в «ВКонтакте».
biz360