There is always more to learn about a product is all I can say. 6 months is definitely not a long time, but just long enough for me to have more reflections to write on here!!!! Let’s get into it.

1. There is always more you do not know, and there is always more to know. A PM can never technically know everything for three reasons in my opinion:

a) Work is very cross-functional: PMs work with so many teams to make decisions, lead, and make a great product. Each team has its specialization and knowledge — they could be technical know-how, knowledge specific to one aspect of the business and so on. The PM oversees projects and is the ‘Jack of all trades’ + the point of contact for a particular project or feature/ the overall roadmap, but not the nitty-gritty of how something is coded. Although you should 200% know all the use cases/ edge cases/ feature behaviours.

b) Nature of work is ‘creating something new’: some work is cyclical and predictable in nature. Although ‘basic PM skills’ (like a general product sense, communication, requirement-writing, finding data and making decisions) can be learned through practice… Each new feature that we create is still brand new, and it could be an area that no one on the team has experience in. We just figure it out together. Creating something completely new is extremely exciting to me and I do think because of this — the PM AND the rest of the team will never “know everything” and will have to figure out as we go.

c) Do we ever know everything???: we’re getting philosophical here, I know that I mentioned some work is more cyclical and predictable in nature, but now upon reflection, those work may require applying the same method to new situations too. Does anyone really every know everything? I do not think so. And if someone does think so, then they either have outgrown their job or a little cocky.

Which leads me to my second point…

1. Never be afraid to ask questions. Because the nature of PMing is so cross-functional, PMs will definitely know the overall big picture. That is not to say we do not need to care at all about the nitty-gritty — we really do. Without asking our subject matter experts or stakeholders questions…

a) PMs cannot make the best decisions: Without clarifying, we may think we know something but that just turns out to be a misinterpretation of what is actually meant. ALWAYS ask questions to clarify or to dig deeper.

b) Subject matter experts or stakeholders may not reflect: this is an interesting one — I have found that asking questions from a broader perspective to a subject matter expert has helped them reflect on their needs and decisions as well. Why are they doing X? Would it be better to have decided on Y?

All in all, communication is always worth it. I find that the best thing I overcame in the past 6 months is stopping worrying I’ll look ‘stupid’ for asking questions when it’s actually almost always been beneficial — either for myself or for the team. I never really regretted asking!

1. You are likely not going to be the expert in one area. However, you do have to be an expert in documenting, organizing, decision-making, influencing, and running meetings. I keep mentioning PMs are very ‘Jack of all trades’ and ‘cross-functional’ and such… Okay, so what is something that PMs really have to be good at then? I’m ranking these in order, from [essentials every PM should know] to [what a good PM would know].

a) Organization and documentation: We have to remember to jot down decisions, what is in-scope/ out-of-scope and why, all the stakeholder needs and wants, timelines… And make sure they are organized so that there is one source of truth to refer to.

b) Good follow-ups: Each team is busy with their own items but the PM will have to pull everyone together to discuss or work on a feature. Not that the team members won’t be on top of it (I’m sure they will be), the PM will just have to really drive that process and ensure all deadlines are met. Thus, good follow-ups with all stakeholders are essential.

c) Influence and negotiation: A personal favourite (or least favourite?) I’d say this is something I am actively working on for myself. PMs work with so many different members on our OWN team with different needs, then also INTERNAL stakeholders with another set of needs, then EXTERNAL stakeholders with yet another set of needs… To balance all those needs and our own needs is extremely hard. Currently still learning day by day how to get to the best outcome. Also learning to look at it not so much as a negotiation, but ‘working together to solve a common problem, to achieve a common goal’.

d) Decision-making: Making a good decision based on data, user feedback, business needs, and ‘product spidey sense’. This definitely comes with time and experience both as a PM and with the particular product one is working on. I’m sure some product-related learning would help a ton as well.

e) Initiative: Like the TTC public announcement… “If you see something, say something.” I think a PM has to always be on the lookout for what needs to be improved or done better. We always have to have our brains on active mode: Why are we doing X? Could Y be done better through a new process? Are we collecting enough user feedback in the right way? It can be easy to fall into the trap of a good working pace and rhythm (it is GREAT) but that comfort can make us forget to reflect. We need to always be thinking about what else can be done outside of our current ‘curriculum’ — to go above and beyond.

