Booklet
Estate

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

Product goals

Same as working with our clients, first, we formulate goals. They look like:

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.

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?

Data validation

• 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.