Lessons learnt after a year as a Product Manager in my second job
Coming up to nearly a year in my second stint as a product manager in my short PM career, I wanted to share the experiences and insights I’ve gained that have helped me become more effective in my role.
To give a little bit of context to add is that I was previously a developer before transitioning to a product manager, so I had extensive knowledge of the codebase of the product. I didn’t have this advantage when moving to a new company.
Adapt to working with different team members to bring the best out of the team
Every team member has their strengths, personalities, ways of working, etc. Conversely, this means you have to work a little differently with each member to bring the best out of the team, sort of like a sports coach.
Whilst my onshore team was fluent in English and very well spoken and opinionated about different tickets, the offshore team in Sri Lanka was the opposite. Some of the challenges working with the offshore team included:
- They were so scared of losing their jobs that they dared not ask me any questions to me as they believed it was a sign of weakness.
- Certain developers were implementing the acceptance criteria verbatim, without questioning that it was wrong or whether what they were doing made sense in the grand scheme of the product
To overcome this, I had to make sure the specifications and notes were clearer to adjust for individuals whom English wasn’t their first language. The other main adjustment I made was to make the offshore team feel like they were a team I was physically working with.
I tried to make the meetings and conversations more joyous, fun, and happy such that they weren’t scared of me and the onshore team. If they were quiet in meetings, I’d always loop them in and ask them for their input in front of everyone as well.
Eventually, they felt more comfortable reaching out to us and asking questions without any fear they would be ridiculed for asking questions they felt they should have known the answers.
The team should not be a feature factory
When I first started as a product manager, I was focused solely on pumping out new features and releases as quickly as possible. I slowly realised this approach is fundamentally flawed. Though I had a whole list of features deployed, I was left with:
- Disinterested team members not satisfied with the results
- a product that was getting unnecessarily complicated and influenced by a vocal minority
- not getting the metrics we wanted to meet our objectives.
I needed to put more technical debt tickets in each sprint and help improve the current product. It ensures we continually improve our existing product and bring value to our existing customer base. Neglecting to do this can lead to high churn rates, as our frustrated customers will find other products that provide the experience they need. Stakeholders most likely won’t see the benefit, the customers will.
Let the developers think for themselves
I used to believe that writing detailed specifications would help the team to have a clear understanding of what needed to be done without having to ask me any questions.
However, I soon realised that this approach prevented the developers from thinking for themselves and coming up with innovative solutions to the problems at hand.
Furthermore, the developers became disinterested because they were not allowed to think for themselves. Might as well have just gotten ChatGPT to write the code instead.
I learned that it is better to set the boundaries and the end goal for the task first. Then let the developers come up with how it should be implemented. I needed to not be afraid of collaboration with my developers, and that requirements can change during a ticket if a good idea is raised. Having the whole team add their input without fear of reprisals, meant the team was more engaged leading to better outcomes.
Two week sprints are just right
In my short experience as a product manager, a two-week sprint is the optimal length for a product team. While longer sprints of 4–6 weeks may seem like you can release a lot of meaty features on deployment, those longer sprints lead to a lack of motivation and productivity within the team. Planning for each team becomes more difficult, and it felt like a slog to get everything done.
With a two-week sprint, the team could see the finish line in sight, and there was an energy that could be maintained to complete all sprint goals in a short period. A shorter sprint allowed for more flexibility if unexpected issues arose, I could adjust what tickets need to be removed from the sprint, and how it’d impact deliverables.
Additionally, with a shorter sprint, after each developer finished their main ticket in the sprint, I got the developers to focus on small tech debt tickets towards the tail end of the sprint.
Overall there’s a significant morale boost for the team moving to a two-week sprint, mainly with the sense of accomplishment that comes with being able to finish everything in the sprint.
Conclusion
Through my second stint as a product manager, I have learned several valuable lessons. It is important to keep an open mind, remains fluid and adaptable, and continuously learn and grow as a product manager. I hope that these lessons I have shared will benefit other product managers starting their journey, and ultimately lead to successful product development and improved customer experiences.