There is always more to learn about a product is all I can say. 6 months is definitely not a long time, but just long enough for me to have more reflections to write on here!!!! Let’s get into it.

1. There is always more you do not know, and there is always more to know. A PM can never technically know everything for three reasons in my opinion:

a) Work is very cross-functional: PMs work with so many teams to make decisions, lead, and make a great product. Each team has its specialization and knowledge — they could be technical know-how, knowledge specific to one aspect of the business and so on. The PM oversees projects and is the ‘Jack of all trades’ + the point of contact for a particular project or feature/ the overall roadmap, but not the nitty-gritty of how something is coded. Although you should 200% know all the use cases/ edge cases/ feature behaviours.

b) Nature of work is ‘creating something new’: some work is cyclical and predictable in nature. Although ‘basic PM skills’ (like a general product sense, communication, requirement-writing, finding data and making decisions) can be learned through practice… Each new feature that we create is still brand new, and it could be an area that no one on the team has experience in. We just figure it out together. Creating something completely new is extremely exciting to me and I do think because of this — the PM AND the rest of the team will never “know everything” and will have to figure out as we go.

c) Do we ever know everything???: we’re getting philosophical here, I know that I mentioned some work is more cyclical and predictable in nature, but now upon reflection, those work may require applying the same method to new situations too. Does anyone really every know everything? I do not think so. And if someone does think so, then they either have outgrown their job or a little cocky.

Which leads me to my second point…

1. Never be afraid to ask questions. Because the nature of PMing is so cross-functional, PMs will definitely know the overall big picture. That is not to say we do not need to care at all about the nitty-gritty — we really do. Without asking our subject matter experts or stakeholders questions…

a) PMs cannot make the best decisions: Without clarifying, we may think we know something but that just turns out to be a misinterpretation of what is actually meant. ALWAYS ask questions to clarify or to dig deeper.

b) Subject matter experts or stakeholders may not reflect: this is an interesting one — I have found that asking questions from a broader perspective to a subject matter expert has helped them reflect on their needs and decisions as well. Why are they doing X? Would it be better to have decided on Y?

All in all, communication is always worth it. I find that the best thing I overcame in the past 6 months is stopping worrying I’ll look ‘stupid’ for asking questions when it’s actually almost always been beneficial — either for myself or for the team. I never really regretted asking!

1. You are likely not going to be the expert in one area. However, you do have to be an expert in documenting, organizing, decision-making, influencing, and running meetings. I keep mentioning PMs are very ‘Jack of all trades’ and ‘cross-functional’ and such… Okay, so what is something that PMs really have to be good at then? I’m ranking these in order, from [essentials every PM should know] to [what a good PM would know].

a) Organization and documentation: We have to remember to jot down decisions, what is in-scope/ out-of-scope and why, all the stakeholder needs and wants, timelines… And make sure they are organized so that there is one source of truth to refer to.

b) Good follow-ups: Each team is busy with their own items but the PM will have to pull everyone together to discuss or work on a feature. Not that the team members won’t be on top of it (I’m sure they will be), the PM will just have to really drive that process and ensure all deadlines are met. Thus, good follow-ups with all stakeholders are essential.

c) Influence and negotiation: A personal favourite (or least favourite?) I’d say this is something I am actively working on for myself. PMs work with so many different members on our OWN team with different needs, then also INTERNAL stakeholders with another set of needs, then EXTERNAL stakeholders with yet another set of needs… To balance all those needs and our own needs is extremely hard. Currently still learning day by day how to get to the best outcome. Also learning to look at it not so much as a negotiation, but ‘working together to solve a common problem, to achieve a common goal’.

d) Decision-making: Making a good decision based on data, user feedback, business needs, and ‘product spidey sense’. This definitely comes with time and experience both as a PM and with the particular product one is working on. I’m sure some product-related learning would help a ton as well.

e) Initiative: Like the TTC public announcement… “If you see something, say something.” I think a PM has to always be on the lookout for what needs to be improved or done better. We always have to have our brains on active mode: Why are we doing X? Could Y be done better through a new process? Are we collecting enough user feedback in the right way? It can be easy to fall into the trap of a good working pace and rhythm (it is GREAT) but that comfort can make us forget to reflect. We need to always be thinking about what else can be done outside of our current ‘curriculum’ — to go above and beyond.