RoadCaptain - When product design meets growth hacking
Summary
The challenge was clear: we needed new business opportunities for the consumer facing unit at TomTom. How can we leverage TomTom's tech to build a product or service capable to generate revenue? This project is all about rapid validation, design, user-centered and strategic growth. Keep scrolling to see a breakdown of the project's story and the learnings we took along the way.
My Role
I led the Product design, being responsible for user research, idea conceptualisation, interaction and visual design for the app. Also had a lot of fun growth hacking the product during validation stage, wearing the marketeer hat to smoke test and validate there was a business opportunity behind the whole idea. I played a pivotal role in the development and expansion of the app as well.
Early Stage: Ideation and MVP Definition
Competitive Research: We reverse-engineered key players in the motorcycle navigation app market, like Calimoto, OsmAnd, and Rever, identifying gaps and revenue opportunities. This led to the validation of a rider-specific app, leveraging existing TomTom technology.
Smoke Testing for Interest: We created a fake brand, landing page and ran targeted ad campaigns on social media, generating 1,400 website visits, 598 beta signups, and a 22% conversion rate—proving market interest, in less than 2 days, with a budget under 500€.
Feature prioritisation - KANO Model: The idea was taking shape, interest was proven, but what would be the features that will make this product successful? We ran an online survey, leveraging the leads we got during the smoke test campaigns, plus some extra bikers I found on forums and Facebook groups. Trying to asses interest on a long list of features is not easy. Customers, when asked, would most likely push for having all of them in the product. However, research has proven that products with too many features tend to fail. Hence, we used the KANO model to asses the best set of features for our MVP. It helped prioritise features that would drive engagement and satisfaction, focusing on solving real-world rider problems.
User interviews - Prototype validation: We had a prototype and wanted to get user reactions. So we ran some interviews with potential users, using a UX research technique we had never used before - The Wizard of Oz, a human-computer interaction research method, which involves participants interacting with an interface that is seemingly autonomous, but is actually controlled by a human operator (the "wizard"). This allowed us to assess user experience and feasibility before developing a full technical solution. In other words, my colleague will request participants to fill out a form with the details about their next trip, while I'll be in the room next door using our unique algorithm for calculating a thrilling route for them based on the given details, with some TomTom legacy software. A minute later, I'll share the resulting route over a map with my colleague, so he could showcase the result to participant and get their feedback.
Product Validation
With the learnings from the previous stage, we crafted the very first version of the TomTom app for motorcyclists, for IOS devices. We decided to go off-brand and call it RoadCaptain, so the product nor the brand had any reference to TomTom when we started. This approach allowed us to move fast, and validate our assumptions quickly, without taking any risks that could damage our brand.
Beta testing in Australia. We chose Australia as the first testing market due to 2 main reasons:
Longer riding seasons compared to Europe (especially Northern and Western Europe);
English speaking so we can manage the app and acquisition all in English
We launched and tested a few value propositions with paid ads mainly on Facebook and Instagram, targeting an audience with interests in motorcycling. Here is how it performed:
~3% ad CTR
0.50€ ad CPC
1862 app downloads
💡Top learning: Our first users were excited about the product, but still missing some stability and key features to get them engaged.
Expansion to worldwide with organic growth. Once we validated user satisfaction and excitement about the product, we jumped into developing the Android version. Android beta program has quite some benefits compared to IOS: your app can be listed in the Google Play Store, so potential users can find it organically by searching through the store or browsing the explore section.
This turned out to be a better acquisition strategy for acquiring beta testers, as they would find our product when intentionally searching for motorcycle navigation apps. Users would come from all over the world, giving as a diversified set of insights to validate the product and its features.
💡Top learning: Investing in ASO pays back quite nicely. We managed to double the organic adquisition growth rate by improving the app name, description and assets with the relevant keywords.
Feedback loop. Since we started validating the app, we implemented an in-app chat through Intercom to allow users to contact us with their questions and suggestions. This chat has stablished as our main communication channel with our user base, also becoming the number 1 source of feedback we have for the product.
We have used this channel for customer support, user research and feature validation. Overall, our user base shows a good level of satisfaction with the direction the product is taking, even though it still doesn’t have a complete set of features and doesn’t offer a solid experience sometimes. They already started to show some love to us with their messages, what help us validate that we are close to delivering a highly satisfying experience.
We use a tool called ProductBoard to map every user feedback to the corresponding user stories they are asking for, or the bugs they are reporting. Along with this feature mapping we define a User Impact Score for every request, which allows us to separate the “Nice to have” features from the “Critical” ones. This means we make sure we follow a user-centric approach, where we prioritise our backlog based on user requests and their estimated impact. The tool also makes it handy to close the loop and notify users when their requested features get released - win, win!
💡 Top learning: We discovered a new USP by processing the comments from our user base. We received plenty of compliments about how quick and easy to use is our route planner, compared to competitors. The current experience is missing some standardised steps present in all major route planning and navigation apps. While we skipped the development of these steps for the sake of velocity, we discovered that our users found this as an advantage instead of the other way around.
Scaling and Monetization
The next key assumtion to validate next is willingness to pay for this product. We managed to gather some insights about what type of features could drive payment but a proper paywall experimentation would be needed to get harder validation on this matter. We ran a quick "buy-a-feature" survey among beta users, where our goal was to identify key features we could base our paid plans on.
Twisty roads routing (currently available as "super thrilling" in the app) represents the strongest value for users followed by flexibility and personalization features. We learned there are many different use cases when route planning, so allowing them to personalize the experience and being flexible with export/import (sharing as purpose) options can represent solid revenue drivers.
All in all, my team managed to take this project from idea conceptualisation all the way to realisation, reaching 30k monthly active user, proving there is an interesting business opportunity within this niche for Tomtom. Up to this point, we decided to set up a skilled project team behind this app to take it to the next level. To get a sense of how the project evolved from this stage check GO Ride article.
