10 mistakes of the young RO (part I - three mistakes)
Hi, I am Olya and I am a new RO. I work as the owner of the product for 1.5 years, every couple of months new instays arrive, the world turns upside down, and I think: “Damn”! I did everything wrong! But now I know exactly how to! Of course, every time I can not even imagine how wrong I am.
In the quality of "intro" a little bit more about the product, the team, and me.
We are creating a technological platform for managing partner gas station networks. We build it from scratch, use microservices, work on a screen, try to implement devops, etc. We now have 30 gas stations, by the end of the year there will be more than 150.
1.5 years ago, after all the mandatory activities like pitch, solution architecture, budget protection, etc., I briefly thought about a team of 8 people, 6 - BE, 1 - FE, 1 - designer. Each developer is unique, he writes only on something of his own, I heard the word “agile” somewhere, once I read it on Habré, and what a colleague is doing there basically does not matter much.
')
I studied applied computer science and in parallel worked as a hookah, waiter, sports nutrition consultant, bartender, logistics at the port, declarant (in the same port), product distribution manager in large retail, analyst, head of business analytics, head of SAP system analytics department , head of the department of developing BI solutions, all in the same retail.
In the last position I had a team of system analysts and developers, backlog of tasks for 100 years ahead, a lot of users who themselves brought me feedback (even no caste-devas need to be carried out, although at that time I didn’t even know that it was such). We worked for four weeks in sprints, because the CIO said so, all the action takes place in the format. No demonstrations, retrospectives — no, metrics — no, scrum master — who is it at all?
And 1.5 years ago I was sitting in the school of product owners at Gazprom Neft. There is already the third week of classes, they tell us about the blueprint service, about caste-dev, about CJM, about metrics ... and I don’t understand anything. Why do I need it? Why am I here? Can I already go typing command?
So, what we have:
But there are important people who for some reason are against the bright future of our startup and the squinting men's views of colleagues, who also do not really understand what I'm doing here.
I conclude with preludes, go to the mistakes.
So, RO school is a necessary, useful and obligatory thing, but only if you are already RO. Otherwise, it will be like in school or uni - they tell something there, it is interesting, but how does this relate to life? Unclear.
When you first start working with RO, you are, of course, extremely charged with the quality of your product and the product itself, this is a new role for you, which is very interesting on the Internet, they even speak very coolly at conferences and it’s necessary to comply.
In pursuit of truly impressive increments, every sprint you will do everything possible and impossible, the stakeholders (investors) will “help” you to determine the metrics of YOUR product, for which you will answer, you will try all the methods of motivation and demotivation of the team and yourself, you will dream about the product at night, and new features will be generated at the speed of light.
As you understand, there will be no time at all to deal with the product and, most importantly, the customer’s problem!
But sooner or later, the euphoria will pass, and feedback from customers will appear, it will open your eyes for the first time, and you will understand: something went wrong. Here you start to google, find out what CJM is, how important the research is, and what hypotheses are actually needed to test them, rather than catch and do it right away.
And this is the very moment to go to the RO school.
This is my main mistake. And then everything is simple.
When you are a new RO, it seems to you that no one knows the product better than you (and this is so) and no one will do better (and this is not so), and here you are trying to be a scram-master, an analyst, an architect, and Secretary, and many more by whom. Perhaps you can even combine all these roles in yourself, BUT not for long, and most importantly - you will cease to be the owner of your product.
You need to take care of yourself and learn to trust the team, they are no less sick of the product and want to make it successful. All that you owe to these people is a vision, prioritized backlog, and attempts to protect them from any bureaucracy, simply speaking, do not prevent them from making decisions on HOW to make a product.
What kind of person is a snowflake can be found here:
Often, ROs save on this position and believe that it is better to take one more developer for the same money, because there the effect is immediately visible.
I thought the same way and almost lost my dev-team. First of all, it is very important to immerse the team in the philosophy of Scram, infect them with the very idea of ​​a product, teach them how to do it correctly, and show why the daily is very necessary and why they should take 15 minutes. What will happen if it is wrong to evaluate the tasks, how to refuse the RO to perform something unnecessary, which is not in the sprint (you yourself will not wear 2 caps, and you will not teach them to refuse you yourself).
I seem to be writing everyday things, but in practice a well-organized team is a much more productive and efficient team that does what you need, does not shoot each other during retrospectives, surpasses your expectations, and then you will have 50% of your happiness customer
There will be a continuation of errors, because I have accumulated a lot of fakaps. And how are you with this?
In the quality of "intro" a little bit more about the product, the team, and me.
We are creating a technological platform for managing partner gas station networks. We build it from scratch, use microservices, work on a screen, try to implement devops, etc. We now have 30 gas stations, by the end of the year there will be more than 150.
1.5 years ago, after all the mandatory activities like pitch, solution architecture, budget protection, etc., I briefly thought about a team of 8 people, 6 - BE, 1 - FE, 1 - designer. Each developer is unique, he writes only on something of his own, I heard the word “agile” somewhere, once I read it on Habré, and what a colleague is doing there basically does not matter much.
')
I studied applied computer science and in parallel worked as a hookah, waiter, sports nutrition consultant, bartender, logistics at the port, declarant (in the same port), product distribution manager in large retail, analyst, head of business analytics, head of SAP system analytics department , head of the department of developing BI solutions, all in the same retail.
In the last position I had a team of system analysts and developers, backlog of tasks for 100 years ahead, a lot of users who themselves brought me feedback (even no caste-devas need to be carried out, although at that time I didn’t even know that it was such). We worked for four weeks in sprints, because the CIO said so, all the action takes place in the format. No demonstrations, retrospectives — no, metrics — no, scrum master — who is it at all?
And 1.5 years ago I was sitting in the school of product owners at Gazprom Neft. There is already the third week of classes, they tell us about the blueprint service, about caste-dev, about CJM, about metrics ... and I don’t understand anything. Why do I need it? Why am I here? Can I already go typing command?
So, what we have:
- Ideal from the point of view of the bass factor, a team built from scratch
- A lot of theoretical knowledge in the field of product development
- Many different experiences from past places.
- A company in which there is not even Jira
But there are important people who for some reason are against the bright future of our startup and the squinting men's views of colleagues, who also do not really understand what I'm doing here.
I conclude with preludes, go to the mistakes.
Error one
It makes no sense to learn to be RO - you need to try
So, RO school is a necessary, useful and obligatory thing, but only if you are already RO. Otherwise, it will be like in school or uni - they tell something there, it is interesting, but how does this relate to life? Unclear.
When you first start working with RO, you are, of course, extremely charged with the quality of your product and the product itself, this is a new role for you, which is very interesting on the Internet, they even speak very coolly at conferences and it’s necessary to comply.
In pursuit of truly impressive increments, every sprint you will do everything possible and impossible, the stakeholders (investors) will “help” you to determine the metrics of YOUR product, for which you will answer, you will try all the methods of motivation and demotivation of the team and yourself, you will dream about the product at night, and new features will be generated at the speed of light.
As you understand, there will be no time at all to deal with the product and, most importantly, the customer’s problem!
But sooner or later, the euphoria will pass, and feedback from customers will appear, it will open your eyes for the first time, and you will understand: something went wrong. Here you start to google, find out what CJM is, how important the research is, and what hypotheses are actually needed to test them, rather than catch and do it right away.
And this is the very moment to go to the RO school.
Error two
Snowflake man - very ambitious but useless
This is my main mistake. And then everything is simple.
When you are a new RO, it seems to you that no one knows the product better than you (and this is so) and no one will do better (and this is not so), and here you are trying to be a scram-master, an analyst, an architect, and Secretary, and many more by whom. Perhaps you can even combine all these roles in yourself, BUT not for long, and most importantly - you will cease to be the owner of your product.
You need to take care of yourself and learn to trust the team, they are no less sick of the product and want to make it successful. All that you owe to these people is a vision, prioritized backlog, and attempts to protect them from any bureaucracy, simply speaking, do not prevent them from making decisions on HOW to make a product.
What kind of person is a snowflake can be found here:
Mistake three
The team will do without scrum master
Often, ROs save on this position and believe that it is better to take one more developer for the same money, because there the effect is immediately visible.
I thought the same way and almost lost my dev-team. First of all, it is very important to immerse the team in the philosophy of Scram, infect them with the very idea of ​​a product, teach them how to do it correctly, and show why the daily is very necessary and why they should take 15 minutes. What will happen if it is wrong to evaluate the tasks, how to refuse the RO to perform something unnecessary, which is not in the sprint (you yourself will not wear 2 caps, and you will not teach them to refuse you yourself).
I seem to be writing everyday things, but in practice a well-organized team is a much more productive and efficient team that does what you need, does not shoot each other during retrospectives, surpasses your expectations, and then you will have 50% of your happiness customer
There will be a continuation of errors, because I have accumulated a lot of fakaps. And how are you with this?
Source: https://habr.com/ru/post/453668/
All Articles