The first experience of developing our own product
High-quality product development processes must be based on a solid methodology. We refine our methodology as we develop our products, such as Booklet Estate. We know the market problems from within because we cooperate a lot with real estate agencies and have developed a lot of products in this domain. Many agencies in the Ukrainian market actively work with public sources to find properties for their clients. They need to offer the object to the client as quickly as possible because a great offer immediately gets on the radar of other agents. The real estate agents prepare presentations with a description of the object, its photos, parameters, and contact information.
Creating a presentation for each property is a long and time-consuming process because the agent must present unstructured information in a client-friendly way. One agent needs to make several presentations daily, sometimes dozens of them. Knowing this problem, we decided to create a product that would make the work of such real estate agents more effective. We have successfully solved this problem for over 1000 real estate agents, many of whom successfully use our product every working day.
Booklet Estate was our first in-house product. We chose real estate because we had domain expertise in this area due to our collaborations in this field. The best way to understand our clients' problems is to put yourself in their shoes. Like every entrepreneur, we formed a first product concept and determined how to solve the users' problems. We did a rough P&L and made sure the product would be profitable. We chose a subscription business model with a trial period.
In the beginning, we set ourselves a not-so-complex task: to create an innovative product that allows every realtor to quickly prepare a good presentation of property (residential, suburban, or commercial) for their client, having only a link to the ad with the property.
Even though the domain was not new to us and our company had spent more than 10,000 hours on real estate industry products before the start of this project, it was tough to make decisions. No matter how constructively we organized our work, each decision took a lot of time, as much as we never did with a particular client.
Examples of questions we were looking for answers to
How much data do we need to know about the product's user?
Attracting the user to such a product is difficult. It's essential to make retargeting possible if we can involve a client.
How do we need onboard users who don't understand the sense of the product from the very beginning?
We conducted demonstrations of the product before its development. Sometimes, even in personal contact, we couldn't explain the value of a product to lead.
What exactly should the presentation design be and why?
At the idea level, we weren't sure whether we were aiming more at companies with a low average check or more at the high-end segment. Therefore, it was unclear how much we had to work on the visual part of the presentation.
What kind of subscription has to be? Do we need promo codes? What is the duration of the subscription period?
We understood that in the beginning, we would have mistakes, and interested clients must behold. The refund is an unwanted process in an operational sense. That's why we need to use other instruments to resolve the problem.
How to protect the product from abusing trial accounts?
We were not going to collect credit card details up-front on a free trial or verify users in another way. So, we wanted to protect the product from unwanted resource usage.
Same as working with our clients, first, we formulate goals. They look like:
The product has to show the value of correct presentation of real estate objects and explain benefits of quick creation of presentation in PDF.
The product has to do its job: generate an attractive and personalized presentation of an object quickly and without errors. The product receives as input only an URL to an ad on a public site.
Creating a presentation takes into account the features of most users because real estate agencies build quite different working processes.
Detecting product goals wasn't easy cause it was first when we had to decide by ourselves, which usually our clients make. We faced with same problems as our clients at the start of creating a concept. If goals are not formulated specifically, the product will direct in the wrong way, and the product could not reach the desired level of profitability. Thinking through goals, we had to comprehend functionality: what should they be, do we need them, could we make them quite well according to our budget.
Who did we develop the product for?
An independent real estate agent wants to gain more trust from new clients through quality presentations.
An employee of a real estate agency wants to increase the interest of their clients in their own services and increase conversions through the quality of materials sold.
The owner of a real estate agency wants his colleagues to spend more time directly communicating with clients, rather than making presentations.
In this process, we formulated the product tasks. These requirements we defined as essential:
The main page explains our vision of a real estate presentation. We show our solution's advantages and motivate the lead to try our decision free.
To increase the conversion into the registration, we ask for a minimum of information from the client, just email and password. Also, the user can enter optional fields "Name" and "Phone." We explain that we'll use this data to add contact information to the user's PDF presentations.
After registration, the user can take a tour of the service. • We show the process of creating a presentation and a result, an attractive personalized PDF presentation ready to send to the client.
During the trial period, the user gets used to the product and can build it into their business process.
The product is resistant to user errors and problems with data sources. The user can copy an URL to an object page from the site incorrectly, the target site may be inaccessible, or the page may be deleted.
After making significant decisions about product features, we wrote the formal requirements. In the process of requirement development, it was difficult to choose between “I want to make the product better” or “it's enough to test a hypothesis.”
Examples of problems with Decision making
Let's look at the page with real estate objects and materials received from the site. Here are our thoughts after defining the list of real estate fields:
The presentation structure assumes several photo displays, assuming an approximately equal aspect ratio of all images. Users' photos are often different in that sense.
- Is it worth cutting photos? If yes, for how many percents maximum?
- Do we need to give the ability to create the first beautiful collage of 4 rectangular landscape photos? What if we lose a sequence of images and show the bathroom and storage room at the beginning?
- Do we need to give users the ability to organize photos by themselves? Then how do you teach him that they can move photos?
We defined that the description can be up to 800 characters for a nice presentation.
- Do we need to notify a user if the description is too long? What do we need to advise him if the description cannot be shortened?
- Is it possible to cut some text from source data? For example, information about the ad's author on the website?
- Is it worth changing the font size to smaller in a presentation? How comfortable will it be to read it, and if so, to what size can it be reduced? And how to determine the font size for PDF from the text?
- Do we need to notify the user if the "Price" field contains a not-a-number value? Do we need to have that data in number format for some analytics?
- Some fields couldn't contain long text by presentation design. Do we need to notify a user about this, or it's not worth his attention?
- How to generate the presentation title? We can take it from the page title (in this case, we need to cut out prefixes like "Rent an apartment"), you can do it yourself by gluing important characteristics (object type, area, street), you can search for a relevant data field on the source site. How to make sure of the quality for the user?
Main page user flow
We solved the technical issues much more successfully. We chose our regular stack for the back-end: Python as the programming language, Django for the API, asyncio for data collection. We had no experience in modern frameworks then, so we solved the front-end tasks with jQuery with a few open-source solutions. Some tasks gave us a new experience. When testing the payment aggregator, we realized it was worth connecting another one immediately because some payment services may not be available to the first users. Thus we provided our users with the maximum number of ways to pay for a subscription.
At last, the main page passed testing by the target audience (fake landing page) service tour was tested to the smallest detail on all browsers and supported devices. Getting data on all sites works stably, and our customers rate the design of the presentation as worthy. Payment systems are linked, legal issues have been resolved, leads have been collected, and we are ready to open the service to the public.
BookletEstate's experience has given us a better understanding of our clients' businesses. We keep continuing to develop BookletEstate. Two years after launching, we plan a new release with broad functionality and a new design. We also plan to create our own products in the future.
The main results of the product for the first year are:
Used the product500+
real estate agents sent at least one presentation made in our service
Received feedback from100+
Many of them were glad not just to share feedback about the product but to tell about their market and routine working problems
Generated the test presentation25%
of site visitors have generated the test presentation, which is available right before registration
Used each function15%
of registered users used each function of the product.