10 mistakes of the young PO (part II)
The second part with my mistakes, the first here .
Let me remind you that I am the owner of the product in a team consisting exclusively of developers, and we are making an IT platform for managing partner networks of gas stations.
Error four.
Dial 8 people who can not replace each other at all, without a tester, but first without an analyst? It would seem that I went crazy and decided to sink the product.
In fact - I need to make 6 different groups of services, for each of them there is already “the best practice”, which are easily and quickly deployed, the market of experienced developers is great.
')
What does such a team mean to me ? The ability to very quickly find a team with the necessary competencies, quickly deploy MVP and begin to validate business hypotheses, and occupy that free niche in the market.
What is it for the team ? At the start level, there are a lot of different competencies that they can share with each other, the opportunity for each feature to use the fastest solution possible, and most importantly, they learn something new all the time, and this, you see, is interesting even for senior. (At least my development team shares these principles).
During the testing of business hypotheses, the development team gets used to each other and eventually begins to test technical hypotheses inside of itself, thus, the target architecture of the platform created by the TEAM, rather than one person - the architect, emerges in disputes. “All architect” is a useless person, in my opinion, expensive and they don’t exist :) When a team has equal responsibility, the product becomes a common brainchild, everyone is sick of it, you don’t feel like shifting responsibility. It is in such a thorny way that the team grows, makes decisions, HOW to make the product further, competences expand, interchangeability and self-organization appear. We have not yet passed this path, but sooner or later we will pass. Of course, now we are expanding the team to a dedicated tester, but at the start, the team is quite capable of handling this function itself.
Yes, it is easier to take 6 java-developers and now they are immediately interchangeable, but quickly from scratch they will not make a working product, and will be very much limited by their competencies.
By the way, to be the owner of an IT product without experience in that IT, for example, by a developer, system analyst or consultant (anyone other than project managers) is extremely difficult, and even if you have an architect guru, it will be his product, not yours . Here you can argue, but the practice and statistics are as follows.
Error five.
Our team often had questions: “And who needs it?”, “The client wants it like this,” “This is definitely inconvenient because I don’t like it,” and so on. At the start, of course, you can think of a client, offer him something and fill in the backlog based on feedback. Here the main thing is to conduct a qualitative study, and hear the pain, and not ready-made solutions, otherwise they will ask for a “faster horse”, rather than a perfectly working machine.
It is necessary to immerse the team in the pain of the client , call on the customer gruming and the team, give the team contacts of those clients whom they can always ask for an opinion or quickly check the functionality.
I began to say to myself more often: “Never try on the role of a client, if you were not in his place and do not allow the team to do it”. Why argue for nothing if you can ask the person for whom you are doing this?
Error six.
A very big mistake for a beginner RO is not to make prototypes and not to test hypotheses. I want to quickly create the beautiful and immediately productive.
If the client’s pain: he doesn’t see stars at night due to bad weather, and you immediately create a spacecraft for him, trying to exceed his expectations and make him 100 times better than he could have imagined, then this is a clear mistake. He had a different task, pain and wishes.
You can spend three days or a week, draw a freehand how the product will look, and be sure to show it to the client. Ask him to figure out how he will use it and do not forget to do it every time when ideas move to the backlog of the product.
Well, when you came up with a brilliant feature, prototyped it, your user claps his hands and wants it very much - no, you still can’t take it to work :) Do not forget about feature metrics, both grocery and business. Metrics are generally a special story with errors - about them later and in more detail in the next installment. While the announcement ...
Error seven.
Let me remind you that our team is part of a very large startup in a large company. It was difficult to agree with the stakeholders on the metrics of the product. Putting a business metric on an IT solution that is still at the design stage is a bad idea. But investors need to show their work, even if there are no increments for the user yet.
Any monetary metrics will demotivate both you and the team, but it is on them that the stakeholders will want to look. And now you are already on the slippery PI track, confidently striving downwards, you cannot influence this metric in a positive sense. And in every sense, from now on, the product looks inefficient and unprofitable.
If you have not made a mistake number 6, then you have every chance to convince the stakeholders, use and show the prototype to users, collect feedback, and hang the attraction metrics on it. Make the development as transparent as possible, show what you are doing on this prototype, which button or form will work, what it will allow you to do, and how to use the beautiful schedule that you will have very soon. The main thing is not to promise too much and fulfill all their promises.
Brief conclusions:
Let me remind you that I am the owner of the product in a team consisting exclusively of developers, and we are making an IT platform for managing partner networks of gas stations.
Error four.
Bus factor: what at first seemed to be a mistake for many, but in fact it turned out to be an obvious jackpot for the team
Dial 8 people who can not replace each other at all, without a tester, but first without an analyst? It would seem that I went crazy and decided to sink the product.
In fact - I need to make 6 different groups of services, for each of them there is already “the best practice”, which are easily and quickly deployed, the market of experienced developers is great.
')
What does such a team mean to me ? The ability to very quickly find a team with the necessary competencies, quickly deploy MVP and begin to validate business hypotheses, and occupy that free niche in the market.
What is it for the team ? At the start level, there are a lot of different competencies that they can share with each other, the opportunity for each feature to use the fastest solution possible, and most importantly, they learn something new all the time, and this, you see, is interesting even for senior. (At least my development team shares these principles).
During the testing of business hypotheses, the development team gets used to each other and eventually begins to test technical hypotheses inside of itself, thus, the target architecture of the platform created by the TEAM, rather than one person - the architect, emerges in disputes. “All architect” is a useless person, in my opinion, expensive and they don’t exist :) When a team has equal responsibility, the product becomes a common brainchild, everyone is sick of it, you don’t feel like shifting responsibility. It is in such a thorny way that the team grows, makes decisions, HOW to make the product further, competences expand, interchangeability and self-organization appear. We have not yet passed this path, but sooner or later we will pass. Of course, now we are expanding the team to a dedicated tester, but at the start, the team is quite capable of handling this function itself.
Yes, it is easier to take 6 java-developers and now they are immediately interchangeable, but quickly from scratch they will not make a working product, and will be very much limited by their competencies.
By the way, to be the owner of an IT product without experience in that IT, for example, by a developer, system analyst or consultant (anyone other than project managers) is extremely difficult, and even if you have an architect guru, it will be his product, not yours . Here you can argue, but the practice and statistics are as follows.
Error five.
I feel uncomfortable, so others will not like it
Our team often had questions: “And who needs it?”, “The client wants it like this,” “This is definitely inconvenient because I don’t like it,” and so on. At the start, of course, you can think of a client, offer him something and fill in the backlog based on feedback. Here the main thing is to conduct a qualitative study, and hear the pain, and not ready-made solutions, otherwise they will ask for a “faster horse”, rather than a perfectly working machine.
It is necessary to immerse the team in the pain of the client , call on the customer gruming and the team, give the team contacts of those clients whom they can always ask for an opinion or quickly check the functionality.
I began to say to myself more often: “Never try on the role of a client, if you were not in his place and do not allow the team to do it”. Why argue for nothing if you can ask the person for whom you are doing this?
Error six.
Nobody needs prototypes
A very big mistake for a beginner RO is not to make prototypes and not to test hypotheses. I want to quickly create the beautiful and immediately productive.
If the client’s pain: he doesn’t see stars at night due to bad weather, and you immediately create a spacecraft for him, trying to exceed his expectations and make him 100 times better than he could have imagined, then this is a clear mistake. He had a different task, pain and wishes.
You can spend three days or a week, draw a freehand how the product will look, and be sure to show it to the client. Ask him to figure out how he will use it and do not forget to do it every time when ideas move to the backlog of the product.
Well, when you came up with a brilliant feature, prototyped it, your user claps his hands and wants it very much - no, you still can’t take it to work :) Do not forget about feature metrics, both grocery and business. Metrics are generally a special story with errors - about them later and in more detail in the next installment. While the announcement ...
Error seven.
Absolute metric
Let me remind you that our team is part of a very large startup in a large company. It was difficult to agree with the stakeholders on the metrics of the product. Putting a business metric on an IT solution that is still at the design stage is a bad idea. But investors need to show their work, even if there are no increments for the user yet.
Any monetary metrics will demotivate both you and the team, but it is on them that the stakeholders will want to look. And now you are already on the slippery PI track, confidently striving downwards, you cannot influence this metric in a positive sense. And in every sense, from now on, the product looks inefficient and unprofitable.
If you have not made a mistake number 6, then you have every chance to convince the stakeholders, use and show the prototype to users, collect feedback, and hang the attraction metrics on it. Make the development as transparent as possible, show what you are doing on this prototype, which button or form will work, what it will allow you to do, and how to use the beautiful schedule that you will have very soon. The main thing is not to promise too much and fulfill all their promises.
Brief conclusions:
- Try it first, if yours, go to the RO school
- You are not immortal, do not grab at all at once, dial a team that is ready to trust
- You just need a scrum master. On fulltime.
- Risk it. The Scrum team will become interchangeable sooner or later, and the business hypotheses on the floor do not roll, it is better to take a free place on the market with your MVP, albeit with the risk of a bass factor at the start, than not to take it.
- Communicate more with the client, remember about his pain, try to solve it.
- Question all your ideas, create prototypes and test hypotheses, look at the reaction of the client, we are here for this :)
- Choose metrics yourself, they should help you to make a qualitatively and iteratively good product. Remember that the products that remained in the "valley of death" due to lack of quality abound.
Source: https://habr.com/ru/post/457764/
All Articles