10 mistakes of 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 solely of developers, and we are creating an IT platform for managing affiliate networks of gas stations.
Error four.
To recruit 8 people who cannot replace each other at all, without a tester, and 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 quickly and easily deployed, the market of experienced developers is large.
What does such a team mean to me ? The ability to quickly find a team with the right competencies, quickly deploy MVP and start validating business hypotheses, and occupy that very free niche in the market.
What is this for the team? At the start level, there are a lot of different competencies that they can share with each other, the ability for each feature to use the fastest solution possible, and most importantly, they learn something new constantly, and this, you see, is interesting even for senior. (At least my development team shares these principles).
While testing business hypotheses, the development team grinds to each other and over time begins to test technical hypotheses within themselves, thus, in the disputes, the target architecture of the platform that the TEAM created, and not just one architect, is formed. “All architect” is a person, in my opinion, useless, expensive, and they don’t exist :) When a team has equal responsibility, the product becomes a common brainchild, everyone cheers for it, I don’t want to shift the responsibility anymore. In such a thorny way, the team grows, makes decisions, HOW to make the product further, competencies expand, interchangeability and self-organization appear. We have not passed this path yet, 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 dealing with this function itself.
Yes, it’s 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, it’s extremely difficult to be the owner of an IT product without experience in that IT, for example, a developer, system analyst or consultant (anyone except project managers), 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 asked “Who needs this?”, “The client wants it like that”, “It’s definitely inconvenient because I don’t like it” and so on. At the start, of course, you can think about the client, offer him something and, based on feedback, fill in the backlog. The main thing here is to conduct a qualitative study and hear pains, not ready-made solutions, otherwise they will ask for a “faster horse”, and not a perfectly working machine.
It is necessary to immerse the team in the pain of the client , call the clients and the team for grooming , give the team contacts of those clients whom they can always ask for an opinion or quickly check the functionality.
I began to say more often to myself: “Never try on the role of a client if you were not in his place and do not let the team do it.” Why argue in vain 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 or test hypotheses. I would like to quickly create the beautiful and immediately into the productive.
If the client’s pain: he doesn’t see the stars at night due to bad weather, and you create a spaceship for him right away, trying to exceed his expectations and do 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 by hand how the product will look, and also show it to the client. Ask him to figure out how he will use it and do not forget to do it every time ideas are transferred to the product backlog.
Well, when you came up with a brilliant feature, prototyped it, your user claps his hands and really wants it - no, you still can’t take it to work :) Do not forget about the metrics of features, both grocery and business. Metrics are generally a special story with errors - more about them later and in more detail in the next installment. While the announcement ...
Mistake seven.
Let me remind you that our team is part of a very large startup in a large company. Dealing with product metrics with stakeholders was difficult. Putting a business metric on an IT solution that is still in 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 money metrics will demotivate both you and the team, but it is precisely on them that stakeholders will want to watch. And now you are already on the slippery track PI, confidently striving down, you can not influence this metric in a positive sense. And in every sense, from now on, the product looks inefficient and unprofitable.
If you didn’t make a mistake number 6, then you have every chance to convince stakeholders, use and show the prototype to users, collect feedback, and put 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 a beautiful schedule that will appear very soon. The main thing here is not to promise too much and keep all of your promises.
Summary of conclusions:
Let me remind you that I am the owner of the product in a team consisting solely of developers, and we are creating an IT platform for managing affiliate networks of gas stations.
Error four.
Bus factor: what at first seemed like a lot of mistakes, but in fact it turned out to be a clear jackpot for the team
To recruit 8 people who cannot replace each other at all, without a tester, and 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 quickly and easily deployed, the market of experienced developers is large.
What does such a team mean to me ? The ability to quickly find a team with the right competencies, quickly deploy MVP and start validating business hypotheses, and occupy that very free niche in the market.
What is this for the team? At the start level, there are a lot of different competencies that they can share with each other, the ability for each feature to use the fastest solution possible, and most importantly, they learn something new constantly, and this, you see, is interesting even for senior. (At least my development team shares these principles).
While testing business hypotheses, the development team grinds to each other and over time begins to test technical hypotheses within themselves, thus, in the disputes, the target architecture of the platform that the TEAM created, and not just one architect, is formed. “All architect” is a person, in my opinion, useless, expensive, and they don’t exist :) When a team has equal responsibility, the product becomes a common brainchild, everyone cheers for it, I don’t want to shift the responsibility anymore. In such a thorny way, the team grows, makes decisions, HOW to make the product further, competencies expand, interchangeability and self-organization appear. We have not passed this path yet, 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 dealing with this function itself.
Yes, it’s 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, it’s extremely difficult to be the owner of an IT product without experience in that IT, for example, a developer, system analyst or consultant (anyone except project managers), 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.
It’s inconvenient for me, so others will not like it
Our team often asked “Who needs this?”, “The client wants it like that”, “It’s definitely inconvenient because I don’t like it” and so on. At the start, of course, you can think about the client, offer him something and, based on feedback, fill in the backlog. The main thing here is to conduct a qualitative study and hear pains, not ready-made solutions, otherwise they will ask for a “faster horse”, and not a perfectly working machine.
It is necessary to immerse the team in the pain of the client , call the clients and the team for grooming , give the team contacts of those clients whom they can always ask for an opinion or quickly check the functionality.
I began to say more often to myself: “Never try on the role of a client if you were not in his place and do not let the team do it.” Why argue in vain if you can ask the person for whom you are doing this?
Error six.
No one needs prototypes
A very big mistake for a beginner RO is not to make prototypes or test hypotheses. I would like to quickly create the beautiful and immediately into the productive.
If the client’s pain: he doesn’t see the stars at night due to bad weather, and you create a spaceship for him right away, trying to exceed his expectations and do 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 by hand how the product will look, and also show it to the client. Ask him to figure out how he will use it and do not forget to do it every time ideas are transferred to the product backlog.
Well, when you came up with a brilliant feature, prototyped it, your user claps his hands and really wants it - no, you still can’t take it to work :) Do not forget about the metrics of features, both grocery and business. Metrics are generally a special story with errors - more about them later and in more detail in the next installment. While the announcement ...
Mistake seven.
Metric of omnipotence
Let me remind you that our team is part of a very large startup in a large company. Dealing with product metrics with stakeholders was difficult. Putting a business metric on an IT solution that is still in 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 money metrics will demotivate both you and the team, but it is precisely on them that stakeholders will want to watch. And now you are already on the slippery track PI, confidently striving down, you can not influence this metric in a positive sense. And in every sense, from now on, the product looks inefficient and unprofitable.
If you didn’t make a mistake number 6, then you have every chance to convince stakeholders, use and show the prototype to users, collect feedback, and put 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 a beautiful schedule that will appear very soon. The main thing here is not to promise too much and keep all of your promises.
Summary of conclusions:
- First try, if yours - go to the RO school
- You are not immortal, do not grab everything at once, recruit a team that you are ready to trust
- You definitely need a scrum master. On the full time.
- Take a chance. The scrum team will become interchangeable sooner or later, and business hypotheses do not lie on the floor, it is better to take an empty seat in the market faster with your MVP, albeit with the risks of the bass factor at the start, than not have time 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 to get together :)
- Choose the metrics yourself, they should help you make a quality and iteratively good product. Remember that there are plenty of products that remained in the "death valley" due to lack of quality.