task prioritization and team happiness

I and other colleagues had a lot of ideas and suggestions. Then, as in all other companies, the question arose: what to do in the first place? And then a framework appeared in the company. Either it was self-made, or it was created at the suggestion of agile coaches, who had just begun to appear on the market (to be honest, I don’t remember exactly). The framework looked like this: there were two estimates, value (in money or for the client) and labor. Estimates could be set by Fibonacci numbers. At the first stages within the company, we called them estimates in parrots.

And this assessment was given by about ten experts from different divisions of the companies, starting with the development manager and ending with the general director. And then the weighted average value was divided by the weighted average expenses / costs for this feature and the overall priorities for the entire company were obtained. This is called poker planning. The advantage of this method was speed – literally within half an hour, this method could eliminate a large number of potential features and the company had plans ready.

But this scoring had problems: often because of it, there were shifts towards tasks that could generate money from users at the moment, but at the same time dramatically reduced the user’s life in investments. Only a part of the experts had expertise in development, so those features that were supposed to be released in production in a month were created several times longer.

In the future, companies began to form separate product teams, by that time I had already retrained in sales, and the team and I tried different methodologies, including the RISE methodology optimized for us and other frameworks. It was not a negative experience, but in the end, the team and I came to the conclusion that as a result we were still wrong in the assessment. It seems that it makes no difference which particular feature to do, if only a small part of them (one out of ten) bring a multiple result, and all the rest either slightly affect the metrics or even worsen the client’s experience. I think many sales people here will say that you can check what you are doing for 1000 and 1 iterations and then the likelihood of success will increase due to quantitative and qualitative research. In general, I agree, but if you work in a small team and need multiple results, then sometimes it’s easier to reduce time to market and test your hypothesis in the market.

Of course, I had many cases when I checked my features before the launch and rejected them. But usually, every time I mentally compared the cost of an error and the cost of research and test hypotheses before the start of development and potential benefits.

But back to the main topic 🙂 After a couple of years of work in several iterations, the team and I came up with this question – why complicate prioritization, if in any case all teams on the market also use different methods, and the result is the same for everyone: features that either bring results or worsen the product. As a result, we simply abandoned prioritization according to any methodology.

Team work

Once a quarter before the start of the next one, we got together and looked at the pool of ideas, desires and suggestions of customers. From this list, we chose tasks that inspired us and, in theory, should bring revenue, which is what the client needs. Then, at the same meeting, we superficially found a client flow and, together with testers, back-end and front-end developers, estimated how long it would take us to make this feature. Thus, we came up with several large and small features, with which we composed the quarter.

Then the guys themselves prioritized the tasks within the ĸaĸ quarter, ĸаĸ it was convenient for them and it seemed right. I interfered minimally – managed the deadlines and helped solve the problems that the team faced. As a result, after the transition from the framework to the execution of tasks that we believe in, the productivity of the team, its interest and involvement increased. We saw results that helped us grow faster and more significantly.

I hasten to assure you, before the product community accused us of being unscientific, that we checked and rechecked a lot of things before starting work on a feature. Thus, I had a belief that such a system is much more efficient than using the frameworks that you can find in the articles that I talked about at the beginning.

But it is worth emphasizing one point: this system will only work when the team has a high level of expertise for everyone, from the tester to the designer. The whole team should have the same goals – money, metrics, customer happiness, or not how many tasks in the sprint they closed on time (this was also in my experience).

Recently, I sat and remembered how many features and hypotheses were tested during my work with the team. Often I, and many other people with impostor syndrome (and who of us was not praised for an excellent result in childhood), underestimate myself, which is why I say that very little has been done to create a useful and effective result. But in the end, I realized that there are results and they are still very serious, although I have not worked for this company for a long time. But these features still bring money to shareholders and benefit to customers.

After this company, I went to work in another and was very surprised that in the new workplace, in one of the coolest fintech companies on the market, everyone does only what they believe in. I was happy 🙂 Here the result of such work was immediately noticeable (I observed the same within the framework of my team at my previous job), but only within the framework of the company – high efficiency and effectiveness. After that, I did a little research among my known sales managers and found out that the coolest products on the market are built by exactly those people and teams who believe in what they do.

I shared purely my experience, I don’t know how valuable it is to you, the readers, but I judge by the articles here, by the videos on YouTube, and I see a lot of stereotyped approaches and little understanding.

Tell us about your experience of working with teams, and which approach to product development do you prefer 🙂