How to develop a product if the team has one developer and two customers?

To be honest, all experts say that you need to run the prototype as early as possible. In theory, this is easy, but in practice, especially for a public company, the fear of screwing up is very big. Therefore, I will try to openly talk about our experience in developing a product that few people believed in.

Dream Team

By the will of fate, my colleague and I took responsibility for the development of the site connecting b2b clients to QIWI ( ishop.qiwi.com ) and the bill payment page ( bill.qiwi.com ). At the time of our magnificent arrival in the project, the dream team consisted of two customers (we), one JavaScript developer on the remote and one QA specialist. By the way, the day before, the Java server developer left the team. Also in the working group there was a brand new project manager, but having decided that 3 managers for 1 developer - overkill - diverged.

Statistics Impudent lies

The easiest way would be to open vacancies and begin to build ambitious plans. A well-fed and calm life would be enough for half a year, maybe even a year, and then a new project. But seriously, what can 2 managers with limited ability to influence only the product interface with many users?

The only possible plan was to start building analytics in search of problems. Therefore, we set about rechecking the basic statistics that were collected in aggregates. General statistics for all products were believable. We looked at the sections in ours and found that in some places the data do not coincide with reality from 2 to 10 times. The analysts who assembled the general units, unfortunately, were divorced from the product and development, therefore, they could not guarantee their accuracy with further refinements. The external unit was supposed to provide an independent assessment. However, if reliable and objective data are not needed by the team, then there is a million and one way to make mistakes in the calculations, even by accident.

I believe that it is impossible to build reliable analytics outside the product team if the product is actively developing.

Product development work is reminiscent of research. The team puts forward a hypothesis and strives to test it as fast as possible and cheaper. The hypothesis is always more than the resources to test them, so we put analytics at the forefront to get data online, even for raw prototypes. Oddly enough, money has become the key metric of all changes. To do this, I had to do a lot, including writing my own business analytics product system. It allowed us to study not only product changes in real time, but also to see the fall of system elements, evaluating them in terms of money. So another product and even a developer for it appeared, but this is a completely different story.

First shame

While we were engaged in analytics, the processing team cheerfully reported on the emergence of support for new levels of identification, allowing payments to be made over 15,000 rubles.



In general, the need to include increased limits on the payment page, for which we were responsible, was doubtful, in comparison, for example, with changes for payment by cards.

Judge for yourself, our reasoning looked like this: The

average bill is about 500 rubles;

• If a client without the required level of identification tried to pay the bill, then, unfortunately, it was irrevocably canceled. This, in theory, would kill conversion and turnover;
• We also asked for 7 years to limit the amount of the bill to 15,000 rubles on the side of the stores, so it is not known how many of them will be able to quickly raise the limit;
• For small stores, raising the limits is statistically pointless, so you have to experiment with large partners.

We decided to evaluate the time for a version with a normal interface and the correct API. It turned out that it would take three to four months and definitely need a server-side Java developer, which we do not have.
We took a chance by raising the limits for some providers with a minimal change in interface. Yes, unfortunately, those users who did not know anything about identification received an unsightly error - the account was canceled. We evaluated the results online, preparing to return everything to normal at the first sign of loss of turnover. The conversion to successful payment was only 20% and it is a shame for her. The turnover in a short time showed a very high result and it became clear - there is life and what it is!

Crutches are Kosher

There is life, but there are no server development resources. Therefore, we decided to make a form telling the user about identification levels, if the account is more than 15,000 rubles, and the user is anonymous.
We found a request to verify the identification status and were delighted. The only thing left is to compare the invoice amount with the level allowed for the user and you can go get laurels and the envy of competitors ... However, looking at the statistics, we saw that a significant share of the turnover was held by currency accounts. It is impossible to know the amount of a foreign currency account in rubles without a server developer.

By that time, QIWI had taken a course on microservices, so we went to shake whether our colleagues had something. It turned out that yes. In the new payment form service, a course request was found.

