1.5 years ago we realized that it was time to expand the team of product managers and divide areas of responsibility.
Reason 1: We wanted to grow even faster and needed additional resources to test more hypotheses, bring them to development and release them into production.
Reason 2. We have really improved our development processes and learned to release features very quickly - there was a need to have even more ideas at the input that we could give to designers and developers.
In the summer of 2021, there were three of us, product managers, on the team:
I am a product manager and responsible for business processes, strategic projects, and development of new tools;
one product manager is responsible for retention - doing everything to ensure that the product brings maximum value and customers stay with us as long as possible;
Another product manager is responsible for acquisition —that is, for everything that happens to the user before he pays us.
I have worked with different teams and know several possible structures, but our option seems to me the most suitable for the current business needs.
We communicate with the support team, with the customer importance of ig database service and marketing teams, and do not generate product hypotheses only within ourselves.
Chaizat
Product Manager and Analyst
Aitarget One Product Team
Generating hypotheses
Each product manager is responsible for a specific metric and, as part of their routine, looks at the data, conducts cast developments, reads Telegram channels or Facebook groups where our target audience sits, and extracts insights from there .
Fun fact: often hypotheses are born after a product manager reads a Telegram channel where some marketer complains about life.
1.5 years ago, we rethought the processes and started keeping business documentation for the product in Confluence. It is extremely important not to confine knowledge to one product manager! Otherwise, problems snowball — the product manager quits, and other team members, like blind kittens, poke around in the interface themselves or bother developers to understand how the feature works and what experiment is currently underway.
Our business documentation is used by everyone - developers during the sprint, support when answering user questions, and marketing for preparing promotional materials. Writing documentation takes a little more time for the product when releasing a feature, but saves a lot of hours for the entire team in the future.