new feature for address normalization application
Hello! My name is Nikolay Gorlanov and I anonymous aspiring product manager 🙂 I want to share my first experience of working on the development of Pullenti Address SDK, which helps to normalize addresses and automate work with them in various systems.
Hypothesis: The new feature will increase the level of interest in the product
Given: Pullenti Address SDK software product, which can normalize addresses. The program can understand from a text string like “Samara, Artemovskaya, 22, 23” that Samara is a city, Artemovskaya is a street, 22 is a house number, and 23 is an apartment number.
Hypothesis: if we supplement our product with data on GPS coordinates of objects (addresses), it will be useful for potential clients. In my imagination, I imagined a store with delivery that would be able to check whether the client is in the delivery zone when entering the address in the CRM (I had previously encountered a similar problem when it was necessary to organize the delivery of documents by district).
Examples of using the GPS coordinates function
According to the Jobs to be Done (JTBD) methodology, the product must perform a specific job for the customer. I will give examples below.
Store with delivery: When a delivery manager enters a customer's address into the CRM, he wants to instantly determine the delivery zone in order to quickly organize delivery without unnecessary checks.
Logistic company: When a logistics company plans routes for its drivers, it wants to take into account the exact coordinates of addresses in order to minimize travel time and fuel costs.
Service company: The contact center operator instantly identifies the manager serving the client and the service center phone number based on the client's address information.
Automated voice recognition system: When receiving calls on the telephone line, the city district administration wants the voice-dictated addresses with information about problems in the housing and communal services to be verified and recorded in the database.
Step one: implementing the hypothesis
I proposed this hypothesis to the SDK developer. Together we identified the source of data for GPS coordinates – data from Rosreestr, which is official and accurate. A month later we managed to download this data, conducted manual testing of the new functionality. As a result, we received a new version of the program, which now had a new function – determining the GPS coordinates of the entered address.
Issues discovered and new features
During the work, we found out that not all objects in the real estate registry have GPS coordinates. This prompted us to the next step – downloading data from other sources, the first of which was OpenStreetMap (still in progress).
Hooray! My first feature is in production! The new version of Pullenti Address can determine the geolocation of an object by address. Moreover, in some cases it does it better than other geoservices. In this article I wanted to tell you about some examples.
Let's take a text line that relates to a real estate object (the address appears in Rosreestr in this form):
Samara region, Samara, Kirovsky district, 17 km of Moskovskoe highway, building 2B.
Yandex API returns the following coordinates for this address: [53.246822, 50.286252]
But the address is returned with the parameter “other”. Thus, we understand that this is not exactly the address we are interested in, but some other one. When checking, it turns out that this is the address of the Kirovsky district (apparently, some kind of middle point). The Kirovsky municipal district is too large an object to take into account the determination of coordinates.
Result of searching by text string in 2GIS (using web interface): “No exact matches. Look at similar places or change your request.”
Search result via Pullenti Address: “Selecting the current entity in the source text Quality factor: 100. Standard normalization via ToString/GetFullPath: Russia, Samara region, Samara city, Kirovsky inner-city district, Moskovskoe highway, kilometer 17, d.2B”
GPS parameter for this address in Pullenti Address: 53.27284, 50.25372
Let's check what can be found in 2GIS using these coordinates: Link to 2GIS
On Yandex.Maps: Link to Yandex.Maps
“Hints” and “Normalization” from dadata allow you to find exact coordinates (for some reason they are different for these two tools, but both versions point to the same building: 53.272839, 50.2537247 or 53.2729098, 50.253668).
Promotion, collaboration and first refusal
Great, the feature is implemented, and now it is necessary to test the hypothesis that this function is really needed by clients. After some thought, it was decided to offer the SDK function to potential clients. But where to find them? We need to look for partners! So it was decided to write a proposal for integration with a well-known CRM platform.
Before contacting the developers of this system, I checked the work with addresses inside the CRM. It turned out that there is already a built-in mechanism for normalizing addresses for the “Address” field in the client card, but it does not always work correctly. For example, when entering the address “Samara, Serdobskaya St. 8”, the system cannot find it on the map.
It turned out that the problem is that CRM searches for addresses in the OpenStreetMap database and can display it on the map. But if the address is not in OSM (as in my case), then it is not determined and is not displayed on the map. It seems that this creates inconvenience for users, especially if they work with delivery of goods or correspondence.
Our SDK can normalize addresses by breaking a text string into parts (city, street, house, etc.) and finding their coordinates. These coordinates can then be displayed on OpenStreetMap. Implementing Pullenti Address on the CRM side would eliminate the need for additional integrations with other systems, such as DaData or Yandex.Maps, which implies a higher level of convenience for CRM system users.
So, it was decided to offer integration of our SDK with a well-known CRM platform. However, the answer was: “You can make your application in the market and integrate into the product. We have an open API.” Thank you, but this is not our option yet. It was a valuable lesson – despite the fact that we had a great idea, the potential client had other priorities at that moment.
Confirming the hypothesis: in-depth interviews with clients
Now it's time to confirm the hypothesis that the new functionality will be in demand. To do this, we are looking for potential clients with whom we will conduct in-depth interviews on the possibility of using our new functionality. This will help us better understand the needs of the market and adapt the product to the real needs of clients.
If your application works with addresses and you want to optimize the process of working with them, consider using Pullenti Address SDK.
In any case, I hope that my experience and lessons will be useful to other aspiring product managers. Good luck in your endeavors and may your GPS coordinates always show you the right way!
