I'm starting a new job in a few days as a senior PM at a ~1000 person company, but I've never been a PM before. My career path has been: PhD -> Engineer -> Founder.
My time as a founder has given me some unique perspective on products in my space, but I'm less experienced with the day-to-day of a PM in a medium sized company. My exposure has been second hand watching the PMs while I was an engineer. Any advice on how to help ensure things kick off well?
- meet as many different verticals as possible and understand how they work
- speak with all other senior PMs and tech leads and understand their workflows
You're going to be working with multiple teams and stakeholders and it's crucial you have a mental map of how everyone's workflow is. You also will have an 'outsiders' view for the first 30-90 days as you look at the product with fresh eyes. Use this to drive insights for the product if applicable.
Lastly, don't ever stop customer meetings. It may not be on the agenda for other Senior PMs, but don't let that stop you. Customer meetings will keep your insights fresh and valid.
I'm not saying its the most important thing or specific to the first days. But getting the dynamics early on will benefit you, your project and the people involved.
Also more specific to day one: have fun and be excited :) good luck!
Pausing and engaging on the benefits of a proposal can be incredibly valuable, even if your mind has already raced to the considerations about implementation and opportunity cost. Many engineers understand that there's no higher praise than a leader diving into the weeds on something, but many other stakeholders don't have the same context!
I suggest the opposite: assume good intent from everyone, listen a lot, don’t be afraid to ask dumb questions, identify people who can help your team and identify people who need your help. In leadership, the job is not about you, it’s about setting up your team for success.
The most difficult and political people I know think like this. They never see themselves as the problem. They just think they’re playing defense and playing the meta-game better than others.
If you go into a workplace thinking that your first step is to identify your enemies so you can be on constant high alert to defend yourself, there’s a high risk that you’re going to become the political problem you claim to want to avoid.
What if there are no enemies? What if nobody was denied this role, because it was added headcount to expand the team? Imagine the OP going in on the defense because HN told them to “identify your enemies” as the first step, but really their team just wants to add another person to the group? This type of advice causes more problems than it solves.
It's probably also worth figuring out who holds power and authority. It's not always based on org or chart.
As a founder, you probably already have a lot of the skill set that's needed for that. If you listen to people and apply your intuition, I bet you'll do well.
Sure, understand what the role is generally about, what the expectations are and all that. But I don't think it's a problem that you didn't hold it before, no need to make it one. PMs are in my experience a slightly different job at each company anyway. The most important thing with your background is probably to develop an eye and tactics for the games other PMs and middle managers play.
Talk to your users relentlessly, find out how they use and don't use your product. Get a deep understanding of their workflows and user journeys in the product.
Trim the fat (shift focus) and solve problems they have that the product doesn't solve yet or solve well.
Reduce the steps in their critical user journeys. For example, if it's something they do every day, going from 5 clicks to 3 clicks adds up over time and improves satisfaction.
Dive into metrics and implement quantitative metrics where they don't exist. Survey users for qualitative metrics.
Bring data (metrics, market research, customer quotes etc) to executive meetings to back up your ideas, data speaks louder than your words.
Basically, if your product is in the market you don't need to always guess what to build, your users will guide you. That's not to say you can't innovate too, but a large part of being a PM is bringing the user experience and their frustrations to your team to action.
ps. a cheatsheet for a famous general management-onboarding book The First 90 Days; while it doesn't specifically address your question a lot of it will apply:
Your first few weeks at any company in any role, though, are well spent meeting people and learning the product really well.
I also like to get or sit in on a sales demo and an onboarding call.
Maybe even with very sensible titles like 'Junior Prime Minister'.
Ask the engineering team for a demo.
Ask the founder/execs for a demo.
Ask tech support for a rundown of the most frequent issues.
Each of those will show you what each silo think is important.
I once got shown a customer support tips shared spreadsheet that was more valuable documentation than anything else in the entire company.
https://github.com/sixarm/project-management-guide
This guide doesn't tell you what to do; it give you much of the lingo and a bunch of framework choices that you can use, or perhaps that the existing teammates are already using.
- The First 90 Days: Proven Strategies for Getting Up to Speed Faster and Smarter (https://a.co/d/dRDXQtg)
- Inspired: How to Create Tech Products Customers Love (https://a.co/d/aw73ped)
I’ve also found some good stuff in Lenny Rachitsky’s Podcast/Blog (https://www.lennyrachitsky.com)
As a senior PM, you probably need to pay a lot more attention to your executive stakeholders than a junior PM who might focus instead on lower level cross functional needs, developer focus, design, etc. I would also suggest that after you’re comfortable with your onboarding that you embrace high visibility and even fight for it if anyone discourages you or devalues your communication efforts. Good luck!
Understanding the dynamic (ie. inherent tension) between engineering and product/business is a really important part of a software job no matter what your role is.
I learned a lot of lingo I was unfamiliar with and the broad and comprehensive treatment of the field gave much more confidence. Being forced to deal with all the topics in PM, at least to some degree, was very eye opening for someone like me, whose experience was restricted to only certain aspects of it.
And not the least, it gives you access to people in similar positions in other organizations and industries for exchange and to learn from.
EDIT: If you meant PM as product manager this is probably not for you. I was curious how common PM for product manager is and searched HN for the abbreviation. Most commonly on HN it stands for - surprise, surprise - prime minister.
Even though you have experience in the domain, don't rush in and start trying to change everything, first understand why it is the way it is.
Gain your engineers' trust through active listening, kindness, empathy, and engagement on critical topics. Don't be afraid to say "let me do that for you" in the early days. It's both a learning opportunity and a trust building technique.
Meet every stakeholder and peer you can. Ask them about themselves, the company, and their perspective on the opportunities for your product. Set up regular 1:1s with key stakeholders.
Understand what your teams and your mgmt wants from you. They may conflict. If they do, see if you can figure out a way to address both needs. If you can't, you'll need to figure out a way to manage one group's needs while meeting the other's.
Ask for feedback from the engineers you work with and your peers, especially on your first couple of initiatives but I find it's worth doing all the time. If you don't get any meaningful feedback just assume you've done a good job and keep going.
When you use a product for the first time, write down your feedback as you go through it. Identify what you think is confusing or frustrating, but also what you think it working well. Take screenshots or videos as necessary to further illustrate your perspective. Most of the people who work on the product already have probably internalized these faults and no longer see them the way you will with fresh eyes. Discuss your findings with the team.
You'll want to speak with as many customers/users as possible, but unless you're already an expert in the product, not right away. Gain basic competency in the product, develop a hypothesis about what you think needs to be done, and then go speak to users. You'll quickly find out if you're on the right or wrong path.
One thing I've learned is that many founders actually suck at talking to users in a way that gives them actionable information. If that's you, and perhaps why you're not a founder any more (not saying this is you), then quickly learn how to do interviews well. There are plenty of books and videos on this topic.
Celebrate your team's wins and understand that you are there to help your teams win, not the other way around.
Understand that PMs are judged on outcomes not inputs. No body cares if you worked really hard on something or if you cruised into it. The results will speak for you.
Be prepared to say "no" a lot. That's one of the primary jobs of a PM, but be wary of saying it a lot right away. If you're unsure of something in the early days get council from your team or mgmt.
Your teams want you in the problem space, not the solution space. Unless you have some keen insight on a solution or are part of a solution brainstorming session, don't tread into the engineer's domain. Conversely though, embrace engineers that want to get a deeper understanding of the problem space.
Look for leverage points. That is, look for opportunities with low effort and high impact. I've been able to make seemingly big strides in a product early on just by identifying the right leverage points.
I can keep going but I'll stop for now. I hope this helps you on your journey. Best of luck!
