Как Kotlin Multiplatform вошёл в топ-3 кроссплатформенных технологий

Кейс рассказала продакт-менеджер JetBrains Анастасия Капанина; Ваня комментирует.

Компания и специфика рынка: инструменты для разработчиков

Я работаю в JetBrains, компании, создающей инструменты для разработчиков, в команде языка программирования Kotlin.

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

Важные и необычные особенности:

• Kotlin выпускает новые крупные релизы пару раз в год; большие изменения в продукт можно вносить только в этих релизах. На новую версию пользователи пересаживаются в течение пары месяцев. «Feedback loop» для действительно важных вещей может замкнуться только через год.
• Мы очень ограничиваем сбор данных от наших пользователей, GDPR отдыхает. Доверие программистов потерять очень легко, заслужить его обратно — почти невозможно, а программисты очень не любят, когда кто-то лезет в их код без спроса. И мало того, что JetBrains в целом очень аккуратно собирает пользовательские данные, так пользователи Kotlin в 80 % случаев ещё и разрабатывают свой код там, где JetBrains долго не мог собирать данные. Работу над своим продуктом я начала в 2019 году, про retention впервые узнала в 2022.

Мы хотели сделать продукт из технологии

У меня и моего ментора Егора Толстого было сразу две задачи:

• Глобальная: дать команде «распробовать» продуктовый менеджмент [мы были первыми продактами в команде].
• Локальная: сделать продукт из технологии под названием Kotlin Multiplatform.

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

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

Проблемы старого подхода: технический фокус без приоритетов

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

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

А вот моё любимое из архива. Это структурированный список ВСЕХ проблем, которые были в нашем трекере к тому моменту, когда мы начали работать над продуктом. За несколько лет мы решили где-то четверть. Если бы команда пыталась решить всё, мы бы никогда не пришли к успеху.

Мы начали с довольно очевидной мысли — решили выбрать пользовательский сегмент, под который стоило «заточить» технологию в первую очередь. Довольно быстро стало очевидно, что границы между платформами больше всего размыты у мобильных разработчиков, и людям очень не нравится писать код под Android и iOS два раза. Но и игроков на этом рынке хватало: Flutter, React Native, Xamarin. Было непонятно, зачем людям выбирать Kotlin.

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

Мы быстро пришли к идее, что можно действовать иначе

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

Когда я проходила курс (это был аж 13-й поток), «AJTBD» находилась ещё в зачаточном состоянии. Многие теоретически здравые идеи было непонятно, как их применять на практике — например, скрипты интервью казались сырыми, и я откровенно кринжевала, задавая некоторые вопросы. Тем не менее, даже этой базы хватило, чтобы мощно продвинуть продукт вперёд.

Мы нашли задачи, которые люди решают с помощью Kotlin Multiplatform

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

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

Например, у тебя есть приложение для водителей такси, где стоимость поездки как-то хитро считается в зависимости от километража и ещё кучи факторов. И приложение должно работать в регионе с довольно слабым интернетом, поэтому ты считаешь эту стоимость у клиента на смартфоне. Будет очень неловко, если водителям с Android-смартфонами будут платить меньше, чем водителям с iPhone, правда? Хорошо бы, чтобы механизм подсчёта был общим для двух платформ.

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

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

Сопротивления не было: у нас была полная свобода действий, и команда нас очень поддерживала. Им и самим хотелось понять, так на чём им всё-таки стоит сфокусироваться и кто их пользователи.

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

Сейчас мы в тройке лидеров кросс-платформенных технологий

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

Мы перестали делать «продукт для всех», отстроили бэклог и маркетинг под задачи фокусных сегментов. Примерно через полгода после этого о технологии начали писать, Kotlin Multiplatform впервые стала появляться в сторонних опросах, о ней заговорили на рынке как о реальном использовании, подтянулись новые бизнес-кейсы.

В 2019 году про Kotlin Multiplatform никто не знал, сейчас:

• KMP в тройке лидеров кроссплатформенных технологий и растёт дальше.
• Удовлетворённость пользователей выросла на 20%.

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

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

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

Сейчас я залетаю в новый продукт и планирую пересмотреть записи ещё раз — там явно много нового появилось за год.