Igor Afonov
This essay is a recap of 3 years of product management experience (After 10 years of being software developer). I worked on projects that had direct business impact - fun, stressful, and intense experience. No regrets 😉
I sorted my observations and learnings by their subjective importance.
I started to realize this is important when I was at least one year into product management. If you’re running a team, maintaining team health is an essential part of your job.
In theory, you’ll have an engineering manager who is responsible for that, but in reality, you should be laser focused on it yourself. At the end - even if you have an excellent backlog, full of brilliant ideas - if the team is not feeling well or you don’t have team trust - you won’t be able to execute, and everything will inevitably fall apart.
Do 1-1s with engineers and designers. Make sure that they are happy and motivated. Build trust.
Invest in yourself and learn a few bits about psychology, building relationships with people, and engineering management.
You’re responsible for project outcomes. Listen to your team, your boss, boss of your boss, friends, family, that random person from a coffee shop - be informed and process information, but never forget that you are in charge and you are making decisions.
Be bold, make decisions yourself, and be prepared to carry responsibility.
Democracy and business do not blend.
Management is a 24/7 job. Even if you show up in the office for a few hours, you’ll inevitably think about the project 24/7. It’s exhausting and exhausted people aren’t good at making decisions.
Consider your job a marathon, not a sprint. Don’t work in the evenings. Don’t work on the weekends. Re-charge. Take vacations often. Fully disconnect during vacations/weekends/time off.
This thing applies both to you and your team - it’s ok to be idle. Make sure that team understands that and comfortable with that. If you don’t know what to work on - let the team know. Do not try to keep the team busy. Let people work on whatever they want to work on, take time to learn something new, refactor that annoying piece of tech debt from the past or just rest and re-charge.
Do not work on low priority stuff or 10-year-old bugs to fill the time - in the long run, it’s counterproductive and lowers team morale.
And never say no to vacation requests. Even if they are coming at the worst time. Think long term.
Avoid meetings congestion - skip meetings if you don’t see the value. Find a polite way to skip and avoid meetings that don’t bring value to you or your team. Provide feedback to meeting owners.
1-1s are for everything. 1-1s are the most important and productive meetings. Take as much value from them as you can. Prepare the agenda in advance. Never skip them (it can send the wrong message). Have them scheduled for the same time always. Make them a habit. (I usually schedule them close to each other and block 2-4 hours every week for them)
Write > Talk. Unless it’s bad news or something that could be interpreted wrong (because it will always be).
It is part of - people manager first thing - grow your team, let team members be in charge. Create safety nets, let people make mistakes and be wrong.
A few techniques that worked for me:
Do not put it off for an official “planning meeting” or “backlog grooming.” Planning is a vital part of your job - groom and review your backlog every day - if something changed or you learned something new - adjust immediately.
As a bonus, you’ll recover time by combining staying in planning mode and discussing product future with the team during 1-1s. You’ll be able to drop “official” plannings. These meetings tend to be long and exhausting. Many times they end up in a format where 2 persons argue about a small thing and the rest of the team just listening and thinking about what they could do better with their time.
Data informs everything. Do it yourself (or delegate within your team). Learn SQL and Statistics 101. Do not depend on other teams. Data is your job.
Start every project with data infrastructure. If you can’t measure improvement - there is no improvement.
I always set aside 5-10 minutes between demo and retrospective to do data demo for stakeholders. Walk through metrics and tell what we are going to do next sprint to drive team metrics. I find that it forces me to dig deeper into the data and avoid working on things that do not drive metrics.
Distractions creep into the backlog. Review and purge often. Skip bugs unless they are that bad. Bugs tend to eat 90% of the time in return of 10% improvement.
Focus on one metric and drop anything that doesn’t affect it.
Make it run, make it right, make it fast transfers perfectly to product management.
Release the product as soon as it looks like something usable, and then iterate on the live product. Perfection is the enemy of good.
Constant cadence of iteration helps a lot with meeting deadlines (and predicting misses).
Pick your processes and stick to it.
Adjust by doing retrospectives and carefully listening during 1-1s.
Long meetings are the worst - avoid them at all cost. Always moderate. Ask people to follow-up 1-1. If there is a meeting that needs more than 30 minutes - refactor it by splitting, canceling, changing participants.
Politics and cross-team dynamics are very fluid and company depending.
A few things I learned:
I didn't found anything that stand out as the only source of truth. Hovewer there were a few reads that I enjoyed.
YMMV 😉