After working as an engineer for 10 years, I experimented with my career and worked as a product owner (a fancy title for a product manager) for 3 years. I worked on projects that had direct business impact. It was fun, stressful, and intense. No regrets 😉
I’ve sorted my observations and learnings by their (subjective) importance:
People manager first
This is the thing that I started to realize 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 are in charge
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.
Conserve energy (part 1 - you)
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.
Conserve energy (part 2 - team)
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.
Stay on the maker schedule
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).
Delegate everything (and grow your team)
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:
- One of the team members is a scrum master. This role is not only an accountant or meeting moderator. The scrum master should be able to answer questions during standups and be your ambassador. Invest time in training. Rotate every quarter/year.
- When you’re off by any reason (vacation, sick, etc.) ask one of the team members to assume product owner role instead of you. They should drop engineering/design and pretend that it’s a full-time job. Let this person plan, change backlog, attend all meetings instead of you and be in charge. (Safety net - if you’ll drive in a wrong direction we’ll fix it)
- Team members do demos - let people show off their work in front of the audience. Stakeholders must be present at this meeting. Invest time into training and making sure that people understand what’s the purpose of the demo and how to do it.
- Always ask for input on backlog or roadmap during 1-1s. I don’t see much value in doing it during group meetings because people tend to be more closed and less sincere. 1-1 is a perfect time. If you do it every week, it gets into the habit, and people inevitably think about it before 1-1s.
Always be in the planning mode
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
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.
Pursue the big thing
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.
Get thing out of the door ASAP
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).
The Process
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.
Cross team communication (a.k.a The Politics)
Politics and cross-team dynamics are very fluid and company depending.
A few things I learned:
- “No” is the default answer. (But never say “no” be a polite and diplomatic person). People around are asking for random things that are important to them around your area of ownership. Use it as an input and consider it but do not jump into it or you are risking saturating your backlog with random things and impeding work on The Big Thing.
- Ask for help or advice very carefully. You’re sharing responsibility when asking for help. People will (unconsciously) expect you to follow their advice and become sad if you don't. If you are not going to follow their advice — it’s better to avoid asking.
Reading recommendations
I didn't found anything that stand out as the only source of truth.
Hovewer there were a few reads that I enjoyed.
- 37 Signals - Getting Real ★★★★★
- Michael Lopp - Managing humans ★★★★★
- Michael Lopp - Blog ★★★★★
- Joel Spolsky - Blog ★★★★★
- Paul Gragham - Blog ★★★★
- Ryan Holiday - The Daily Stoic: ★★★★
- Malcolm Gladwell - Blink: The Power of Thinking Without Thinking ★★★★
- Allan Pease - The Definitive Book of Body Language ★★★
- Robert Greene - 48 Laws of Power ★★★
The End
YMMV 😉
Top comments (1)
A very good read, thanks Igor for sharing valuable insights! 👍