everything from A to B

A story about how to use analytics in the development of your device

Hi all! My name is Alexander Grigoriev and I work for Intersvyaz. This is a Ural company that is engaged in communication services, intercom and IT products. I work as a product analyst in intercom and want to talk about the experience of analytics in the development of “tangible” products.

When designing a product, it is important to remember that you most often do not come up with something completely new. Rather, you simply improve the solution of current problems by an order of magnitude. Just like Google got better than WebCrawler, iPhone got better than Nokia, and so on.

In developing hardware products that people use literally hands, it’s about the same. The difference is only in the way the product contacts the user. You often have to remember this even when you are making an ordinary and familiar device, for example, an intercom.

Actually, I want to talk about the features of using the product approach in hardware development.

Such a panel is placed on five- and ten-story houses.  The main difference from a conventional intercom is the presence of a camera and Internet access.
Such a panel is placed on five- and ten-story houses. The main difference from a conventional intercom is the presence of a camera and Internet access.

More information about technical solutions can be found at our reports.

We will talk about the Sokol intercom panel of the Intersvyaz company. More than two years have passed from the first render and prototype to the finished device, and it’s time to share our experience. What is it like to make an “iron” product?

Why do intercoms need a product approach?

The main reason is to make sure that we do everything right. In other words, to prove the hypothesis of value.

The hypothesis of the value of our intercom is that “smart functions” will bring the main benefit: video surveillance, opening from an application, calls to a smartphone.

To test our hypothesis, we started with the cornerstone of product development, the problem interview. After installing the first working prototypes on the entrances, we decided to make a phone call to our users.

“Why are you pulling people? They would put it and not bathe, ”some may say. We also doubted whether it was worth spending resources on it. We have already supplied over 8,000 panels from other manufacturers in the past and have had a lot of conversations with users about their pains and needs. But in the situation with Sokol intercoms, we were not completely sure whether we were doing everything right.

There were three reasons for this:

  • Previously, intercoms were not installed on five-story buildings. It was important to make sure that the residents of the Khrushchevs had the same needs as the residents of multi-storey buildings. Do they need mobile app calls and video surveillance? We didn’t know this for sure.

  • It was necessary to make sure that we make the product with the same quality as the competitors.

  • For Sokol, there were one and a half times more calls to technical support from users than to other panels.

Sokol users contacted technical support with fairly typical problems: some had noises in the handset, others did not get a call. These are classic shortcomings that are solved by remote diagnostics and panel configuration. But even after analyzing the appeals and adding questions to interviews like “How are you with the pipe?” we did not understand what was the true reason for the greater number of requests.

In the statistics, appeals on the intercom handset are pronounced. There were more than 47% of them, while smart functions were treated much less frequently. There were no more than 35% of requests for smart functions, and mostly they were requests to explain how a particular service works.

A large number of requests also influenced the format of the interview. We deliberately took risks and asked a lot of questions about technical problems, and this, in principle, is not implied when conducting such surveys. It was a forced step, because the poor technical quality of the product could not play in our favor.

Distribution of hits before we figured out the cause
Distribution of hits before we figured out the cause

We conducted about 50 interviews in the hope of finding out the true reason for such a large number of requests. We did not achieve our goal, but we received confirmation of the hypothesis of the value of our intercom, which I spoke about at the beginning of the article. People were really happy with the additional features of the Falcon:

  • Users were delighted with the intercom chips, which we bet on. Many mentioned features such as access to recordings from the intercom camera and calls to the mobile application.

  • In addition to emotions, the intercom brought practical benefits to people. Some noted that they began to feel more comfortable with the intercom, and it became safer in the entrance. There were several people who, before the installation of the Sokol, had their bicycles stolen right from the entrance – they were especially happy about the intercom with a camera. People also noticed that more cars began to park under the intercom camera.

  • Some users admitted that they just like to stick to the online broadcast from the intercom camera. An unobvious plus for us and a kind of visual meditation for subscribers.

Of course, all the information collected was valuable to us. But we still could not find the answer to the main question: “Why are there so many requests?”. Instead of the expected claims in the spirit: “Guests come to us every week, and your intercom has a disgusting sound!”, We heard gratitude and delight from the new device.

Obviously, we were looking for the problem somewhere else.

Why is it not enough to have a superficial knowledge of business processes?

We delved more and more into the reasons for the appeals. We came across different opinions of engineers and guys from the support service. Here is some of them:

  • People often get excited about something new and different. But when the effect of novelty subsides, users begin to notice previously inconspicuous little things. Perhaps the sound problem was already on the old intercoms. When emotions subsided, subscribers discovered the same problem on new devices.

  • We put “Sokol” mainly on Khrushchev. Intercoms appeared in these houses about 15 years ago, but during all this time no one checked or changed the old wires. And if most of the residents of the house did not use the old intercoms, no one could know about these problems. But when subscribers begin to actively use new intercoms, then old problems in communications are revealed. Add to this our round-the-clock support – of course, there will be more requests, because before people simply had nowhere to turn.

These two explanations seemed to us quite reasonable. We thought that things would settle down soon and added a few more new features: black and white mode, motion detection and increased key storage. But there were more and more requests.

And at some point it became clear: we were digging in the right direction, but our judgments and research were superficial. What was needed was depth and a look from a new, unusual angle. It was necessary to act counterintuitively.

Then we got together as a large team and arranged a brainstorming session, in which we thoroughly analyzed each of our steps, questioned all the automated processes familiar to us. And it gave its results.

  1. First of all, we carefully studied how the process of setting up the intercom panel goes after contacting technical support. It turned out that in half the cases, the engineers used the usual setting scheme: they pulled the same sliders and set approximately the same volume values. Based on the data received, the engineers assigned new default values. It turns out that earlier the default values ​​​​were obtained empirically “on the table”, but in the field it was necessary to set other parameters.

  2. We also intensified technical research on both the software and hardware levels. Changes to the hardware product are expensive in terms of labor costs, but gave a good result in the long run.

What did we end up with? By changing the usual settings that engineers used for years out of habit, looking at the situation from a different angle, we achieved a 30% drop in the number of requests. It was not a matter of new, unusual for users, functions such as video surveillance. The catch was in Core UX, the basic functionality of the product.

What global conclusions have we made for ourselves?

Statistics and dashboards are great, but they can’t help you draw unambiguous conclusions about what’s going on with the product. You can give an assessment of the general condition, but they will not give you direct answers to the specific question “Why?”.

Interviewing users is lovely! However, this is just a piece of the puzzle. Often, users broadcast the same point of view. And this, in turn, harms our perception of the product. Sometimes you need not to bury yourself, but to check how well and efficiently the basic functions of the device work.

You can learn well different approaches in the study of hypotheses. But in the grocery approach, there is no magic pill that will give answers to all questions. It is very important to double-check yourself through a set of tools to avoid cognitive biases. And also – learn to doubt, ask yourself uncomfortable questions and not be afraid to try non-standard solutions.

Similar Posts

Leave a Reply