Мы занимаемся мобильной телематикой: отслеживание пользователей по GPS, контроль манеры вождения для клиентов страховых компаний и т.п. Клиенты — крупные страховщики, автопарки, логистические компании. Это не массовый, а довольно консервативный и нишевой рынок с высоким порогом входа. Например, чтобы серьезно конкурировать с текущими игроками, необходимо лет 7 работать над своим продуктом, тщательно разбираться, как правильно снимать и анализировать данные.
Модель монетизации продуктов Raxel — подписка. Причем цена напрямую зависит от количества конечных пользователей: если 50 000 клиентов страховой компании захотели скидку на КАСКО и согласились на отслеживание манеры езды, то именно за них мы и будем получать деньги. Отсюда особенность бизнеса: у нас много конечных пользователей, но ограниченное количество клиентов — а значит, к их требованиям мы относимся с повышенным вниманием.
У нас всегда есть видение, как продукт будет развиваться в следующие несколько лет, и четкая дорожная карта на два года вперед. Мы понимаем, как работает рынок и что ему нужно, знаем своих клиентов и их задачи, потому что у нас большой опыт работы как со страховщиками, так и с общественным транспортом, логистикой и т.д.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Тем не менее, задачи в бэклоге постоянно ротируются, а фича, которую планировали выпустить через год, внезапно может оказаться в спринте уже сегодня. А вот состав релиза пересматривается крайне редко — когда спринт уже запланирован, мы движемся по заданному пути. И если прилетают новые задачи, стараемся взять их уже в следующий релиз. Хотя это и не всегда получается 🙂
У нас три главных критерия приоритизации и отбора фич:
- Потенциальная выгода.
- Универсальность.
- Соответствие бизнесу и продуктовой стратегии.
Всегда есть вероятность, что крупный клиент придет с нужной ему фичей и мы возьмем ее в работу без очереди — прямо сейчас, а не через полгода. Если наша архитектура позволяет реализовать ее сразу и мы понимаем, что она принесет нам достаточный профит в ближайшие шесть месяцев, то она берется в работу. При этом мы не делаем кастомные решения под конкретного клиента, даже очень крупного, и реализуем только универсальные функции, которые могут быть полезны всем клиентам.
Запросы на них приходят либо от потенциальных инвесторов (и, соответственно, требований рынка), либо от текущих или потенциальных крупных клиентов. Требования клиентов прилетают из разных источников: прямого общения с нашими продавцами (это, наверное, основной канал), результатов CustDev (включая конечных пользователей наших клиентов), службы поддержки и крашлитики.
Если на весах лежит две фичи, которые просят два разных крупных клиента, мы будем взвешивать потенциальный профит от них на полгода вперед с учетом количества конечных активных пользователей за этот период. Когда какой-то крупный клиент говорит: «Ребята, эта фича даст нам возможность привлечь еще N пользователей», — мы сразу просчитываем потенциальную выручку (естественно, по реалистичному прогнозу, а не просто по тем цифрам, которые озвучил клиент) и принимаем решение — выполнять ли это требование и в какой срок это делать.
Еще мы отбираем фичи и продукты с точки зрения соответствия нашему бизнесу. Например, мы не станем добавлять функции для fleet management (управление автопарком) — это не наша сфера. У нас есть четкое понимание: мы — поставщик данных, а значит, должны давать понятные и простые инструменты по работе с ними.
Но главный фильтр — насколько потенциальная фича укладывается в нашу продуктовую стратегию. Мы двигаемся в сторону дизраптинга существующего рынка хардверной телематики, и когда к нам приходят запросы, связанные с любыми девайсами кроме мобильных, мы тысячу раз подумаем, заниматься ли ими — и как правило, не берем эти запросы в работу.
«Как правило» — потому что исключения тоже бывают. Например, мы сделали уникальную для рынка фичу — интеграцию с bluetooth-устройствами. Это не хардверная телематика, но и не мобильная в чистом виде, потому что по сути мы собираем данные с бортового компьютера авто. Но именно эта фича стала для нас серьезным драйвером роста: хотя это в первую очередь работа с устройствами, именно она стала мостиком для крупных игроков, которые через нее стали постепенно переходить на смартфоны.
И конечно, мы закладываем в бэклог 20% запас по времени и объемам. Хотя, как правило, оно в итоге забивается — у нас комплексный продукт, а значит могут проявляться баги, в том числе критические или массовые, и их нужно решать в режиме ASAP.
Дмитрий ведет телеграм-канал Productology.
