how we decide where to launch new services
The development and success of the service is influenced by how it will be launched – within an existing product or as a separate application. In this post – how we at 2GIS decide where to launch: inside or outside
Mikhail Melnikov
Product lead of the Othello service
New services are an important part of the life of large technology companies. They expand the audience, increase the frequency of use and create new monetization scenarios. They are necessary to keep up with trends and the market.
But the larger the main product, the more difficult it is to launch new products within it. They need to be integrated with existing tools and technologies, they must logically fit into the main use cases of the application and its interface. New services increase the load on the core product team and fall into the slow release cycle of large applications.
When deciding whether new services will launch within the main application or as a separate product, we weigh the pros and cons of three main categories.
Level of uncertainty. A new service is a hypothesis or a stable project
Some services naturally fit into the usage scenario of the main application. We know how to make them, and we are sure that our users need them. Others are new territory. They need to be tested, “warm up” the audience and experiment with the format.
Launch speed. Will it be faster if you run it from outside?
2GIS is a large application with many use cases and a rich interface. Integrating a new service into such an application takes more time than launching it externally. In addition, the release cycle of large applications can take several weeks, so it will not be possible to quickly release updates.
When running externally, creating and updating a working version is usually faster.
Conflicts. Does the new service fit into the 2GIS system?
More than 70 million people use 2GIS, and the new tool could impact their experience. We are assessing how the update will fit into popular use cases and whether there is a user request for it. Another important factor is monetization. It is important that the new product does not conflict with the way we interact with business partners and advertisers.
Learn more using real cases.
Case No. 1: Navigator
Navigator today is a standard tool for any online map. But it was not always so. In 2017, 2GIS had the ability to build routes, and several million people used it every month. But they could not travel along these routes – there was no navigator.
At that time, the same Yandex navigator was a separate application. We thought about whether to make our own navigator separately or integrate it into the main 2GIS application.
Level of uncertainty. Navigator is a stable and understandable product. We had a lot of feedback asking us to do it.
Better to do: in the product
Launch speed. It's faster to release a navigator outside of the main app's release cycle. Speed of development is an important factor, as it was required by a significant part of our audience.
Better to do: separately
Conflicts. 2GIS helps people find and contact companies. Building a route to these companies is one of the search and contact scenarios. Accordingly, there is no conflict with monetization and user experience.
Better to do: in the product
The decision was not easy and painful – we could have made the navigator faster outside, but other factors spoke in favor of launching inside the main application. After much discussion, we launched the navigator internally, and it turned out to be a strategically correct decision.
It fits harmoniously into the 2GIS usage scenario, into our monetization scheme and development strategy. Already in the first year, a third of the mobile audience used a navigator, now – 45%.
Case No. 2: 2GIS Pharmacies
We tried several times to add product search to 2GIS. As in the story with the navigator, this was a fairly common request from users. On the other hand, we had several million pharmacy card opens – users wanted to call to check drug availability, compare prices, etc. It seems that launching a drug search was obvious. We turned to the assessment by category.
Level of uncertainty. Tall, there was a lot to check. First, find out whether it will be possible to store and update large volumes of data efficiently. Secondly, we did not understand how the new tool fits into the usual scenario for using 2GIS – searching by companies, not by goods. Thirdly, we did not find any successful references at that time; there was nothing to compare the project with.
Better to do: separately.
Launch speed. Launching inside 2GIS would have taken more time, since we would have had to create the service using native technologies and for two platforms (iOS and Android). A separate product could be made entirely using web technologies.
Better to do: separately.
Conflicts. A tangible conflict with the main monetization model of 2GIS. We make money from attention to companies. In the new service, the user searches for products instead of companies, and this model does not work for all of our partners. In addition, product search must somehow exist with search by company, integrating into the search results, or a separate interface. To test the hypothesis inside 2GIS it would be too expensive.
Better to do: separately.
We decided to start testing in a separate project. In 3 months, we developed an application in React Native and began to “add” an audience from 2GIS to it through push notifications. In parallel with the launch, we worked with data providers to ensure timely updates.
The Pharmacy project is now closed, but it helped test several important hypotheses. Including the fact that retaining an audience in a separate product can be half as expensive as the main one.
Case No. 3: Hotel booking “Othello”
In 2022 we have developed service for hotel reservations. We had several prerequisites to go into this area:
After leaving Booking.com and Airbnb has created a free niche in the market
Every month several million users search for hotels in 2GIS
We have all the resources to quickly and inexpensively test a hypothesis and make an MVP – map, search, unique content about hotels (reviews, ratings, attributes)
At first glance, everything fits well with the main 2GIS product, but we launched Othello as a separate application.
Level of uncertainty. We didn't understand whether we could make a competitive product without the necessary expertise. We had good resources, but hotel booking was a new product for us.
Better to do: separately.
Startup speed. It was necessary to launch as quickly as possible – after the departure of Booking, the hotel booking market was redistributed among Russian companies, and we wanted to have time to occupy a niche.
Better to do: separately.
Conflicts. Of the above cases, Othello has the most serious situation with conflicts. At Othello, we make money from booking commissions – this is a completely different business model than the main 2GIS product.
Better to do: separately.
We managed to launch the MVP in two months. Othello practically does not use native tools – the service works only on web technologies. This allows us to quickly release updates almost daily, without lengthy reviews in stores.
So where to launch?
These three criteria: level of uncertainty, speed of launch and conflicts are only part of what you can focus on when deciding on launching a service. And the final decision can be based on a much larger number of conditions: from the cost of developing the main service to the complexity of its marketing.
But answering these questions and understanding the extent of their influence on your product will help you understand the fundamental pros and cons of each approach.
