Команда Kotlin превратила технологию Kotlin Multiplatform в продукт, вошла в топ-3 кроссплатформенных технологий за счёт изучения и выполнения правильных задач клиентов и фокуса на сегменте с помощью методологии «Advanced Jobs To Be Done».
Кейс рассказала продакт-менеджер JetBrains Анастасия Капанина; Ваня комментирует.
Все кейсы — результат внедрения методологии AJTBD
Освоить методологию в теории и на практике можно на курсе «Как делать продукт»
Узнать про курсКомпания и специфика рынка: инструменты для разработчиков
Я работаю в 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 я считаю решающим.
Это может звучать пафосно, но курс стал одной из вещей, которые сформировали меня как продакта. Долгое время меня мучил тот факт, что я «качественный» продакт, а не «количественный»: я чувствовала себя неполноценной в мире, где все принимают решения на основе данных и умеют считать юнит-экономику.
Мне доверили новую работу, я очень хотела сделать её хорошо, но не понимала «как» и хваталась за всё подряд — полезным было не всё. Думаю, без курса я бы просто сгорела от синдрома самозванца и не смогла чувствовать себя «настоящим продактом» в проекте, где практически нет данных для опоры.
Сейчас я залетаю в новый продукт и планирую пересмотреть записи ещё раз — там явно много нового появилось за год.