Forms and logic were collected from everything that they found at home, with colleagues, and not without the almighty blue electrical tape. By the way, we did everything very quickly, because we remembered about a large number of errors among clients. Testing, releasing in a release and ... Urgent rollback! It turned out that we have so many currency accounts that requesting a rate puts a friendly microservice.

What to do? That's right - a small crutch. We send verification requests only if the account is more than $ 200. Despite the fluctuations in the exchange rate, they decided that $ 200 is still less than 15,000 rubles. We also give the user the opportunity to try to make a payment if the conversion rate could not be obtained. (Anyway, payment processing will not miss the wrong amount.) By the way, this reinsurance helped us a lot on 11.11 at the time of AliExpress promotion. Even with such a restriction, the load was huge and the service with rates fell, and the payment page stood. And AliExpress knows how to arrange promotions and it was a real challenge for the team.


AliExpress can surprise!

We post the new version and see almost a doubling of the turnover, and the conversion tripled and came to 60%! Great result, but you need more gold!

It’s worth it

Unfortunately, it was impossible to move on with 4 people, so they showed the leaders of the departments an analyst with the results. And they believed in the product, and in the team appeared a specialist in common sense in the interface (UX) and a whole Java developer. Another analyst joined us, she is also a Scrum-master. The team began to remind the minimum necessary for the full development of the product. Obviously, there was still a big bias in management, so we continued to dig into processes and analytics, because it was in it that all the main growth in turnover was hidden.

Final improvements, as expected, took the greatest amount of time. We replaced and optimized part of the requests and significantly redesigned the interface. The UX analyst had some fun evaluating the identity interface we put together on the knee from the existing forms and highlighted the main problems in red.



Some crutches were considered architecturally useful, for example, they left a request for courses through a separate microservice, starting with an amount of $ 200.

As a result, we increased the conversion to 90-95%. 90-95% - a stunning result. This is the maximum indicator that we saw in the product! At the same time, we consider the conversion honestly, taking into account the user's departure from the page for any reason, including lack of balance. It turns out that the additional step of filling out the form does not affect the desire to make a payment for this scenario. Turnover increased by another 40%! The mechanics began to look very clear to users and partners. In parallel with product improvements, we agreed with the sales department on the implementation of large partners. There, the process takes much longer, but the guys did well and doubled the turnover in accounts for more than 15,000 rubles in six months.

Gag

The start of work was in a very strange composition on a product where no one expected much growth. The payment page developed on a residual basis until the transition to product teams, which I wrote about earlier . The beginning was difficult, but we relied on analytics and a quick test of hypotheses on prototypes and did not fail.

Many thanks to the team that launched payments of more than 15,000 rubles:

JavaScript (React JS)	Java	QA
Sergey Yuferev	Ladygin Vladimir	Nikolsky Alexander
Analytics and Sprints	Ux	Product managers
Medvedeva Olga	Momot Catherine	Konnov George Bryuzgin Sergey

Of course, there were much more improvements and improvements. Together, the team and sales managers managed to increase the turnover of the product at its peak by 30-40% per month! They believe in us, so gradually the team grew to 14 people.



There was even a small product R&D team where we play pranks on Node.js (TypeScript), Angular 2 and a bit on golang, focusing on the quick launch of service prototypes. Soon we will try to share the fruits of his work on github, which is a separate small, but a challenge.

A virtual server in the cloud is the closest analogy to the approach to the work of our team. The team is a startup in spirit, level of “bureaucracy” and focus on results. But we have the opportunity to "scale on demand", using the opportunities available only to a large company. For example, to attract cool highly specialized specialists to solve hot issues or to improve something for a really large number of customers. It inspires flexibility when useful hypotheses from any colleague are tested quickly and without a bunch of lengthy approvals. It is especially nice to develop a popular and sought after product, as even small improvements give a significant effect. Such freedom rarely happens in large companies.

We are now inviting a system analyst to the ishop.qiwi.com restart team. Our unusual team will be glad to those who are ready to work with focus on the result and with burning eyes, we will help and teach the rest. :)

PS React JS developers and Java programmers at QIWI are always welcome in all teams of the group.