I recommend reading a book about consulting, e.g. in McKinsey's style.
Your PM job will be a lot more about influence and communication.
Influence is often about getting people to trust you and get the last 10% done. Prepare to spend 3 months on a very technically-difficult project, then have the CEO rip apart your demo because the copy on the first screen isn't what he expects, without every getting deeper in to the product. That's the last 10% and your job is getting your tired team to care about it.
The way decisions are made will be significantly different compared to the egalitarianism of engineering. Understanding how your organization makes decisions and adapting to it is key to success as a PM. (Consensus? Founder mode? Disagree and commit?)
Good PMs make impact and at the end of the day. Your career is almost entirely dependent on your manager's subjective opinion of your work. You'll need to learn to "manage up" - ensuring that your manager agrees with your decisions and thinks that you have had impact.
The persona that fails in PM is the pseudo-academic who was told they were smart as a kid, and can't hustle, make a decision, or sell others on their ideas. You need to be prepared for conflict.
Might want to reconsider. PMs are not really needed. They exist for dysfunctional teams that cannot manage their workload. (PMs are not Product Owners)
Dusting off some old replies. The TL;DR is: reduce information asymmetry, expose thought processes and align (everyone knows what to do, what not to do, why, and how we got there). People should send in pull requests to your thought processes. They should be able to take decisions based on their model of your thought processes, which you can help them build. Increase leverage and fire yourself every day.
The posts that are more relevant to you:
Remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align:
On taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable:
I recommend reading a book about consulting, e.g. in McKinsey's style.
Your PM job will be a lot more about influence and communication.
Influence is often about getting people to trust you and get the last 10% done. Prepare to spend 3 months on a very technically-difficult project, then have the CEO rip apart your demo because the copy on the first screen isn't what he expects, without every getting deeper in to the product. That's the last 10% and your job is getting your tired team to care about it.
The way decisions are made will be significantly different compared to the egalitarianism of engineering. Understanding how your organization makes decisions and adapting to it is key to success as a PM. (Consensus? Founder mode? Disagree and commit?)
Good PMs make impact and at the end of the day. Your career is almost entirely dependent on your manager's subjective opinion of your work. You'll need to learn to "manage up" - ensuring that your manager agrees with your decisions and thinks that you have had impact.
The persona that fails in PM is the pseudo-academic who was told they were smart as a kid, and can't hustle, make a decision, or sell others on their ideas. You need to be prepared for conflict.
What are you doing to learn how to PM?
I recommend reading The Mom Test.
Might want to reconsider. PMs are not really needed. They exist for dysfunctional teams that cannot manage their workload. (PMs are not Product Owners)
Dusting off some old replies. The TL;DR is: reduce information asymmetry, expose thought processes and align (everyone knows what to do, what not to do, why, and how we got there). People should send in pull requests to your thought processes. They should be able to take decisions based on their model of your thought processes, which you can help them build. Increase leverage and fire yourself every day. The posts that are more relevant to you:
If I disappear, what will happen:
- https://news.ycombinator.com/item?id=25008223
Communication, alignment:
- https://news.ycombinator.com/item?id=24177646
Useful things for the team and product that add leverage:
- https://news.ycombinator.com/item?id=21808439
Communication with the team (link, and subsequent clarification):
- https://news.ycombinator.com/item?id=21598632
- https://news.ycombinator.com/item?id=21614372
Fractal Communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets:
- https://news.ycombinator.com/item?id=26123017
Product development:
- https://news.ycombinator.com/item?id=22827841
Management involvement as a spectrum:
- https://news.ycombinator.com/item?id=22715971
Giving a damn:
- https://news.ycombinator.com/item?id=20356222
Researching topics:
- https://news.ycombinator.com/item?id=25922120
Keeping up with a firehose of information:
- https://news.ycombinator.com/item?id=26147502
Tips to learn from videos:
- https://news.ycombinator.com/item?id=22710623
- https://news.ycombinator.com/item?id=22723586
Remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align:
- https://news.ycombinator.com/item?id=26179539
Less relevant to you, included nonetheless...
Understanding codebases:
- https://news.ycombinator.com/item?id=19924100
Testing pipelines, scaffolding, issue templates:
- https://news.ycombinator.com/item?id=26591067
Making the most out of meetings and leveraging your presence:
- https://news.ycombinator.com/item?id=22873103
Consulting, understanding the problem your "client", who can be your manager, has:
- https://news.ycombinator.com/item?id=24972611
Product, architecture, and impact on the team:
- https://news.ycombinator.com/item?id=24503365
Onboarding new hires to a codebase, what if it were you, improve code:
- https://news.ycombinator.com/item?id=22860716
Reduce information asymmetry, template for taking minutes of meetings to dispatch to the team:
- https://news.ycombinator.com/item?id=21427886
On taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable:
- https://news.ycombinator.com/item?id=24209518
More meeting notes. Reply to a person who had trouble talking in corporate meetings:
- https://news.ycombinator.com/item?id=20323660