How to develop a product, if there is one developer and two customers in a team?
Let's be honest, all experts say that you need to run a prototype as soon as possible. In theory, this is easy, but in practice, especially for a public company, the fear of screwing up is very large. Therefore, I will try to openly talk about our experience in the development of a product in which few people believed.
By the will of fate, my colleague and I took responsibility for the development of the b2b client connection site to QIWI ( ishop.qiwi.com ) and the bill payment page ( bill.qiwi.com ). At the time of ourgreat coming to the project, the dream team consisted of two customers (we), one JavaScript developer on remote and one QA specialist. On the eve, by the way, a Java server-side developer left the team. Also in the working group there was a brand new project manager, but having decided that 3 managers per 1 developer - bust - were separated.
The easiest thing would be to open vacancies and start building ambitious plans. A full and relaxed life would be enough for half a year, or maybe even a year, and then a new project. But seriously, what can make 2 managers with limited ability to influence only the interface of a product that has many users?
')
The only possible plan was to start building analytics in search of problems. Therefore, we started to re-check the basic statistics that were collected in the aggregates. Overall statistics on all products was plausible. We looked at the cuts in ours and found that in some places the data do not coincide with reality from 2 to 10 times. Unfortunately, analysts who assembled general aggregates were cut off from the product and development, and therefore could not guarantee their accuracy with further refinements. It was assumed that the external unit will 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 a mistake in the calculations, even by accident.
Work on product development is reminiscent of research. The team puts forward a hypothesis and by all means seeks to test it, as quickly as possible and cheaper. There are always more hypotheses than resources to test them, so we put analytics at the forefront to get data online, even for raw prototypes. The key metric of all changes, oddly enough, was money. To do this, I had to do a lot, including writing my own product business analytics system. It allowed to investigate not only the product changes in real time, but also to see the fall of system elements, evaluating them in money. So there was another product, and even the developer for it, but this is another story.
While we were engaged in analytics, the processing team cheerfully reported on the appearance of support for new levels of identification, allowing payments to be made in excess of 15,000 r.
In general, the need to include increased limits on the payment page, for which we were responsible, was questionable, in comparison, for example, with the changes for payment by cards.
Judge for yourself, our reasoning looked like this:
The average check is about 500 rubles;
We decided to estimate the time for the version with a normal interface and the correct API. It turned out that it would take three or four months and definitely need a server-side Java developer, which we don’t have.
We risked raising the limits for a part of providers with minimal changes in the interface. Yes, unfortunately, those users who did not know anything about identification received an unattractive error - the account was canceled. We evaluated the results online, preparing to return everything back to normal at the first signs of a loss of turnover. Conversion to a successful payment was only 20% and shame for it. The turnover in a short time showed a very high result and it became clear that there is life and what else!
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.
Found a request to check the status of identification and delighted. It remains the case for small: to compare the amount of the bill with the level permitted for the user and you can go to get the laurels and the envy of competitors ... However, looking at the statistics, we saw that a significant share of the turnover is occupied by currency accounts. Without a server developer, it is impossible to know the amount of a currency account in rubles.
By that time, QIWI was heading for microservices, so we went to shake if there were any colleagues. It turned out that yes. In the new service of payment forms found the request rate.
Forms and logic collected from all that they found in their colleagues, and not without omnipotent blue electrical tape. By the way, they did everything very quickly, because they remembered about a large number of mistakes from customers. We test, release to release and ... Urgently roll back! It turned out that we have so many foreign currency accounts that a course request puts a friendly microservice.
What to do? That's right - a small crutch. Requests for verification are sent only if the account is more than $ 200. Despite the fluctuations in the course, they decided that $ 200 is still less than $ 15,000. We also enable the user to try to make a payment if the conversion rate could not be obtained. (All the same, payment processing will not miss incorrect amounts.) By the way, this reinsurance helped us a lot 11.11 at the time of the AliExpress promotion. Even with such a restriction, the load was huge and the service with the courses dropped, and the payment page resisted. And AliExpress is able to organize promotions and this was a real challenge for the team.
AliExpress knows how to surprise!
We post a new version and we see an almost doubling of turnover, and the conversion tripled and came to 60%! Great result, but you need more gold!
Unfortunately, it was impossible to continue moving in the structure of 4 people, therefore we showed the leaders of the departments an analyst with the results. And they believed in the product, and the team had a specialist in common sense in the interface (UX) and a whole Java developer. Another analyst has joined us, she is a Scrum-master. The team began to remind the minimum necessary for the full development of the product. Obviously, there was still a big imbalance in management, so we continued to dig into processes and analytics, because it was in it that the entire main growth in turnover was hidden.
Final improvements, as expected, took the most time. We replaced and optimized some requests and significantly reworked the interface. UX analyst had fun, assessing the identification interface, which we collected on the knee of the existing forms, and marked the main problems with red.
Some crutches were recognized architecturally useful, for example, they left a request for courses through a separate microservice, starting at $ 200.
As a result, we raised the conversion to 90-95%. 90-95% - a stunning result. This is the maximum we saw in the product! At the same time, we consider conversion fairly, taking into account the user's leaving the page for any reason, including the 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%! Mechanics began to look very understandable to users and partners. In parallel with the modifications of the product, we agreed with the sales department on implementation from major partners. There, the process takes much more time, but the guys did a good job and in half a year they doubled the turnover on their accounts for more than 15,000 r.
Getting started was a very strange composition on the product, where no one expected much growth. The payment page was developed on a residual basis prior to the transition to the product teams, which I wrote about earlier . The beginning was hard, but we relied on analytics and quick testing of hypotheses on prototypes and did not lose.
Many thanks to the team that launched payments for more than 15,000 rubles:
Of course, there were more improvements and improvements. Together, the team and sales managers managed to increase the turnover of the product at the peak of 30-40% per month! They believe in us, so gradually the team grew to 14 people.
There was even a small grocery R & D team where we prank on Node.js (TypeScript), Angular 2 and a bit on golang, focusing on quickly launching prototype services. Soon we will try to share the fruits of his work on github, which is a separate small, but challenging.
Virtual server in the cloud - the closest analogy to the approach to the work of our team. The team is a startup in spirit, level of “bureaucracy” and result orientation. But we have the ability to “scale on demand”, using opportunities available only to a large company. For example, to attract steep highly specialized specialists to solve hot issues or improve something for a really large number of clients. Encourages flexibility when useful hypotheses from any colleague are tested quickly and without heaps of lengthy approvals. It is especially pleasant to develop a popular and sought-after product, since even small improvements have a significant effect. Such freedom rarely happens in large companies.
PS React JS developers and Java programmers in QIWI are always welcome in all teams of the group.
Dream Team
By the will of fate, my colleague and I took responsibility for the development of the b2b client connection site to QIWI ( ishop.qiwi.com ) and the bill payment page ( bill.qiwi.com ). At the time of our
Statistics of Insolent Lies
The easiest thing would be to open vacancies and start building ambitious plans. A full and relaxed life would be enough for half a year, or maybe even a year, and then a new project. But seriously, what can make 2 managers with limited ability to influence only the interface of a product that has many users?
')
The only possible plan was to start building analytics in search of problems. Therefore, we started to re-check the basic statistics that were collected in the aggregates. Overall statistics on all products was plausible. We looked at the cuts in ours and found that in some places the data do not coincide with reality from 2 to 10 times. Unfortunately, analysts who assembled general aggregates were cut off from the product and development, and therefore could not guarantee their accuracy with further refinements. It was assumed that the external unit will 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 a mistake 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.
Work on product development is reminiscent of research. The team puts forward a hypothesis and by all means seeks to test it, as quickly as possible and cheaper. There are always more hypotheses than resources to test them, so we put analytics at the forefront to get data online, even for raw prototypes. The key metric of all changes, oddly enough, was money. To do this, I had to do a lot, including writing my own product business analytics system. It allowed to investigate not only the product changes in real time, but also to see the fall of system elements, evaluating them in money. So there was another product, and even the developer for it, but this is another story.
First shame
While we were engaged in analytics, the processing team cheerfully reported on the appearance of support for new levels of identification, allowing payments to be made in excess of 15,000 r.
In general, the need to include increased limits on the payment page, for which we were responsible, was questionable, in comparison, for example, with the changes for payment by cards.
Judge for yourself, our reasoning looked like this:
The average check is about 500 rubles;
- If a client without the required level of identification tried to pay the bill, he, unfortunately, was irretrievably 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 limits is statistically meaningless, so you have to experiment with large partners.
We decided to estimate the time for the version with a normal interface and the correct API. It turned out that it would take three or four months and definitely need a server-side Java developer, which we don’t have.
We risked raising the limits for a part of providers with minimal changes in the interface. Yes, unfortunately, those users who did not know anything about identification received an unattractive error - the account was canceled. We evaluated the results online, preparing to return everything back to normal at the first signs of a loss of turnover. Conversion to a successful payment was only 20% and shame for it. The turnover in a short time showed a very high result and it became clear that there is life and what else!
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.
Found a request to check the status of identification and delighted. It remains the case for small: to compare the amount of the bill with the level permitted for the user and you can go to get the laurels and the envy of competitors ... However, looking at the statistics, we saw that a significant share of the turnover is occupied by currency accounts. Without a server developer, it is impossible to know the amount of a currency account in rubles.
By that time, QIWI was heading for microservices, so we went to shake if there were any colleagues. It turned out that yes. In the new service of payment forms found the request rate.
Forms and logic collected from all that they found in their colleagues, and not without omnipotent blue electrical tape. By the way, they did everything very quickly, because they remembered about a large number of mistakes from customers. We test, release to release and ... Urgently roll back! It turned out that we have so many foreign currency accounts that a course request puts a friendly microservice.
What to do? That's right - a small crutch. Requests for verification are sent only if the account is more than $ 200. Despite the fluctuations in the course, they decided that $ 200 is still less than $ 15,000. We also enable the user to try to make a payment if the conversion rate could not be obtained. (All the same, payment processing will not miss incorrect amounts.) By the way, this reinsurance helped us a lot 11.11 at the time of the AliExpress promotion. Even with such a restriction, the load was huge and the service with the courses dropped, and the payment page resisted. And AliExpress is able to organize promotions and this was a real challenge for the team.
AliExpress knows how to surprise!
We post a new version and we see an almost doubling of turnover, and the conversion tripled and came to 60%! Great result, but you need more gold!
Worth it
Unfortunately, it was impossible to continue moving in the structure of 4 people, therefore we showed the leaders of the departments an analyst with the results. And they believed in the product, and the team had a specialist in common sense in the interface (UX) and a whole Java developer. Another analyst has joined us, she is a Scrum-master. The team began to remind the minimum necessary for the full development of the product. Obviously, there was still a big imbalance in management, so we continued to dig into processes and analytics, because it was in it that the entire main growth in turnover was hidden.
Final improvements, as expected, took the most time. We replaced and optimized some requests and significantly reworked the interface. UX analyst had fun, assessing the identification interface, which we collected on the knee of the existing forms, and marked the main problems with red.
Some crutches were recognized architecturally useful, for example, they left a request for courses through a separate microservice, starting at $ 200.
As a result, we raised the conversion to 90-95%. 90-95% - a stunning result. This is the maximum we saw in the product! At the same time, we consider conversion fairly, taking into account the user's leaving the page for any reason, including the 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%! Mechanics began to look very understandable to users and partners. In parallel with the modifications of the product, we agreed with the sales department on implementation from major partners. There, the process takes much more time, but the guys did a good job and in half a year they doubled the turnover on their accounts for more than 15,000 r.
Gag
Getting started was a very strange composition on the product, where no one expected much growth. The payment page was developed on a residual basis prior to the transition to the product teams, which I wrote about earlier . The beginning was hard, but we relied on analytics and quick testing of hypotheses on prototypes and did not lose.
Many thanks to the team that launched payments for more than 15,000 rubles:
| JavaScript (React JS) | Java | QA |
|---|---|---|
| Sergey Yuferev | Ladygin Vladimir | Nikolsky Alexander |
| Analytics and sprints | Ux | Product Managers
|
| Olga Medvedeva | Momot Catherine | Konnov George
Bryuzgin Sergey |
Of course, there were more improvements and improvements. Together, the team and sales managers managed to increase the turnover of the product at the peak of 30-40% per month! They believe in us, so gradually the team grew to 14 people.
There was even a small grocery R & D team where we prank on Node.js (TypeScript), Angular 2 and a bit on golang, focusing on quickly launching prototype services. Soon we will try to share the fruits of his work on github, which is a separate small, but challenging.
Virtual server in the cloud - the closest analogy to the approach to the work of our team. The team is a startup in spirit, level of “bureaucracy” and result orientation. But we have the ability to “scale on demand”, using opportunities available only to a large company. For example, to attract steep highly specialized specialists to solve hot issues or improve something for a really large number of clients. Encourages flexibility when useful hypotheses from any colleague are tested quickly and without heaps of lengthy approvals. It is especially pleasant to develop a popular and sought-after product, since even small improvements have a significant effect. Such freedom rarely happens in large companies.
Now we invite the system analyst to the ishop.qiwi.com restart command. Our unusual team will be glad to those who are willing to work to work with a focus on results and burning eyes, with the rest we will help and teach. :)
PS React JS developers and Java programmers in QIWI are always welcome in all teams of the group.
Source: https://habr.com/ru/post/324666/
All Articles